我有几个WorkerRole只做很短时间的工作，把它们放在一个实例中会浪费钱。我们可以将它们合并为一个，但这会很混乱，并且在遥远的将来，当负载增加时它们应该独立工作。
WorkerRole有没有办法像创建“多站点”一样创建“多角色” WebRole？
在否定的情况下，我认为我可以创建一个“主工作者角色”，它能够从给定文件夹加载程序集，查找具有反射的 RoleEntryPoint 派生类，创建实例并调用.Run()or.OnStart()方法。这个“主工作者角色”也会重新抛出意外异常，并在主节点调用时调用.OnStop()所有子节点。它会起作用吗？我应该注意什么？RoleEntryPoint.OnStop()
正如其他人所提到的，这是最大化实例利用率的一种非常常见的技术。可能有示例和“框架”抽象了工作人员基础结构和您想要完成的实际工作，包括这个（我们的）示例中的一个：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
多个工作者角色提供了一个非常干净的实现。但是，空闲角色实例的成本足迹将远高于单个工作角色。
角色组合是我见过的一种常见模式，在他们的 Windows Azure 部署中与 ISV 合作。您可以拥有一个后台线程，该线程每隔一段时间就会唤醒并运行一个进程。另一种常见的实现技术是使用 Azure 队列发送表示要执行的进程的消息。如果需要，您可以有多个队列，也可以有一个命令队列。在任何情况下，您都会在后台线程中运行一个队列侦听器，该线程将在每个实例中运行。第一个获得消息的人会处理它。您可以更进一步，并有一个定时过程将这些消息推送到队列中（可能每 24 小时或每小时一次）。
除了 CPU 和内存限制，请记住单个角色最多只能有 5 个端点（如果您使用远程桌面，则更少）。
编辑：截至 2011 年 9 月，角色配置变得更加灵活，现在您在整个部署中拥有 25 个输入端点（可从外部访问）和 25 个内部端点（用于角色之间的通信）。MSDN 文章在这里
我最近写了一篇关于重载 Web Role 的博客，这有点相关。
虽然已经指出的解决方案没有真正的问题，以寻找在单个 Worker Role 中执行多个 Worker 组件的方法，但我只想让您记住，首先定义不同的 Worker Role 的全部意义在于隔离面对错误。如果您只是将所有内容都塞入一个 Worker Role 实例中，那么只有其中一个表现不佳的 Worker 组件有能力取消该角色中的所有其他 Worker 组件。现在突然之间，您正在编写大量基础架构来提供跨组件的隔离和容错，这几乎就是 Azure 为您提供的。
再说一次，我并不是说严格地做一件事是绝对的。有一个地方可以使单个 Worker Role 下的多个组件有意义（尤其是在monaterily 上）。简单地说，你应该记住为什么它首先是这样设计的，并在你规划你的架构时适当地考虑到这一点。
为什么“多角色”会一团糟？您可以将每个工作角色实现编写为松散耦合的组件，然后从所有适当的组件组成一个工作角色。
当您以后需要将一些职责分离到一个单独的工作者角色时，您可以仅使用该组件组成一个新的工作者角色，同时将其从旧的工作者角色中删除。
如果你愿意，你可以使用后期绑定，这样甚至可以在不重新编译的情况下完成，但我通常认为这不值得付出努力。