Кластеризация приложения Java EE без сохранения состояния с помощью Glassfish в Amazon AWS

Question

Каков наилучший способ развертывания приложения Java EE 6 без сохранения состояния в распределенной среде для обеспечения высокой доступности и масштабируемости? Моя заявка не имеет статуса. Поэтому мне не нужно реплицировать какое-либо состояние сеанса (HTTP-сеанс, EJB-компоненты с состоянием и т. Д.)

В частности, я хотел бы знать следующее:

• Нужны ли мне возможности кластеризации Glassfish 3.1 (учитывая, что мне не нужно реплицировать состояние сеанса)?
• Я активно использую очереди JMS и управляемые сообщениями bean-компоненты. Как настроить JMS, чтобы она работала в кластерной среде?
• Я также использую службу таймера EJB. Как это работает в кластерной среде? Есть ли что-то, что мне нужно сделать, кроме использования общей базы данных для хранения таймеров (а не встроенной базы данных Derby)?

Я планирую использовать Amazon AWS (RDS с многоадресным развертыванием, эластичное распределение нагрузки, EC2).

Answer 1

Я нахожусь в подобной ситуации, и в настоящее время я обнаруживаю, что кластеризация GF может / не может сделать для меня.

Re 1) Нужны ли мне возможности кластеризации Glassfish 3.1 * 1004?*

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

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

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

Re 2) ... Как настроить JMS, чтобы она работала в кластерной среде?

Не уверен, что я понимаю ваш вопрос ... Если вы хотите иметь брокера сообщений с высокой доступностью за пределами GF, вам необходимо соответствующим образом настроить его и управлять им самостоятельно.Например, ActiveMQ имеет несколько способов настройки кластеризации / HA / горизонтального масштабирования.Если вы используете OpenMQ, предоставляемый GF, настройка GF-кластера также предоставляет кластеризованный брокер сообщений.Из коробки.

Но кластеризация брокеров - это тема сама по себе, и ее нельзя недооценивать.Возможно, вам придется подумать о постоянстве и общем хранилище сообщений и тому подобном - независимо от использования внешнего брокера или кластера, предоставленного GF.

Если JMS является такой неотъемлемой частью вашего приложения, я 'буду рекомендовать соответствующее внимание брокеру.Я бы, вероятно, не использовал GF-брокера, а имел бы отдельный брокер-кластер (разделение задач; например, вы можете обновить GF / брокера независимо друг от друга).

Re 3) EJBСлужба таймера ... Что мне нужно сделать, кроме использования общей базы данных для хранения таймеров?

Если вам требуется, чтобы таймеры автоматически запускались только один раз в вашей группе (appserver-) экземпляров, яПолагаю, вам нужно нужна кластеризация GF (плюс, конечно, общая БД).Иначе я не вижу, как каждый экземпляр должен знать, должен ли он срабатывать или нет.Однако это легко проверить ...

tl; dr

• Использование кластеризации GF для экономии на работе администратора
• Использование внешнегохорошо понятный высокодоступный брокер сообщений
• Использование общей базы данных для таймеров EJB

Answer 2

Моя точка зрения на ваши вопросы:

1) Репликация сеанса является частью управления кластером, а не целью создания кластерной серверной среды.Преимущества кластеризации, которые вы получаете:

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

2) Вы можете использовать Apache ActiveMQс вашим сервером Glassfish, чтобы ваша JMS работала в кластерной среде.

3) Я думаю, что общей базы данных должно быть достаточно

Answer 3

Вам, вероятно, понадобится среда EJB промышленного класса, если вы действительно хотите, чтобы ваше приложение работало гладко ... Однако вы определенно не ограничены только Glassfish. Важно помнить, что EJB - это спецификация, которая не обязательно ограничена какой-либо одной реализацией!

1) Нужны ли мне возможности кластеризации Glassfish 3.1 (учитывая, что мне не нужно реплицировать состояние сеанса)?

НЕТ, вы определенно не делаете. Если ваше приложение не имеет состояния, Glassfish не понадобится.

2) Я активно использую очереди JMS и управляемые сообщениями бины. Как настроить JMS, чтобы она работала в кластерной среде?

Здесь можно выбрать JBoss. I Службы кластеризации JBOSS просто переизбирают новые главные узлы для управления обменом сообщениями, если он выходит из строя, поэтому доступность гарантируется.

3) Я также использую службу таймера EJB. Как это работает в кластерной среде? Есть ли что-нибудь, что мне нужно сделать, кроме использования общая БД для хранения таймеров (а не встроенная БД Derby)?

Синхронизация может быть прозрачно сгруппирована, если вы используете либо weblogic, либо реализации Jboss ejb. В этом случае, я не думаю, что вам нужна встроенная база данных: фреймворки могут обрабатывать это напрямую: http://community.jboss.org/wiki/DeployingEJB3TimersInCluster.