Зависимость микросервисной архитектуры
Я много читал об архитектуре микросервисов, но есть одна вещь, которую я не понимаю, как этого достичь, и надеюсь, что вы сможете мне помочь с этим...
Допустим, у меня есть конечная точка web-api, которая получает заказы, за которые отвечает OrderMicroservice. Когда заказ выставлен, необходимо обновить инвентарь, чтобы OrderMS опубликовал событие для подписчиков (pub/sub, используя, например, Nats), а InventoryMS обновит инвентарь, так как он подписывается на текущее событие / сообщение.... Я хочу потерять объединенная архитектура и использование асинхронных вызовов для модулей /MS, которые заинтересованы в данной информации.
Данный сценарий будет отлично работать, если у вас есть 1 экземпляр InventoryMS, но что произойдет, если вы масштабировали InventoryMS по горизонтали, т.е. есть 5 экземпляров InventoryMS, и все они подписываются на inventory.change.event и будут пытаться обновить инвентарь?
Какую архитектуру или шаблон сообщения следует использовать для такого сценария с горизонтально масштабируемыми MS, чтобы у меня была слабосвязанная архитектура, когда MS зависят друг от друга? Один из способов заключается в том, что внутренняя связь осуществляется посредством REST-вызовов с использованием схемы автоматического выключателя, но затем я чувствую, что я строю монолит MS с некоторой сообразительностью (автоматический выключатель)...
Спасибо за вашу помощь!
2 ответа
Используйте модель обмена сообщениями "точка-точка", и только один потребитель получит сообщение. В модели pub/sub все подписчики будут уведомлены.
Пример с ActiveMQ.
Вы по-прежнему можете использовать модели pub/sub, но вам нужно установить несколько экземпляров, чтобы только один получал сообщение. конкретное зависит от механизма pub/sub
например, в системах AMQP (например, RabbitMQ) вы публикуете события на бирже. служба потребителя отправит очередь на этот обмен, и все экземпляры одной и той же службы будут читать из одной и той же очереди (поэтому только один из них будет обрабатывать любое данное сообщение)
Другим примером является Kafka - в Kafka все экземпляры одного и того же сервиса будут использовать одну и ту же группу потребителей - поэтому, опять же, только один экземпляр каждого подписавшегося сервиса получит сообщение
Другие пабы / подсистемы будут иметь аналогичные решения.
Точка-точка на конкретные экземпляры не является отличным решением, так как объединяет экземпляры различных служб.