Проблема масштабируемости Saga Orchestration в микросервисной архитектуре

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

Воспользуемся примером ниже. CreateOrderSaga может быть много, если у меня несколько OrderService.API, и это будет так. Потому что у меня может быть несколько OrderService.API. Тогда, если CreateOrderSaga является своего рода конечным автоматом, значит ли это, что он должен обрабатывать все шаги в нем самостоятельно или другие координаторы могут выполнять его работу?

Тогда что, если этот один API выйдет из строя во время выполнения процесса саги, могут ли другие координаторы саг продолжать работать с тем же состоянием, в котором остался аварийный API? Как лучше всего справиться с этой ситуацией? Как может помочь хранение событий?

Позвольте мне объяснить подробнее

  1. Coordinator1 в одном из Order.API запускает CreateOrderSaga

  2. CreateOrderSaga в Coordinator1 создает заказ, который находится в состоянии ожидания.

  3. Потом по какой-то причине вылетел Coordinator1. (возможно, электричество пропало) заказ остался в состоянии ожидания и никого не интересует. Кто-то должен продолжить его обработку или пометить его как неудачный (кто несет ответственность). Возможно, также необходимы некоторые компенсационные транзакции.

Так можно ли заставить координатора саги запускать процесс, но другие также могут продолжать его обрабатывать?

Как можно увеличить масштаб координатора саг?

введите здесь описание изображения

c

Решение:

Я выбрал Masstransit для управления распределенными транзакциями


microservices c# saga
person Barış Velioğlu    schedule 02.12.2019    source источник
comment
Вы вообще изучали служебные сети?   -  person    schedule 02.12.2019
comment
@JoshWilliard Я не уверен, что сервисная сетка обеспечивает распределенную транзакцию.   -  person Barış Velioğlu    schedule 02.12.2019
comment
Сквозная трассировка распределенных транзакций - один из многих преимуществ развертывания сервисной сети.   -  person    schedule 02.12.2019
comment
Вы говорите о параллелизме в случае сбоя? Как вы справляетесь с параллелизмом? Вы пробовали модель программирования актеров? Service Fabric / Akka.Net / Орлеан   -  person Praveen Raghuvanshi    schedule 02.12.2019
comment
specific.net/blog/you-dont-need-ordered-delivery   -  person Praveen Raghuvanshi    schedule 02.12.2019

Ответы (1)


arrow_upward
3
arrow_downward

Паттерн сага должен быть реализован как асинхронный процесс. В данном случае asynchronous означает отправку сообщений. Большинство типов очередей сообщений имеют функцию подтверждения (для rabbitmq). Здесь я собираюсь описать службы без сохранения состояния (т.е. нормально обрабатывать CreateOrder запросы в разных экземплярах OrderService).

Вы нажимаете кнопку «сделать заказ», CreateOrder сообщение отправляется в очередь сообщений, OrderService получает это сообщение из очереди. Он масштабируется, потому что вы можете создать множество экземпляров OrderService.

Тогда у нас есть два случая:

1. Сага, основанная на оркестровке: OrderService получает сообщение, создает экземпляр координатора, координатор потребляет CustomerService. Если OrderService завершится ошибкой до завершения обработки сообщения, CreateMessage сообщение не будет подтверждено в очереди сообщений. Впоследствии другой экземпляр OrderService получит сообщение и попытается его обработать. Если CustomerService завершился ошибкой во время вызова: вы можете пропустить все CreateOrder сообщение и повторить его позже или повторить конкретный вызов CustomerService.

2. Сага, основанная на хореографии: OrderService получает сообщение и пытается его обработать. Если это не удается, то ситуация такая же: сообщение не будет подтверждено и будет повторно доставлено для следующей повторной попытки позже. Этот подход заключается в генерировании таких событий, как OrderCreated, CustomerCreated и т. Д. (Т.е. он ориентирован на события)

Конечно, вы должны настроить мониторинг и оповещения для своих служб, чтобы убедиться, что система работает и может обрабатывать сообщения.

Также вы должны подумать, нужно ли вам реализовать некоторую логику компенсации или проверки. Представьте себе: вы делаете два запроса HTTP POST к разным службам при обработке сообщения, первый вызов службы завершен успешно, а второй - неуспешно. Если повторить попытку всего CreateOrder сообщения - не следует повторно вызывать первую службу.

Дополнительная литература: обзор саг , координирующие саги, саги на основе хореографии:

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

Чтобы получить дополнительные сведения о том, как его правильно реализовать, прочитайте, как реализована структура саги NServiceBus. Это .NET framework для саг, но концепции не зависят от языка.

person mtkachenko    schedule 02.12.2019
comment
Как происходит общение в хореографии. UI - ›OrderService -› CustomerService? - person Praveen Raghuvanshi; 02.12.2019
comment
@PraveenRaghuvanshi очередь сообщений производитель-потребитель en.wikipedia.org/wiki/Message_queue - person mtkachenko; 02.12.2019
comment
Просто пытаюсь понять разницу между двумя упомянутыми вами подходами. Оба они работают с очередями сообщений. В чем разница? - person Praveen Raghuvanshi; 02.12.2019
comment
@PraveenRaghuvanshi в случае начального сообщения Orchestration и все события отправляются в очередь. В случае Хореографии в очередь отправляется только начальное сообщение. - person mtkachenko; 02.12.2019
comment
@PraveenRaghuvanshi На самом деле MQ можно использовать и в случае координатора. Основное отличие состоит в том, что у вас есть одно место для координации потока саги. В случае с хореографическими сервисами просто испускают события, а другие сервисы слушают. - person mtkachenko; 02.12.2019
comment
Можем ли мы сказать specific.net/blog/you-dont-need-ordered-delivery - это пример саги, основанной на оркестровке, а на основе хореографии - на основе событий (включая события для сбоев)? - person Praveen Raghuvanshi; 02.12.2019
comment
Давайте продолжим это обсуждение в чате. - person Praveen Raghuvanshi; 02.12.2019
comment
Я понимаю идею, но проблема в том, что обычно показаны примеры, поскольку оркестровка - это своего рода конечный автомат. Но вы говорите, что каждое сообщение о событии может быть взято из очереди сообщений и может быть обработано одним из координаторов. Но если я это сделаю, то будет сложно компенсировать возникновение каких-либо ошибок, потому что конечный автомат может быть запущен любым из координаторов. Затем конечный автомат может быть запущен с одним из состояний, потому что любезно новый координатор может обработать следующее событие. Теперь стало труднее поддерживать, если координатор запуска не является тем, который завершает конечный автомат. - person Barış Velioğlu; 03.12.2019
comment
@ BarışVelioğlu Координатор недолговечен. Его можно создать на любом сервере. Да, правильно реализовать это непросто. Вы должны где-нибудь сохранить состояние саги. Это дает вам возможность восстановить координатор в допустимом состоянии. О компенсации: в распределенных системах вы все равно должны думать о компенсации. Чтобы получить дополнительные сведения о том, как его правильно реализовать, прочтите docs.particular.net/nservicebus/sagas/concurrency. Это .NET framework для саг, но концепции не зависят от языка. - person mtkachenko; 03.12.2019