J2EE Cluster: Существует ли общий способ обработки центральной конфигурации?

Question

Мы разрабатываем приложение, которое обычно развертывается на одном веб-сервере. Теперь мы проверяем, как он работает в кластерной среде, поскольку некоторые клиенты используют кластеры.

Проблема заключается в создании локальной конфигурации (в реестре/файле), которая не имеет никакого смысла в кластере. Конфигурация изменяется приложением. Есть ли общий способ (например, интерфейс) для создания центральной конфигурации, поэтому сам config (-file) не дублируется на каждом узле при развертывании приложения в кластере? Любые другие рекомендуемые варианты? (делать это вручную с помощью конфигурации на сетевом ресурсе/в базе данных/некоторых MBean?)

почему generic? Он должен работать на разных серверах приложений (например, tomcat, jboss, Webspere, weblogic ...), поэтому мы не можем использовать определенную специфику для сервера.

Спасибо.

Answer 1

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

Мы делаем это для некоторых наших приложений. Общие библиотеки и/или файлы свойств, которые нам интересны (в нашем случае). Мы настраиваем либо JVM parms, либо переменные среды JNDI (пытаемся перейти к ним), чтобы мы могли искать путь к смонтированному диску во время выполнения и загружать данные из файлов.

Работы довольно пятно для нас.

Теперь, если вы пишете информацию, это совсем другая история. Как и тогда, вам нужно беспокоиться о том, как вы используете свой кластер (насколько он доступен только для загрузки?). Приложение работает в обоих кластерах, как если бы это было одно приложение? Или он работает независимо на каждом узле кластера? Если это так, тогда вам, возможно, придется беспокоиться о параллельной записи. Вероятно, лучше пойти с базой данных или одним из других решений, как упомянуто выше.

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

Answer 2

Вы можете использовать библиотеку, например Commons Configuration, и выбрать реализацию, удобную для кластеров, такую ​​как JDBC или JNDI.

Answer 3

Сначала я бы рассмотрел JDBC и JDNI, однако если вы хотите, чтобы ваши серверы могли работать независимо, я бы предложил систему распределения файлов, такую ​​как subversion/git/mercurial, т.е. если ваши центральные серверы конфигурации недоступны или недоступны, вы не хотят прекращения производства.

версии управляемой системы обеспечивает историю о том, кто сделал то, что изменения, когда и контролируемые выбросы (и откатом выпусков)

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