我正在为Windows azure cloud service开发一个应用程序。
该应用程序的一般描述非常简单：MVC 4 上的前端、用于处理前端处理请求的中间层和 SQL Azure/Blob 后端......
到目前为止，我还没有开始编写代码，在此之前，我想获得一些反馈，说明以下哪种场景模型更具可扩展性以及可能的原因。如果您认为存在我没有考虑过的第 N 个选项，请公开它！
只是要明确单层应用程序是不可能的。
场景 1：
前端使用中间层的 WCF 服务来执行所有处理。场景 2：
前端在中间层使用 WCF 服务，该服务在 SB 上对该请求进行排队并等待。“第 3 层”使用消息并对其进行处理，还排队等待 WCF 服务响应的答案......场景 3：
前端将消息排队并循环等待响应消息。“第 3 层”消费消息，对其进行处理并将其重新排队以供前端停止等待......
基本上所有的问题都恢复到“WCF 横向扩展的效果如何？”......
消息传递始终是最具可扩展性的解决方案，因为您可以配置任意数量的工作人员来使用消息并处理它们。
但是，如果您仍希望 UI 同步操作，则切换到异步处理并非易事。您通常会切换到基于任务的 UI，其中不会向用户提供即时反馈（或伪造的反馈）。
我写过关于如何使用查询、域事件和命令来扩展的博客：http: //blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/
你没有说前端需求是什么。这是一个需要数据响应的网站吗？通常，消息队列模式将更具可扩展性（但不是更快），因为您有许多选项来处理请求。然而，一旦你走上了这条路，就很难在没有一些技巧的情况下获得直接的类似同步的反馈给用户（SignalR 可能是这里的选择）。
对于它的价值，我倾向于在云中使用 CQRS 模式，因为它可以很好地扩展以满足我的需要。我必须处理命令被异步处理并且用户没有得到同步响应的事实。然后 UI 必须处理它。我们使用带有状态的命令处理表。网络（在这种情况下是我们的客户端）必须轮询该表以确定命令何时完成，以便知道何时尝试向客户端显示任何结果。对我们来说，为了获得我们正在寻找的规模（以及 CQRS 的其他好处），这是一个值得权衡的选择。
最具可扩展性的解决方案是您排除的解决方案——一个没有共享状态的单层 Web 应用程序，它可以拥有任意数量的节点。没有什么比负载均衡器后面的n 个Web 服务器和m个分布式数据库节点更具可扩展性了。由于您已经排除了最具可扩展性的架构，因此您问错了问题，因为您可能不追求可扩展性。也许您正在研究其他一些架构原则，例如可用性。
为什么我们要在多个服务中分离出功能？有很多原因。异步处理允许更好的可用性（通过写入队列而不关心故障）。它还允许我们管理瓶颈，例如数据库。我们还将我们的应用程序分解为服务，以简化开发和部署。因此，它可能是可用性、可维护性、安全性、性能、可部署性、成本、可用性、可测试性、合规性或您正在寻找的其他东西。在抓住可扩展性锤之前，您需要自己回答这个问题。我专门写了CALM来帮助提出和回答这些难题。
回到你的问题的细节。在 Windows Azure 上通常可扩展（如果这是您真正需要的话）的事实上的异步处理模式中没有 WCF。WCF 有特定的原因吗？它最好是一个好的，因为如果不需要，WCF 和服务总线会引入不必要的复杂性。在 Windows Azure 上，我们使用 Web 角色（托管 MVC 应用程序）实现异步处理，将消息放在 Windows Azure 队列上，这些由工作角色处理。如果您需要客户端（浏览器）了解结果，您可以手动滚动 CQRS 模式，或使用 SignalR，正如其他人提到的那样。我会认真考虑取出 WCF。
就您的场景而言：
场景 0： 无状态 Web 服务器完成所有处理并直接与分布式数据库节点通信。这是最具可扩展性的，但还有其他缺点。
场景 4： 前端将消息放入 Azure 队列并将结果返回给客户端。Worker 角色处理消息并将结果放在某处（表存储或 blob）。浏览器 Javascript 轮询结果数据并在“完成”时将其呈现给客户端。这是CQRS-ish。（邓瑞的回答）
场景 5： 前端将消息放入 Azure 队列并将结果返回给客户端。Worker 角色处理消息并通过 SignalR 将结果发送给客户端。（jgauffin的回答）
我更喜欢场景5