17

我有几个WorkerRole只做很短时间的工作,把它们放在一个实例中会浪费钱。我们可以将它们合并为一个,但这会很混乱,并且在遥远的将来,当负载增加时它们应该独立工作。

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

在否定的情况下,我认为我可以创建一个“主工作者角色”,它能够从给定文件夹加载程序集,查找具有反射的 RoleEntryPoint 派生类,创建实例并调用.Run()or.OnStart()方法。这个“主工作者角色”也会重新抛出意外异常,并在主节点调用时调用.OnStop()所有子节点。它会起作用吗?我应该注意什么?RoleEntryPoint.OnStop()

4

4 回答 4

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

于 2011-03-15T17:31:19.973 回答
5

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

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

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

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

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

于 2011-03-15T15:20:38.083 回答
4

虽然已经指出的解决方案没有真正的问题,以寻找在单个 Worker Role 中执行多个 Worker 组件的方法,但我只想让您记住,首先定义不同的 Worker Role 的全部意义在于隔离面对错误。如果您只是将所有内容都塞入一个 Worker Role 实例中,那么只有其中一个表现不佳的 Worker 组件有能力取消该角色中的所有其他 Worker 组件。现在突然之间,您正在编写大量基础架构来提供跨组件的隔离和容错,这几乎就是 Azure 为您提供的。

再说一次,我并不是说严格地做一件事是绝对的。有一个地方可以使单个 Worker Role 下的多个组件有意义(尤其是在monaterily 上)。简单地说,你应该记住为什么它首先是这样设计的,并在你规划你的架构时适当地考虑到这一点。

于 2011-03-16T00:32:57.863 回答
3

为什么“多角色”会一团糟?您可以将每个工作角色实现编写为松散耦合的组件,然后从所有适当的组件组成一个工作角色。

当您以后需要将一些职责分离到一个单独的工作者角色时,您可以仅使用该组件组成一个新的工作者角色,同时将其从旧的工作者角色中删除

如果你愿意,你可以使用后期绑定,这样甚至可以在不重新编译的情况下完成,但我通常认为这不值得付出努力。

于 2011-03-15T14:38:11.817 回答