我正在向Windows Azure移植一个巨大的应用程序。它将具有Web服务前端和处理后端。到目前为止，我认为我将使用Web角色为后端处理服务客户端请求和工作者角色。
管理两种角色似乎有问题 - 我需要决定如何扩展两种角色，同时我还需要几个（至少两个）实例，以确保合理的容错能力，这将略微增加运营成本。同样在我的应用程序中，客户端请求相当轻量级，后端处理是重量级的，因此我预计后端处理将比服务客户端请求消耗更多的处理能力。
这就是为什么我正在考虑将Web角色用于所有事情 - 只是生成线程并在每个实例中同时执行服务请求和后端处理。这将使角色更复杂，但我猜想简化管理。我会有更多的统一角色和更好的容错能力。
重用Web角色进行后端处理是一个好主意吗？我应该期待哪些缺点？
答案 0 :(得分：4)
听起来你已经非常了解在使用多个角色时应该考虑什么：
然而：如果你在一个角色中运行所有东西，那么一切都在一起。例如，如果您在端口8000上有一个管理网站，如果您的用户群正在通过流量抨击端口80上的主站点，则可能难以到达它。
我发表了关于组合网络和工作人员角色的博客here，其中详细介绍了我们在此讨论的内容。此外，截至3月份的某个时候，每个角色限制了5个端点 - 请参阅我的博客文章here，了解您现在可以在多大程度上推送端点。拥有这种限制较少的端点模型确实为单一角色部署开辟了新的可能性。
答案 1 :(得分：2)
根据我的理解，您正在询问是否有必要整合服务层，以便您只需要处理单个图层。在高层次上，我认为这是有道理的。越简单越好，只要不是那么简单就不能达到你的主要目标。
如果您的主要目标是性能，并且对您的服务的调用是内联的（意味着调用者正在等待答案），那么合并这些层可能有助于您实现更高的性能，因为您不必处理额外物理层的额外网络延迟的开销。您可以使用任务并行库（TPL）来实现线程逻辑。
如果您的主要目标是可扩展性，并且对您的服务的调用是带外的（意味着调用者实现了“即发即弃”模式），那么使用处理队列和工作者角色可能更有意义。云计算的原则之一是松散耦合的服务。虽然您有更多的维护工作，但您还可以更灵活地独立地扩展您的图层。您的工作者角色也可以使用上面提到的TPL，以便您可以在较大的VM（例如4CPU或8）上部署您的工作者角色，这将使部署的实例数量保持最小。
我的2美分。 ：）
答案 2 :(得分：1)
我建议你将它们作为单独的角色进行开发：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/