При работе над проектом разработчикам, аналитикам, тестировщикам приходится участвовать в процессе проектирования архитектуры. Чтобы понимать, как различные части системы или сервисы могут между собой взаимодействовать, нужно разбираться в брокерах сообщений. Так как с их использованием достаточно часто строится коммуникация компонентов системы.
В статье разберемся, что такое брокеры сообщений, из чего они состоят и когда используются, плюсы и минусы. А также разберем особенности трех самых популярных брокеров — Apache Kafka, RabbitMQ и Redis.
Брокер сообщений — это архитектурный паттерн, используемый в распределенных системах. Представляет собой программный компонент, который служит посредником в коммуникации между различными частями системы. Реализуется как часть общей архитектуры системы, либо как отдельный сервис.
ИЗ ЧЕГО СОСТОИТ БРОКЕР СООБЩЕНИЙ
В работе любого брокера сообщений используются две основные сущности:
- Producer / Publisher — занимается отправкой сообщения в брокер;
- Consumer / Subscriber — получает и обрабатывает сообщения из брокера;
Сообщение отправляется напрямую от отправителя к получателю.
Также есть Topic / Тема — логическая единица, которая объединяет все сообщения по некоторому критерию.
Схема публикации/подписки.
Есть два основных алгоритма передачи сообщений в очередь:
- Есть Producer, который направляет сообщения в брокер, и есть Consumer, который их получает.
- Есть Publisher, который закидывает сообщения в очередь, и есть n-ое количество Subscriber'ов, которые их обрабатывают в дальнейшем.
КОГДА НУЖНО ИСПОЛЬЗОВАТЬ БРОКЕРЫ
Существует много кейсов, в которых применяются брокеры. Разберем основные:
- Отложенное выполнение действий. Потребность использовать брокеры возникает, когда нужно выполнить тяжелые операции, но не обязательно их выполнять в момент запроса от пользователя. Например, чтобы сформировать отчет, мы не должны заставлять пользователя ждать, пока пройдет время, и появится результат. Вместо этого мы отправляем задачу в очередь и даем клиенту ответ, что процесс запущен и ответ формируется.
- Реализация асинхронного обмена между сервисами с обеспечением буферизации сообщений. В данном случае брокер будет выступать неким буфером для накопления сообщений. И мы можем регулировать нагрузку и в некоторых кейсах ускорять обработку данных, по сравнению с тем, что если бы мы делали это однопоточно.
- Осуществление сложной бизнес-логики, в которой задействовано несколько компонентов информационной системы. В основном это касается микросервисов. Часто нужно выполнять изменения, которые должны происходить в нужной последовательности. Брокер поможет этому процессу. Получив сообщения в первом сервисе, выполняются необходимые изменения, и закидывается следующая задача для второго сервиса.
- Сглаживание пиковых нагрузок. Отправить какую-то задачу в брокер быстрее, чем ее выполнить. Поэтому мы можем накапливать определенные действия, а их выполнение делать уже позже.
- Отправка уведомлений (чаще перекликается с пунктом выше). Например, если идет массовая регистрация на мероприятие, мы хотим всем отправить подтверждение регистрации. Для того чтобы не перегружать основную часть системы отправкой уведомлений, мы просто складываем эти задачи в брокер, и потом в фоновом режиме работаем с ними.
- Когда требуется агрегировать и выполнять задачи по расписанию либо собирать данные телеметрии, логи и статистики. Запись в файл или передача в какую-то другую систему для агрегации этой информации — достаточно трудоемкий процесс. За счет использования очередей мы можем снизить нагрузку на наш основной сервис. Потому что это не первичная задача для бизнес-логики, мы можем выполнять ее фоново. И это никак не повлияет на производительность системы для пользователя.
ПЛЮСЫ И МИНУСЫ ИСПОЛЬЗОВАНИЯ БРОКЕРОВ
Как и у любой другой технологии, у брокеров сообщений есть свои плюсы и минусы:
+ | - |
Отказоустойчивость и масштабируемость. Способствует созданию отказоустойчивых и масштабируемых систем благодаря асинхронной обработке данных и возможности использовать кластеры брокеров. | Усложнение системы. Использование брокеров повлечет за собой увеличение сложности системы за счет добавления нового элемента в нее. Усложняется отладка, обслуживание и администрирование. |
Разделение слоев. Допускает разделение слоев приложения, уменьшая связность между ними, что предоставляет возможность сделать приложение более модульным, гибким и удобным в разработке. Также будет полезен при организации микросервисной системы. | Сложность в освоении. Изучение данного ПО может занять длительный период времени из-за сложности архитектуры. |
Гарантии доставки сообщений. Обеспечивают гарантии доставки сообщений. Если получатель не готов обработать полученную информацию в данный момент, она будет сохранена в очереди, и получатель сможет обработать ее позже. |
Дополнительная точка отказа. Это место возможного критического отказа, при котором большинство систем не смогут функционировать. Однако, многие брокеры обеспечивают высокую доступность и надежность функционирования. Это потенциальное узкое «горлышко» в производительности. Поэтому современные брокеры проектируются с возможностью высокой масштабируемости. |
Повышение производительности. Использование брокеров может повысить производительность благодаря асинхронной обработке сообщений. | Дополнительная нагрузка на сеть. Использование брокеров может повлечь за собой дополнительную нагрузку на сеть из-за передачи данных. |
Безопасность. Предоставляют механизмы шифрования и аутентификации, обеспечивая безопасность обмена данными. | Возможность конфликтов версий: Если участники системы используют разные версии протоколов или разные реализации брокеров сообщений, могут возникнуть проблемы совместимости. Это может привести к неправильной обработке или потере сообщений. |
ПОПУЛЯРНЫЕ БРОКЕРЫ СООБЩЕНИЙ
На самом деле, на рынке сейчас существует огромное количество брокеров сообщений. Например, Apache Kafka, RabbitMQ, Redis, Apache ActiveMQ, Amazon SQS, Apollo, Google Pub/Sub и другие. Этот список можно продолжать долго, но мы остановимся на первых трех. Так как они чаще всего используются в современной разработке.
Мы сравнили брокеры по ряду критериев. Для сравнения выделим три основных критерия, которые будут влиять на выбор:
- Scale (масштаб брокера) — количество сообщений, отправляемых в системе, в секунду.
- Data Persistency (постоянное хранение данных, персистентность) — возможность восстановления сообщений.
- Клиентские возможности — способность управлять клиентами в режиме one-to-one (один к одному) и/или one-to-many (один ко многим).
Брокер | Scale | Data Persistency | Клиентские возможности |
Apache Kafka |
Очень быстрый, позволяет обрабатывать более 1 млн сообщений в секунду | Да | One-to-many |
RabbitMQ | Около 50 тысяч сообщений в секунду (зависит от конфигурации) | Поддерживает постоянные и временные сообщения | One-to-one и one-to-many |
Redis | До 1 млн сообщений в секунду | Частичная реализация | One-to-one и one-to-many |
Особенности Apache Kafka
Один из самых популярных брокеров, который достаточно активно используется и имеет очень много возможностей.
- Подписчики должны сами «забирать» сообщения;
- Постоянное хранение данных. Все сообщения хранятся ограниченное количество времени, которое конфигурируется на уровне брокера.
- Позволяет перечитывать сообщения.
- Гарантирует порядок сообщений в разрезе топика. В каком порядке publisher прислал сообщения, в таком порядке subscriber их и получит.
Особенности Rabbit MQ
Тоже один из популярных брокеров. Он менее производительный, по сравнению с Kafka, но у него есть свои плюсы.
- Гибкая маршрутизация. Здесь мы можем выстраивать такие системы, которые требуют передачи данных в множество частей или микросервисов. За счет него можно облегчить эту задачу путем использования всех возможностей.
- Удаляет сообщение после доставки его получателю.
Есть сложности при горизонтальном масштабировании в кластере.
Особенности Redis
-
Резервное копирование на определенный момент времени;
-
Имеет ограниченный функционал по сравнению с другими брокерами.
какой БРОКЕР в каких случаях использовать
Выбор брокера сообщений зависит от конкретных требований и контекста использования.
Apache Kafka | RabbitMQ | Redis |
когда нужно обработать большой объем данных, которые очень быстро генерируются | нет большого потока данных | необходима обработка больших объемов данных |
при реализации транзакционных или конвейерных систем | важна гибкость маршрутизации сообщений внутри системы | не требуется персистентность |
при построении событийно-ориентированной архитектуры | важен факт доставки сообщений | необходима высокая скорость доставки сообщений |
при использовании буфера для логов и метрик |
заключение
Брокеры сейчас очень активно используются при построении крупных информационных систем. Не стоит делать однозначного вывода, какой брокер лучше, мы рекомендуем поработать с несколькими и выбрать самостоятельно. Потому что все зависит от контекста, в котором его будут использовать. Выбор конкретного решения нужно делать, исходя из той задачи, которая поставлена вам в текущий момент работы.
статьи по теме
-
ЧитатьКак улучшить читаемость JavaScript-кода? Советы разработчиков MediaSoft29.10.2024
-
ЧитатьКак организовать переиспользование компонентов в React? Советы разработчиков MediaSoft08.08.2024
-
ЧитатьUSE CASE — что это, из чего состоит и как избежать ошибок при написании27.06.2024
-
ЧитатьКак перейти с Java на Kotlin при создании веб-приложений? Ресурсы для начала изучения и мнения экспертов07.05.2024
-
ЧитатьИспользование снифферов трафика в тестировании на примере Charles Proxy04.04.2024
-
ЧитатьMediaSoft Java Weekend — 4 доклада с презентациями для Java-разработчиков20.03.2024