Microservices on .net - the optimal "communication" protocol?

Question

.NET

If we are talking about microservices on the .net/.net core platform, what is the optimal "communication" protocol between them? wcf? web API? XML-/JSON-RPC? RabbitMQ type message broker?
And is it worth bothering with the topic of a single "communication" protocol between all microservices?

Answer 1

There are only 2 basic principles of communication:
1. Influence on the system (action). This is the API. Typically json REST
2. System response to action (also used as low coupling). These are message queues.
In general, everything depends on the user case and there is no common universal protocol. Many different architectures and all are good in their own way. Personally, I use the REST API everywhere and after any (successful and not) call I send a message to the ESB. If I need to influence another subsystem (for example, after accepting an order, send it to the sales department for confirmation), then I use Consumer to send it to another api.

Answer 2

Personally, I use such a scheme from experience:
if, according to business logic, the call was
1. synchronous, then a REST request is used, json. There may be a whole chain of calls.
2. asynchronous - then the event is published to the RabbitMQ bus. One event can then spawn a chain of events.
2.1 sometimes the first calls go to REST - but then the event is published, etc. this option is still considered asynchronous.

Answer 3

Depends on what kind of "communication" occurs between services.
To receive data from other services, it is logical to use REST.
If we are talking about publishing events, then it is logical to use queues (for example, you need to recalculate aggregates when updating data).
If we are talking about distributed transactions, then there are queues and sagas (architectural pattern). You need a separate service that will coordinate transaction steps, handle failures, etc. I advise you to look at such a project for .NET as MassTransit.
It is also worth considering the issue of logging and tracing so that you can get all the logs of a specific user request from all microservices.

Answer 4

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

Answer 5

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