wcf - 哪种架构更具可扩展性

Question

我正在为 Windows azure 云服务开发应用程序。

应用程序的一般描述非常简单:MVC 4 上的前端、用于处理前端处理请求的中间层和 SQL Azure/Blob 后端...

到目前为止，我还没有开始编写代码，在此之前，我想获得一些反馈，了解以下哪种场景模型更具可扩展性以及可能的原因。如果您认为有第 N 个选项我没有考虑过，请公开它!

需要明确的是，单层应用程序是不可能的。

Scenario 1:
Front-End consumes a WCF service on middle tier that does all the processing.

Scenario 2:
Front-End consumes a WCF service on middle tier that queues up that request on a SB and waits. "Tier 3" consumes the message and processes it, also queueing the answer for WCF Service to respond...

Scenario 3:
Front-End queues a message and loops waiting for response message. "Tier 3" consumes the message, processes it and re-queue it for Front-End to stop waiting...

基本上所有的问题都会回到“WCF 水平扩展的效果如何？”...

Answer 1

最具可扩展性的解决方案是您排除的解决方案 - 没有共享状态的单层 Web 应用程序，可以拥有任意数量的节点。没有什么比负载均衡器后面的 n 个 Web 服务器和 m 个分布式数据库节点更具可扩展性了。由于您已经排除了最具可扩展性的架构，因此您提出了错误的问题，因为您可能并不追求可扩展性。也许您正在考虑其他一些架构原则，例如可用性。

为什么我们要区分多个服务的功能？原因有很多。异步处理可以实现更好的可用性(通过写入队列而不用担心失败)。它还允许我们管理瓶颈，例如数据库。我们还将应用程序分解为服务，以便于开发和部署。因此，它可能是可用性、可维护性、安全性、性能、可部署性、成本、可用性、可测试性、合规性或您正在寻找的其他东西。在拿起可扩展性锤子之前，您需要自己回答这个问题。我写了CALM专门帮助提出和回答这些难题。

回到您的问题的具体内容。 Windows Azure 上事实上的异步处理模式通常是可扩展的(如果这是您真正需要的)，但其中没有 WCF。 WCF 有具体原因吗？它最好是一个好的，因为如果不需要，WCF 和服务总线会带来不必要的复杂性。在 Windows Azure 上，我们使用 Web 角色(托管 MVC 应用程序)实现异步处理，将消息放置在 Windows Azure 队列上，这些消息由辅助角色处理。如果您需要客户端(浏览器)了解结果，您可以手动滚动 CQRS 模式，或使用 SignalR，正如其他人提到的那样。我会认真考虑取消 WCF。

就您的场景而言:

Scenario 0: Stateless web servers do all processing and communicate directly with distributed database node. This is the most scalable, but has other disadvantages.

Scenario 4: Front end places message on Azure queue and returns result to client. Worker role processes message and puts result somewhere (table storage or blob). Browser Javascript polls for result data and presents it to client when 'done'. This is CQRS-ish. (dunnry's answer)

Scenario 5: Front end places message on Azure queue and returns result to client. Worker role processes message and sends result to client via SignalR. (jgauffin's answer)

我更喜欢场景 5