Очереди сообщений в микросервисной архитектуре
Как известно, схемы синхронного и асинхронного взаимодействия на основе REST API имеют свои недостатки. Чтобы эти недостатки нивелировать, существуют очереди сообщений — Message Queues. Поговорим о принципах их работы.
Очереди предоставляют буфер, обеспечивающий временное хранение сообщений, и конечные точки, позволяющие в свою очередь подключаться к очереди в целях отправки/получения сообщений в асинхронном режиме. В таких сообщениях могут быть: — запросы; — ответы; — ошибки; — прочие данные, которые передаются между программными компонентами.
В очередях сообщений существует компонент, который называют производителем — Producer. Он служи для добавления сообщения в очередь, где оно станет храниться до тех пор, пока другой компонент с именем потребитель (Consumer) не извлечет это сообщение и не выполнит с ним нужную операцию.
Вот как можно представить очередь сообщений:
На практике очереди могут поддерживать получение сообщений и посредством метода Push, и посредством метода Pull. При этом: • в случае с Pull подразумевается периодический опрос очереди получателем на предмет наличия новых сообщений; • в случае с Push подразумевается отправка уведомления получателю в случае прихода сообщения. Также здесь реализуется модель «Издатель/Подписчик» (Publisher/Subscriber).
Как известно, очереди могут работать одновременно с несколькими производителями и потребителями. По этой причине очереди, как правило, реализуют посредством дополнительной системы, которую называют брокер.
Message Broker — это брокер сообщений, который занимается как сбором, так и маршрутизацией сообщений, используя для этого предопределенную логику. При этом сообщения можно передавать с некоторым ключом — как раз таки по этому ключу брокер и понимает, в какую именно очередь (в одну либо в несколько) должно попасть нужное сообщение.
Давайте приведем пример, связанный с отправкой рецензии (отзыва) на сайте. Существует часть сервиса, к которой обращается пользователь. Эта часть выступает в роли производителя, который направляет запросы на создание отзывов в очередь сообщений. В момент добавления сообщения в очередь юзеру можно сразу направлять уведомление, что операция прошла успешно. В результате вся последующая логика обработки станет выполняться вне зависимости от пользователя.
После окончания обработки потребитель выполнит отправку подтверждения в очередь, в результате чего исходное сообщение удалится. Однако если в процессе обработки произойдет какой-нибудь сбой и подтверждение вовремя получено не будет, сообщение можно повторно извлечь потребителем из очереди.
Вот как выглядит один из вариантов асинхронного взаимодействия, построенный на основе очереди сообщений:
Выводы
Итак, применение очередей сообщений позволит решить две задачи одновременно: — сокращение времени ожидания пользователя благодаря асинхронной обработке; — предотвращение потери информации при сбоях.
Однако не стоит рассматривать очереди в качестве универсального средства для любого вида приложений. Дело в том, что у такого подхода тоже есть и плюсы, и минусы. Но о них мы поговорим в следующей статье, следите за обновлениями!
По материалам https://mcs.mail.ru/blog/.
