Микросервис Архитектура дизайн для подписки

Question

Хотелось бы получить некоторое мнение о разработке системы с моделью подписки с использованием микросервисной архитектуры

Мы реализовали сервер идентификации, который аутентифицирует и авторизует пользователи, и хранит их профиль подписки. (то есть ресурсы, которые они могут доступ как журнал и вопросы)

на сервисе ресурсов, профиль подписки будет использоваться для фильтровать их соответствие. Например, если их подписка начинается с Год 2018, тогда это вступит в силу и вернет только данные года 2018 пользователям через REST API.

Это стандартная / правильная реализация архитектуры микросервиса? или есть ли лучший способ создать это?

Answer 1

Я бы сказал, что нет, особенно если вы хотите использовать принципы микросервисов - вы храните данные авторизации и области приложения на своем сервере идентификации. Ваш IDP должен интересоваться только вопросами аутентификации.

Я бы предложил отдельную услугу или набор услуг для управления и получения этой дополнительной информации, которая связана с пользовательскими объектами в вашем IDP через соответствующий идентификатор (например, идентификатор субъекта, адрес электронной почты, код учетной записи и т. Д.). Эта служба будет владеть своими собственными данными и использоваться всем, что нужно знать о подписках и т. П.