Apache Camel — это популярная, зрелая, интегрированная библиотека с открытым исходным кодом. Он реализует шаблоны интеграции предприятия, представляющие собой набор шаблонов, которые часто встречаются при интеграции распределенных систем. В прошлом я много писал о Camel, в том числе о том, почему он мне нравится больше, чем Spring Integration , как работает механизм маршрутизации , как использовать селекторы JMS с AWS SQS и многое другое .
Camel также реализует 197 коннекторов / адаптеров для общения с внешними системами (перейдите в исходный код, каталог компонентов / и запустите это: ls -lp components / | grep / | wc -l), у github гораздо больше , и вы можете написать Ваш собственный довольно тривиально. Это дает Camel гораздо более широкий диапазон возможностей подключения, чем любая другая библиотека интеграции.
В последнее время мне повезло, что я смог помочь одному из ведущих интернет-магазинов с именем Camel. Они принимают онлайн-заказы и обрабатывают их, используя управляемую событиями архитектуру, которая включает в себя публикацию таких событий, как «order_received», «order_cancelled», «order_ready_to_ship» и другие. Эти события обрабатываются микросервисами, заинтересованными в участии в потоках обработки заказов, и довольно слабо связаны из-за наличия EDA.
Характер данного вида розничного бизнеса очень сезонный. И есть времена в течение года (праздники и т. Д.), Которые имеют тенденцию увеличивать нагрузку на порядки. Таким образом, возможность масштабирования без перебоев для удовлетворения этих сезонных пиков имеет первостепенное значение.
К счастью, поскольку они умные, они используют Apache Camel для своей интеграции и, в частности, для реализации некоторых из этих сервисов. Каждый заказ генерирует довольно много событий, и они должны быть обработаны своевременно и не отставать от остальной нагрузки. Службой очередей для этого был Amazon SQS, и для этого у Camel есть компонент AWS SQS .
Для номинальной нагрузки Camel обрабатывал эти события просто отлично. Но когда очередь стала глубже, у Верблюда возникли некоторые проблемы. Мы получали только 200 сообщений в минуту, что не проходит тест на запах. Углубившись немного глубже, мы обнаружили, что библиотеки AWS позволяют масштабировать по вертикали, увеличивая количество соединений и путем пакетной доставки сообщений (максимум 10 пакетных сообщений). Пакетная обработка помогает, и Camel был реализован, чтобы справиться с пакетной обработкой, но это все еще не было достаточно быстро, только около 10K сообщений в час.
При дальнейшем копании мы могли видеть, что только один поток обрабатывает опрос очереди сообщений. Поэтому вместо обработки сообщений, встроенных в поток, который опрашивает очередь, мы решили использовать очередь SEDA, чтобы мы могли извлекать сообщения из SQS и быстро создавать дамп в очереди в памяти, чтобы мы могли начать следующий опрос, что-то вроде этого :
from("amazon-sqs://order.queue").to("seda:incomingOrders");
from("seda:incomingOrders").process(do our processing in another thread...);
Это позволило нам справиться с нагрузкой, используя шаблон Staged Event Driven Architecture . Это изменение дало нам еще один прирост производительности — около 40 тыс. Сообщений в час, но мы говорим об очень популярном коммерческом сайте, поэтому масштабирования все еще недостаточно для удовлетворения потребностей системы в пиковые периоды.
Итак, мы взглянули еще раз и удивились, почему мы не можем одновременно опросить несколько потоков / соединений? Библиотеки AWS были созданы с учетом этого, но не было способа настроить Camel, чтобы сделать это для этого конкретного типа конечной точки. Camel может сделать это для других конечных точек (JMS, SEDA и т. Д.), Но нам нужно было внести небольшое небольшое изменение в Camel SQS для этого.
И вот в чем прелесть использования философии разработки с открытым исходным кодом, в стиле сообщества: код открыт, сообщество приветствует изменения, и теперь будущие пользователи Camel и его функциональные возможности могут воспользоваться преимуществами этого сотрудничества.
Таким образом , мы совершили патч , который позволяет установить concurrentConsumers вариант на SQS очереди , которая будет наращиваться количество потоков , используемых для подключения и опроса очереди. Что-то вроде этого:
from("amazon-sqs://order.queue?concurrentConsumers=50").to(.... processing here....)
Смотрите документацию на Camel-sqs для получения дополнительной информации . Это изменение будет частью релиза Apache Camel 2.15.0, который должен выйти в ближайшие пару недель.
С помощью этого параметра мы смогли обработать всю нагрузку, которую Черная пятница и Кибер понедельник могли выбросить на сайт, в один момент обрабатывая> 1,5 миллиона сообщений в час.
Спасибо Open Source!
Чтобы узнать больше о Camel , ActiveMQ , микросервисах и облачных сервисах, подпишитесь на меня в Twitter @christianposta и на мой блог http://christianposta.com/blog