我正在将一个大型应用程序移植到 Windows Azure。它将有一个 Web 服务前端和一个处理后端。到目前为止，我认为我会使用 Web 角色来为客户端请求提供服务，并使用工作角色来进行后端处理。
管理两种角色似乎有问题 - 我需要决定如何扩展两种角色，并且我需要每个角色的多个（至少两个）实例以确保合理的容错性，这将略微提高操作性费用。此外，在我的应用程序中，客户端请求是相当轻量级的，而后端处理是重量级的，因此我预计后端处理会比服务客户端请求消耗更多的处理能力。
这就是为什么我正在考虑对所有事情都使用 Web 角色 - 只需生成线程并在每个实例中执行服务请求和后端处理。这将使角色更加复杂，但我想会简化管理。我会有更多的统一角色实例和更好的容错能力。
将 Web 角色重用于后端处理是否是个好主意？我应该期待什么缺点？
【问题讨论】：
标签： windows azure cloud azure-web-roles
听起来您已经非常清楚在使用多个角色时应该考虑什么：
但是：如果您以一个角色运行所有内容，那么所有内容都会一起扩展。例如，如果您在端口 8000 上有一个管理网站，那么如果您的用户群在端口 80 上的主站点大量流量，您可能会难以访问它。
我写了一篇关于结合网络角色和工作角色的博客，here，其中更详细地介绍了我们在此处讨论的内容。此外，在 3 月的某个时间，每个角色 5 个端点的限制被取消 - 请参阅我的博客文章 here，了解您现在可以将端点推到多远。拥有这种限制较少的端点模型确实为单角色部署开辟了新的可能性。
【讨论】：
据我了解，您问的是整合服务层是否有意义，以便您只需要处理一个层。在高层次上，我认为这是有道理的。越简单越好，只要不是简单到无法实现主要目标即可。
如果您的主要目标是性能，并且对您的服务的调用是内联的（意味着调用者正在等待应答），那么合并层可能会帮助您实现更高的性能，因为您不必处理额外物理层的额外网络延迟的开销。您可以使用任务并行库 (TPL) 来实现您的线程逻辑。
如果您的主要目标是可扩展性，并且对服务的调用是带外的（这意味着调用者实现了即发即弃模式），那么使用处理队列和工作角色可能更有意义。云计算的原则之一是松散耦合的服务。虽然您有更多的维护工作，但您也可以更灵活地独立扩展图层。您的辅助角色也可以使用上面提到的 TPL，这样您就可以将辅助角色部署在更大的虚拟机（比如 4 个 CPU 或 8 个）上，这样可以将部署的实例数量保持在最低限度。
我的 2 美分。 :)
【讨论】：
我建议您将它们开发为独立的角色：Web 角色和工作者角色，然后将它们组合成一个 Web 角色。
这样，将来如果需要，您可以轻松转换为真正的分离角色。
更多详情： http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/how-to-combine-worker-and-web-role-in.html http://wely-lau.net/2011/02/25/combining-web-and-worker-role-by-utilizing-worker-role-concept/
【讨论】：