Наверное, каждый, кто впервые сталкивается с термином «микросервисная архитектура», задается вопросом — что это такое и как это работает? Если объяснять простыми словами, то микросервисная архитектура — это подход к разработке программного обеспечения, при котором приложение разделяется на множество небольших, самостоятельных модулей (микросервисов). Каждый из них выполняет свою специфическую функцию и работает независимо от других.
Чтобы общаться и взаимодействовать друг с другом, модулям необходим посредник, который будет осуществлять пересылку и трансляцию сообщений. В мире микросервисов роль таких посредников играют брокеры сообщений — программные компоненты, обеспечивающие связь и согласованность между отдельными сервисами.
В этой статье мы подробно рассмотрим популярные брокеры сообщений, поймем, для чего вообще они нужны, и узнаем, какой брокер в каких случаях лучше использовать.
cloud
Микросервисная архитектура, где приложение разбито на небольшие независимые сервисы, предоставляет множество преимуществ, способствующих гибкости, масштабируемости и отказоустойчивости в процессах создания и обслуживания приложений.
В такой архитектуре крайне важно обеспечить успешное взаимодействие и обмен данными между независимыми микросервисами, и именно здесь в игру вступают брокеры сообщений. Рассмотрим несколько основных причин, зачем нужен брокер сообщений:
Помогает микросервисам общаться. Без брокера каждому микросервису нужно было бы наладить связь со всеми остальными, что привело бы к избыточной сложности и беспорядку.
Защищает от потери данных. Если микросервис «упадет» или перестанет работать, брокер сохранит сообщения до момента, когда получатель будет готов обработать их, что обеспечивает устойчивость системы в случае временных сбоев.
Делает систему гибкой. Если нужно добавить новый микросервис или убрать старый, брокер облегчает это изменение, отслеживая все сообщения и решая, куда их перенаправить.
Позволяет применять шаблоны асинхронной коммуникации. Брокер сообщений позволяет реализовать шаблоны проектирования, такие как «очередь сообщений» или «публикация-подписка». Это означает, что микросервисы могут отправлять информацию, не думая о том, кто и в какой момент ее получит. Это добавляет гибкости и параллелизма в работу.
Помогает распределять нагрузку. Брокеры сообщений могут распределять сообщения равномерно между сервисами, обеспечивая баланс нагрузки и поток данных.
На сегодняшний день на рынке представлено огромное количество различных брокеров сообщений. Например, Apache Kafka, RabbitMQ, NATS (NATS Messaging System), ActiveMQ, Redis Pub/Sub, Amazon Simple Notification Service (SNS), Google Cloud Pub/Sub, Microsoft Azure Service Bus и другие. Рассмотрим подробнее такие популярные брокеры сообщений, как Kafka, NATS и RabbitMQ.
Apache Kafka — это высокопроизводительный брокер сообщений, созданный для обеспечения обмена данными в распределенных системах. Изначально созданный в LinkedIn и впоследствии ставший открытым проектом Apache Software Foundation, брокер сообщений Kafka обеспечивает надежный и устойчивый механизм передачи сообщений в режиме реального времени между различными компонентами системы.
Темы и разделы. В Apache Kafka данные организованы в темы. Тема (topic) — это логическая категория, которая представляет собой поток сообщений. Например, тема может быть создана для событий определенного типа. Темы позволяют эффективно организовывать потоки данных. Каждая тема разделена на несколько разделов. Разделы (partitions) служат для физического распределения данных внутри темы. Это позволяет параллельно обрабатывать сообщения и повышает производительность системы.
Продюсеры и потребители. Продюсеры (producer) отвечают за отправку сообщений в темы, они создают данные или события и публикуют их в определенные темы Kafka. А потребители (consumer) подписываются на темы и обрабатывают поступающие сообщения, они могут читать данные из одного или нескольких разделов.
Оффсет. Каждое сообщение в теме имеет уникальный идентификатор, называемый оффсетом (offset). Оффсет — это числовое значение, которое указывает позицию сообщения внутри раздела. Это обеспечивает устойчивость данных, так как система запоминает до какого момента каждый потребитель обработал сообщения. В случае сбоя или перезапуска потребителя, он может начать обработку с сохраненного оффсета, предотвращая дублирование сообщений или потерю данных.
Представим тему «логи» с тремя разделами. Продюсер записывает логи от серверов эту тему. Потребители подписываются на разные разделы, обрабатывая логи асинхронно. Оффсеты каждого потребителя отслеживают прогресс обработки данных, обеспечивая точность и восстановление после сбоев.
Такая структура данных в Kafka обеспечивает гибкость, масштабируемость и устойчивость при обмене сообщениями в распределенных системах.
Помимо этого, Kafka представляет собой распределенную систему, состоящую из нескольких брокеров. Брокеры работают в кластере, обеспечивая высокую доступность, отказоустойчивость и распределенную обработку данных. Кластер Kafka обычно включает в себя несколько брокеров, каждый из которых выполняет свои функции в системе, обрабатывая данные, управляя разделением и обеспечивая общую производительность.
Высокая производительность: благодаря своей распределенной архитектуре, а также использованию нескольких копий для каждого раздела, брокер сообщений Apache Kafka может с легкостью обрабатывать миллионы сообщений каждую секунду. Это делает его незаменимым инструментом для работы с потоковыми данными, особенно, когда речь идет о больших объемах информации.
Гарантированная доставка сообщений: когда продюсер отправляет сообщение, система обеспечивает гарантированную доставку. За счет использования атомарных операций, подтверждений, репликации и структуры лидера (leader) и последователей (followers), Kafka обеспечивает высокий уровень уверенности в сохранности и целостности передаваемых сообщений.
Масштабируемость и гибкость: благодаря динамическому распределению данных в кластере брокеров, система способна легко масштабироваться, обеспечивая равномерную загрузку и оптимальное управление ресурсами при росте объемов данных. Гибкость в управлении потоками достигается за счет возможности создания различных тем и разделов, что позволяет организовывать данные в соответствии с требованиями приложения.
Отказоустойчивость и репликация: в Kafka реализован механизм репликации данных между брокерами. Это означает, что каждый раздел данных имеет несколько реплик, распределенных по разным брокерам в кластере. Когда данные записываются в тему, они реплицируются на другие брокеры. Репликация данных обеспечивает отказоустойчивость системы. В случае сбоя одного из брокеров, другие брокеры с репликами данных остаются доступными. Это гарантирует непрерывную работу системы даже при непредвиденных ситуациях.
Широкое применение: крупные компании, такие как LinkedIn, Uber и Airbnb, используют Apache Kafka для управления потоками данных в режиме реального времени. Применение Kafka в таких организациях подтверждает его эффективность в условиях высоких нагрузок и требований к обработке данных.
Экосистема и интеграция: комплекс инструментов и библиотек Kafka включает в себя многочисленные решения, среди которых особо выделяются Kafka Streams и Kafka Connect. Эти компоненты предоставляют различные возможности для обработки данных, их анализа и синхронизации с другими системами.
RabbitMQ — это высоконадежный брокер сообщений, построенный по принципу открытого исходного кода и предназначенный для обеспечения стабильного асинхронного обмена информацией между отдельными компонентами внутри системы. Для связи между приложениями RabbitMQ использует протокол AMQP (Advanced Message Queuing Protocol), который обеспечивает высокую надежность и гибкость коммуникационных процессов.
Очереди и обмены. Очереди (queues) можно представить как специализированные хранилища, предназначенные для временного удержания сообщений. Продюсер выполняет отправку сообщений в определенную очередь, после чего потребитель извлекает их из очередей для дальнейшей обработки. Обмены (exchanges) в этой системе играют роль маршрутизаторов. Они решают, в какие именно очереди будут направлены сообщения, исходя из установленных правил маршрутизации и конкретного типа обмена.
Продюсеры и потребители. Продюсеры могут отправлять сообщения как непосредственно в очереди, так и в обмены. Потребители извлекают информацию из очередей для дальнейшей обработки.
Принцип работы брокера сообщений RabbitMQ основан на использовании обменов, очередей и правил маршрутизации сообщений. Продюсер генерирует сообщение и направляет его в обмен, он также может указать ключ маршрутизации, который определяет, в какую очередь должно быть направлено сообщение. Обмен, получив сообщение, решает, в какую очередь его направить, исходя из типа обмена и установленных правил маршрутизации. Каждая очередь связана с определенным обменом и ожидает поступления сообщений для их дальнейшей обработки. Потребители, в свою очередь, подписываются на очереди и выполняют обработку поступающих сообщений.
Типы обменов в RabbitMQ определяют правила маршрутизации сообщений от обмена к очередям. Основные типы обменов:
Прямой обмен (direct exchange): маршрутизирует сообщение в очередь, связанную с конкретным ключом маршрутизации.
Обмен веером (fanout exchange): отправляет сообщение во все связанные с ним очереди, игнорируя ключи маршрутизации.
Обмен тематический (topic exchange): маршрутизирует сообщения на основе шаблонов ключей маршрутизации.
Обмен с использованием заголовков (headers exchange): позволяет определить критерии маршрутизации с использованием заголовков сообщений, таких как тип контента, приоритет и другие.
Гибкость маршрутизации: есть возможность конфигурации обменов и очередей с учетом разнообразных схем маршрутизации. Например, использование топик-обмена позволяет направлять сообщения одновременно в несколько очередей в зависимости от их содержания. Такая гибкость в настройке потоков сообщений способствует эффективной обработке данных в разнообразных приложениях, таких как системы управления заказами, событийные системы и другие.
Поддержка множества протоколов обмена данными: RabbitMQ выделяется поддержкой широкого спектра протоколов, что делает его универсальным инструментом. Прежде всего, система активно использует протокол AMQP, который гарантирует стандартизированный обмен информацией между компонентами системы. Помимо этого, RabbitMQ позволяет работать с сообщениями через HTTP/HTTPS, а также поддерживает протоколы STOMP и MQTT.
Отказоустойчивость и репликация: по аналогии с Kafka RabbitMQ обеспечивает высокую отказоустойчивость за счет репликации данных между узлами. Если один из брокеров выходит из строя, информация остается доступной, исключая риски потери важных сообщений.
Высокая производительность: обработка большого количества сообщений в секунду, что делает RabbitMQ подходящим для высоконагруженных сценариев.
Интеграция с широким спектром языков и платформ: RabbitMQ предоставляет официальные клиентские библиотеки для множества языков программирования, таких как Java, Python, .NET (C#), Ruby, JavaScript, Go и других. Благодаря наличию клиентских библиотек, обеспечивается гибкость при интеграции с разнообразными технологическими стеками и платформами.
NATS — это легковесный, высокопроизводительный брокер сообщений, который ориентирован на простоту использования и обеспечивает быструю асинхронную коммуникацию в распределенных системах.
Темы. В NATS данные организованы в темы, также известные как «subjects». Темы представляют собой именованные каналы для передачи сообщений. Темы делятся на сегменты, разделенные точками, позволяя создавать иерархические структуры.
Публикация/Подписка. Основной принцип работы NATS основан на модели публикация/подписка (pub/sub). Отправители (публикаторы) отправляют сообщения в темы, а получатели (подписчики) могут подписываться на эти темы для получения сообщений.
Простота и производительность: обмен сообщениями в NATS происходит посредством простого и быстрого протокола публикации/подписки. Когда публикатор отправляет сообщение в тему, все подписчики, подписанные на эту тему, получают это сообщение. Минимизация накладных расходов позволяет брокеру успешно передавать сообщения с минимальными задержками.
Без состояния: NATS не сохраняет информацию о состоянии предыдущих сообщений, переданных через брокер. Кроме того, не сохраняются данные о подписчиках или их состояниях. Это позволяет брокеру быть легко масштабируемым, поскольку нет необходимости в сложной синхронизации состояний.
Отсутствие очередей по умолчанию: NATS не использует очереди по умолчанию, что делает его предпочтительным в сценариях, где актуальность сообщений важнее сохранения. Это освобождает от необходимости управления и настройки очередей.
Протокол надежной доставки: NATS обеспечивает протокол «at-most-once delivery», что обеспечивает доставку сообщений получателю максимум один раз. Это подходит для сценариев, где требуется быстрая и надежная коммуникация.
Выбор подходящего брокера в значительной степени зависит от объема данных и требований к производительности вашего проекта. Каждый из рассмотренных брокеров предоставляет свои уникальные возможности, сфокусированные на определенных аспектах обработки данных.
Если ваш проект работает с огромными потоками данных, особенно в режиме реально времени, Apache Kafka может стать вашим идеальным выбором. Его архитектура, ориентированная на обработку потоков данных, обеспечивает высокую производительность и масштабируемость.
Пример использования: аналитическая система финансового рынка, где важна обработка транзакций в реальном времени и хранение данных для последующего аудита.
В Timeweb Cloud мы предлагаем настроенное и готовое к работе решение в облаке по использованию сервиса Kafka.
Если ваш проект требует гибкой маршрутизации сообщений и поддержки различных паттернов взаимодействия, то в этом случае предпочтительным выбором является RabbitMQ. С его многообразием обменов и возможностью настройки различных типов маршрутизации, RabbitMQ предоставляет широкие возможности для создания сложных сценариев обмена сообщениями.
Пример использования: система управления заказами в электронной коммерции, где важна асинхронная обработка заказов и уведомления от клиентов.
Если вам необходим эффективный механизм для обмена сообщениями между компонентами системы, рассмотрите возможность использования облачного сервиса аренды RabbitMQ от Timeweb Cloud. Мы предлагаем надежное и масштабируемое облачное решение для управления обмена сообщениями и данными в различных системах.
Для проектов, где акцент сделан на легких и быстрых асинхронных коммуникациях в распределенных системах, NATS предоставляет оптимальное решение. Благодаря своей простоте и высокой производительности, NATS является идеальным выбором для сценариев, где обмен сообщениями должен быть осуществлен максимально быстро и с оптимальным использованием ресурсов.
Пример использования: система мониторинга IoT, где требуется быстрая и надежная передача событий от датчиков к серверу для дальнейшей обработки.
Подготовили для вас выгодные тарифы на облачные серверы
В этой статье мы рассмотрели три ключевых поставщика по обработке сообщений: Apache Kafka, RabbitMQ и NATS. Каждый из них обладает уникальными особенностями, которые делают их пригодными для различных задач. Выбор брокера — это индивидуальное решение, зависящее от конкретных потребностей вашего проекта.
Для того чтобы сделать правильный выбор, оцените требования, выделите приоритеты и внимательно рассмотрите каждого брокера в контексте ваших целей. Надеемся, что данное руководство поможет вам сделать обоснованное решение и успешно внедрить брокер сообщений в вашем проекте.
Если вы уже решили, какой брокер подходит именно вашему проекту, но теперь задаетесь вопросом — как правильно его установить и использовать? Вам помогут инструкции Timeweb Cloud по установке и эксплуатации брокеров: