Микросервис и совместная работа сервисов
В контексте микросервисной архитектуры одна бизнес-операция может потребовать совместной работы двух или более сервисов.
Предположим, у нас есть служба управления заказами и служба каталогов товаров. Когда пользователь добавляет элемент заказа в заказ, служба управления заказами сохраняет объект OrderItem, который среди многих других имеет следующие атрибуты:
OrderItem
+ Id
+ ProductId
+ ProductName
Чтобы Служба управления заказами заполнила атрибут ProductName, у нас есть 4 варианта, как я это вижу:
Выбор 1 : ProductName предоставляется клиентским приложением, так как оно, вероятно, уже имеет эти данные из предыдущих запросов.
Выбор 2 : если в архитектуре используется шлюз API, шлюз будет нести ответственность за получение ProductName из службы каталогов продуктов, а затем предоставлять его службе управления заказами.
Выбор 3 : Служба управления заказами напрямую вызывает Службу каталогов продуктов и запрашивает у него ProductName с учетом идентификатора продукта.
Выбор 4 : Служба управления заказами имеет дублированную (но не исчерпывающую) информацию о продуктах в своей собственной базе данных, и эти данные будут обновляться каждый раз, когда событие обновления будет получено от Службы каталогов продуктов.
Среди этих 4 вариантов мне кажется, что номер 1 не подходит, так как мы не можем доверять клиенту, который даст нам правильное и обновленное значение ProductName.
Я хотел бы узнать ваше мнение о том, что вы считаете лучшим выбором и почему!
Спасибо !
Риана
@ zack6849 в его нынешнем виде этот пост не будет по теме для CR, потому что в нем отсутствует код (а также звучит как гипотетический - учитывая «Предположим, у нас есть ...."). См. "Какой сайт?" и «Проверка кода или нет?»
Ответы 1
Choice 1 : ProductName is given by the client app as it probably already has this data from previous requests
Как вы сказали, это не лучшая идея, потому что у клиента может быть устаревшая информация. Может быть приемлемым, если информация о продукте меняется нечасто и/или у вас есть вторичная проверка при обработке заказа.
Choice 2 : If the architecture uses an Api Gateway, the gateway will be responsible for retrieving the ProductName from the Product Catalog Service then provide it to the Order Management Service.
ИМХО, это не лучшая идея. Таким образом, ваша доменная/бизнес-логика просочится в шлюз API. Шлюз теперь знает взаимосвязь между Заказами и Продуктами. Эту конфигурацию/скрипты шлюза API необходимо будет поддерживать, и это вводит дополнительную связь.
Choice 3 : The Order Management Service will call directly the Product Catalog Service and asks him for the ProductName givent a product id.
Это мой предпочтительный выбор. Хотя я не рекомендую "прямые" синхронные вызовы. Возможно получение ProductName через механизм обмена сообщениями (очередь сообщений, шина событий). Связанные синхронные вызовы снизят доступность ваших сервисов. Дополнительную информацию можно найти на странице Шаблон обмена сообщениями микросервиса.
Choice 4 : The Order Management Service has a duplicate (but not exhaustive) product informations in its own database and these datas will be updated each time an update event is received from the Product Catalog Service.
Дублирование данных обычно осуждается, если для этого нет действительно веской причины. В данном случае я их не вижу. Зачем разделять базы данных на две для каждой из служб, но при этом дублировать данные между ними? Кроме того, обновление данных каждый раз при получении события обновления указывает на то, что доступна какая-то инфраструктура событий/обмена сообщениями, в таком случае, почему бы просто не использовать обмен сообщениями?
Это дублирование может быть оправдано для больших объемов запросов с малой задержкой, но это скользкий путь, который может привести к дублированию данных во всех ваших службах. Представьте себе последствия изменения длины или типа/формата строки ProductName...
Спасибо за ответ, Сет. Как вы сказали, вариант 3 может быть хорошим. Недостаток, который я вижу, заключается в том, что теперь служба управления заказами не совсем автономна для выполнения бизнес-операции «заказать товар». Если каталога товаров нет, то вся бизнес-операция потерпит неудачу. Я знаю, что идеального выбора не бывает, нужно идти на компромиссы.
Я понимаю, потому что я борюсь с подобными дилеммами. Я думаю, что один из способов взглянуть на это — подумать об автономии с технической точки зрения. Пока интерфейсы остаются прежними или обратно совместимыми, служба управления заказами должна иметь возможность изменяться в максимально возможной степени без какой-либо зависимости от других микрослужб.
" если вашей первоначальной микрослужбе нужны данные, которые изначально принадлежали другим микрослужбам, не полагайтесь на выполнение синхронных запросов для этих данных. Вместо этого реплицируйте или распространяйте эти данные (только те атрибуты, которые вам нужны) в базу данных исходной службы, используя конечную согласованность (обычно с помощью событий интеграции, как описано в следующих разделах)». цитата из документации Microsoft по микросервисам: docs.microsoft.com/en-us/dotnet/standard/…
Вероятно, это лучше подходит для Code Review SE.