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

Question

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

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

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

from (" activemq: inboundQueue? MaxConcurrentConsumers = 50 ") .process (decode ()) .process (transform ()) .process (validate ()) .process (saveToDatabase ()) .to ("activemq: topic: ouboundTopic");

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

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

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

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

Если кто-нибудь сможет уточнить для меня компромиссы ... Я быценить это.

Answer 1

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

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

• Увеличение количества экземпляров ActiveMQ. Запуская дополнительные экземпляры ActiveMQ и объединяя их в сеть, вы создаете сеть брокеров.В некоторых кругах это называется распределенными очередями, поскольку данная очередь может быть доступна для всех посредников в сети.Но если вы собираетесь запустить несколько экземпляров ActiveMQ, вам следует просто подумать о запуске дополнительных экземпляров ServiceMix.

• Увеличение количества экземпляров ServiceMix - каждый экземпляр ServiceMix встраивает экземпляр ActiveMQ.Увеличивая количество экземпляров ServiceMix, вы не только увеличиваете количество экземпляров ActiveMQ (которые могут быть объединены в сеть для формирования сети брокеров), но и получаете возможность развертывать больше копий своего приложения в этих экземплярах ServiceMix.,Если вам нужно увеличить количество экземпляров ActiveMQ или ServiceMix, вы можете развернуть приложение-потребитель с соответствующим количеством одновременных потребителей для каждого экземпляра.Сообщения не разбиваются и не дублируются, они рассылаются по кругу всем потребителям в очереди, независимо от того, где они находятся, в зависимости от потребительского спроса.То есть, если у одного экземпляра ActiveMQ в сети нет потребителей, у него не будет сообщений в своем экземпляре очереди для использования.Это приводит к моему последнему предложению, увеличивая число потребителей, опрашивающих входящую очередь.

• Увеличение числа потребителей JMS во входящей очереди - это, вероятно, самый простой, мощный и наиболее управляемый способ увеличения пропускной способности.Это проще всего, потому что вы развертываете дополнительные экземпляры вашего потребляющего приложения, чтобы они конкурировали за сообщения из входящей очереди (независимо от того, конкурируют ли они за локальную очередь или очередь, которая распределена через сеть брокеров).Это может быть так же просто, как увеличение числа одновременно работающих потребителей, или чуть более сложным путем разделения части приложения, содержащей потребителей, и развертывания его во многих экземплярах ServiceMix.Он самый мощный, потому что обычно он не сложный, а масштабирование событийно-ориентированных приложений всегда осуществляется путем увеличения числа потребителей.Это наиболее управляемо, потому что у вас есть возможность изменить способ упаковки ваших приложений таким образом, чтобы приложение-потребитель было полностью отдельным, предоставляя ему возможность распространяться.

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

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

Брюс