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

Question

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

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

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

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

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

Answer 1

Есть ли «автономный» == «рабочий стол»?

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

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

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

.3. См. Мой ответ на 1. для HA.

Answer 6

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