В чем разница между сагой, менеджером процессов и подходом на основе документов?

Я понимаю, что все три концепции связаны с долгосрочными транзакциями.

Менеджер процессов, насколько мне известно, конечный автомат, который просто реагирует на события и испускает команды. Он не содержит никакой бизнес-логики, он просто выполняет маршрутизацию. Его цель - довести вас до конечного состояния, когда вы знаете, что ваша транзакция прошла успешно или не удалось.

До сих пор так хорошо.

Но теперь мои проблемы в понимании начинают:

Что такое сага в отличие от диспетчера процессов?
Существует также подход, основанный на документах, как указано в CagRS sagas - я понял их правильно?... как я понимаю, документ - это всего лишь "кусок бумаги", где вы делаете заметки и передаете их. Как это вписывается в концепцию команд и событий?

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

Ответ 1

Взгляните на проект CQRS Journey на MSDN:

http://msdn.microsoft.com/en-us/library/jj591569.aspx

Разъяснение терминологии

Термин сага обычно используется в обсуждениях CQRS для обозначения фрагмент кода, который координирует и направляет сообщения между ограниченным контекстов и агрегатов. Однако для целей настоящего руководства мы предпочитают использовать термин диспетчер процессов для обозначения этого типа кода артефакт. Для этого есть две причины:

Существует известное, ранее существовавшее определение термина сага, имеющее другое значение из того, что обычно понимается в отношение к CQRS. Термин диспетчер процессов - лучшее описание роли, выполняемой этим артефактом кода.

Хотя термин сага часто используется в контексте CQRS шаблон, он имеет уже существующее определение. Мы решили использовать в этом руководстве, чтобы избежать путаницы с этим уже существующее определение.

Термин сага в отношении распределенных систем изначально определенную в газете "Саги" Гектором Гарсией-Молиной и Кеннетом Салем. В этом документе предлагается механизм, который он называет сагой как альтернатива использованию распределенной транзакции для управления долгосрочный бизнес-процесс. В документе признается, что бизнес процессы часто состоят из нескольких этапов, каждый из которых включает транзакцию и что общая согласованность может быть достигнута группируя эти отдельные транзакции в распределенные сделка. Однако в длительных бизнес-процессах, используя распределенные транзакции могут влиять на производительность и concurrencyсистемы из-за блокировок, которые должны удерживаться на время распределенной транзакции.

Ответ 2

Что такое сага в отличие от диспетчера процессов?

Цель этих шаблонов различна. Диспетчер процессов - это шаблон рабочего процесса, который, как вы говорите, может быть построен поверх конечного автомата. Менеджер процессов сохранит состояние между сообщениями и будет содержать логику, чтобы определить, какое действие следует предпринять в ответ на сообщение (например, переход состояния или отправка другого сообщения). Некоторые структуры неправильно ссылаются на них как на саги.

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

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

Являются ли они взаимоисключающими? Можете ли вы пройти весь путь только с одним из них?

Они не являются взаимоисключающими - вероятно, что, например, система, участвующая в саге, может использовать диспетчер процессов для фактической обработки своей части обработки.

Другие ресурсы

Некоторые из этих сообщений могут помочь предоставить более подробную информацию и привести примеры:

Ответ 3

У Saga нет состояния, пока диспетчер процессов имеет.

Другое отличие - Process Manager - это конечный автомат, Saga - нет.

Сага не имеет

состояние конечного автомата
состояние данных (некоторые сохраненные данные)

.. и диспетчер процессов

состояние конечного автомата
состояние данных (некоторые сохраненные данные)

Подробнее в блоге: http://blog.devarchive.net/2015/11/saga-vs-process-manager.html

Ответ 4

Оба диспетчера процессов и сага направляют сообщение через несколько этапов обработки, когда требуемые шаги могут быть неизвестны во время разработки и могут не быть последовательными.

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

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

Ответ 5

Saga и Process Manager - это два шаблона интеграции. Они очень похожи, но не полностью.

Saga - это шаблон, который поможет вам реализовать каждую бизнес-транзакцию, которая охватывает множество сервисов как сагу. Фактически, вы создадите последовательность локальных транзакций, где каждая локальная транзакция обновляет базу данных и публикует сообщение или событие, чтобы вызвать следующую локальную транзакцию в саге. Существует два возможных способа реализации саги: Orchestration (оркестрант рассказывает участникам, какие локальные транзакции выполнять) и хореография (каждая локальная транзакция публикует события домена, которые вызывают локальные транзакции в других сервисах). Очень распространено, что использование Saga будет определять использование CQRS и EventSourcing.
Process Manager - это блок обработки, который он существует для обеспечения состояния последовательности и определения следующего этапа обработки на основе промежуточных результатов. Это шаблон маршрутизации. Это больше похоже на сага о оркестре.