传奇,流程管理器和基于文档的方法有什么区别?

Gol*_*den 46 cqrs

据我所知,这三个概念都与长期运行的交易有关.

据我所知,进程管理器是一个有限状态机,它简单地响应事件并发出命令.它不包含任何业务逻辑,只是路由.它的目标是让您进入最终状态,在那里您知道您的交易成功或失败.

到现在为止还挺好.

但是现在我的理解开始了:

  • 与流程经理相比,什么是传奇?
  • 还有基于文档的方法,正如CQRS传奇中提到的那样 - 我理解它们了吗?......据我所知,一份文件只是一张"纸条",你可以在其中记笔记并随身携带.这如何适合命令和事件的概念?

任何人都可以解释这些差异,并且 - 我特别感兴趣的是 - 这些概念中的哪一个对于什么是好的,什么时候你需要什么.它们是互相排斥的吗?你可以只用其中一个一路走吗?您是否需要多个场景?...?

小智 46

与流程经理相比,什么是传奇?

这些模式的意图是不同的.流程管理器是一种工作流模式,正如您所说,它可以构建在状态机之上.进程管理器将在消息之间保留状态,并将包含逻辑以确定响应消息应采取的操作(例如,转换状态或发送另一个消息).一些框架错误地将这些称为传奇.

相比之下,一个传奇(根据原始定义)是一种旨在帮助管理失败的模式.它涉及跨系统的多个工作流程,其中每个工作流程允许在其他地方发生故障的情况下在稍后的事务中采取某种形式的补偿操作.

这种补偿是传奇的定义特征.请注意,传奇本身并不知道补偿行为可能是什么.Sagas通常使用路由滑动模式来实现.

它们是互相排斥的吗?你可以只用其中一个一路走吗?

它们并不相互排斥 - 例如,参与传奇的系统可能会使用流程管理器来实际处理其处理过程.

其他资源

其中一些帖子可能有助于提供更多细节并提供示例:


Jak*_*cki 26

看一下MSDN上的CQRS Journey项目:

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

澄清术语

术语saga通常用于CQRS的讨论中,以指代在有界上下文和聚合之间协调和路由消息的一段代码.但是,出于本指南的目的,我们更喜欢使用术语流程管理器来引用此类代码工件.有两个原因:

有一个众所周知的,预先存在的术语定义saga,其含义与通常与CQRS有关的含义不同.术语流程管理器是对此类代码工件执行的角色的更好描述.

虽然术语saga经常在CQRS模式的上下文中使用,但它具有预先存在的定义.我们选择在本指南中使用术语流程管理器,以避免与此预先存在的定义混淆.

与分布式系统相关的术语saga最初在Hector Garcia-Molina和Kenneth Salem的论文"Sagas"中定义.本文提出了一种机制,它将saga称为使用分布式事务来管理长期运行的业务流程的替代方法.本文认识到业务流程通常由多个步骤组成,每个步骤都涉及一个事务,并且可以通过将这些单独的事务分组到分布式事务中来实现整体一致性.但是,在长时间运行的业务流程中,使用分布式事务会影响系统的性能和并发性,因为在分布式事务期间必须保持锁定.

  • 据我所知,Process Manager是Saga的一个新术语,它被引入以限制在分布式事务世界中使用术语Saga的不同含义的混​​淆.所以流程经理*是CQRS中的*Saga. (6认同)

Kir*_*ili 7

当过程管理器有时,Saga没有州.

另一个区别 - 进程管理器是状态机,Saga不是.

佐贺没有

  • 国家机器状态
  • 数据状态(一些持久数据)

..和流程经理有

  • 国家机器状态
  • 数据状态(一些持久数据)

阅读我的博客:http: //blog.devarchive.net/2015/11/saga-vs-process-manager.html

  • 我确定一个传奇可以拥有国家?如果没有,它怎么能长时间运行和容错? (4认同)
  • 总是包括链接的同意,即使它是你自己的博客;) (2认同)

Din*_*dan 6

Saga和Process Manager是两种集成模式。它们非常相似,但不完全相同。

  • 传奇是一种模式,可帮助您将跨越多个服务的每个业务交易作为传奇来实现。实际上,您将创建一系列本地事务,其中每个本地事务都会更新数据库并发布消息或事件以触发传奇中的下一个本地事务。有两种实现传奇的可能方法:编排(协调器告诉参与者要执行哪些本地事务)和编排(每个本地事务发布触发其他服务中本地事务的域事件)。使用Saga决定CQRS和EventSourcing的使用是非常普遍的。
  • 流程管理器是一个存在的处理单元,用于维护序列状态并根据中间结果确定下一个处理步骤。这是一个路由模式。它更像是Orchestrator Saga。