В настоящее время растёт потребность компаний в проектах по интеграции. Системные аналитики всё чаще сталкиваются с проектированием не только и не столько новых систем, сколько новых интеграционных потоков. В этих условиях для выставления качественных требований и разработки полезных артефактов аналитик должен хорошо понимать, как работают системы, помогающие организовать обмен между участниками взаимодействия. Зачастую для корректной работы бизнес-процесса нужно правильно настроить брокер. Требования к такой настройке должны учитывать особенности его работы.

Из статьи вы узнаете:

• Что такое брокер сообщений и для чего он необходим аналитику;
• Как устроен RabbitMQ (на примере его реализации в онлайн-сервисе CloudAMQP) и из чего он состоит: обменники, очереди, маршрутизация.

Прежде, чем мы начнём разбираться с тем, как устроен RabbitMQ, необходимо понять, что такое брокеры сообщений и для чего они используются в современных информационных системах.

Брокер сообщений — программное обеспечение и определённый архитектурный паттерн, который позволяет выстроить действия в информационных системах таким образом, чтобы обеспечить асинхронный обмен сообщениями между сервисами. Сервис, отправляющий данные, называется продюсер (producer), а потребляющий — потребитель (consumer).

Асинхронный обмен предполагает отправку запроса или сообщения от одного сервиса к другому, при этом деятельность сервиса-отправителя не приостанавливается в ожидании ответа от получателя.

Для обеспечения асинхронной доставки сообщений используется специальное программное обеспечение — брокер сообщений.

В использовании брокеров для интеграции приложений есть ряд преимуществ:

1. Надёжность — брокеры обеспечивают гарантированную доставку сообщений даже при сбоях в системах или их перегрузках. Также они учитывают порядок доставки и отслеживают её состояние.
2. Масштабируемость — брокеры имеют гибкую архитектуру, что позволяет эффективно масштабировать систему горизонтально или вертикально при необходимости обработки больших объемов данных.
3. Асинхронность — повышает производительность системы в целом, поскольку при асинхронном обмене сообщениями, различные компоненты системы работают независимо и обрабатывают их в своём темпе.
4. Гибкость интеграции — брокеры можно назвать универсальным инструментом интеграции систем, так как они поддерживают различные протоколы и форматы сообщений.

В настоящий момент брокеры часто используется в системах, предполагающих высокую нагрузку, доступность и производительность.

Задачи брокера:

1. Получить сообщение от сервиса.
2. Обеспечить маршрутизацию, управление очередями.
3. Гарантировать доставку сообщения потребителю.

RabbitMQ — это один из популярных брокеров, который служит посредником для обмена информацией между различными системами. Он осуществляет передачу сообщений посредством очередей.

RabbitMQ основан на протоколе AMQP (Advanced Message Queuing Protocol).
Разумеется, RabbitMQ — не единственный подобный инструмент. Также стоит упомянуть ActiveMQ, IBM MQ и LanvinMQ.

Например, LavinMQ, как и RQM, работает на основе того же самого протокола AMQP, но его производительность на порядок выше. Продюсер может отправить около 1,6 млн сообщений в секунду, а потребитель может получить порядка 1,2 млн сообщений в секунду.

Чтобы обеспечить асинхронный обмен между продюсером и потребителем, RabbitMQ использует следующие компоненты:

3. Exchange — точка обмена;
4. Queue — очередь;
5. Message — сообщение.

Из этих трёх внутренних компонентов состоит вся топология объектов RabbitMQ, эти объекты могут многократно соединяться между собой, как показано на примере выше.

Рассмотрим пример, когда несколько приложений публикуют сообщения, отправляя их в RQM. Все входящие сообщения в этом примере попадают в точку обмена «Preprocessing exchange» — это единая точка в рассматриваемой топологии. Дальше брокер осуществляет их маршрутизацию и здесь возможны варианты:

• Направить сообщение в какую-либо очередь;
• Направить его в другие точки обмена, которые уже будут связаны с очередями.

В конечном счёте, каждая очередь подключается к консьюмеру, приложению Worker, которое читает эти сообщения и выполняет их дальнейшую обработку.
Среди прочих свойств, RabbitMQ часто приписывают свойство «проталкивать» сообщения потребителю. Для этого потребителю необходимо установить соединение, в рамках которого открывается канал взаимодействия и осуществляется транспортировка сообщений. Потребитель должен быть подписан на текущую очередь — это необходимое условие для доставки из неё.

Теперь рассмотрим каждый из объектов топологии RabbitMQ по отдельности с учётом их особенностей.

Начнём разбор объектов с очередей (Queue). В RabbitMQ они работают по принципу FIFO (First Input First Output). При конфигурации очереди можно задавать как обязательные, так и необязательные параметры. Каждая очередь должна иметь уникальное имя и свойства, которые будут определять её поведение.

Для демонстрации принципов работы RQM возьмем сервис CloudAMQP — онлайн-платформу, которая предоставляет управляемые серверы RabbitMQ и LavinMQ в облаке. Она имеет подробную документацию и наглядный веб-интерфейс.

Создавать и настраивать очереди, а также указывать атрибуты для них необходимо через административную панель RabbitMQ в сервисе CloudAMQP. Сперва надо назвать очередь и определить её свойства, чтобы потребитель мог считывать данные из неё.

При формировании имён необходимо учитывать ограничения RabbitMQ:

1. Длина имени не должна превышать 255 символов в кодировке utf-8.
2. Имя не может начинаться со слова «amq.» — это зарезервированная часть для очередей создаваемых в RabbitMQ и используемых по умолчанию.

Помимо имени в административной панели RabbitMQ можно установить параметр свойства «Durable» (устойчивость) — это свойство определяет, сохранится ли очередь после перезапуска брокера. Для того, чтобы очередь была устойчива к сбоям брокера, этот параметр должен иметь значение «True» или, как указано в примере, «Durable».

Ещё одно важное свойство «Auto delete» (автоудаление). Оно означает, что как только последний потребитель заканчивает читать сообщения из очереди, она удаляется.

Также здесь есть свойство «Arguments» — аргументы очереди, это свойство не является обязательным, но оно позволяет задавать время сообщения и очередей по отдельности, а также задавать ограничения длины очереди, как в сообщениях так и в байтах и другие свойства, которые мы подробно рассмотрим в разделе формулирования требований.

Следующий объект брокера — точка обмена или обменник (Exchange). Все сообщения RabbitMQ, прежде чем попасть в очереди, публикуются в точке обмена брокера. Exchange принимает сообщения от приложения-производителя и направляет их в одну или несколько очередей на основе созданных связей между ним и очередью. В спецификации протокола AMQP, по которому работает RabbitMQ, существует несколько типов точек обмена, каждый со своей собственной семантикой маршрутизации.

Тип точки обмена настраивается при её создании в сервисе CloudAMQP.

Таблица заимствована из статьи Анны Вичуговой.

При настройке типа задаются атрибуты точек обмена:

1. Name, каждая точка обмена должна иметь уникальное название.
2. Durable — постоянная или «Transient» — временная очереди. Если есть необходимость создать постоянную точку обмена, которая будет храниться на диске даже после перезапуска сервера или брокера, то выбирается свойство «Durable». При выборе значения «Transient» точка обмена будет удаляться после перезагрузки.
3. Internal — внутренние точки обмена. Такой атрибут может принимать два значения: «да» или «нет». Если продюсеры не могут напрямую публиковать сообщения в эту точку обмена, то соответственно этот обменник имеет значение «нет». В том случае, если используем значение «да», то обменник используется исключительно в привязках с другими обменниками брокера.
4. AutoDelete — автоматическое удаление обменника. Этот атрибут удаляет точку обмена по завершению использования, после соответствующего удаления всех связанных с ней очередей.
5. Arguments — необязательные аргументы. Чаще всего через эти дополнительные аргументы задается альтернативная точка обмена. Она нужна в тех случаях, когда сообщение внутри брокера не может пройти по первоначальному маршруту, но с помощью данного аргумента его можно отправить в альтернативный обменник для маршрутизации по другому пути.

Третья сущность, которая участвует в информационном обмене — Сообщение (Message).

В структуре Сообщения можно выделить три основных блока:

• Attributes — заголовок;
• Payload — блок полезной нагрузки;
• Headers — заголовки сообщения, блок дополнительных атрибутов, участвующих в построении логики обработки и маршрутизации в топологиях брокера.

Атрибуты сообщения:

1. Routing key — ключ маршрутизации, обязательная характеристика, которая позволяет обменнику типа Direct или Topic направить сообщение в очередь внутри брокера.
2. Headers — содержит дополнительную информацию для сложной маршрутизации и используется обменником типа Headers. Иногда может быть нужно выполнить маршрутизацию в зависимости от одного какого-то ключа. Чаще можно столкнуться с необходимостью выполнить проверку нескольких условий. Эти условия можно указать как атрибуты в поле заголовка (Headers) и затем использовать их в брокере для более сложной маршрутизации.
3. Properties — характеристики сообщений, наиболее важными из них являются тип (Content_type) и кодировка (Content_encoding).
4. Delivery mode — режим доставки, сохранение опубликованных сообщений до момента их передачи потребителю.

Выделяют две разновидности режима доставки:

• Persistent — постоянная, то есть сохранение сообщений;
• Non-persistent — непостоянная, несохранение сообщений.

Этот атрибут работает в связке с атрибутом Durable. Если Durable обеспечивает сохранность очереди, то Delivery mode отвечает за то, чтобы в случае сбоя или перезагрузки сервера ранее опубликованные в ней сообщения были сохранены.

Теперь разберёмся, как задается маршрутизация в RabbitMQ. В интерфейсе менеджера, в разделе, посвященном точкам обмена, имеется поле Bindings. Оно необходимо для установления привязки, которая обеспечивает взаимосвязь очереди и точки обмена. При необходимости точки обмена могут быть также соединены не только с очередью, но и между собой.

В примере выше изображена структура отправляемого сообщения для последующей маршрутизации. Важно обратить внимание на специальное поле Routing key, содержащее ключ маршрутизации. Именно этот ключ должен совпадать с ключом, указанным в поле Bindings в настройках взаимодействия точек обмена и очереди.

Также в примере «Структура сообщения» представлен способ отправки полезной json-нагрузки с помощью ещё одного ключа, который обеспечивает доставку полезной нагрузки от продюсера к брокеру и далее к консьюмеру.

После того, как сообщение с определённым ключом маршрутизации попадает в точку обмена, его дальнейший маршрут внутри очереди определяется в зависимости от самого обменника. Рассмотрим примеры использования обменников типа Direct, Topic и Fanout.

Начнем с Direct exchange, который обеспечивает передачу сообщений в очередь согласно строго заданному ключу маршрутизации.

Например, очередь привязана к обменнику с ключом маршрутизации «rk-a». Когда новое сообщение с таким ключом от приложения-продюсера с названием Producer 1 поступает в обменник с названием Е, тот направляет его в очередь Queue1 по совпадению ключа маршрутизации. Такой тип обменника полезен при адресной маршрутизации сообщений по конкретным потребителям.

Далее рассмотрим тип точки обмена Topic exchange. Такой обменник также использует ключ для выборочной маршрутизации. Но, в отличие от прямого обменника, Topic использует шаблоны для сопоставления ключа, а не конкретное значение. Шаблон может включать следующие символы подстановки:

• * (звездочка) — заменяется ровно на одно слово;
• # (решетка) — заменяется на 0 и более слов.

Например, к обменнику типа Topic привязаны разные очереди по следующим шаблонам:

• user.delete.profile — ключ маршрутизации для привязки к очереди Queue1;
• user.*.profile — ключ маршрутизации для привязки к очереди Queue2;
• user.delete.* — ключ маршрутизации для привязки к очереди Queue3;
• user.# — ключ маршрутизации для привязки к очереди Queue4.

Тогда при публикации сообщения с ключом маршрутизации user.delete.profile оно попадет в очереди Queue1 и Queue4, а с ключом маршрутизации user.update.profile — в очереди Queue2 и Queue4. Если ключ маршрутизации будет равен user.delete.item, обменник направит сообщение в очереди Queue3 и Queue4. Данные из очередей получат потребители, которые на них подписаны.

В заключение рассмотрим обменник типа Fanout, который просто реплицирует сообщения во все связанные с ним очереди или обменники без проверки ключа маршрутизации. Даже если сообщение было опубликовано с прямым или шаблонизированным ключом или атрибутами в заголовке — это игнорируется. Этот тип обменника самый быстрый, поскольку проверка и сопоставление атрибутов с заданным образцом не производится.

На этом закончим рассмотрение основных объектов брокера сообщения RabbitMQ. Разумеется, в этом материале показаны не все особенности работы этого брокера, однако мы постарались отразить ключевые принципы устройства этого средства асинхронной интеграции приложений.

Вам могут быть интересны дополнительные материалы по теме работы с RabbitMQ:

Запись вебинара Зои Степчевой «Разработка требований к Rabbit MQ»

Статья Анны Вичуговой «RabbitMQ для аналитика: практический ликбез»

Статья Mary Moore «RabbitMQ in Microservice Architecture»