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

Question

我正在使用Windows Azure和WF4，并且我的工作流服务托管在Web角色（带有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位左右。

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

下面的几个其他建议：

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

Answer 2

使用即开即用的SQL实例存储与SQL Azure在使用Azure 1.3 SDK作为每个部署时存在一些问题，即使您对代码进行了0次更改，也导致了新的服务部署，这意味着已经持续的工作流程无法继续。这是一个可以解决的错误，但现在是PITA。

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

使用WCF通过MSMQ发送消息NetMsmqBinding工作得很好。内部WF使用称为书签的完全不同的机制，允许工作流程停止并恢复。每个Receive活动以及其他一些类似Delay的项目将创建一个书签并等待恢复。您只能恢复现有的书签。即使恢复书签也不是直接操作，而是由工作流调度程序放入内部队列中，而不是MSMQ，并通过SynchronizationContext执行。您无法控制调度程序，但可以在使用WorkflowApplication时替换SynchronizationContext，从而获得对如何以及在何处执行活动的控制权。