@Matisumi

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

Если мы говорим о микросервисах на платформе .net/.net core, какой протокол "общения" между ними считается оптимальным? Wcf? WebApi? XML-/JSON-RPC? Брокер сообщений типа RabbitMQ?
И стоит ли заморачиваться на тему единого протокола "общения" между всеми микросервисами?
  • Вопрос задан
  • 133 просмотра
Пригласить эксперта
Ответы на вопрос 6
inoise
@inoise
Solution Architect
Есть всего 2 базовых принципа сообщения:
1. Влияние на систему (действие). Это API. Как правило json REST
2. Реакция системы на действие (так же используется как низкая связанность). Это очереди сообщений.

В целом все зависит от юзкейса и нет общего универсального протокола. Много разных архитектур и все хороши по-своему. Лично я использую везде REST API и после любого (успешного и нет) вызова отправляю в ESB сообщение. Если мне нужно влиять на другую подсистему (например, после принятия заказа отправить его в отдел продаж для подтверждения) то я использую Consumer для отправки в другое api.
Ответ написан
@Sha644
Не вдаваясь в подробности скажу так. Не заморачивайтесь вопросом и не пишите решение которое строго замыкаться на единый протокол общения. В таком случае у вас переезд не будет головной болью.
Ответ написан
NYMEZIDE
@NYMEZIDE
программист
Лично я по опыту такую схему использую:
если, согласно бизнес логике, вызов был
1. синхронный - то используется REST запрос, json. Может быть целая цепочка вызовов.
2. асинхронный - то публикация события в шину RabbitMQ. Одно событие может потом порождать цепочку событий.
2.1 бывает первые вызовы идут REST - но потом происходит публикация события и т.д. этот вариант все равно считается асинхронным.
Ответ написан
Зависит от того, какого рода "общение" происходит между сервисами.
Для получения данных от других сервисов логично использовать REST.
Если мы говорим о публикации событий, то логично использовать очереди (например, нужно пересчитать агрегаты при обновлении данных).
Если мы говорим про распределенные транзакции, то тут очереди и саги (архитектурный шаблон). Нужен отдельный сервис, который будет координировать шаги транзакций, обрабатывать отказы и т.д.. Советую посмотреть на такой проект для .NET, как MassTransit.
Также стоит продумать над вопросом логирования и трассировки, чтобы можно было получить все логи конкретного пользовательского запроса со всех микросервисов.
Ответ написан
@abbaboka
"Смешались к кучу люди, кони...."
RabbitMQ и пр. MQ всего лишь посредник. Их задача - удобно доставлять информацию. Что там будет внутри сообщения - другой вопрос.
Заморачиваться едиными правилами/единым форматом для протокола - стоит, да.
В наше время для мелких проектов - скорее JSON, HTTP.
Для крупных проектов лучше что-то более строгое и формализованное Protobuf, XML.
Для документирования OpenAPI/Swagger. И/или специализированные инструменты типа Postman.
Если скорости критичны, то использовать бинарные с предопределенной типизацией.
Если критичная скорость разработки, то использовать текстовые без типизации.
Ответ написан
Ogoun
@Ogoun
Programmer
Раньше использовать брокеры сообщений (RabbitMQ, ActiveMQ, NATS, ZeroMQ), в итоге пришел к общению посредством ServiceDiscovery.
Т.е. в сети есть сервис который хранит таблицу адресов других сервисов и периодически ее раздает. Плюс проходит по таблице и пингует не пропал ли какой сервис из доступа. Остальные сервисы общаются друг с другом напрямую, получая адрес нужного сервиса из таблицы. При этом, если запущено несколько одинаковых сервисов, то передача данных им идет через round-roobin балансировку (конечно это для stateless сервисов, если есть состояние придется усложнить алгоритм общения).
Транспорт может быть любой, использую REST или протокол поверх TCP как более быстрый вариант.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы