@Matisumi

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

Если мы говорим о микросервисах на платформе .net/.net core, какой протокол "общения" между ними считается оптимальным? Wcf? WebApi? XML-/JSON-RPC? Брокер сообщений типа RabbitMQ?
И стоит ли заморачиваться на тему единого протокола "общения" между всеми микросервисами?
  • Вопрос задан
  • 115 просмотров
Пригласить эксперта
Ответы на вопрос 5
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.
Если скорости критичны, то использовать бинарные с предопределенной типизацией.
Если критичная скорость разработки, то использовать текстовые без типизации.
Ответ написан
Ваш ответ на вопрос

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

Войти через TM ID
Похожие вопросы
Fmedia Санкт-Петербург
от 120 000 до 150 000 руб.
LC Group Новосибирск
от 90 000 до 160 000 руб.
Faradise Москва
от 120 000 до 120 000 руб.