每个实例运行多个 WorkerRoles
我有几个仅在短时间内完成工作的 WorkerRole，将它们分别放在一个实例中会浪费金钱。我们可以将它们合并为一个，但这会很混乱，而且在遥远的将来，当负载增加时，它们应该独立工作。
有没有办法像创建“多站点”WebRole 一样创建“多角色”WorkerRole？
在负面情况下，我认为我可以创建一个“主工作者角色”，它能够从给定文件夹加载程序集，通过反射查找 RoleEntryPoint 派生类，创建实例并调用 .Run() 或 .OnStart() 方法。这个“主从角色”也会重新抛出意外异常，并在 .OnStop() 为时在所有子 RoleEntryPoint 中调用 .OnStop()叫来了一位师傅。会起作用吗？我应该注意什么？
I have several WorkerRole that only do job for a short time, and it would be a waste of money to put them in a single instance each. We could merge them in a single one, but it'd be a mess and in the far future they are supposed to work independently when the load increases.
Is there a way to create a "multi role" WorkerRole in the same way you can create a "multi site" WebRole?
In negative case, I think I can create a "master worker role", that is able to load the assemblies from a given folder, look for RoleEntryPoint derivated classes with reflection, create instances and invoke the .Run() or .OnStart() method. This "master worker role" will also rethrown unexpected exceptions, and call .OnStop() in all sub RoleEntryPoints when .OnStop() is called in the master one. Would it work? What should I be aware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正如其他人所提到的，这是最大化实例利用率的一种非常常见的技术。可能有一些示例和“框架”抽象了工作人员基础结构和您想要完成的实际工作，包括本（我们的）示例中的一个：http://msdn.microsoft.com/en-us/library/ff966483.aspx（向下滚动到“实现内部”）
触发工作的最常见方式是：
作业）
上面提到的代码示例实现了 #2 的进一步抽象，并且可以轻松扩展 #1。
但请记住，与队列的所有交互都基于轮询。工作线程不会因队列中的新消息而醒来。您需要主动查询队列以获取新消息。过于频繁的查询会让微软高兴，但可能不会让你高兴:-)。每个查询都算作一次计费交易（其中 10K = 0.01 美元）。一个好的做法是通过某种延迟回退来轮询队列中的消息。另外，批量获取消息。
最后，将这一点发挥到极致，您还可以在单个实例中组合 Web 角色和辅助角色。请参阅此处的示例：http://blog.smarx.com/posts/ windows-azure 中的网页图像捕获
As mentioned by others, this is a very common technique for maximizing utilization of your instances. There may examples and "frameworks" that abstract the worker infrastructure and the actual work you want to be done, including one in this (our) sample: http://msdn.microsoft.com/en-us/library/ff966483.aspx (scroll down to "inside the implementation")
Te most common ways of triggering work are:
jobs)
The code sample mentioned above implements further abstractions for #2 and is easily extensible for #1.
Bear in mind though that all interactions with queues are based on polling. The worker will not wake up with a new message on the queue. You need to actively query the queue for new messages. Querying too often will make Microsoft happy, but probably not you :-). Each query counts as a transaction that is billed (10K of those = $0.01). A good practice is to poll the queue for messages with some kind of delayed back-off. Also, get messages in batches.
Finally, taking this to an extreme, you can also combine web roles and worker roles in a single instance. See here for an example: http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure
多个工作者角色提供了非常干净的实现。然而，空闲角色实例的成本足迹将远高于单个辅助角色。
角色组合是我在 ISV 的 Windows Azure 部署中见过的一种常见模式。您可以拥有一个经常唤醒并运行进程的后台线程。另一种常见的实现技术是使用 Azure 队列发送表示要执行的进程的消息。如果需要，您可以拥有多个队列，也可以拥有单个命令队列。在任何情况下，您都会有一个在后台线程中运行的队列侦听器，该线程将在每个实例中运行。第一个收到消息的人会处理它。您可以更进一步，设置一个定时进程将这些消息推送到队列中（可能每 24 小时或每小时一次）。
除了 CPU 和内存限制之外，请记住，单个角色最多只能有 5 个端点（如果您使用远程桌面，则数量会更少）。编辑：截至 2011 年 9 月，角色配置已变为更加灵活，现在您在整个部署中拥有 25 个输入端点（可从外部世界访问）和 25 个内部端点（用于角色之间的通信）。 MSDN 文章为 这里
我最近有关重载 Web 角色的博客，这有些相关。
Multiple worker roles provide a very clean implementation. However, the cost footprint for idle role instances is going to be much higher than a single worker role.
Role-combining is a common pattern I've seen, working with ISV's on their Windows Azure deployments. You can have a background thread that wakes up every so often and runs a process. Another common implementation technique is to use an Azure Queue to send a message representing a process to execute. You can have multiple queues if you want, or a single command queue. In any case, you would have a queue listener running in a background thread, which would run in each instance. The first one to get the message processes it. You could take it further, and have a timed process pushing those messages onto the queue (maybe every 24 hours, or every hour).
Aside from CPU and memory limits, just remember that a single role can only have a maximum of 5 endpoints (less if you're using Remote Desktop).EDIT: As of September 2011, role configuration has become much more flexible, now that you have 25 Input endpoints (accessible from the outside world) and 25 Internal endpoints (used for communication between roles) across an entire deployment. The MSDN article is here
I recently blogged about overloading a Web Role, which is somewhat related.
虽然已经指出的解决方案没有真正的问题，可以找到在单个辅助角色中执行多个辅助组件的方法，但我只是希望您记住，首先定义不同的辅助角色的全部要点是隔离在错误面前。如果您只是将所有内容都放入单个辅助角色实例中，那么只有其中一个表现不佳的辅助组件就有能力取消该角色中的所有其他辅助组件。现在突然之间，您正在编写大量基础设施来提供跨组件的隔离和容错能力，这几乎就是 Azure 为您提供的功能。
再说一遍，我并不是说一定要严格做一件事。在某个地方，单个辅助角色下的多个组件是有意义的（尤其是单例）。简而言之，您应该首先记住为什么要这样设计，并在规划架构时适当考虑这一点。
While there's no real issue with the solutions that have been pointed out for finding ways to do multiple worker components within a single Worker Role, I just want you to keep in mind the entire point of having distinct Worker Roles defined in the first place is isolation in the face of faults. If you just shove everything into a single Worker Role instance, just one of those worker components behaving badly has the ability to take down every other worker component in that role. Now all of a sudden you're writing a lot of infrastructure to provide isolation and fault tolerance across components which is pretty much what Azure is there to provide for you.
Again, I'm not saying it's an absolute to strickly do one thing. There's a place where multiple components under a single Worker Role makes sense (especially monaterily). Simply saying that you should keep in mind why it's designed this way in the first place and factor that in appropriately as you plan your architecture.
为什么“多重角色”会变得一团糟？您可以将每个辅助角色实现编写为松散耦合组件，然后从所有适当的组件组合一个辅助角色。
当您稍后需要将某些职责分离到单独的辅助角色时，您可以仅使用此组件组成一个新辅助角色，同时将其从旧辅助角色中删除角色。
如果您愿意，您可以使用后期绑定，这样甚至可以在不重新编译的情况下完成此操作，但我通常认为这不值得。
Why would a 'multi role' be a mess? You could write each worker role implementation as a loosely coupled component and then compose a Worker Role from all appropriate components.
When you later need to separate some of the responsibilities out to a separate worker role, you can compose a new worker role with only this component, while at the same time removing it from the old worker role.
If you wanted to, you could employ late binding so that this could even be done without recompilation, but often I don't think that would be worth the effort.