Микросервисы на .net — оптимальный протокол «общения»?

Question

[Matisumi]

Если мы говорим о микросервисах на платформе .net/.net core, какой протокол "общения" между ними считается оптимальным? Wcf? WebApi? XML-/JSON-RPC? Брокер сообщений типа RabbitMQ?
И стоит ли заморачиваться на тему единого протокола "общения" между всеми микросервисами?

Answer 1

[Иван Шумов]

Есть всего 2 базовых принципа сообщения:
1. Влияние на систему (действие). Это API. Как правило json REST
2. Реакция системы на действие (так же используется как низкая связанность). Это очереди сообщений.

В целом все зависит от юзкейса и нет общего универсального протокола. Много разных архитектур и все хороши по-своему. Лично я использую везде REST API и после любого (успешного и нет) вызова отправляю в ESB сообщение. Если мне нужно влиять на другую подсистему (например, после принятия заказа отправить его в отдел продаж для подтверждения) то я использую Consumer для отправки в другое api.

Answer 2

[Иван Филатов]

Лично я по опыту такую схему использую:
если, согласно бизнес логике, вызов был
1. синхронный - то используется REST запрос, json. Может быть целая цепочка вызовов.
2. асинхронный - то публикация события в шину RabbitMQ. Одно событие может потом порождать цепочку событий.
2.1 бывает первые вызовы идут REST - но потом происходит публикация события и т.д. этот вариант все равно считается асинхронным.

Answer 3

[Никита Гусев]

Зависит от того, какого рода "общение" происходит между сервисами.
Для получения данных от других сервисов логично использовать REST.
Если мы говорим о публикации событий, то логично использовать очереди (например, нужно пересчитать агрегаты при обновлении данных).
Если мы говорим про распределенные транзакции, то тут очереди и саги (архитектурный шаблон). Нужен отдельный сервис, который будет координировать шаги транзакций, обрабатывать отказы и т.д.. Советую посмотреть на такой проект для .NET, как MassTransit.
Также стоит продумать над вопросом логирования и трассировки, чтобы можно было получить все логи конкретного пользовательского запроса со всех микросервисов.

Answer 4

[abbaboka]

"Смешались к кучу люди, кони...."
RabbitMQ и пр. MQ всего лишь посредник. Их задача - удобно доставлять информацию. Что там будет внутри сообщения - другой вопрос.
Заморачиваться едиными правилами/единым форматом для протокола - стоит, да.
В наше время для мелких проектов - скорее JSON, HTTP.
Для крупных проектов лучше что-то более строгое и формализованное Protobuf, XML.
Для документирования OpenAPI/Swagger. И/или специализированные инструменты типа Postman.
Если скорости критичны, то использовать бинарные с предопределенной типизацией.
Если критичная скорость разработки, то использовать текстовые без типизации.

Answer 5

[Ogoun Er]

Раньше использовать брокеры сообщений (RabbitMQ, ActiveMQ, NATS, ZeroMQ), в итоге пришел к общению посредством ServiceDiscovery.
Т.е. в сети есть сервис который хранит таблицу адресов других сервисов и периодически ее раздает. Плюс проходит по таблице и пингует не пропал ли какой сервис из доступа. Остальные сервисы общаются друг с другом напрямую, получая адрес нужного сервиса из таблицы. При этом, если запущено несколько одинаковых сервисов, то передача данных им идет через round-roobin балансировку (конечно это для stateless сервисов, если есть состояние придется усложнить алгоритм общения).
Транспорт может быть любой, использую REST или протокол поверх TCP как более быстрый вариант.