Windows Azure 和其他 NLB 环境上的 WF4 Affinity
我正在使用 Windows Azure 和 WF4，我的工作流服务托管在 Web 角色中（具有 N 个实例）。我现在的工作是找出如何 进行关联，以便我可以将消息发送到正确的工作流实例。为了解释这种情况，我的工作流程（附后）从“StartWorkflow”接收活动开始，创建 3 个“人”，并以并行方式等待这 3 个人的确认（“ConfirmCreation”接收活动）。
然后我开始搜索如何在其他 NLB 环境中进行关联（主要是查找有关 Windows Server AppFabric 上如何工作的信息），但我没有找到准确的答案。那么在其他 NLB 环境中是如何完成的呢？
我的下一个任务是找出如何实现一个系统来处理 Windows Azure 上的这种亲和力，以及该解决方案的成本是多少（价格、时间和工作量），看看它是否可行，或者只使用一个解决方案是否更好当我们等待 Azure AppFabric 的 WF4 主机时，Web 角色实例。我发现的唯一方法是保留工作流实例。还有其他方法可以做到这一点吗？
我的第三个（但不是最后一个）任务是找出 WF4 如何处理同时收到的多个消息。在我的场景中，这意味着如果3个人同时确认并且确认消息也同时收到，它将如何处理。由于这个问题最合乎逻辑的答案似乎是使用队列，因此我开始在 WF4 上查找有关队列的信息，并发现有人在谈论 MSQM。但是本机 WF4 消息处理系统是什么？这个处理程序真的是一个队列还是另一个系统？这个并发是如何处理的？
I'm using Windows Azure and WF4 and my workflow service is hosted in a web-role (with N instances). My job now is find out how
to do an affinity, in a way that I can send messages to the right workflow instance. To explain this scenario, my workflow (attached) starts with a "StartWorkflow" receive activity, creates 3 "Person" and, in a parallel-for-each, waits for the confirmation of these 3 people ("ConfirmCreation" Receive Activity).
I then started to search how the affinity is made in others NLB environments (mainly looked for informations about how this works on Windows Server AppFabric), but I didn't find a precise answer. So how is it done in others NLB environments?
My next task is find out how I could implement a system to handle this affinity on Windows Azure and how much would this solution cost (in price, time and amount of work) to see if its viable or if it's better to work with only one web-role instance while we wait for the WF4 host for the Azure AppFabric. The only way I found was to persist the workflow instance. Is there other ways of doing this?
My third, but not last, task is to find out how WF4 handles multiple messages received at the same time. In my scenario, this means how it would handle if the 3 people confirmed at the same time and the confirmation messages are also received at the same time. Since the most logical answer for this problem seems to be to use a queue, I started looking for information about queues on WF4 and found people speaking about MSQM. But what is the native WF4 messages handler system? Is this handler really a queue or is it another system? How is this concurrency handled?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你不应该需要任何亲和力。事实上，这就是持久工作流程的全部要点。当您的工作流程等待此确认时，它应该被保留并从任何一台服务器卸载。
就 Windows Azure 的持久性而言，您要么需要破解标准 SQL 持久性脚本，以便它们在 SQL Azure 上工作，要么编写您自己的
InstanceStore实现位于 Azure 存储之上。我们已经为在 Azure 中运行的工作流程完成了后者，但我无法共享代码。按照 1 到 10 的工作量等级，我将其排名在 8 左右。就多条消息而言，将会发生的情况是，将一次一条消息接收消息并将其传递到工作流实例。现在，这些消息中的每一条都可能会发送到同一台服务器，或者可能每条消息都会发送到不同的服务器。服务器。无论如何发生，工作流运行时都会尝试从实例存储加载工作流，查看它当前是否已锁定并阻止/重试，直到工作流可用于处理下一条消息。因此，只要正确配置所有内容并且 InstanceStore 实现正在执行其工作，您就不必担心对同一工作流实例的并发访问。
以下是一些其他建议：
You shouldn't need any affinity. In fact that's kinda the whole point of durable Workflows. Whilst your workflow is waiting for this confirmation it should be persisted and unloaded from any one server.
As far as persistence goes for Windows Azure you would either need to hack the standard SQL persistence scripts so that they work on SQL Azure or write your own
InstanceStoreimplementation that sits on top of Azure Storage. We have done the latter for a workflow we're running in Azure, but I'm unable to share the code. On a scale of 1 to 10 for effort, I'd rank it around an 8.As far as multiple messages, what will happen is the messages will be received and delivered to the workflow instance one message at a time. Now, it's possible that every one of those messages goes to the same server or maybe each one goes to a diff. server. No matter how it happens, the workflow runtime will attempt to load the workflow from the instance store, see that it is currently locked and block/retry until the workflow becomes available to process the next message. So you don't have to worry about concurrent access to the same workflow instance as long as you configure everything correctly and the
InstanceStoreimplementation is doing its job.Here's a few other suggestions:
<workflowIdle timeToUnload="00:00:00" /><sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />目前，使用 Azure 1.3 SDK 与 SQL Azure 一起使用开箱即用的 SQL 实例存储有点问题，因为每次部署，即使您进行了 0 次代码更改，也会导致新的服务部署，这意味着已经保留的工作流可以不继续了这是一个将被解决的错误，但目前还属于 PITA。
正如 Drew 所说，您的工作流实例应该根据需要从一个服务器移动到另一个服务器，无需将其固定到特定的计算机。即使可以，这也会损害可扩展性和可靠性，因此应该避免。
使用 WCF NetMsmqBinding 通过 MSMQ 发送消息效果很好。 WF 在内部使用一种完全不同的机制，称为书签，允许工作流程停止和恢复。每个接收活动以及其他活动（如延迟）都将创建一个书签并等待其恢复。您只能恢复现有书签。即使恢复书签也不是直接操作，而是由工作流调度程序放入内部队列（而不是 MSMQ）中，并通过 SynchronizationContext 执行。您无法控制调度程序，但可以在使用 WorkflowApplication 时替换 SynchronizationContext，从而对活动的执行方式和位置进行一些控制。
Using the out of the box SQL instance store with SQL Azure is a bit of a problem at the moment with the Azure 1.3 SDK as each deployment, even if you made 0 code changes, results in a new service deployment meaning that already persisted workflows can't continue. That is a bug that will be solved but a PITA for now.
As Drew said your workflow instance should just move from server to server as needed, no need to pin it to a specific machine. And even if you could that would hurt scalability and reliability so something to be avoided.
Sending messages through MSMQ using the WCF NetMsmqBinding works just fine. Internally WF uses a completely different mechanism called bookmarks that allow a workflow to stop and resume. Each Receive activity, as well as others like Delay, will create a bookmark and wait for that to be resumed. You can only resume existing bookmarks. Even resuming a bookmark is not a direct action but put into an internal queue, not MSMQ, by the workflow scheduler and executed through a SynchronizationContext. You get no control over the scheduler but you can replace the SynchronizationContext when using the WorkflowApplication and so get some control over how and where activities are executed.