Масштабируемость и высокая доступность автономного приложения Java - PullRequest
4 голосов
/ 18 февраля 2009

В настоящее время мы работаем с приложением интеграции Java на Linux. Сначала обзор приложения.

Приложение Java является автономным приложением (не развернуто на каком-либо сервере приложений Java EE, таком как OracleAS, WebLogic, JBOSS и т. Д.). Под автономностью я подразумеваю, что это НЕ приложение DESKTOP. Однако он запускается из командной строки из основного класса. Пользователь напрямую не взаимодействует с этим приложением. Сообщения сбрасываются в очередь с помощью API, который затем считывается моим приложением, которое работает круглосуточно и без выходных. Я бы не квалифицировал это как настольное приложение, так как пользователь не имеет прямого взаимодействия с ним (не уверен, что это правильное рассуждение, чтобы квалифицироваться как одно).

Он использует Spring и подключается к WebSphere MQ и Oracle Database Мы используем Spring Listener (Spring Message Driven POJO), который прослушивает очередь в WebSphere MQ. Как только в очереди появляется сообщение, приложение считывает сообщение из MQ и сбрасывает (вставляет / обновляет) его в базу данных.

Теперь вопрос:

  1. Как мы можем горизонтально масштабировать это приложение? Я имею в виду просто поставить больше ящиков и запустить несколько экземпляров одного и того же приложения, это жизнеспособный подход?
  2. Должны ли мы рассмотреть переход от Spring MDP к EJB MDB? Тем самым развертывая его на сервере приложений. Есть ли какая-то дополнительная выгода от этого?
  3. Есть запрос сделать приложение доступным (HA)? Каковы предлагаемые методологии или стратегии, которые можно использовать для самостоятельного применения HA?

Ответы [ 6 ]

3 голосов
/ 18 февраля 2009

Другой вариант - Terracotta , платформа, которая делает именно то, что вы хотите; запуск приложения на нескольких компьютерах одновременно и распределение нагрузки между ними.

2 голосов
/ 15 марта 2009
  1. Горизонтальное масштабирование приложения, управляемого сообщениями, очень просто ... в большинстве случаев. Вы, конечно, можете добавить еще один прослушиватель сообщений, работающий в той же очереди. Будьте осторожны, потому что у вас могут быть тонкие зависимости от порядка сообщений. Теперь они могут не быть проблемой, если у вас всего один процессор, но с более чем одним вам гарантировано, что в какой-то момент сообщения будут обработаны «не по порядку».
  2. EJB MDP не предлагают ничего кроме Spring MDB. Придерживайтесь того, что работает.
  3. Горизонтальное масштабирование процессоров - это только начало, но этот вопрос требует более подробного обсуждения.

Для HA вам необходимо уточнить требования. «Высокая доступность» - интересный вопрос для приложения на основе очередей. Если ваше приложение закрывается на несколько минут, сообщения накапливаются в очереди. До тех пор, пока вы можете восстановить и запустить ваше приложение, эти сообщения будут обрабатываться, только с большей задержкой. Вероятно, стоит спросить: «Какова максимальная допустимая задержка для сообщения?»

Вероятно, существует некоторая проблема, связанная с аппаратными сбоями, потерей центра обработки данных и т. Д. Они не будут устранены путем горизонтального масштабирования в том же месте. Вам нужно будет реплицировать все компоненты на каждом уровне: сама очередь, процессоры, серверная база данных и все сетевое оборудование, соединяющее их.

Это дорогое предложение, поэтому стоит также спросить: «Какова разница между годовой ожидаемой потерей времени простоя между сценарием HA и сценарием без HA?» ALE включает в себя как прямые убытки, так и нормативные или юридические издержки, поэтому это хороший способ отразить стоимость простоев.

2 голосов
/ 18 февраля 2009

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

Решения True High Availability очень дороги в реализации. Я также видел различные степени высокой доступности, но по определению это означает абсолютное минимальное время простоя или отсутствие доступа к источнику данных. Для этого требуется большое количество избыточного оборудования, сетей и программного обеспечения, которое может использовать избыточное оборудование без потери возможности доступа к данным в случае сбоя одного из источников данных. Аппаратный сбой неизбежен, это произойдет, а также перебои с питанием и другие случайные природные явления. В зависимости от того, насколько важны эти данные для решения высокой доступности, также потребуется несколько центров обработки данных на нескольких независимых энергосистемах. Очевидно, что это будет очень дорого, поэтому все зависит от того, насколько важны эти данные для конечного пользователя.

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

0 голосов
/ 08 июля 2009

Вы пытались сделать несколько ящиков? Я думаю, вы можете увидеть документ вашего MQ? запуск нескольких блоков может потребовать некоторой конфигурации в вашем MQ, но он будет работать ISA

0 голосов
/ 15 марта 2009

0,1. Создание большего количества слушателей в очереди может увеличить количество потребителей. Когда потребитель умирает, остальные потребители могут продолжать работать. Примечание: ваш MQ и база данных также должны иметь решения высокой доступности.

0,2. Не уверен, что изменит сервер приложений в вашем случае. Возможно, вы могли бы объяснить, какие функции вы собираетесь использовать?

0,3. Смотрите мой ответ на 1. для HA.

0 голосов
/ 18 февраля 2009

Есть ли "standalone" == "desktop"?

Как пользователи взаимодействуют с контроллером, которому принадлежат управляемые сообщениями компоненты?

Мое мнение по вашим вопросам:

  1. Вы можете масштабировать, добавляя больше слушателей сообщений в пул слушателей, поскольку каждый из них работает в своем собственном потоке. Вы должны сопоставить размер пула соединений с базой данных с прослушивателями сообщений, так что это также должно увеличиться. Сделайте это, прежде чем добавлять больше серверов. Убедитесь, что у вас достаточно оперативной памяти.
  2. Я не вижу, что EJB MDB покупает у вас за Spring MDB. Вы продолжаете ссылаться на «серверы приложений». Вы имеете в виду серверы приложений Java EE, такие как WebLogic, WebSphere, JBOSS, Glassfish? Потому что, если вы развертываете Spring на Tomcat, в этом разговоре я буду считать Tomcat «сервером приложений».
  3. HA означает балансировку нагрузки и аварийное переключение. Вам нужно иметь базы данных, которые могут быть либо синхронизированы, либо могут быть развернуты в горячем режиме. То же самое с очередями. F5 - отличное аппаратное решение для балансировки нагрузки. Я бы поговорил с вашими ребятами из инфраструктуры, если у вас есть.
...