Рекомендации по настройке решений JavaEE

Question

Мы создаем 3-уровневые корпоративные решения, которые обычно состоят из нескольких модулей webapp и ejbjar, которые взаимодействуют с БД и имеют несколько внешних точек интеграции.

Каждый модуль обычно нуждается в собственных конфигурациях, которые могут изменяться в течениевремя жизни решения.Развертывание становится кошмаром, потому что теперь у нас есть 18 файлов свойств, которые необходимо запомнить, чтобы скопировать и настроить, а также настроить источники данных, очереди, требования к памяти и т. Д.

Я надеюсь, но не могу надеяться, что это можетбудь лучше.Некоторые варианты, которые мы рассмотрели / использовали, каждый со своими плюсами и минусами:

1. Использование нескольких проектов maven и непрерывной интеграции (например, hudson или jenkins) для создания файла конфигурации, включающего все файлы свойствдля каждой среды (dev, qa, prod), а затем объединить все в EAR.Но тогда все это не может быть легко изменено на производстве при необходимости.
2. Поместите большинство настроек в БД и у вас будет простой экран для их изменения.Внутренне у нас может быть универсальный EJB службы конфигурации, который может читать и изменять значения.Каждый модуль может иметь собственную расширенную версию, в которой есть определенные методы получения и установки.
3. Контроль версий всех файлов свойств, затем проверка его на производстве и внесение его в производственную ветвь после внесения изменений.

С учетом всего этого вам все еще необходимо настроить источники данных, очереди и т. Д. Для конкретного контейнера: (

Answer 1

Я знаю, что на этот вопрос уже дан ответ, и мой ответ не обязательно является общим, но вот мое мнение:

Обратите внимание, что здесь я рассматриваю только свойства системы / ресурса, а не настройки приложения.На мой взгляд, настройки приложения (такие как порог оплаты или другие настройки должны храниться в базе данных, чтобы можно было перенастроить систему без перезапуска службы или вызвать простои путем повторного развертывания или повторного чтения файла свойств).

Для параметров, которые влияют на то, как различные части системы соединяются друг с другом (например, конечные точки веб-службы и т. Д.), Я бы использовал дерево JNDI.

Подключение к базе данных иСоединение JMS будет затем настраиваться с помощью консоли Websphere и может управляться администраторами Websphere.Они также могут быть созданы в виде сценариев JACL, которые при необходимости могут быть включены в управление версиями.

В дополнение к ресурсам JNDI для дополнительных свойств, таких как имена пользователей для вызовов веб-служб в бэкэнд и т. Д., Я бы хотелиспользуйте Websphere "Привязки пространства имен".Эти привязки могут быть отредактированы с помощью консоли Websphere и доступны через JNDI с использованием имени «cell / persistent / mypassword».

Таким образом, я могу создать привязку «mypassword» (строку), и управление для нее упадетадминистратору Websphere (вдали от глаз разработчика или других людей, которые не должны иметь доступа к рабочим системам), в то время как один и тот же файл EAR можно использовать для разработки, тестирования, подготовки и производства (что предпочтительно для разных файлов EAR для разных систем)., поскольку вероятность проникновения других различий уменьшается).

Код Java будет тогда использовать простой поиск JNDI (и, возможно, кэшировать значение в памяти).

Преимущества перед файлами свойств:

• Отсутствует «уязвимый» файл, который необходимо защищать, поскольку системные свойства содержат пароли.
• Нет необходимости добавлять политики безопасности Java, чтобы разрешить доступ к этому расположению файла

Преимущества перед свойствами базы данных:

• Не тМне нужно было связать одну базу данных с сервером приложений.

Надеюсь, это поможет

Answer 2

Я прошел несколько циклов поиска способов сделать это. У меня до сих пор нет определенного ответа.

Последний цикл завершился процессом, основанным на файлах свойств. Идея заключалась в том, что каждый экземпляр сервера был настроен с одним файлом свойств, который настраивал все. Этот файл был прочитан сценариями запуска, настройкой параметров памяти, сервером приложений и самим приложением.

Ключевым моментом было то, что этот файл не управлялся напрямую. Скорее, это был продукт процесса сборки. У нас был ряд файлов для разных целей, которые контролировались версиями, и шаг сборки, который объединял соответствующие. Это позволяет вам выделить общие черты, общие для разных осей.

Например, у нас были среды разработки, непрерывной интеграции, QA, UAT, промежуточные и производственные среды, каждая со своей базой данных. Для серверов в разных средах требовались разные настройки базы данных, но каждый сервер в данной среде использовал одни и те же настройки. Итак, было что-то вроде development-db.properties, qa-db.properties и так далее. В каждой среде у нас было несколько видов серверов - веб-серверы, серверы управления контентом, серверы пакетных процессов и т. Д. Каждый из них имел настройки JVM для размера кучи и т. Д., Которые отличались от других типов серверов, но согласовывались между серверами по всему сред. Итак, у нас было что-то вроде web-jvm.properties, cms-jvm.properties, batch-jvm.properties и так далее. У нас также был способ иметь переопределения для определенных систем - например, production-cms-jvm.properties. У нас также были общие свойства, которые устанавливают общие свойства и разумные значения по умолчанию, которые могут быть переопределены при необходимости.

Наш процесс сборки был немного сложнее, чем просто выбор правильных опций из каждого набора; у нас был мастер-файл для каждого сервера в каждой среде, в котором указывалось, какие другие файлы включать. Мы позволили файлам указывать другие файлы для включения, поэтому мы могли построить график импорта для максимального повторного использования.

Все закончилось довольно сложно. Слишком сложно, я думаю. Но это сработало, и с его помощью было очень легко вносить изменения, влияющие на многие серверы контролируемым образом. Мы даже объединили набор входных файлов из разработки и другой из операций, которые содержали конфиденциальную информацию. Это был очень гибкий подход.

Answer 3

1. Рассмотрим привязку пользовательского объекта конфигурации к JNDI.Затем найдите этот объект в своих приложениях, чтобы настроить их.Преимущества - вы можете использовать пользовательский объект конфигурации вместо довольно общего Map или Properties.
2. . Другой способ - использовать JMX для настройки необходимых приложений.Преимущества - вы можете привязать объекты, которые необходимо настроить, непосредственно к MBean Server, а затем использовать такие хорошо известные инструменты, как jconsole или visualvm, для настройки компонентов вашего приложения.

Оба способаПоддержка динамической реконфигурации ваших приложений во время выполнения.Я бы предпочел использовать JMX.

Answer 4

Используйте несколько проектов Maven и непрерывную интеграцию (например, Hudson или Дженкинс), чтобы построить конфигурационную флягу, которая включает все свойство файлы для каждой среды (dev, qa, prod), а затем связать все как уши. Но тогда вещи не могут быть легко изменены в производстве когда нужно.

Я думаю, что конфиг должен быть в базе данных экземпляра приложения. Конфигурация вашего локального компьютера может отличаться от dev и QA, PROD, DR и т. Д.

То, что вам нужно, это простой способ вывести конфигурацию из базы данных.

Я создаю отдельный проект с предоставленной зависимостью от общей конфигурации Apache У него есть много способов хранения данных, но мне нравятся базы данных, а конфигурации живут в среде баз данных.

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");
        }
    }

Поместите большинство настроек в БД и у вас есть простой экран для изменения Это. Внутренне мы можем иметь универсальный сервис конфигурации EJB, который может читать и изменять значения. Каждый модуль может иметь расширенный пользовательский версия, в которой есть определенные методы получения и установки.

Объединяет конфигурации как простой API, затем вы можете написать GUI по своему желанию. Вы можете сделать интерфейс в любом случае. Или как быстрый выигрыш не имеют интерфейса.

Контроль версий всех файлов свойств и проверка их на производстве. и внесите его в производственную ветку после внесения изменений.

Контроль версий великолепен. Добавьте другую DatabaseConfiguration, используя композицию. Класс, который вы расширяете, является активным, а составной - аудитом. Существует еще один конструктор, может иметь версию. Просто перегрузите нужные методы, чтобы получить желаемый эффект.

    import javax.sql.DataSource;
    import org.apache.commons.configuration.DatabaseConfiguration;

    public class MYConfig extends DatabaseConfiguration {
        final DatabaseConfiguration audit;

        public MYConfig(DataSource datasource) {
            super(datasource, "TABLE_CONFIG", "PROP_KEY", "PROP_VALUE");

            audit = new DatabaseConfiguration("TABLE_CONFIG_AUDIT", "PROP_KEY", "PROP_VALUE");
        }
        @Override
        public void addProperty(String key, Object value) {
            Object wasValue = super.getProperty(key);
            super.addProperty(key, value); 
            audit.put(key,wasValue);//add version code
        }
    }

http://commons.apache.org/proper/commons-configuration/

Answer 5

Интересный альтернативный формат файла конфигурации: написать черту scala.Тогда ваш конфигурационный файл может быть просто файлом scala, который вы компилируете и анализируете при запуске сервера.http://robey.lag.net//2012/03/26/why-config.html

Answer 6

Пользователь простой таблицы базы данных (раздел, ключ, значение). Добавьте «Version», если вам это нужно, и оберните все это в простой класс ConfigurationService с помощью таких методов, как getInt(String section, String key)

Не много работы, и это делает код приложения очень аккуратным и очень легко настраивает конфигурацию.