Совместно используемые данные на нескольких микросервисах

Question

У меня есть следующий сценарий:

Вы можете создать приложение через приложение-сервис. Перед созданием приложения необходимо проверить конкретную информацию. Эта информация распространяется и доступна только через пользовательский сервис и продукт-сервис.

Первой идеей было бы отправить сообщение через все сервисы через служебную шину, расширить его всеми необходимыми данными и снова обработать данные в конце в службе приложений:

-> Application-сервис-> User-сервис-> Product-сервис-> Applicaton-сервис

Вторая идея заключается в хранении всех соответствующих данных, избыточных во всех сервисах. Означает, что служба приложений имеет копию данных пользователя и продукта.

Обе идеи не подходят.

Есть ли лучшие подходы?

Answer 1

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

Я предлагаю пересмотреть границы ваших сервисов, хотя,Услуга - это технический орган для конкретного бизнес-процесса .Сервисы не предназначены для согласования с бизнес данными .

Например, ваши Product Service и User Service звучат как бизнес-данные, а Application-Service звучит слишком широко, не знаядополнительная информация.

Рассмотрим Order-Service, которому нужна информация о продуктах.Он может подписаться на ProductCreated события из Product-Service, чтобы заполнить себя информацией о продукте, хотя, вероятно, просто ProductID.Order-Service не нужно знать название продукта, его описание, цену (это может указываться в услуге Billing) и т. Д.

Поскольку служба является единственным органом управления бизнес-процессом,поэтому он также должен владеть пользовательским интерфейсом.Составные шаблоны пользовательского интерфейса позволяют разрисовывать одну страницу с компонентами из нескольких служб.Application-Service будет содержать страницу и клей, который объединяет компоненты.Для получения дополнительной информации об этом я нашел Micro Frontends хорошее чтение.