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