Коммуникации в микросервисной архитектуре

Просто о NET | создано: 7/14/2022 | опубликовано: 7/15/2022 | обновлено: 11/16/2022 | просмотров: 1420 | всего комментариев: 4

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

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

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

  • Механизмы обеспечения безопасности (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).

 

Комментарии к статье (4)

Здравствуйте.

Вы крутой, без вариантов.

Если есть возможность поделитесь опытом - как подружить IdentityServer с AD (локальной). Есть ли у вас такой опыт?

В частности, не будет ли тормозить LDAP? Или стоит делать хранилище все же на БД, а уже ее данные синхронизировать с AD периодически?

Буду благодарен любому ответу.

Есть опыт,  чуть позже отвечу.

Здравствуйте. Прошу прощения, что не сразу ответил, не было возможности. Итак, у IdentityServer4 есть специальный механизм, который позволяет для проверки пользователей "смотреть" в другие базы данных. Рекомендую посмотреть в сторону IResourceOwnerPasswordValidator.

Вот еще может пригодиться:

https://stackoverflow.com/questions/39859641/validating-against-credentials-custom-users-db-iresourceownerpasswordvalidator
https://docs.identityserver.io/en/latest/topics/resource_owner.html

Спасибо большое!