给定一个简单的高级架构，例如具有 Web 角色和计算角色的云服务，在什么情况下我们会选择使用 WCF 作为 Web 角色和计算角色之间的通信方式，而不是使用服务总线.
有很多关于服务总线的文档和示例，但我想了解使用服务总线而不是 WCF 是否有任何平台优势。
鉴于调用是同步且简短的，例如用于将数据获取到网站上的典型 API 调用，您会选择 WCF 而不是排队消息和回复到队列中吗？
从逻辑上讲，对于同步调用，WCF 会提供最少的开销和延迟？
我不完全了解该平台是否提供了任何“聪明”的技巧来保持服务总线的运行速度与 WCF 上的 TCP 连接一样快（考虑到排队开销？）并且想进一步了解这一点。
目前，如果我要为这种类型的调用选择一个实现，我会选择 WCF，这可能有点幼稚。
只是为了清楚，调用总是返回数据，它们不会长时间运行，或者触发并忘记。
谢谢！
【问题讨论】：
我认为这取决于您具体想做什么。
Service Bus 通常更多地用于我所说的持续联系类型的交互。它应该更高效，但设置起来更复杂。它还具有双向通信能力。因此，您可以从中获得很多额外的灵活性。
我会将 WCF 换成更现代的 Web Api。两者都主要在提供内容方面解决相同的核心问题。我认为它只是一个 API，不一定是消息传递和处理的平台。它们解决了 2 个不同的核心问题。
我实际上会以不同的方式解决可能的问题，并使用 Azure 网站 + WebJobs。它是同一类的东西。您可以将 WebJob 绑定到 Azure 队列、表或 blob，并将消息放在该存储机制上，作业会拾取并使用该存储机制。我不认为网络角色应该依赖于从工作中获得的内容。该作业可能会在完成后访问 AzureWeb 站点上的 SignalR Hub，从而将状态推送回受影响的各方。
参考资料： 网络招聘：https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/
Azure Web 应用程序：https://azure.microsoft.com/en-us/services/app-service/web/
【讨论】：