Apache Camel с кластеризацией ActiveMQ

Я пытаюсь определить свои варианты кластеризации моего приложения ServiceMix 3.3.1/Camel 2.1/AMQ 5.3. Я выполняю обработку больших объемов сообщений, и мне нужно кластер для высокой доступности и масштабирования по горизонтали.

Вот в основном то, что делает мое приложение... HTTP- > QUEUE- > PROCESS- > DATABASE- > ТЕМА

from ( "jetty: http://0.0.0.0/inbound" ) .to( "ActiveMQ: inboundQueue" );

из ( "ActiveMQ: inboundQueue maxConcurrentConsumers = 50" ) .process(декодирования()) .process(преобразование()) .process(проверить()) .process(saveToDatabase()) .то ( "ActiveMQ: тема: ouboundTopic" );

Итак, я прочитал все страницы кластеризации ServiceMix и AcitveMQ, но до сих пор не знаю, куда идти.

Я знаю, что могу использовать настройку Master/Slave для HA, но это не помогает масштабируемости.

Я читал о сети брокеров, но не знаю, как это относится. Например, если я развертываю одинаковые маршруты верблюдов на нескольких узлах в кластере, как они будут "взаимодействовать" точно? Если я укажу свой HTTP-производитель на один node (NodeA), какие сообщения будут отправляться в NodeB? Будут ли разделяться очереди/темы между node A/B... если да, то как, сообщения расщепляются или дублируются? Кроме того, как бы внешний клиент подписался на мой "outboundTopic" точно (и получить все сообщения и т.д.)?

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

Если кто-то может прояснить компромиссы для меня... Я был бы признателен.

Ответ 1

Существует несколько стратегий масштабирования, когда вы используете ServiceMix/Camel/ActiveMQ. Поскольку каждая часть программного обеспечения предлагает так много опций, существует множество путей, которые вы можете использовать в зависимости от того, какая часть приложения должна масштабироваться. Ниже приведен список высокого уровня из нескольких стратегий:

Увеличьте количество входящих входящих экземпляров Jetty - для этого требуется запустить больше экземпляров веб-сервера и запросить балансировку нагрузки по нескольким экземплярам или выставить несколько URL-адресов и отправить все запросы в ту же входящую очередь в ActiveMQ.
Увеличьте количество экземпляров ActiveMQ. Запустив дополнительные экземпляры ActiveMQ и объединив их вместе, вы создаете сеть брокеров. В некоторых кругах это относится к распределенным очередям, потому что данная очередь может быть доступна для всех брокеров в сети. Но если вы собираетесь запускать несколько экземпляров ActiveMQ, вы должны просто рассмотреть возможность запуска дополнительных экземпляров ServiceMix.
Увеличьте количество экземпляров ServiceMix. Каждый экземпляр ServiceMix включает экземпляр ActiveMQ. Увеличивая количество экземпляров ServiceMix, вы не только увеличиваете число экземпляров ActiveMQ (которые могут быть объединены в сеть вместе с целью создания сети брокеров), но затем у вас есть возможность развернуть больше копий вашего приложения через эти экземпляры ServiceMix, Если вам нужно увеличить количество экземпляров ActiveMQ или ServiceMix, вы можете развернуть приложение-потребитель с соответствующим количеством одновременных потребителей для каждого экземпляра. Сообщения не становятся разделенными или дублированными, они распределяются круговым способом всем потребителям в очереди, независимо от того, где они расположены, исходя из потребительского спроса. Если один экземпляр ActiveMQ в сети не имеет потребителей, он не будет иметь никаких сообщений об этом экземпляре очереди, которая будет потребляться. Это приводит к моему последнему предложению, увеличивая количество потребителей, опросивших входящую очередь.
Увеличьте количество пользователей JMS во входящей очереди. Это, вероятно, самый простой, самый мощный и наиболее управляемый способ увеличить пропускную способность. Это проще всего, потому что вы развертываете дополнительные экземпляры вашего приложения-потребителя, чтобы конкурировать за сообщения из входящей очереди (независимо от того, конкурируют ли они за локальную очередь или очередь, которая распространяется через сеть брокеров). Это может быть так же просто, как увеличение количества одновременных потребителей или более активное участие, разделяя часть приложения, содержащего потребителей, и развертывая его во многих экземплярах ServiceMix. Он является самым мощным, потому что обычно это не сложно, а масштабирование приложений, управляемых событиями, всегда осуществляется за счет увеличения числа потребителей. Это наиболее управляемо, потому что у вас есть возможность изменить способ упаковки ваших приложений, чтобы потребляющее приложение было полностью разделено, давая ему возможность распределяться.

Это последнее предложение является самым мощным способом масштабирования вашего приложения. Пока входящая конечная точка HTTP может обрабатывать большой объем трафика, вам может потребоваться только увеличить количество пользователей во входящей очереди. Большая причина для этого заключается в том, что либо потребители, либо bean, с которыми они передают, делают весь тяжелый подъем, основной объем обработки и проверки. Обычно это процесс, который в конечном итоге нуждается в большинстве ресурсов.

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

Брюс