Микросервисы Зачем использовать RabbitMQ?

Я не нашел существующий пост, спрашивая об этом, но приношу извинения, если я пропустил это.

Я пытаюсь настроить микросервисы и найти статьи, в которых используется RabbitMQ. Я смущен, почему нужен RabbitMQ. Предполагается ли, что службы будут использовать веб-api для общения с внешним миром и RabbitMQ для общения друг с другом?

Ответ 1

В архитектуре Microservices у вас есть два способа связи между микросервисами:

  • Синхронный - то есть каждая услуга напрямую вызывает другую микросервис, что приводит к зависимости между службами
  • Асинхронный - у вас есть центральный центр (или очередь сообщений), где вы размещаете все запросы между микросервисами и соответствующей службой, принимает запрос, обрабатывает его и возвращает результат вызывающему. Это то, что RabbitMQ (или любая другая очередь сообщений - MSMQ и Apache Kafka - хорошие альтернативы). В этом случае все микросервисы знают только о существовании концентратора.

У микросервисов.io есть несколько очень хороших статей об использовании микросервисов

Ответ 2

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

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

Здесь - история, объясняющая, как Parkster (служба цифровой парковки) разбивает свою систему на несколько микросервисов с помощью RabbitMQ.

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

Здесь рассказывается о том, как и почему CloudAMQP использовал очереди сообщений и RabbitMQ между микросервисами.

Здесь рассказывается об использовании RabbitMQ в архитектуре микросервисов на основе событий для поддержки 100 миллионов пользователей в месяц.

И, наконец, ссылка на Kontena о том, почему они выбрали RabbitMQ для своей микросервисной архитектуры: "Потому что нам нужно стабильное, управляемое и высокодоступное решение для обмена сообщениями".

Обратите внимание, что я работаю в компании, стоящей за CloudAMQP.

Ответ 3

Тот же вопрос может быть, почему REST необходим для микросервисов? Концепция микросервиса не нова под луной. Долгое время распределение рабочего процесса использовалось для бэкэнд-инжиниринга и асинхронной обработки запросов. Микросервис - это тот же компонент в отдельном jvm, который соответствует S (единственная ответственность) в SOLID. Что делает его микро СЕРВИСОМ - это то, что он сбалансирован. И это все! В частности (!), Это может быть служба REST на базе Spring Cloud/REST, которая зарегистрирована Eureka, имеет прокси-шлюз и балансировку нагрузки через Zuul и Ribbon. Но это не весь мир микросервисов! Кстати, асинхронная распределенная обработка - одна из задач, для которой используются микросервисы. Давным-давно сервисы (компоненты) в отдельной JVM были интегрированы в любой обмен сообщениями, и этот паттерн известен как ESB. Микросервисы - это те же субъекты, что и шаблон. Из-за моды на Spring Cloud REST кажется единственным способом использования микросервисов. Нет! Например, Vertx https://dzone.com/articles/asynchronous-microservices-with-vertx поддерживает асинхронную микросервисную архитектуру на основе сообщений. Почему бы не использовать RabbitMQ в качестве канала сообщений? В этом случае распределение нагрузки может быть обеспечено путем построения кластера RabbitMQ. Например:https://codeburst.io/using-rabbitmq-for-microservices-communication-on-docker-a43840401819. Итак, мир намного шире.