Микросервисы на основе событий: MQTT с брокером ИЛИ HTTP с API GATEWAY?

Question

Я пытаюсь разработать проект с использованием микросервисов.

У меня есть несколько вопросов по этой теме c (что-то неясно):

1) Как реализовать взаимодействие с микросервисами?

A) HTTP: каждый микросервис предоставляет HTTP API, запросы широковещательной рассылки API GATEWAY.

B) MQTT: каждый паб / субсервис микросервиса для брокера

C) ОБА: но как понять, когда один лучше другого?

Должен ли я использовать протокол pub / sub в качестве стандарта даже для операций classi c, обычно выполняемых по HTTP? Например, у меня есть два микросервиса: веб-менеджмент и продукт-сервис . web-management - это панель, которая позволяет администратору добавлять, изменять, ... товары в своем электронном интернет-магазине. Допустим, мы хотим реализовать операцию createProduct. Это команда (в соответствии с различиями событий / команд), связь один к одному.

Я могу открыть API в product-service, скажем, (POST, "/ product "), которые добавляют новый продукт. Я также могу реализовать это преобразование команды в событие productCreationRequest . В этом случае: web-manage mnet publi sh это событие. product-service прослушивание productCreationRequest событий (а также productUpdateRequest, productGetEvents, ...), как только он получает уведомление, он выполняет операцию и генерирует событие productCreated .

Я считаю это дело пограничным. Например, служба последнего случая может прослушать productCreated и немедленно отправить сообщение (уведомление по электронной почте или pu sh) клиентам. Что вы думаете об этом сценарии использования?

2) Кто может быть действительным брокером (я буду использовать docker -композит или kubernetes для организации контейнерных микросервисов: язык принят, вероятно, java, javascript, python)?

Answer 1

И то и другое определенно возможно! Выберите брокера, который позволяет легко смешивать и сопоставлять HTTP (синхронную) связь и многое другое asyn c управляемый событиями pub / sub. Это должно позволить вам переносить ваши микросервисы между двумя вариантами по мере необходимости.

API-интерфейсы HTTP отлично подходят для периферии вашего распределенного приложения, где клиент хочет отправить заказ или что-то в этом роде, и block ожидание ответа (200 OK).

Но внутри вашего приложения между микросервисами многие из них не нуждаются в ответе ... asyn c, в конце концов непротиворечивый. А использование pub / sub (например, MQTT) позволяет легко использовать несколько последующих пользователей. Еще одно полезное использование MQTT - потоковая передача обновлений нижестоящим потребителям ... например, поток данных от автобусной или авиационной компании или что-то в этом роде, вместо того, чтобы опрашивать REST API для обновлений.

Для вашего варианта использования и аналогичных, я бы почти всегда рекомендовал использовать связь паб / суб, даже если сегодня это простое взаимодействие запрос-ответ с одним бэкэнд-процессом. REST over HTTP является двухточечным, и, возможно, в будущем вы захотите, чтобы другой процесс мог видеть / потреблять / отслеживать это событие или взаимодействие. Если вы уже используете publi sh -subscribe, добавление второго (или более) потребителя этого потока данных тривиально. С REST / HTTP сложнее.

С точки зрения производительности, я бы сильно сомневался, что протокол блокировки, такой как HTTP, превзойдет что-то асинхронное и двунаправленное, например MQTT, который использует WebSockets для веб-коммуникации.

Что касается брокера, склеивающего все это, проверьте стандартную версию Solace PubSub +, брокер событий ... может выполнять как (и переводить между) MQTT и HTTP. Я даже написал CodeLab для этого (почти) точного варианта использования хаха!

(Кстати, я работаю на Solace! К вашему сведению.)

Answer 2

Рассмотрите возможность использования SMF-инфраструктуры для Javascript / Node.js, это помогает прототипировать паб / суб-коммуникацию через брокер сообщений (RabbitMQ) между микросервисами из коробки:

https://medium.com/@krawa76 / bootstrap - node-js -microservice-stack-4a348db38e51

Что касается маршрутов посредника сообщений, используйте соглашение о присвоении имен, основанное на событиях, например, отправьте "web.new-product", где "web" имя подсистемы, «новый продукт» - имя события.