J2EE Cluster: есть ли общий способ обработки центральной конфигурации? - PullRequest
3 голосов
/ 03 декабря 2010

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

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

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

Спасибо.

Ответы [ 3 ]

0 голосов
/ 03 декабря 2010

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

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

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

0 голосов
/ 03 декабря 2010

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

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

Работает у нас довольно гладко.

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

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

0 голосов
/ 03 декабря 2010

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

...