3

我使用的是 Windows Azure 和 WF4，我的工作流服务托管在一个网络角色中（有 N 个实例）。我现在的工作是找出如何进行关联，以便我可以将消息发送到正确的工作流实例。为了解释这种情况，我的工作流程（附加）从“StartWorkflow”接收活动开始，创建 3 个“Person”，并以并行方式等待这 3 个人的确认（“ConfirmCreation”接收活动）。

然后我开始搜索在其他 NLB 环境中是如何产生亲和力的（主要是寻找有关它如何在 Windows Server AppFabric 上工作的信息），但我没有找到准确的答案。那么在其他 NLB 环境中是如何完成的呢？

我的下一个任务是找出如何实现一个系统来处理 Windows Azure 上的这种亲和力，以及这个解决方案的成本（价格、时间和工作量）是否可行，或者只使用一个解决方案是否更好web-role 实例，同时我们等待 Azure AppFabric 的 WF4 主机。我发现的唯一方法是持久化工作流实例。还有其他方法可以做到这一点吗？

我的第三个（但不是最后一个）任务是找出 WF4 如何处理同时收到的多条消息。在我的场景中，这意味着如果 3 个人同时确认并且同时收到确认消息，它将如何处理。由于这个问题最合乎逻辑的答案似乎是使用队列，因此我开始在 WF4 上查找有关队列的信息，并发现有人在谈论 MSQM。但是什么是原生 WF4 消息处理系统？这个处理程序真的是一个队列还是另一个系统？这种并发是如何处理的？

4

2 回答 2

2

你不应该需要任何亲和力。事实上，这就是持久工作流的全部意义所在。当您的工作流程正在等待此确认时，它应该被保留并从任何一台服务器上卸载。

就 Windows Azure 的持久性而言，您要么需要破解标准的 SQL 持久性脚本，以便它们在 SQL Azure 上工作，要么编写您自己的InstanceStore位于 Azure 存储之上的实现。我们为在 Azure 中运行的工作流完成了后者，但我无法共享代码。在 1 到 10 的努力等级上，我将其排在 8 左右。

至于多条消息，将发生的情况是消息将被接收并一次一条消息传递到工作流实例。现在，这些消息中的每一条都有可能发送到同一台服务器，或者每条消息都发送到不同的服务器。服务器。无论它如何发生，工作流运行时都将尝试从实例存储加载工作流，查看它当前被锁定并阻止/重试，直到工作流可用于处理下一条消息。因此，只要您正确配置所有内容并且InstanceStore实现工作正常，您就不必担心对同一工作流实例的并发访问。

这里有一些其他的建议：

  • 确保在 SendReply 活动中使用 PersistBeforeSend 选项
  • 配置以下工作流服务选项
    • <workflowIdle timeToUnload="00:00:00" />
    • <sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />
于 2011-03-18T21:58:07.087 回答
1

使用 SQL Azure 开箱即用的 SQL 实例存储目前使用 Azure 1.3 SDK 作为每个部署有点问题，即使您进行了 0 次代码更改，也会导致新的服务部署，这意味着已经持久化的工作流可以不要继续。这是一个将要解决的错误，但现在是一个 PITA。

正如 Drew 所说，您的工作流实例应该根据需要从服务器移动到服务器，无需将其固定到特定机器。即使你可以这样做会损害可扩展性和可靠性，所以要避免一些事情。

使用 WCF NetMsmqBinding 通过 MSMQ 发送消息可以正常工作。WF 在内部使用一种完全不同的机制，称为书签，它允许工作流停止和恢复。每个接收活动以及其他活动（如延迟）都会创建一个书签并等待它恢复。您只能恢复现有书签。即使恢复书签也不是直接操作，而是由工作流调度程序放入内部队列而不是 MSMQ 并通过 SynchronizationContext 执行。您无法控制调度程序，但您可以在使用 WorkflowApplication 时替换 SynchronizationContext，从而对执行活动的方式和位置进行一些控制。

于 2011-03-19T07:28:47.517 回答