Azure 几个工人角色更贵？

使用Windows Azure时，$$$中的哪种方案成本更低？将这两项任务分开是否更好。电子邮件很少发送，但聊天信息一直在发布

每10秒有一个工作者角色处理从Azure队列收到的电子邮件，每1秒有一个工作者角色处理从Azure发布的聊天消息

具有一个通用工作人员角色，每1秒处理一次电子邮件发送和聊天消息

---

这一切都取决于您的扩展策略以及需要运行多少实例来处理负载

如果您计划利用受支持的SLA（99.999正常运行时间），则每个角色至少需要2个实例

因此，如果将它们拆分，则至少需要4个实例。如果你把它们放在一起，你至少需要两个

每10秒处理一封电子邮件和每秒处理一条聊天信息听起来并不多，我认为您不需要超过2个实例来处理所有事情

---

但是，如果处理能力变得不平衡（即聊天信息比电子邮件信息需要更多的计算能力），并且总负载超过4个实例，我建议将它们分开，以便您可以分别扩展这两个进程

您将根据您运行的小时数和CPU核数收取费用。因此，如果您启动四个小型虚拟机，它们都在做同一件事，而两个小型虚拟机做一件事，两个做另一件事，那么成本是相同的。

当以或接近全部CPU容量运行时，工作者角色的效率最高——毕竟，您是按CPU小时为它们付费的。实现这一点的一个有用方法是合并工作人员角色，以便所有后台工作最终都在一个角色中执行

运行单个工作者角色类型体系结构的一个好方法是使用某种通用工作者角色模式—基本上是一种插件模式，工作者角色从队列中读取消息，并使用编码到消息（或queu名称）中的一些元数据来确定其所需的处理类型。然后它将转到blob存储来检索.NET程序集以执行该类型的处理，将其实例化到新的appdomain中，并将上下文打包到该程序集中进行处理

中的异步工作负载会话中介绍了这一点。这还包含一个实践实验室，指导您完成其中一种方法的示例实现

Lokad的人有一个非常优雅的实现，包括所有的波兰和管理机制，如果你做得好的话。他们的实现是新的BSD许可，并于去年获得MSFT Azure年度合作伙伴奖。它几乎是我构建的每个Azure项目的重要组成部分。强烈推荐和琐碎的整合

所以简而言之，我更喜欢一个通用的worker角色，它被实现为一个带有动态类型加载和实例化的插件类型模式