Должна ли существовать бизнес-логика в отдельных услугах в экосистеме микросервиса?

Question

Предположим, у меня всего 2 службы Оплата и Заказы и один шлюз API, который может отключать запросы к этим услугам для выставления счетов или создания заказов.

Учитывая этот новый сценарий заказа:

1. пользователь создает заказ (запрос -> Rest API)
2. проверки пользователя должно быть сделано
3. объект заказа должен быть создан
4. Billing объект
5. Уведомление об уведомите пользователя

Где должна находиться моя прикладная логика? и должны ли вызовы этих служб выполняться синхронно (в остальном api)? или каждый сервис должен отвечать за вызов другого? например:

Новый запрос заказа пользователя -> Rest API -> требует обслуживания заказов для создания заказа -> (в случае успеха) Rest API -> (в случае успеха) вызывает службу биллинга

Или

Новый запрос на заказ -> Rest API -> вызывает службу заказа для создания порядка -> возвращает ответ. Затем заказывайте обслуживание оттуда асинхронно?

Спасибо!

Answer 1

Ваш вопрос не является полным, но я могу попытаться угадать вопрос из заголовка ...

Каждый компонент должен иметь свою собственную бизнес-логику, компоненты (или microservices) должны быть полностью автономным, не разделяя ничего , никакого кода нет данных.

Компоненты могут поднять события (используя обмен сообщениями), чтобы сообщить о факте что-то добавить.

Имеют смысл?

Вот новый запрос заказа пользователя example in .net using NServiceBus

Answer 2

-> Rest API -> требует обслуживания заказов для создания заказа -> возвращает ответ. Затем заказывайте обслуживание оттуда асинхронно?

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

Новый запрос заказа пользователя -> Rest API -> требует обслуживания заказов для создания заказа -> (в случае успеха) Rest API -> (в случае успеха) называет постоплаты

Ваша вещь, которую вы звоните Rest API в этом описании фактически является бизнес-сервисом (создайте заказ, затем - если успешно - создайте платежную информацию - это бизнес-логика). Ваши шлюзы должны быть очень глупыми, и я советую вам НЕ писать их самостоятельно! There is plenty of gateway solution out there!

Предполагая, что шлюз теперь говорит о заказе (и только о заказе), вам нужно каким-то образом сообщить службе биллинга, что ему необходимо создать платежную информацию для этого заказа! Я полагаю из вашего вопроса, что это необязательно должно происходить синхронно, поэтому я согласен с sean-farmar в этом: используйте какую-то асинхронную связь, чтобы служба биллинга узнала, что вы создали новый порядок. Также обратите внимание на услугу биллинга, чтобы отправить сообщение, как только оно закончит создание платежной информации, поэтому служба заказа может принять это уведомление и добавить идентификатор счета в заказ. И как это вы должны полностью асинхронно:

• создана платежная информация
• связаны, что информация по заказу и
• связала заказ к информации фактуры.

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

К слову: Обновление означает только убийство и запуск новой версии вашего сервиса, что означает, что теперь у вас есть безопасный способ обновления ваших услуг, не влияя на время вашей системы или SLA!

Дайте мне знать, если это было полезно!