6 причин, почему «1С:Интеграция КОРП» использует ActiveMQ, а не Kafka

Продукты Apache ActiveMQ (далее ActiveMQ) и Apache Kafka (далее Kafka) – два популярных брокера сообщений. При этом, они реализованы с использованием различных архитектурных подходов, поэтому имеют разные типовые сферы применения. В основе транспортного слоя нашего ESB-решения «1С:Интеграция КОРП» (сервисная шина предприятия, корпоративная шина данных, КШД) лежит ActiveMQ. И в этой статье расскажем, почему выбор был отдан именно этому решению. 

В отличие от системы Kafka, которая оптимизирована под обработку больших потоков данных, публикацию/подписку и хранение – ActiveMQ больше ориентирован на классическую модель очередей и интеграцию через Java Message Service (JMS). 

При выборе брокера мы исходили из типовых и регулярно воспроизводимых сценариев именно с точки зрения систем ESB, в которых ActiveMQ предпочтительнее, чем Kafka:

1. Традиционная система задач, завязанная на очереди. Если используется приложение, которое обрабатывает очереди заданий, где сообщения должны быть гарантированно доставлены и обработаны один раз (например, заказы на обработку, транзакции) – ActiveMQ отлично подходит благодаря поддержке JMS, транзакций и подтверждений.
2. Интеграция с Java-приложениями через JMS. Если проект построен на Java и использует стандарт JMS API – ActiveMQ обеспечивает нативную и удобную работу с сообщениями.
3. Сценарии с большим количеством различных протоколов. Если нужно одновременно работать с MQTT, AMQP, STOMP – ActiveMQ позволяет обслуживать разные протоколы на одном брокере. 
4. Низкая задержка (таймаут) при обмене сообщениями с небольшой или средней нагрузкой и необходимостью сложной маршрутизации, фильтрации и трансформации сообщений. 
5. Если инфраструктура не требует долговременного хранения сообщений и обработки больших потоков данных – фокус смещен на мгновенную гарантированную доставку и эффективное использование дискового пространства. 
6. В последнем, но немаловажном пункте нужно отметить – Kafka не поддерживает приоритизацию сообщений «из коробки» (если это нужно, придется предпринять существенные усилия). А для решений класса ESB приоритизация нужна. В частности – в нашем решении она широко используется. И брокер ActiveMQ ее сразу поддерживает, без дополнительных хлопот.

Мы подсветили шесть основных кейсов, в каких случаях ActiveMQ позволяет быстрее и проще реализовать стабильное, управляемое и интегрированное решение для обмена сообщениями. Кроме этого, выбор ActiveMQ вместо Kafka может быть обоснован следующими сильными сторонами ActiveMQ, перечисленными ниже. 

1. Простота и традиционность моделей очередей: ActiveMQ реализует классическую модель очередей и топиков, что хорошо подходит для традиционных систем с типичной логикой обмена сообщениями (очереди, pub/sub). 
2. Легкая настройка и использование: ActiveMQ проще развернуть и конфигурировать для небольших и средних проектов, особенно если нужна быстрая интеграция с JMS.
3. Полное соответствие JMS: ActiveMQ – один из самых популярных JMS-брокеров, что обеспечивает тесную интеграцию с Java-приложениями и стандартным API. 
4. Поддержка сложных маршрутов и трансформаций: ActiveMQ предоставляет встроенные механизмы маршрутизации, фильтрации и трансформации сообщений, что упрощает логику обмена сообщений.
5. Надежность: ActiveMQ поддерживает гарантированную доставку, транзакции, подтверждения сообщений, а также устойчивость к сбоям. 
6. Поддержка нескольких протоколов: кроме JMS, поддерживает MQTT, AMQP, STOMP, OpenWire – это облегчает интеграцию различных типов клиентов. 
7. Хорошо подходит для сценариев с меньшим объемом данных и низкой задержкой, где важна сложная логика маршрутизации сообщений. 

* * *

Мы хорошо знаем плюсы и минусы этих двух популярных систем, поэтому при проектировании и реализации системы ESB выбрали именно ActiveMQ. Однако, такой выбор никак не ограничивает сферу применения нашего решения, так как в нем также реализована поддержка брокера Kafka! При этом вы можете как настроить типовые маршруты на использование этого (или даже любого другого) брокера благодаря механизмам их расширения, так и интегрироваться с Kafka в своих собственных специфических маршрутах только для отдельных сценариев интеграции. Зачем в чем-то себя ограничивать, когда можно спроектировать систему так, чтобы взять лучшее из обоих миров — подумали мы и применили этот подход в своем продукте!