每个实例运行多个WorkerRoles

Question

我有几个WorkerRole只能在短时间内完成工作，并且将它们分别放在单个实例中将浪费金钱。我们可以将它们合并为一个，但它会是一团糟，而且在很远的将来，它们应该在负载增加时独立工作。

有没有办法像创建“多站点”WebRole一样创建“多角色”WorkerRole？在负面的情况下，我想我可以创建一个“master worker role”，它能够从给定的文件夹加载程序集，使用反射来查找RoleEntryPoint派生类，创建实例并调用.Run()或.OnStart()方法。这个“主人工角色”也会重新发生意想不到的异常，并且在主人调用.OnStop()时，在所有子RoleEntryPoint中调用.OnStop()。它会起作用吗？我应该知道什么？

Answer 1

正如其他人所提到的，这是一种非常常见的技术，可以最大限度地利用您的实例。有可能的例子和“框架”是抽象的，你想要做的，其中包括这（我们的）样本中的工作者基础和实际工作：http://msdn.microsoft.com/en-us/library/ff966483.aspx（向下滚动到实施“内部”）

特最常见的方法触发的工作是：

1. 时间安排工人（如“cron的” 作业）
2. 消息baseds工人（通过消息的存在而触发的工作）。

上面提到的代码示例实现了＃2的进一步抽象，并且对于＃1很容易扩展。

请记住，所有与队列的交互都基于轮询。工作人员不会在队列中看到新消息。您需要主动向队列查询新消息。经常查询会让微软感到高兴，但可能不是你:-)。每个查询计为一笔交易（10K = $ 0.01）。一个好的做法是轮询队列中的某种延迟回退消息。此外，批量获取消息。

最后，将这种情况考虑到极端，您还可以将Web角色和工作角色合并到一个实例中。看到这里的一个例子：http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure

Answer 2

为什么'多角色'会变成一团糟？您可以将每个辅助角色实现编写为松散耦合组件，然后组合来自所有适当组件的工作者角色。

当以后需要单独的一些责任了一个单独的工作角色，你可以撰写一个新的工作角色，只有此组件，而在同一时间从老工人角色删除。

如果你愿意，你可以雇用后期绑定，这样即使不重新编译也可以完成，但我经常认为这不值得。

Answer 3

多个工作者角色提供了一个非常干净的实现。但是，空闲角色实例的成本足迹将远远高于单个工作者角色。

角色组合是我见过的一种常见模式，与ISV在他们的Windows Azure部署上合作。你可以有一个后台线程，每隔一段时间唤醒一次并运行一个进程。另一种常见的实现技术是使用Azure队列发送代表要执行的进程的消息。如果需要，可以有多个队列，或者一个命令队列。在任何情况下，你都可以在后台线程中运行一个队列监听器，后者将在每个实例中运行。第一个获取消息处理它。您可以进一步采取措施，并有一个定时进程将这些消息推送到队列中（可能每24小时或每小时）。

除了CPU和内存限制，只需记住一个角色最多只能有5个端点（如果使用远程桌面，则最少）。

编辑：截至2011年9月，角色配置变得更加灵活了，现在您已在整个部署中拥有25个输入端点（可从外部访问）和25个内部端点（用于角色之间的通信）。 MSDN文章是here

我最近blogged about overloading a Web Role，这有点相关。

Answer 4

虽然没有一个真正的问题，已经指出的解决方案，找到方法来做一个工人角色内的多个工人组件，我只是希望你记住的整个点首先定义不同的工人角色是面对缺陷时的孤立。如果您只是将所有内容都推送到一个工作者角色实例中，那么只有其中一个行为不良的工作者组件能够关闭该角色中的其他工作组件。现在突然之间，您正在编写大量基础架构来提供跨组件的隔离和容错功能，这几乎是Azure为您提供的。

再说一遍，我并不是说这绝对是一件好事。有一个地方，一个工作人员角色下的多个组件是有意义的（尤其是一次性的）。简单地说，你应该牢记为什么它是这样设计的，并且在你规划你的建筑时适当地考虑它。