Микросервисная асинхронная архитектура для реализации сервисов, работающих взаимосвязанно

Question

У меня вопрос по микросервисной архитектуре о сервисах, работающих друг с другом. Например;Давайте подумаем о приведенном ниже сенарио в области электронной коммерции.

У нас есть конечная точка BuyProduct и запрос к этой конечной точке.

1. Запрос браузера

2. BuyProduct выполняется. BuyProduct имеет три вызова службы1) Платежный звонокесли платеж не удастсявернуть ложь;ещеПродолжить;2) Фондовая служба вызоваесли сбой на складевернуть ложь;ещеПродолжить;3) Сервисный звонокесли сбой службы учетной записивернуть ложь;ещеПродолжить;

3. Возврат к успеху или неудаче браузера

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

Мой вопрос:

Если у нас есть брокер сообщений и мы хотим создать асинхронную архитектуру сброкер сообщений (например, rabbitmq или другой). Как мы можем реализовать этот senario? Будет ли это решение действительным или есть какое-либо решение? Какова лучшая практика? Я погуглил, но не смог найти решение, которое меня удовлетворило?

Я не уверен, что мое решение, на мой взгляд, верное (я имею в виду архитектуру синхронизации покоя)

Если браузер ожидает немедленного результата имы хотим гарантировать успешное завершение или сбой наших процессов. Что будет?

Когда мы думаем, что этот senario полностью или ничего, что мы можем сделать?

Answer 1

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

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

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