Масштабируемость и высокая доступность автономного приложения Java

Question

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

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

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

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

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

Answer 1

Означает ли «автономный» == «рабочий стол»?

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

.3.Смотри мой ответ на 1.для ХА.

Answer 6

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