Windows Azure 和其他 NLB 环境中的 WF4 Affinity

Question

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

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

我的下一个任务是找出如何在 Windows Azure 上实施一个系统来处理这种相似性，以及这个解决方案的成本（在价格、时间和工作量方面）是否可行或者是否更好地工作在我们等待 Azure AppFabric 的 WF4 主机时，只有一个 Web 角色实例。我发现的唯一方法是持久化工作流实例。还有其他方法吗？

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

Answer 1

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

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

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

这里有一些其他建议：

• 确保在 SendReply 活动中使用 PersistBeforeSend 选项
• 配置以下工作流服务选项
  • <workflowIdle timeToUnload="00:00:00" />
  • <sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />

Answer 2

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

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

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