Дизайн Электронная торговля Микросервисы

Question

Я занимаюсь проектированием электронной коммерции с использованием архитектуры микроуслуг.Предположим, что у меня есть два контекста: каталог товаров, инвентарь и цены.Мне кажется, что они несут ответственность.Но для обслуживания витрины (списка продуктов) мне нужно сделать запрос на каталог продуктов, получить список идентификаторов и затем использовать его для запроса микроуслуг Inventory для проверки состояния запасов (в наличии или в наличии).Помимо этого мне нужно сделать запрос в Pricing, чтобы узнать цену каждого продукта.

Таким образом, в основном для обслуживания фундаментальной функции я выполняю три запроса (например, объединение) в трех микро-сервисах.Я читал об архитектуре микросервисов, и когда вы имеете дело со многими «соединениями», возможно, что эти контексты должны быть едиными.Но, IMO, мне кажется ясным, что каждый контекст имеет свой набор обязанностей.

Другой вариант - создать «поисковый» микро-сервис, который объединит всю эту информацию (продукт + ценообразование + инвентарь).Мы можем использовать событие домена, чтобы уведомить «поисковую» микросекунду о том, что что-то изменилось.Таким образом, мы можем решить витрину с помощью одного запроса.Это похоже на CQRS.

Вопрос в том ...

Есть ли правильный подход?

Какой из них лучше?Компромиссы?

Answer 1

Похоже, что вам нужно, чтобы показать в представлении информацию, поступающую из разных микросервисов (контекстов).

Вы можете использовать технику ViewModel Composition, где компонент инфраструктуры (обработчик запроса) перехватывает запрос httpи позволяет микросервисам участвовать в ответе, ища микросервис, который говорит «эй, у меня есть эта информация» (в инвентаре есть информация о запасе, цена о цене и т. д.).Этот компонент инфраструктуры создает динамическую модель просмотра на лету, с информацией, поступающей от различных микросервисов.

Я никогда не реализовывал это, но посмотрите это видео, объясняющее это, с минуты 17:35 до 21: 00

https://www.youtube.com/watch?v=KkzvQSuYd5I

Надеюсь, это поможет.

Answer 2

вы можете попытаться включить некоторую информацию из разных контекстов домена в контекст другого домена

, чтобы в вашем домене каталога товаров содержалось # товаров, цены из инвентарных и оценочных доменов.

Это будетбыть доступным только для чтения (объекты значения) и должен обновляться событиями из доменов инвентаризации и оценки.

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

Answer 3

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

и выможет использовать события из другого микросервиса (Event Sorucing) для заполнения данных в поиске.

Answer 4

Обновление от 14 февраля 2019

Возможно, это ответит на ваш вопрос более подробно https://stackoverflow.com/a/54676222/1235935

---

Я думаю, что правильный подход здесь - использовать Event Sourcing для предварительного-сгруппировать данные витрины с описанием продукта, инвентаря и цены.Отдельный микросервис, вероятно, не нужен.Эти предварительно агрегированные данные (или материализованное представление) могут храниться в том же микросервисе, который обрабатывает пользовательский запрос на отображение продуктов (возможно, сервис создания заказов).

События могут быть сгенерированы с помощью регистрации изменений данных (CDC) на основе журнала из БД продукта, услуг инвентаризации и ценообразования и записи их в соответствующие темы на платформе потоковой передачи с журнализацией (например, Kafka или AWS).Kinesis) как уже упоминалось здесь .Это также обеспечит гарантии «читайте сами» в продуктах, инвентаризации и ценовых услугах