Брокеры сообщений появились в ответ на растущую сложность и взаимозависимость систем в ИТ-ландшафте. Они позволяют компонентам взаимодействовать, используя сообщения, передаваемые через промежуточный слой. Это повышает гибкость, масштабируемость и надежность инфраструктуры. Появление промежуточного программного обеспечения для обмена сообщениями сыграло важную роль в развитии многих систем корпоративного уровня, позволив им адаптироваться к меняющимся потребностям бизнеса без масштабных усилий по реинжинирингу.
В этой статье сравниваются два популярных брокера: Apache ActiveMQ и Apache Kafka, исследуются их различия, сходства и варианты применения. Для компаний, у которых есть ограничения на использование open source, а также дополнительные требования по безопасности, работе с высокими нагрузками и вендорской поддержке, приводится сравнение коммерческих продуктов Platform V Synapse Messaging и Platform V Corax с ванильными версиями.
Обзор Apache ActiveMQ
Apache ActiveMQ — это многопротокольный брокер сообщений на основе Java, который реализует Java Message Service (JMS). Первоначально он был разработан LogicBlaze, а позже передан в дар Apache Software Foundation. ActiveMQ — популярный выбор для интеграции различных приложений и обеспечения гибкой связи между различными компонентами.
ActiveMQ выпускается в двух вариантах: классическая версия и более новый брокер следующего поколения под названием ActiveMQ Artemis, в котором улучшены производительность и масштабируемость благодаря полностью асинхронной архитектуре. Кроме того, Artemis дает возможность хранить данные в журнале, что эффективнее, чем переносить данные в стороннюю базу. Записи добавляются в конец журнала. Так операции произвольного доступа, обычно самые медленные на диске, сводятся к минимуму.
ActiveMQ поддерживает различные протоколы обмена сообщениями:
- OpenWire (собственный протокол ActiveMQ)
- AMQP
- MQTT
- STOMP
- Core
- XMPP (поддерживается только ActiveMQ Classic)
- WSIF (поддерживается только ActiveMQ Classic)
- RSS и Atom (поддерживаются только ActiveMQ Classic)
ActiveMQ поддерживает кластеризацию для распределения нагрузки по обработке сообщений между несколькими брокерами. Кластеризация также обеспечивает высокую доступность и отказоустойчивость.
ActiveMQ использует подход «сложный брокер, простой потребитель». Это означает, что брокер ActiveMQ отвечает за маршрутизацию сообщений соответствующим потребителям, поддержание состояния потребителей, отслеживание того, какие сообщения были использованы, и обработку повторной доставки при необходимости.
Модель ActiveMQ «сложный брокер, простой потребитель» упрощает разработку клиентских приложений, но оказывает большее давление на брокер, поскольку он должен управлять различными аспектами обмена сообщениями. Как мы обсудим далее в статье, Kafka использует противоположный подход: «простой брокер, сложный потребитель».
Обзор Apache Kafka
В то время как ActiveMQ является традиционным брокером сообщений, функциональность Apache Kafka больше ориентирована на обработку высокоскоростных, объемных и отказоустойчивых потоков данных. Первоначально он был разработан в LinkedIn, а позже передан в дар Apache Software Foundation. Как платформа потоковой передачи событий, Kafka является популярным выбором для построения конвейеров данных в реальном времени.
В отличие от ActiveMQ, Kafka не предлагает многопротокольных возможностей для публикации и использования сообщений. Вместо этого Kafka использует двоичный протокол поверх TCP, который определяет все API как пары сообщений запрос-ответ.
В отличие от подхода ActiveMQ «сложный брокер, простой потребитель», Kafka использует модель «простой брокер, сложный потребитель». Каждый потребитель самостоятельно контролирует скорость, с которой он считывает сообщения, и отслеживает последнее прочитанное (смещенное) сообщение в памяти. Для надежности и гарантии того, что после перезапусков или сбоев пользователь сможет продолжить с того места, где остановился, смещение должно находиться в постоянном хранилище, а не во временной памяти. Вот почему потребители периодически фиксируют свои смещения для долговременного хранения во внутреннем разделе Kafka.
Подход Kafka «простой брокер, сложный потребитель» усложняет разработку и управление потребителями. Однако здесь есть и преимущества:
- Улучшенная масштабируемость. За счет передачи большей части логики отслеживания и обработки пользователю брокер остается легковесным и способным обрабатывать больший объем сообщений.
- Параллельная обработка. Разные потребители могут одновременно считывать разные части журнала сообщений. Это позволяет выполнять параллельную обработку сообщений, обеспечивая более эффективное использование ресурсов.
- Низкая задержка. Поскольку на уровне брокера требуется меньше обработки, сообщения могут доставляться потребителям с потенциально меньшей задержкой.
Сравнение систем для использования в интеграционных сервисах
В современных реалиях часто в рамках проектирования интеграционных взаимодействий с использованием брокеров сообщений архитекторы опираются на принцип «мы это лучше знаем и умеем с этим работать», игнорируя тот факт, что брокеры очередей работают по-разному и имеют разные преимущества и недостатки. Разберем нюансы организации интеграций на примере Kafka и ActiveMQ Artemis.
Kafka является «простым брокером», т. е. осуществляет исключительно функцию передачи данных и служебные для этой функции активности. В зоне ответственности брокера получение, отдача и организация хранения данных тех партиций, в которых он является лидером (leader) или ведомым (follower), авторизация клиентов, получение и раздача метаданных подключенным клиентам. По большому счету это все, что делает брокер для клиента, для остального есть отдельные продукты.
Узел ActiveMQ Artemis, в дополнение к функции передачи, может осуществлять функции трансформации протоколов, функцию маршрутизации на основе серверных фильтров (server-side filtering), обогащать сообщение дополнительными заголовками и т. д. Получается, что потенциально брокер может нести в себе часть логики интеграционного слоя.
Рассмотрим разницу в подходах к организации хранения данных. Основное отличие в том, что Apache Kafka при вычитывании не удаляет сообщение, а двигает «указатель» по отдельно взятой группе читателей. Само удаление происходит позже в соответствии с политиками устаревания. А вот Artemis поступает по-другому: после вычитывания данные удаляются из очереди. Отсюда появляются нюансы работы брокера, оптимизированного на публикацию и подписку (pub/sub). Он хорошо подходит для распространения больших объемов информации в шаблоне «один ко многим», тогда как традиционные менеджеры очередей для этого менее приспособлены: сделать можно, так как Artemis поддерживает такой паттерн, но будет происходить копирование сообщений.
Следующий аспект, в котором есть существенные различия, — это сохранение последовательности. Kafka гарантирует сохранение последовательности только в рамках одного ключа (все сообщения с равными ключами попадают в одну партицию, где последовательность гарантирована), но для всех потребителей. В отличие от этого, Artemis как менеджер очередей обеспечивает последовательность сообщений в рамках очереди, независимо от их содержимого. При этом сообщение получает только первый обратившийся потребитель, а остальные его не получают.
Есть также различия в обеспечении высокой доступности. Если брать атомарный кластер Kafka, то для обеспечения высокой доступности он растягивается между зонами доступности. При этом значение пинга между ними не должно превышать пары десятков миллисекунд, иначе конструкция будет работать плохо. А вот ActiveMQ Artemis не столь требователен в данном случае, можно сделать кластер и на более удаленных зонах. Kafka в случае растянутого кластера потребует подключения клиента к брокерам, находящимся в другой зоне, а Artemis сможет сам отреплицировать сообщение.
| ActiveMQ Artemis | Kafka | |
| Структура данных | Очереди (от точки к точке) и темы (обмен сообщениями в паблике/ подзаголовке) | Темы (общие/ вспомогательные сообщения) |
| Удаление сообщений | Сразу после прочтения | Определяется политиками устаревания |
| Обеспечение высокой доступности | Менее требователен к растягиванию между зонами, сам реплицирует сообщение | Более требователен к растягиванию между зонами, требует подключение к брокерам, находящимся в другой зоне |
| Хранение сообщений | Короткое время — удаляется после первого прочтения | Хранение управляется настройками |
| Протокол обмена сообщениями | Различные протоколы обмена сообщениями: OpenWire, AMQP, MQTT, STOMP, Core, XMPP, WSIF, RSS и Atom | Двоичный протокол поверх TCP |
| Отказоустойчивость | Поддерживает группы оперативного резервного копирования. | Реплицирует данные на нескольких узлах для обеспечения отказоустойчивости.Можно реплицировать данные между разными кластерами, которые могут находиться в разных центрах обработки данных или даже регионах |
| Производительность | Хорошая пропускная способность и низкая задержка (при средних рабочих нагрузках) | Рабочие нагрузки с высокой пропускной способностью (миллионы сообщений в секунду) при чрезвычайно низких задержках (в диапазоне миллисекунд) |
| Сохранение последовательности | Обеспечивает последовательность сообщений в рамках очереди, независимо от данных в них | Сохранение последовательности только в рамках одного ключа (все сообщения с равными ключами попадают в одну партицию, где последовательность гарантирована) |
| Коммерческая поддержка | Не осуществляется, можно прибрести Platform V Synapse Messaging | Не осуществляется, можно прибрести Platform V Corax |
Сценарии интеграции
Рассмотрим типовые шаблоны интеграции и отнесем их к более подходящему брокеру.
- Синхронный запрос-ответ через брокер сообщений.
Несмотря на то, что в данном случае брокер сообщений — лишнее звено, такой тип интеграции существует в промышленных ландшафтах. При данном шаблоне взаимодействия ПО, отправляющее запрос, блокирует поток выполнения до получения ответа на свой запрос. Этот тип интеграции более правильно отнести к MQ-брокеру. В ActiveMQ Artemis не придется хранить каждое сообщение до истечения политики хранения, работа с селекторами на клиентской стороне позволит выбирать только данные, относящиеся к конкретной транзакции, а механизмы серверной фильтрации могут помочь в использовании одного адреса для всех модулей в рамках автоматизированной системы. - Асинхронный запрос-ответ через брокер сообщений.
При данном шаблоне взаимодействия ПО, отправляющее запрос, не блокирует поток выполнения, а ответы обрабатываются по мере поступления. Этот тип интеграции снова более правильно отнести к MQ-брокеру по тем же критериям, что и п. 1. - Публикация сообщений для вычитки кем-то когда-то.
При таком шаблоне взаимодействия поставщик данных ничего не знает о потребителях, их количестве и о том, существуют ли они в принципе. И более правильным в этом случае будет являться использование pub/sub-брокера. Apache Kafka не будет мультиплицировать сообщение, позволит до срабатывания политики истечения более медленным потребителям получить сообщение и обеспечит надежное промежуточное хранение. - Обмен данными между двумя автоматизированными системами в потоковом режиме через брокера сообщений.
При данном шаблоне интеграции обычно есть два встречных топика или очереди, куда автоматизированные системы помещают данные для контрагента. При таком типе обмена как pub/sub-, так и MQ-брокеры подходят для реализации, но выбор лучшего решения зависит от нюансов. Например, если требуется на транспортном уровне разделить потоки между модулями автоматизированной системы, т. е. обеспечивать диспетчеризацию на уровне транспорта, то больше подходит MQ. Когда диспетчеризация делается на уровне шлюза системы, но требуется очень широкая пропускная способность, предпочтительнее выбрать pub/sub и Kafka.
Коммерческие версии на базе Apache ActiveMQ Artemis и Apache Kafka
Компания «СберТех» предлагает решения Platform V Messaging и Platform V Corax для создания событийных интеграций. Оба продукта разрабатывались с учетом высоких требований к безопасности и производительности, зарегистрированы в РРПО, используются в инфраструктуре Сбера и не только. Для клиентов доступна техническая поддержка, в том числе 24/7.
Platform V Messaging — надежный и производительный брокер сообщений на базе ActiveMQ Artemis. Он обладает дополнительной функциональностью для работы в высоконагруженной инфраструктуре и быстро разворачивается с помощью скриптов автоматизации.
Дополнительная функциональность Platform V Messaging:
- формирование событий аудита для упрощения разбора инцидентов;
- трассировка сообщений для прослеживания всего их пути внутри кластера;
- сбор метрик подключения и сессий для мониторинга и администрирования кластера;
- ограничение подключений и скорости отправки сообщений для регулирования нагрузки на брокер;
- работа с бэкапами для восстановления работы кластера в случае возникновения инцидентов;
- работа с хранилищем секретов (vault) для использования внешнего хранилища секретов (паролей и сертификатов);
- шифрование сообщений, пока они находятся в брокере — для безопасного хранения данных;
- клиентские перехватчики для контроля целостности данных при записи и вычитке сообщений.
Platform V Corax — распределенная система обработки потоковых данных на базе Apache Kafka.
Дополнительная функциональность:
- Schema Registry. Центральный реестр схем данных.
- Admin UI. Визуальная утилита управления и мониторинга кластера.
- Auto Data Balancer. Автоматическая ребалансировка данных в кластере.
- E2E encryption. Шифрование данных от источника до потребителя.
- Additional metrics. Получение временной статистики по сообщениям (время записи, время вычитывания, время подтверждения чтения).
- DevOps Automation. Автоматизация плановых операций с кластером.
В качестве вывода
Выбор правильного инструмента зависит от многих нюансов. Есть базовые шаблоны, в которых продукты показывают себя лучше всего. Для Apache Kafka — это публикация/подписка с высокой пропускной способностью и масштабируемыми конвейерами данных. Это связано с дизайном распределенной системы Kafka, возможностями горизонтального масштабирования и эффективной обработкой больших объемов данных в реальном времени несколькими производителями и потребителями.
ActiveMQ Artemis обеспечивает гибкий асинхронный обмен сообщениями. Этот брокер подходит как для управления очередью сообщений, так и в качестве посредника сообщений общего пользования. Кроме того, является хорошим выбором для реализации различных шаблонов корпоративной интеграции, таких как фильтрация сообщений, маршрутизация сообщений (через JMS API message selector), каналы «мертвых писем» или «запрос-ответ».
Поскольку ActiveMQ поддерживает несколько транспортных протоколов и языков программирования, он может выступать в качестве связующего звена для приложений, написанных на разных языках и использующих разные протоколы. Например, с ActiveMQ посередине мобильное приложение, разработанное в Swift и взаимодействующее через MQTT, может беспрепятственно обмениваться данными с корпоративной системой, написанной на Java и использующей протокол OpenWire.
Компании, которым требуется высокий уровень надежности
интеграционной инфраструктуры, могут использовать коммерческие продукты Platform V Messaging и
Platform
V Corax
Решения прошли безопасный конвейер разработки и адаптированы для работы с высокими нагрузками.
