Продукты Apache ActiveMQ (далее ActiveMQ) и Apache Kafka (далее Kafka) – два популярных брокера сообщений. При этом, они реализованы с использованием различных архитектурных подходов, поэтому имеют разные типовые сферы применения. В основе транспортного слоя нашего ESB-решения «1С:Интеграция КОРП» (сервисная шина предприятия, корпоративная шина данных, КШД) лежит ActiveMQ. И в этой статье расскажем, почему выбор был отдан именно этому решению.
В отличие от системы Kafka, которая оптимизирована под обработку больших потоков данных, публикацию/подписку и хранение – ActiveMQ больше ориентирован на классическую модель очередей и интеграцию через Java Message Service (JMS).
При выборе брокера мы исходили из типовых и регулярно воспроизводимых сценариев именно с точки зрения систем ESB, в которых ActiveMQ предпочтительнее, чем Kafka:
- Традиционная система задач, завязанная на очереди. Если используется приложение, которое обрабатывает очереди заданий, где сообщения должны быть гарантированно доставлены и обработаны один раз (например, заказы на обработку, транзакции) – ActiveMQ отлично подходит благодаря поддержке JMS, транзакций и подтверждений.
- Интеграция с Java-приложениями через JMS. Если проект построен на Java и использует стандарт JMS API – ActiveMQ обеспечивает нативную и удобную работу с сообщениями.
- Сценарии с большим количеством различных протоколов. Если нужно одновременно работать с MQTT, AMQP, STOMP – ActiveMQ позволяет обслуживать разные протоколы на одном брокере.
- Низкая задержка (таймаут) при обмене сообщениями с небольшой или средней нагрузкой и необходимостью сложной маршрутизации, фильтрации и трансформации сообщений.
- Если инфраструктура не требует долговременного хранения сообщений и обработки больших потоков данных – фокус смещен на мгновенную гарантированную доставку и эффективное использование дискового пространства.
- В последнем, но немаловажном пункте нужно отметить – Kafka не поддерживает приоритизацию сообщений «из коробки» (если это нужно, придется предпринять существенные усилия). А для решений класса ESB приоритизация нужна. В частности – в нашем решении она широко используется. И брокер ActiveMQ ее сразу поддерживает, без дополнительных хлопот.
Мы подсветили шесть основных кейсов, в каких случаях ActiveMQ позволяет быстрее и проще реализовать стабильное, управляемое и интегрированное решение для обмена сообщениями. Кроме этого, выбор ActiveMQ вместо Kafka может быть обоснован следующими сильными сторонами ActiveMQ, перечисленными ниже.
- Простота и традиционность моделей очередей: ActiveMQ реализует классическую модель очередей и топиков, что хорошо подходит для традиционных систем с типичной логикой обмена сообщениями (очереди, pub/sub).
- Легкая настройка и использование: ActiveMQ проще развернуть и конфигурировать для небольших и средних проектов, особенно если нужна быстрая интеграция с JMS.
- Полное соответствие JMS: ActiveMQ – один из самых популярных JMS-брокеров, что обеспечивает тесную интеграцию с Java-приложениями и стандартным API.
- Поддержка сложных маршрутов и трансформаций: ActiveMQ предоставляет встроенные механизмы маршрутизации, фильтрации и трансформации сообщений, что упрощает логику обмена сообщений.
- Надежность: ActiveMQ поддерживает гарантированную доставку, транзакции, подтверждения сообщений, а также устойчивость к сбоям.
- Поддержка нескольких протоколов: кроме JMS, поддерживает MQTT, AMQP, STOMP, OpenWire – это облегчает интеграцию различных типов клиентов.
- Хорошо подходит для сценариев с меньшим объемом данных и низкой задержкой, где важна сложная логика маршрутизации сообщений.
* * *
Мы хорошо знаем плюсы и минусы этих двух популярных систем, поэтому при проектировании и реализации системы ESB выбрали именно ActiveMQ. Однако, такой выбор никак не ограничивает сферу применения нашего решения, так как в нем также реализована поддержка брокера Kafka! При этом вы можете как настроить типовые маршруты на использование этого (или даже любого другого) брокера благодаря механизмам их расширения, так и интегрироваться с Kafka в своих собственных специфических маршрутах только для отдельных сценариев интеграции. Зачем в чем-то себя ограничивать, когда можно спроектировать систему так, чтобы взять лучшее из обоих миров — подумали мы и применили этот подход в своем продукте!
