Чтобы обеспечить асинхронную связь между микросервисами (microservices), нужен брокер сообщений (message broker). Брокер обеспечивает надежную и стабильную передачу данных, управление и мониторинг, а также предотвращает потерю сообщений. На сегодняшний день существует несколько брокеров, которые различаются по возможностям и объемам передаваемых данных. Сравним три наиболее популярных из них — RabbitMQ, Kafka и Redis.
Синхронная и асинхронная связь между микросервисами
Чтобы обеспечить взаимодействие между микросервисами, используют два распространенных способа: синхронный и асинхронный. В первом случае вызывающая сторона ожидает ответа перед отправкой сообщения, работая как протокол REST (Representational state transfer) поверх HTTP. Во втором — сообщения отправляются, не ожидая ответа. Такой вариант подходит для распределенных систем и обычно нуждается в брокере для управления сообщениями.
При выборе типа связи следует учитывать ряд параметров, в том числе структуру микросервисов, инфраструктуру системы, задержки, масштаб, зависимости и цели взаимодействия. Реализация асинхронной связи может оказаться сложнее и потребовать дополнительных компонентов, но ее преимущества перевешивают недостатки.
Преимущества асинхронной связи
- Асинхронная связь по определению не блокируемая.
- Она поддерживает лучшее масштабирование, чем при синхронном режиме.
- В случае сбоев в работе микросервисов механизмы асинхронной связи предоставляют различные методы восстановления данных и, как правило, лучше справляются с подобными ошибками.
Кроме того, при использовании брокеров сообщений вместо протокола REST, участвующим в обмене данными сервисам не нужно знать друг о друге. Новый сервис можно добавить к уже давно работающему, т. е. они более “развязаны”.
И наконец, асинхронный режим расширяет возможности создания центрального средства обнаружения, мониторинга и выравнивания нагрузки, а также программ контроля за соблюдением политик. При написании кода и создании системы он предоставляет больше возможностей, включая адаптивность и масштабируемость.
Критерии выбора брокера сообщений
Асинхронная передача данных обычно выполняется через брокера сообщений. Другие способы, такие как AsyncIO, имеют ограниченные возможности.
При выборе брокера асинхронного режима следует учитывать ряд требований.
- Scale (масштаб брокера) — количество сообщений, отправляемых в системе, в секунду.
- Data Persistency (постоянное хранение данных, персистентность) — возможность восстановления сообщений.
- Клиентские возможности — способность управлять клиентами в режиме one-to-one (один к одному) и/или one-to-many (один ко многим).
Теперь оценим лучшие современные сервисы, чтобы выбрать наиболее эффективного провайдера по этим трем критериям.
Сравнение брокеров сообщений
RabbitMQ (AMQP)
- Scale. Зависит от конфигурации и ресурсов, приблизительно около 50 тысяч сообщений в секунду.
- Persistency. Поддерживаются как постоянные, так и временные сообщения.
- One-to-one и one-to-many. Поддерживаются оба режима.
RabbitMQ — один из первых брокеров общих сообщений, выпущенный в 2007 году. Это приложение с открытым исходным кодом реализует расширенные протоколы очереди сообщений (AMQP). Сообщения доставляются и методом point-to-point, и методом pub-sub. Поддерживается сложная логика маршрутизации.
Есть несколько управляемых сервисов, которые позволяют использовать RabbitMQ как SaaS, но он не входит в стек крупных облачных провайдеров. RabbitMQ поддерживается всеми основными языками, включая Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.
При высокой нагрузке возможны некоторые проблемы с производительностью.
Kafka
- Scale. До 1 млн сообщений в секунду.
- Persistency. Доступно.
- One-to-one и one-to-many. Поддерживается только one-to-many.
Kafka был разработан Linkedin в 2011 году для обработки данных при высокой пропускной способности и с малой задержкой. Распределенная потоковая платформа Kafka имитирует сервис публикации и подписки (publish-subscribe service). Она обеспечивает постоянное хранение данных и потоков записей, что позволяет обмениваться качественными сообщениями.
Kafka доступна как SaaS на Azure, AWS и Confluent, которые являются создателями и основными участниками этого проекта. Kafka поддерживается всеми основными языками, включая Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift и другие.
Redis
- Scale. До 1 млн сообщений в секунду.
- Persistency. Встроенная память для хранения данных отсутствует.
- One-to-one и one-to-many. Поддерживаются оба режима.
Redis немного отличается от других брокеров сообщений. Он предоставляет высокопроизводительное хранилище данных в памяти, которое можно использовать для хранения ключей, либо как брокер сообщений. Еще одна особенность заключается в том, что Redis не обладает персистентностью (механизм постоянного хранения данных), а наоборот сбрасывает данные на диск/в базу данных. Этот брокер идеально подходит для обработки данных в режиме реального времени.
Изначально Redis не поддерживал режимы one-to-one и one-to-many. Однако в версии Redis 5.0 после расширения возможностей pub-sub появился one-to-many.
Варианты использования брокеров сообщений
Сравним еще раз возможности RabbitMQ, Kafka и Redis. Все три брокера успешно выполняют свои задачи, но действуют при этом совершенно по-разному. Вот рекомендации по выбору в соответствии с особенностями использования.
Сообщения с коротким жизненным циклом — Redis
Резидентная (in-memory) база данных Redis почти идеально подходит для обмена кратковременными сообщениями, когда не требуется персистентность. Благодаря чрезвычайно быстрому обслуживанию и резидентной памяти Redis идеально подходит для обмена сообщениями с незначительной задержкой, когда персистентность не так важна и можно допустить некоторые потери. С версии 5.0 появилась поддержка режима one-to-many, что было необходимо из-за ограниченных ранее возможностей pub-sub.
Большие объемы данных — Kafka
Kafka — это распределенная очередь с высокой пропускной способностью, созданная для длительного хранения больших объемов данных. Она идеально подходит в тех случаях, где требуется персистентность.
Сложная маршрутизация — RabbitMQ
RabbitMQ — давно известный, популярный брокер со множеством функций и возможностей, поддерживающих сложную маршрутизацию. Он способен обеспечивать такую маршрутизацию сообщений при незначительном трафике (несколько десятков тысяч сообщений в секунду).
И финальный этап
Последнее, на что стоит обратить внимание, — программный стек. Если нужна относительно простая интеграция, то можно довольствоваться уже имеющимся в стеке брокером, без использования дополнительного.
Например, если в системе есть Celery для Task Queue поверх RabbitMQ, удобнее работать с RabbitMQ или Redis, а не с Kafka, который не поддерживается и потребует написания дополнительного кода.
Чтобы выбрать необходимый инструмент, важно понимать все их плюсы и минусы, с учетом конкретного применения, ситуации и требований.
Читайте также:
- Рабочая очередь в Go с RabbitMQ
- Как сделать сайт в 25 раз быстрее с помощью нескольких строк кода
- ClickHouse + Kafka = ❤
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Mertcan Arguç: Redis vs Kafka vs RabbitMQ
