Мотивация к созданию архитектуры микросервисов в отличие от монолита может исходить из разных причин.
- Воспользуйтесь преимуществами масштабируемости
- Чаще внедряйте небольшие изменения
- Выделите разные домены для разных команд
Как реализовать архитектуру микросервисов, представляя заказчику единое веб-приложение?
Технические Соображения
Используйте тип предоставления потока кода авторизации OAuth2.
Используйте узел/Экспресс на уровне шлюза для обработки взаимодействия OAuth2 с сервером OAuth2, таким как Cognition или FusionAuth. Вот отличная статья от Fusion Auth , которая поможет вам реализовать взаимодействие OAuth2 на уровне шлюза буквально за 5 минут.
При необходимости выполняйте агрегирование данных из нескольких микросервисов на уровне шлюза. Избегайте прямого вызова микросервиса другим микросервисом.
Передайте токен, полученный с сервера авторизации, в качестве токена на предъявителя в заголовке при вызове внутренних микросервисов REST. Атрибуты идентификации пользователя в токене позволят вашим микросервисам включать детальные проверки авторизации.
Настройте свои внутренние микросервисы для проверки токена. Если вы используете Java, библиотеки spring-oauth2 помогут вам реализовать это очень легко.
Настройте приложение шлюза для выполнения проверки сертификата при выполнении https-вызовов микросервисов REST.
Используйте Lambda Авторизованный, если вам нужно ввести пользовательские атрибуты пользователя, не настроенные в AWS cognito, в токен, созданный AWS Cognito
Проблемы
при разработке микросервисов, управляемых доменом, вы сразу же обнаружите, что, хотя ваши домены могут с самого начала выглядеть независимыми, в разных доменах будут необходимы общие сущности.
Например, у вас может быть микросервис, управляемый доменом, для управления клиентами, который отвечает за добавление новых учетных записей клиентов и их обновление. Но вашей системе заказов также потребуется некоторая базовая информация о клиентах для отображения прошлых заказов и т. Д.
Простой подход к этой проблеме состоит в том, чтобы разрешить существование дублирующихся сущностей в разных доменах. В противном случае разработчик микросервиса не сможет извлечь связанные данные с помощью простого соединения, и вы будете вводить вызов REST из одного микросервиса в другой.
Если существуют дублирующие сущности в разных доменах, четко определите владельца службы для этой сущности и убедитесь, что служба отвечает за отправку уведомлений о любых новых сущностях или обновлениях существующих сущностей. Другим службам необходимо будет подписаться на эти уведомления и обновляться самостоятельно.
У вас также может возникнуть ситуация, когда ваше веб-приложение извлекает этот небольшой фрагмент общих данных из разных служб. Следовательно, обновление, внесенное в адрес клиента, немедленно отразится на потребителях обслуживания клиентов, но может не отображаться без какого-либо действия обновления в другой области веб-приложения, где информация об адресе клиента извлекается в качестве вторичных данных из другого микросервиса.
Другие преимущества
- Позволяет разработчикам пользовательского интерфейса сосредоточиться на разработке интерфейса angular и не беспокоиться о среднем и внутреннем уровнях.
- Позвольте разработчикам Java быть разработчиками Java и не заставляйте их беспокоиться об пользовательском интерфейсе.
- Более быстрое создание и развертывание конвейерных трасс.
Оригинал: “https://dev.to/krishnathotakura/microservices-architecture-for-the-enterprise-1ikb”