每个实例运行多个WorkerRoles

vto*_*ola 17 azure azure-worker-roles

我有几个WorkerRole只能在短时间内完成工作,将它们分别放在一个实例中是浪费钱.我们可以将它们合并为一个,但它会变得混乱,并且在不久的将来它们应该在负载增加时独立工作.

有没有办法WorkerRole像创建"多站点"一样创建"多角色" WebRole

在否定的情况下,我认为我可以创建一个"主工作者角色",它能够从给定文件夹加载程序集,查找具有反射的RoleEntryPoint派生类,创建实例并调用.Run().OnStart()方法.这种"师傅的角色",也将被再次抛出意外的异常,并呼吁.OnStop()在所有子RoleEntryPoint■当.OnStop()是所谓的大师之一.会有用吗?我应该注意什么?

Eug*_*ace 8

正如其他人所提到的,这是一种非常常见的技术,可以最大限度地利用您的实例.可能有示例和"框架"抽象工作者基础结构和您想要完成的实际工作,包括本(我们)样本中的一个:http: //msdn.microsoft.com/en-us/library/ff966483.aspx(向下滚动到"实施内部")

最常见的触发工作方式是:

  1. 时间安排工人(如"cron"工作)
  2. 基于消息的工作者(由消息的存在触发的工作).

上面提到的代码示例实现了#2的进一步抽象,并且很容易为#1扩展.

请记住,与队列的所有交互都基于轮询.工作人员不会在队列中使用新消息唤醒.您需要主动查询队列以获取新消息.过于频繁地查询会让微软高兴,但可能不是你:-).每个查询都算作一个计费的交易(其中10K = $ 0.01).一个好的做法是在队列中查询具有某种延迟退避的消息.另外,批量获取消息.

最后,考虑到这一点,您还可以在单​​个实例中组合Web角色和辅助角色.请看这里的例子:http://blog.smarx.com/posts/web-page-image-capture-in-windows-azure


Dav*_*gon 5

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

角色组合是我见过的常见模式,与ISV在Windows Azure部署中合作.您可以拥有一个每隔一段时间就会唤醒的后台线程并运行一个进程.另一种常见的实现技术是使用Azure队列发送表示要执行的进程的消息.如果需要,可以有多个队列,也可以是单个命令队列.在任何情况下,您都会在后台线程中运行队列侦听器,后台线程将在每个实例中运行.第一个获取消息的消息处理它.你可以更进一步,并有一个定时的过程将这些消息推送到队列(可能每24小时,或每小时).

除了CPU和内存限制之外,请记住,单个角色最多只能有5个端点(如果您使用的是远程桌面,则更少).

编辑:截至2011年9月,角色配置变得更加灵活,现在您可以在整个部署中拥有25个输入端点(可从外部访问)和25个内部端点(用于角色之间的通信).MSDN文章在这里

我最近写了一篇关于重载Web角色的博客,这有点相关.