编排服务是否不适合实施工作流程？答案

【问题标题】：Are orchestration services unfit to implement a workflow process?编排服务是否不适合实施工作流程？
【发布时间】：2012-09-17 09:53:50
【问题描述】：

我在使用 nservicebus 实施工作流程过程中遇到问题，我使用版本 2.0.1329.2 并且我尝试实施的工作流程非常简单：

我有一个需要计算的文章列表，工作流程从发布的第一个列表开始。之后，用户可以进行其他发布，从原始列表中添加或删除一些文章。每个列表都有一个代码标识符。

我已经使用由列表代码标识的编排服务来实现它。在传奇数据中，也有列出列表的所有文章的引用。

问题在于：当用户发布文章列表时，当同一列表的另一个发布正在进行时，没有任何进程状态锁定，这样就没有并发控制，但处理程序将完成稍后将有自己的数据持久化。

例如：

在时间 [t+6] 我应该添加 6 个元素，但我只添加了 5 个元素..

我认为行为应该是这样的：如果与同一个列表相关，第二个消息应该找到进程状态锁定，直到第一个完成。否则如果与另一个列表相关，则应该并行处理。

为此，我想知道编排服务是否没有适当地支持工作流流程的实现，除非将工作线程的数量设置为只有一个会失去并行效率。

【问题讨论】：

您使用的隔离级别是多少？使用可序列化，包含 10 篇文章的第一条消息应该无法保存并重新处理。
在哪里可以设置不同的隔离级别？无论如何，消息 1 失败并且重新处理不是正确的轨道，因为以这种方式假设在第二条消息中我不想只添加 1 个项目，而是要删除 3 个。消息 2 将首先被处理，并且在消息 1 的处理发生更改会迷路了。
已删除邮件有一个墓碑的概念。搜索矢量时钟和墓碑。 Microsoft Sync 框架解释得还不错here

【解决方案1】：

您使用的是非常旧的 NServiceBus 版本，应该升级。从那以后修复了这么多错误，真的不值得您花时间尝试处理这些问题。

【讨论】：

【解决方案2】：

您需要设计您的传奇/长期运行的进程来解决所有并发问题。很难说或推荐其他任何东西。

文章的发布是否需要很长时间以致遇到并发问题？
或者，它们是否如此频繁地重新发布？

当一个文章列表首次发布时，其他人如何修改或重新发布它，而它还没有生成？

【讨论】：

当我为面向服务的架构建模时，我不能做这样的假设，我可以有一个客户端应用程序来创建项目列表并允许在工作流仍在计算时修改其中的一部分。我知道我应该设计我的传奇流程来解决所有这些问题，但这就是重点。像我这样建模的编排服务的缺陷在哪里？在未来的集成中如何防止它？