Что такое RabbitMQ?
В любом облачном приложении микрослужбы должны взаимодействовать для получения всех сведений, необходимых для реагирования на пользователей. Этот обмен сообщениями является надежным даже при возникновении проблем с сетью или сбоев между интеграцией. RabbitMQ — это одно из средств, которые можно использовать для повышения надежности обмена сообщениями.
В вашем розничном магазине оборудования на открытом воздухе вы делаете быстрый прогресс с микрослужбами. Однако при тестировании приложений некоторые вызовы из одной микрослужбы в другую, кажется, потеряны. Вы хотите убедиться, что эта проблема не возникает в рабочей среде, где репутация вашей компании находится на уровне.
В этом уроке вы узнаете, как RabbitMQ может создать гибкую и устойчивую платформу коммуникации для микрослужб.
Зачем использовать брокер сообщений в облачном приложении?
Облачные приложения состоят из независимых микрослужб, которые часто создаются отдельными командами и используют различные технологии и языки. Каждая команда имеет собственные спринты разработки и расписания обновления, а также может постоянно развертывать исправления и новые функции. Однако, когда запрос поступает от пользователя, микрослужба, получающая ее почти всегда, должна вызывать другие микрослужбы и резервные службы и получать от них ответы, чтобы сформулировать полный ответ.
Очевидно, что формат и схема этих межслужбовых запросов и ответов должны быть согласованы между командами разработчиков и редко меняются. Они обычно реализуются как REST API. Необходимо реализовать новые функции каждого интерфейса без изменения существующих методов и параметров. Однако если вы решили напрямую взаимодействовать с микрослужбами, может возникнуть несколько проблем:
- Когда целевая микрослужба отключена или занята, что происходит с сообщениями, отправленными в него? Каковы последствия потери сообщений?
- Как отправить одно и то же сообщение нескольким назначениям?
- Если микрослужба выполняется в нескольких контейнерах, в который следует отправлять сообщения?
Брокер сообщений — это ПО промежуточного слоя, которое устраняет эти проблемы. Службы отправляют сообщения брокеру сообщений, а не непосредственно в место назначения. Брокер хранит их в очередях в порядке их прибытия. Конечные службы подписываются на эти очереди и собирают сообщения по одному за раз для обработки.
Если целевая служба недоступна, то микрослужба отправки по-прежнему может размещать сообщения в очереди. При перезапуске назначения он продолжает собирать сообщения из очереди с той же точки. Сообщения не теряются, хотя отправитель должен ждать больше времени.
Так как несколько назначений могут подписаться на очередь, одно сообщение может быть получено несколькими микрослужбами. Кроме того, если несколько экземпляров узлов контейнеров одного микрослужбы, первый экземпляр, который становится доступным, получает сообщение. Брокер автоматически распределяет сообщения в экземпляры для распространения нагрузки.
Что такое RabbitMQ?
RabbitMQ является одним из самых популярных брокеров сообщений и имеет множество функций, которые делают его идеальным кандидатом для обработки коммуникаций в облачном приложении. Сюда входят:
- Сервер RabbitMQ, на котором размещаются очереди. Сервер поддерживает кластеризацию и отработку отказа для обеспечения высокой доступности и может выполняться в контейнерах.
- Реализации расширенного протокола очереди сообщений (AMQP), протокола простых текстовых сообщений (STOMP) и транспорта телеметрии очереди сообщений (MQTT).
- Клиентские библиотеки AMQP, которые можно использовать в .NET, Java и Erlang.
Основные понятия RabbitMQ
В терминах RabbitMQ микрослужбы, которые отправляют и получают сообщения, являются клиентами. Клиенты, отправляющие сообщения, называются производителями сообщений. Клиенты, получающие сообщения, являются потребителями сообщений. Служба RabbitMQ является брокером сообщений.
Отправка сообщений
RabbitMQ является универсальным и способен реализовать множество различных моделей очередей. Рассмотрим некоторые популярные шаблоны.
Если у вас есть один производитель и один потребитель, вы используете одну очередь и все сообщения достигают одного назначения. Даже в этой простой конфигурации вы создаете надежную систему обмена сообщениями, которая обрабатывает сбои плавно:
Отправка сообщений конкурирующим потребителям
В модели конкурирующих потребителей производитель отправляет сообщения в одну рабочую очередь. Два или более потребителей получают сообщения из очереди. Потребители конкурируют за получение сообщений, так как каждое сообщение может извлекаться только одним потребителем.
Этот шаблон полезен в облачных приложениях при использовании микрослужбы, размещенной на нескольких контейнерах для повышения емкости. Каждое сообщение достигнет только одного экземпляра потребителя, поэтому будет обработано только один раз. Работа не будет повторяться.
Публикация и подписка
Если вы хотите отправить одно сообщение от производителя нескольким потребителям, используйте модель публикации и подписки . Производитель отправляет сообщения в обмен. Каждый потребитель подписывается на сообщения из этого обмена. Когда они подписываются, RabbitMQ создает новую рабочую очередь для этой подписки. Каждое сообщение копируется в каждую очередь для этого обмена и получается каждым потребителем, подписавшемся. Потребители не конкурируют за каждое сообщение. Вместо этого все они получают копию каждого сообщения.
Модель публикации и подписки использует обмен фанутом, который копирует каждое сообщение в каждую рабочую очередь.
Этот шаблон полезен при обработке каждого сообщения несколькими микрослужбами. Например, когда клиент проверяет корзину, может потребоваться отправить сообщение о количестве приобретенных продуктов. Это сообщение должно достичь как микрослужбы доставки, чтобы указать складу упаковать посылку, так и микрослужбу акций, чтобы уменьшать номера запасов и, возможно, активировать заказы поставщикам.
Маршрутизация сообщений и разделов
Иногда требуется распространять отдельные сообщения нескольким потребителям, но для каждого потребителя применяется фильтр. Этот шаблон называется маршрутизатором сообщений. Как и в модели публикации и подписки, потребители подписываются на обмен, чтобы создать несколько рабочих очередей. Однако вместо обмена фантазией модель использует прямой обмен. При этом обмене каждая подписка имеет ключ привязки. Только сообщения, ключ маршрутизации которых соответствует ключу привязки, отправляются в эту подписку. Другие отфильтровываются.
Этот шаблон полезен, если некоторые потребители должны обрабатывать только подмножество потока сообщений. Например, предположим, что у вас есть микрослужба, которая отправляет сообщения при возникновении ошибок. Все ошибки должны отправляться в микрослужбу ведения журнала. Критические ошибки следует отправлять в микрослужбу администрирования, которая будет предупреждать инженеров, чтобы устранить проблему.
Прямой обмен сообщениями направляет сообщения на основе одного критерия. Чтобы сделать вещи еще более гибкими , вы можете использовать обмен темами . Для каждого сообщения можно использовать ключ маршрутизации с несколькими терминами, разделенными точками. В клавише привязки можно использовать подстановочные карточки *, заменить ровно одно слово или # заменить на ноль или несколько слов.
Примечание.
Альтернативы RabbitMQ включают Apache Kafka и Служебная шина Azure. Оба этих брокера сообщений поддерживаются выделенными интеграции в .NET Aspire. Вы узнаете о Служебная шина Azure в следующем модуле в этом пути обучения.