Микросервисы штука непростая, я бы даже сказал, очень непростая, а коммуникации между ними еще сложнее. Хочу обозначить некоторое количество фактов, на основании которые, я надеюсь, будут приняты к сведению при выборе того или иного похода при решение задач коммуникации между микросервисами.

Типы коммуникаций

Есть два основных типа коммуникаций в микросервисной архитектуре: 

• Механизмы обеспечения безопасности (OAuth2.0, SSO, AD или другие типы), если ваши сервисы требуют авторизованного доступа (очень сомневаюсь, что коммуникаций этого типа можно избежать). Пусть они называются, коммуникации обеспечения безопасности;
• Сообщения между сервисами, обмен данными между бизнес-процессами. Назовем их коммуникации обеспечения бизнес-процессов (КОБП);
  • Высокоуровневые (клиентские, если хотите). Сообщения между пользователем и сервисами (client-to-service), например, с использованием Authorization Code Flow  (OAuth2.0).
  • Низкоуровневые (системы, если удобнее). Сообщения между сервисами и сервисами (service-to-service), например, Client Credentials Flow (OAuth2.0)

Взаимодействие типов

Чтобы работали коммуникации между бизнес-процессами, их нужно сопровождать специальным кодом (token), который однозначно идентифицирует автора запроса. А для того, чтобы получить это самый токен, использовать механизмы обеспечения безопасности. То есть, другими словами, если взять, например, спецификацию OAuth2.0 то потребуется:

• Выдавать токены
• Инвалидировать токены
• Отзывать токены
• Обновлять токены
• И еще массу вещей, которые скрыты за набором спецификаций. На данный момент всего 36.

Значит нужно использовать два типа коммуникаций, чтобы обеспечить безопасность.

OAuth2.0

Итак, OAuth2.0 — это промышленный стандарт (industry-standard protocol for authorization) состоящий из 36 правил обмена сообщениями между сервером авторизации и другими клиентами (пользователями, сервисами, устройствами и так далее). Ключевой момент в том, что работают эти правила, согласно спецификациям, по протоколу HTTP(S).

Есть "добрые" люди, которые эти правила "завернули" во фреймворки (например, IdentityServer4, OpenIddict), которые упрощают реализацию, а также помогают встроиться в систему industry-standard, а значит поддерживают сторонние библиотеки, сборки, пакеты и прочие полезные штуки, которые уже "придумали до нас".

Выбор типа коммуникаций

Безусловно, можно не мучить себя сложным выбором и взять то, что уже давно себя зарекомендовало и работает по стандартам, которые поддерживаются и принимаются во всем цивилизованном мире. Тем более, что существует даже несколько стандартов на выбор. А можно "заморочиться" и написать свой механизм обеспечения безопасности: свои спецификации, свой протокол, свой фреймворк и т.д. и .т.п. Вплоть до того, что вообще не использовать механизмы обеспечения безопасности. В любом случае, выбор за вами.

Заключение

В качестве заключения, хочу сказать, что были у меня в карьере случаи, когда внутренняя система безопасности предприятия не доверяла этим фреймворкам (а значит и стандартам) и требовала "ручную" реализацию OAuth2.0, то есть всех спецификаций. Согласен, что звучит глупо, но, как говориться, свои мозги другим не вставишь (© Calabonga).