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

Question

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

Здесь в основном то, что делает мое приложение ... http-> queue-> process-> database-> topic

от ("Причала:http://0.0.0.0/inbound") .to (" ActiveMq: Inboundqueue ");

от ("ActiveMQ: InboundQueue? MaxConcurrentConsumers = 50") .process (decode ()) .process (transform ()) .process (validate ()) .process (savetodatabase ()) .to ("Activemq: тема: Outboundtopic" );

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Брюс