Классический пример — когда приходит заказ на распродаже и публикуется событие. И Finance, и Shipping подписаны на событие, но доставка также подписана на событие, исходящее от Finance.
Самое смешное, что вы понятия не имеете о порядке поступления сообщений. Событие от продаж может вызвать техническую ошибку, потому что база данных находится в автономном режиме. Он может снова оказаться в очереди или оказаться в очереди ошибок для операций, чтобы повторить попытку. Тем временем событие от финансов может прибыть. Таким образом, теоретически событие от продаж должно приходить первым, а затем событие по финансам, но на практике может быть наоборот.
Здесь есть несколько решений, но мне никогда не нравились графические. Как разработчик .NET в прошлом я использовал K2 и Windows Workflow Foundation, но самые гибкие решения создаются в коде, а не через графический интерфейс.
В настоящее время я бы использовал для этого NServiceBus или MassTransit. Кстати, сейчас я работаю в Particular Software, и мы делаем NServiceBus. У NServiceBus есть Sagas для такой работы (документация), и вы также можете прочитать в моем блоге о презентация, в т.ч. код на GitHub.
Термин saga немного загружен, но в основном он обрабатывает длительные (бизнес) процессы. Грегор Хопе называет это Process Manager (ссылка).
Подводя итог тому, что делают саги: они создаются входящими сообщениями и имеют состояние. Входящие сообщения привязываются/отправляются к конкретному экземпляру саги на основе идентификатора корреляции, например customer id или order id. После обработки сообщения (события) состояние сохраняется до тех пор, пока не поступит новое сообщение или пока код не пометит эпопею как завершенную и состояние не будет удалено из хранилища.
Как было сказано, в мире .NET MassTransit и NServiceBus поддерживают это, но, скорее всего, есть альтернативы в других средах.
person
Dennis van der Stelt
schedule
02.06.2016
