Я не нашел существующий пост, спрашивая об этом, но приношу извинения, если я пропустил это.
Я пытаюсь настроить микросервисы и найти статьи, в которых используется RabbitMQ. Я смущен, почему нужен RabbitMQ. Предполагается ли, что службы будут использовать веб-api для общения с внешним миром и RabbitMQ для общения друг с другом?
В архитектуре Microservices у вас есть два способа связи между микросервисами:
У микросервисов.io есть несколько очень хороших статей об использовании микросервисов
Очередь сообщений предоставляет протокол асинхронной связи. У вас есть возможность отправить сообщение от одной службы к другой, не имея необходимости знать, может ли другая служба обработать его немедленно или нет. Сообщения могут ждать, пока ответственный сервис не будет готов. Службе, публикующей сообщение, не нужно ничего знать о внутренней работе служб, которые будут обрабатывать это сообщение. Этот способ обработки сообщений отделяет производителя от потребителя.
Очередь сообщений будет держать процессы в вашем приложении отделенными и независимыми друг от друга; этот способ обработки сообщений может создать систему, которая проста в обслуживании и легко масштабируется.
Здесь - история, объясняющая, как Parkster (служба цифровой парковки) разбивает свою систему на несколько микросервисов с помощью RabbitMQ.
Это руководство соответствует сценарию, в котором веб-приложение позволяет пользователям загружать информацию на веб-сайт. Сайт будет обрабатывать эту информацию и создавать PDF файлы и отправлять их по электронной почте пользователю. В этом примере обработка информации, создание PDF файла и отправка электронного письма займет несколько секунд, и это одна из причин, по которой будет использоваться очередь сообщений.
Здесь рассказывается о том, как и почему CloudAMQP использовал очереди сообщений и RabbitMQ между микросервисами.
Здесь рассказывается об использовании RabbitMQ в архитектуре микросервисов на основе событий для поддержки 100 миллионов пользователей в месяц.
И, наконец, ссылка на Kontena о том, почему они выбрали RabbitMQ для своей микросервисной архитектуры: "Потому что нам нужно стабильное, управляемое и высокодоступное решение для обмена сообщениями".
Обратите внимание, что я работаю в компании, стоящей за CloudAMQP.
Тот же вопрос может быть, почему 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. Итак, мир намного шире.