azure - Windows Azure 和其他 NLB 环境上的 WF4 Affinity

Question

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

然后我开始搜索如何在其他 NLB 环境中进行关联(主要是查找有关 Windows Server AppFabric 上如何工作的信息)，但我没有找到准确的答案。那么在其他 NLB 环境中是如何完成的呢？

我的下一个任务是找出如何实现一个系统来处理 Windows Azure 上的这种亲和性，以及该解决方案的成本是多少(价格、时间和工作量)，以查看其是否可行或是否更好工作当我们等待 Azure AppFabric 的 WF4 主机时，只有一个 Web 角色实例。我发现的唯一方法是保留工作流实例。还有其他方法可以做到这一点吗？

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

Answer 1

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

就 Windows Azure 的持久性而言，您要么需要破解标准 SQL 持久性脚本，以便它们在 SQL Azure 上工作，要么编写您自己的 InstanceStore 位于 Azure 存储之上的实现。我们已经为在 Azure 中运行的工作流程完成了后者，但我无法共享代码。按照 1 到 10 的努力程度，我会给它打大约 8 分。

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

这里有一些其他建议:

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