我有几个WorkerRole只能在短时间内完成工作，将它们分别放在一个实例中会浪费金钱。我们可以将它们合并为一个，但它会变得一团糟，在不久的将来它们应该在负载增加时独立工作。
是否有办法创建“多角色”WorkerRole的方式与创建“多站点”WebRole的方式相同？
在否定的情况下，我认为我可以创建一个“主工作者角色”，它能够从给定文件夹加载程序集，查找具有反射的RoleEntryPoint派生类，创建实例并调用.Run()或.OnStart()方法。此“主工作者角色”也将重新发生意外异常，并在主要成员调用.OnStop()时调用所有子RoleEntryPoint中的.OnStop()。会有用吗？我应该注意什么？
答案 0 :(得分：8)
正如其他人所说，这是一种非常常见的技术，可以最大限度地利用您的实例。可能有示例和“框架”抽象工作者基础结构和您想要完成的实际工作，包括本（我们）样本中的一个：http://msdn.microsoft.com/en-us/library/ff966483.aspx（向下滚动到“实现内部”）
最常见的触发工作方式是：
上面提到的代码示例实现了＃2的进一步抽象，并且很容易为＃1扩展。
请记住，与队列的所有交互都基于轮询。工作人员不会在队列中使用新消息唤醒。您需要主动查询队列以获取新消息。过于频繁地查询会让微软高兴，但可能不是你:-)。每个查询都算作一个计费的交易（其中10K = $ 0.01）。一个好的做法是在队列中查询具有某种延迟退避的消息。另外，批量获取消息。
最后，考虑到这一点，您还可以在单个实例中组合Web角色和辅助角色。请参阅此处以获取示例：http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure
答案 1 :(得分：5)
多个辅助角色提供了非常干净的实现。但是，空闲角色实例的成本足迹将远远高于单个工作者角色。
角色组合是我见过的一种常见模式，在其Windows Azure部署中与ISV合作。您可以拥有一个每隔一段时间就会唤醒的后台线程并运行一个进程。另一种常见的实现技术是使用Azure队列发送表示要执行的进程的消息。如果需要，可以有多个队列，也可以是单个命令队列。在任何情况下，您都会在后台线程中运行队列侦听器，后台线程将在每个实例中运行。第一个获取消息的消息处理它。你可以更进一步，并有一个定时的过程将这些消息推送到队列（可能每24小时，或每小时）。
除了CPU和内存限制之外，请记住，单个角色最多只能有5个端点（如果使用远程桌面，则更少）。
编辑：截至2011年9月，角色配置变得更加灵活，现在您可以在整个部署中拥有25个输入端点（可从外部访问）和25个内部端点（用于角色之间的通信）。 MSDN文章为here
我最近blogged about overloading a Web Role，这有点相关。
答案 2 :(得分：4)
虽然已经指出了寻找在单个辅助角色中执行多个工作组件的方法的解决方案没有实际问题，但我只想让您牢记在第一个工作者角色中定义了不同的工作者角色的整个过程。面对错误，地方是孤立的。如果您只是将所有内容都推送到单个Worker Role实例中，那么只有其中一个工作组件表现不佳就能够删除该角色中的每个其他工作组件。现在突然之间，您正在编写大量基础结构来提供跨组件的隔离和容错能力，这正是Azure为您提供的基础。
同样，我并不是说严格做一件事是绝对的。有一个地方，单个工人角色下的多个组件是有意义的（特别是单一的）。简单地说，你应该记住为什么它首先以这种方式设计，并在计划你的架构时适当考虑因素。
答案 3 :(得分：3)
为什么“多重角色”会变得一团糟？您可以将每个辅助角色实现编写为松散耦合的组件，然后从所有适当的组件撰写工作者角色。
如果您以后需要将某些职责分离到单独的工作人员角色，则可以仅使用此组件构建新工作人员角色，同时将其从旧工人角色。
如果您愿意，可以使用后期绑定，这样甚至可以在不重新编译的情况下完成，但我常常认为这不值得付出努力。