Микросервис и сервисное сотрудничество

Question

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

Предположим, у нас есть служба управления заказами и служба каталога продуктов.Когда пользователь добавляет элемент заказа в заказ, служба управления заказами сохраняет объект OrderItem, который среди прочих имеет следующие атрибуты:

OrderItem 
+ Id
+ ProductId
+ ProductName 

, чтобы служба управления заказами заполнила атрибут ProductNameу нас есть 4 варианта, как я вижу:

Вариант 1 : клиентское приложение задает ProductName, поскольку оно, вероятно, уже содержит данные из предыдущих запросов

Вариант 2 : если в архитектуре используется шлюз Api, шлюз будет отвечать за извлечение ProductName из службы каталога продуктов, а затем предоставит его службе управления заказами.

Вариант 3 : Служба управления заказами напрямую позвонит в Службу каталогов продуктов и запросит у него идентификатор продукта с указанием идентификатора продукта.

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

Из этих 4 вариантов мне кажется, что n ° 1 не подходит, так как мы не можем доверять клиенту правильное и обновленное значение ProductName.

Мне бы хотелось узнать ваше мнение о том, что вы считаете лучшим выбором и почему!

Спасибо!

Риана

Answer 1

Выбор 1: ProductName задается клиентским приложением, поскольку оно, вероятно, уже имеет эти данные из предыдущих запросов

Как вы сказали, это не лучшая идея, потому что клиент может иметьнесвежая информация.Может быть приемлемо, если информация о продукте изменяется нечасто и / или у вас есть вторичная проверка при обработке заказа.

Выбор 2: Если архитектура использует шлюз Api, шлюз будет отвечать за получение ProductName изСлужба каталогов продуктов затем предоставляет ее Службе управления заказами.

ИМХО, это не очень хорошая идея.При этом ваш домен / бизнес-логика попадет в шлюз API.Теперь шлюз знает отношения между Заказами и Продуктами.Эту конфигурацию / сценарий шлюза API необходимо будет поддерживать и вводить дополнительное связывание.

Выбор 3: Служба управления заказами будет напрямую вызывать Службу каталога продуктов и запрашивать у него ProductName, не давая идентификатор продукта.

Это мой предпочтительный выбор.Хотя я не рекомендую «прямые» синхронные звонки.Возможно получение ProductName через механизм обмена сообщениями (очередь сообщений, шина событий).Цепные синхронные звонки уменьшат доступность ваших услуг.Дополнительную информацию можно найти по адресу Шаблон обмена сообщениями Microservice .

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

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

Такое дублирование может быть оправдано для большого объемапоиск с низкой задержкой, но это скользкий уклон, который может привести к дублированию данных во всех ваших службах.Представьте себе последствия изменения длины или типа / формата строки ProductName ...