我正在将一个巨大的应用程序移植到 Windows Azure。它将有一个 Web 服务前端和一个处理后端。到目前为止，我认为我会使用 Web 角色来为客户端请求提供服务，并使用工作角色来进行后端处理。
管理两种角色似乎有问题——我需要决定如何扩展两种角色，而且我需要每个角色的几个（至少两个）实例来确保合理的容错性，这会稍微增加运营成本。同样在我的应用程序中，客户端请求是相当轻量级的，而后端处理是重量级的，所以我希望后端处理会比服务客户端请求消耗更多的处理能力。
这就是为什么我正在考虑对所有事情都使用 Web 角色 - 只需生成线程并在每个实例中都进行服务请求和后端处理。这将使角色更加复杂，但我想会简化管理。我将有更多的统一角色实例和更好的容错能力。
将 Web 角色重用于后端处理是个好主意吗？我应该期待什么缺点？
听起来您已经非常清楚在使用多个角色时要考虑什么：
但是：如果您在一个角色中运行所有内容，那么所有内容都可以一起扩展。例如，如果您在端口 8000 上有一个管理网站，那么如果您的用户群在端口 80 上的主站点受到流量的冲击，您可能会难以访问它。
我在博客上写了关于将网络角色和工作角色结合起来的文章，在这里，其中更详细地介绍了我们在此处讨论的内容。此外，在 3 月的某个时间，每个角色 5 个端点的限制被取消 - 请参阅我的博客文章，了解您现在可以将端点推到多远。拥有这种限制较少的端点模型确实为单角色部署开辟了新的可能性。
据我了解，您在问合并服务层是否有意义，以便您只需要处理一个层。在高层次上，我认为这是有道理的。越简单越好，只要不是简单到你无法实现你的主要目标。
如果您的主要目标是性能，并且对您的服务的调用是内联的（意味着调用者正在等待答案），那么合并层可能会帮助您获得更高的性能，因为您不必处理额外物理层的额外网络延迟。您可以使用任务并行库 (TPL) 来实现您的线程逻辑。
如果您的主要目标是可伸缩性，并且对您的服务的调用是带外的（这意味着调用者实现了即发即弃模式），那么使用处理队列和工作角色可能更有意义。云计算的原则之一是松散耦合的服务。虽然您有更多的维护工作，但您也可以更灵活地独立扩展图层。您的工作人员角色也可以使用上面提到的 TPL，以便您可以将工作人员角色部署在更大的 VM（比如 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/