Я разбиваю чудовищно большое монолитное корпоративное приложение на несколько микросервисов и определил бизнес-возможности, вокруг которых будут моделироваться сервисы. Приложение имеет различные модули (HRMS, управление транзакциями и т. д.), взаимодействующие друг с другом. У меня нет требования питания для разрозненных устройств.
Существуют определенные варианты использования запроса (немедленного) ответа, для которых связь между микросервисами через шлюз API кажется подходящей. Однако для многих функций ответ (немедленно) не требуется, и публикация события (например, «EmployeeCreated») в брокере сообщений (RabbitMQ) кажется более подходящей.
Моя цель состоит в том, чтобы максимально использовать асинхронный pub-sub и сделать шлюз API простым и тупым, чтобы избежать еще одной монолитной и единой точки отказа.
У меня есть следующий вопрос (вопросы):
i) Является ли правильным подходом реализовывать некоторые функции посредством взаимодействия между микросервисами через RESTful API-Gateway, а другие — через асинхронную публикацию-подписку? Есть ли какие-то проблемы, о которых нужно помнить?
ii) Было бы неплохо иметь центральный шлюз маршрутизации, подписывающийся на события брокера сообщений и вызывающий соответствующие API RESTful? Я боюсь, что два гиганта (центральный брокер сообщений и шлюз API) могут свести на нет цель MSA.
iii) Если я буду использовать (i), этот ответ предполагает, что службы Windows лучше работают с RabbitMQ, и что самостоятельный Веб-API в службах Windows могут быть хорошим вариантом. Таким образом, служба Windows может использовать определенные события и предоставлять некоторые API для синхронного вызова. Это рекомендуется? Предполагая парадигму .Net, обязательно ли асинхронные микросервисы должны быть службами Windows?
Извините за широкий охват. Любая помощь приветствуется.
