В этой статье для обучения дата-инженеров и разработчиков распределенных систем сравним Apache Kafka с популярными реализациями Java-стандартов обмена сообщениями, к которым относится Apache ActiveMQ, IBM MQ, Rabbit MQ и другие JMS-брокеры. Чем распределенная платформа потоковой передачи событий отличается от JMS-брокеров и что между ними общего.
Что такое JMS-брокер
Прежде чем приступить к сравнению, вспомним, что представляет собой JMS-брокер сообщений. Java Message Service (JMS) — это стандарт промежуточного ПО для рассылки сообщений, позволяющий standalone или веб-приложениям на платформе Java создавать, посылать, получать и читать сообщения в рамках интеграции информационных систем. При этом отправка сообщений выполняется в асинхронном режиме, т.е. отправитель не ждет ответа от получателя. Получатели могут быть следующих типов:
- MQ (Message Queue) – промежуточное ПО для сообщения (Message Oriented Middleware), которое позволяет независимым и не обязательно синхронным приложениям в распределённой системе обмениваться данными друг с другом через канал обмена сообщениями;
- WEB-контейнер типа JBoss, GlassFish или другого J2EE-сервера приложений с открытым исходным кодом, который обеспечивает обмен сообщениями между приложениями контейнера или по сети с помощью JNDI (Java Naming and Directory Interface), API для доступа к службам имен и каталогов.
Помимо Rabbit MQ, с которым чаще всего сравнивают Apache Kafka, о чем мы писали здесь, к JMS-брокерам относятся Open MQ, Apache ActiveMQ, OpenJMS, JBoss Messaging, Glassfish, TIBCO EMS, Sonic MQ, IBM MQ и другие открытые и проприетарные решения. JMS поддерживает две модели обмена сообщениями:
- из очереди или точка-точка, когда каждое сообщение имеет только одного адресата. Отправленное сообщение попадает в очередь, которая играет роль почтового ящика, и может быть прочитано оттуда когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт. А после получения сообщения сообщение-получатель посылает об этом уведомление отправителю. Поэтому для получения сообщений получателю следует периодически подключаться к нужной очереди и читать в ней сообщения.
- по подписке или издатель-подписчик, когда подписчик подписывается на определённый топик, куда издатель публикует сообщение, которое получают все подписчики этого топика. В этом случае приложение-получатель всегда должно работать и быть подписано на топик в момент отправки сообщения.
Итак, JMS-брокеры предоставляют возможности обмена сообщениями, а Apache Kafka — это платформа потоковой передачи данных, которая сочетает в себе возможности обмена сообщениями, хранения, интеграции данных и потоковой обработки. JMS можно рассматривать как Java-службу сообщений или API Java, предоставляющий общие модели обмена сообщениями, решая проблему интеграции между программными системами. Таким образом, основная возможность брокеров сообщений JMS, которые реализуют JMS API, заключается в отправке сообщений из исходного приложения в другое место назначения в режиме реального времени.
Apache Kafka как распределенная платформа потоковой передачи событий — это реализация протокола с открытым исходным кодом. Она включает не только ядро для распределенного обмена сообщениями и их хранения, обеспечивающее высокую пропускную способность, низкую задержку, доступность и безопасность. Также в состав платформы входит интеграционный компонент Kafka Connect для подключения внешних источников и приемников данных и Java-библиотека Kafka Streams для разработки потоковых приложений в этой среде. Все эти компоненты Apache Kafka позволяют создавать сквозные конвейеры данных и приложения обработки событий в реальном времени, что гораздо больше, чем просто очередь сообщений в JMS-брокерах.
Сходства и отличия Kafka c JMS
Итак, JMS — это спецификация промежуточного программного обеспечения, ориентированного на работу с сообщениями, которую провайдеры внедряют и расширяют по своему усмотрению. Сама спецификация JMS в настоящее время поддерживается в рамках процесса сообщества Java как JSR 343. Эта спецификация была разработана, чтобы предоставить общую библиотеку Java для доступа к брокерам различных поставщиков обмена сообщениями в качестве оболочки для проприетарных API-интерфейсов различных провайдеров аналогично тому, как JDBC предоставляет функции для API-интерфейсов баз данных.
Но на самом деле миграция кода JMS-брокера от одного провайдера к другому довольно сложна по нескольким причинам:
- не все функции JMS являются обязательными (безопасность, маркировка топиков/очередей, кластеризация, маршрутизация, сжатие и т. д.);
- отсутствует JMS-спецификация для транспорта;
- спецификация не определяет, как реализуется отказоустойчивость или высокая доступность;
- различная интерпретация спецификации разными поставщиками приводит к различиям в поведении одних и тех же функций JMS;
- отсутствует спецификация для обеспечения безопасности;
- в брокерах нет спецификации для дополнительных функций, таких как соединение топиков с очередями, маршрутизация между брокерами, списки контроля доступа и т. д.
Различные провайдеры предоставляют большое количество уникальных функций в рамках брокера, например, сопоставление топиков и очередей, маршрутизация брокера и пр., которые предоставляют архитектурные функции для приложения, но являются частью функций брокера, а не приложения или части JMS.
В свою очередь, Apache Kafka — это реализация протокола с открытым исходным кодом для потоковой передачи данных, платформа надежной и масштабируемой потоковой передачи данных в режиме реального времени. Хотя Apache Kafka НЕ является стандартом де-юре как OPC-UA или спецификацией как JMS, она предоставляет справочную реализацию исходного кода, определения протокола и API. Поэтому Kafka зарекомендовала себя как стандарт де-факто для потоковой передачи данных, микросервисных архитектур, управляемых событиями, и потоковой передачи событий.
JMS-брокер сообщений предоставляет транзакционные возможности для небольших объемов сообщений, поддерживая транзакции сеанса и двухфазной фиксации. Транзакционный сеанс поддерживает одну серию транзакций. Каждая транзакция группирует набор произведенных сообщений и набор потребляемых сообщений в атомарную единицу работы. Транзакции двухфазной фиксации работают в ограниченном масштабе. Они используются для интеграции с другими системами, такими как мейнфреймы CICS/DB2 или базы данных Oracle. Но с ними сложно работать, и их невозможно масштабировать за пределы нескольких транзакций в секунду. В отличие от сеансовых транзакций, транзакции двухфазной фиксации необязательны для спецификации JMS 2.0.
В свою очередь, Apache Kafka поддерживает малые и большие объемы сообщений, поддерживая транзакционные и аналитические рабочие нагрузки, а также обеспечивая семантику строго однократной доставки сообщений и API транзакций. Эта распределенная отказоустойчивая система с Transaction API и семантикой exactly-once упрощает создание транзакционных рабочих нагрузок, не нужно обрабатывать дубликаты. Kafka поддерживает атомарную запись в несколько разделов через API транзакций. Это позволяет приложению продюсеру отправлять пакет сообщений в несколько разделов. В конечном итоге все сообщения в пакете либо станут видимыми для любого потребителя или ни одно из них не станет.
Хотя транзакции в Kafka работают по-другому, чем в JMS, они имеют общую цель: каждый потребитель получает произведенное событие ровно один раз. JMS-брокеры передают сообщения приложениям-потребителям по принципу проталкивания (push). А потребители Kafka сами извлекают сообщения, обеспечивая маршрутизацию и обработку противодавления для независимых приложений. С первого взгляда отправка сообщений кажется лучшим выбором для системы обмена сообщениями в реальном времени. Однако обмен сообщениями на основе push-уведомлений имеет различные недостатки, связанные с маршрутизацией и масштабируемостью.
JMS ожидает, что брокер обеспечит противодавление (Backpressure) и реализует возможность предварительной выборки данных, но это не обязательно. Кроме того, противодавление контролирует сам брокер сообщений, а не потребитель. И, хотя у JMS есть какое-то противодавление, продюсер останавливается, если очередь заполнена. В итоге продюсера невозможно масштабировать с помощью JMS, т.к. в очереди или топике нет разделов. А потребителей можно масштабировать, но тогда потеряется гарантированный порядок, который работает в JMS-брокерах сообщений только через одного производителя, одного потребителя и транзакцию.
В Apache Kafka – наоборот, потребитель контролирует противодавление, потребляя события в режиме реального времени, пакетно или только по запросу. Этот принцип вытягивания (pull) позволяет конкретному потребителю поддерживать и обрабатывать поток данных. Это огромное преимущество для негибких и неэластичных сред.
В заключение отметим, что JMS фокусируется на экосистеме Java для языков программирования JVM, а Kafka не зависит от языков программирования. Помимо клиента Java, Kafka предоставляет и другие API, позволяя разработчику потокового приложения писать код на Python, Go, .NET, Ruby, node.js, Groovy. Также Kafka имеет REST API для HTTP-коммуникации с целью создания или потребления событий. Таким образом, гибкость серверной части Kafka позволяет разным клиентским приложениям взаимодействовать друг с другом, независимо от языка программирования. Эта гибкость позволяет создавать дизайн решения, управляемый предметной областью (DDD), для микросервисной архитектуры.
Поскольку речь зашла о проектировании, в заключение отметим, что именно Kafka поддерживает больше современных паттернов микросервисной архитектуры, одним из которых является CQRS — разделение ответственности команд и запросов. Подробнее об этом мы писали здесь. CQRS невозможен с JMS API, поскольку эта спецификация брокеров сообщений не предоставляет возможности состояния и не имеет возможности источника событий.
В 2023 году Kafka сделала шаг навстречу JMS-брокерам, опубликовав предложение по улучшению (KIP, Kafka Improvement Proposal) под номером 932. KIP-932 представляет новый тип групп, называемых общими группами (share group) или группами общего доступа, которые не заменяют группы потребителей, а дополняют их. Что это такое и как работает, читайте в нашей новой статье.
Освойте администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
