使用服务总线与WCF进行计算角色通信

Question

给定一个简单的高级体系结构，例如具有Web角色的云服务和计算角色，在什么情况下我们会选择使用WCF作为web角色和计算角色，而不是服务总线。

有很多文档和有关服务总线的示例，但我想了解是否有使用服务总线的任何平台好处，而不是WCF。

鉴于呼叫是同步的，并且很短，例如一个典型的API数据访问网站的API调用，您会选择WCF队列消息并回复队列吗？

从逻辑上看，对于同步调用，WCF会提供最少的开销和延迟？

我并不完全了解平台是否提供了任何“巧妙”的技巧，以保持服务总线的运行速度与通过WCF的TCP连接一样快（考虑到排队开销？），并且希望进一步了解这一点。

目前，如果我要为这种类型的呼叫选择一个实现，我会选择WCF，这可能有点天真。

只是为了清楚，这些调用总是返回数据，它们不会长时间运行，或者发生并忘记。

谢谢！

Answer 1

我认为这取决于你想要做什么。

服务总线通常更多地用于我称之为常量联系类型的交互。它应该更高性能，但设置起来更复杂。它还具有双向通信功能。所以你会获得很多额外的灵活性。

我会交换WCF的更现代的Web API。两者都解决了同样的核心问题，主要是在提供内容。我认为它只是一个API，不一定是消息传递和处理的平台。他们解决2个不同的核心问题。

我实际上会以不同方式解决可能的问题，并使用Azure网站+ WebJobs。它是同样的东西。您可以将WebJob绑定到Azure队列，表或blob，并将消息放置在该存储机制上，这些作业将采用并执行某些操作。我不相信网络角色应该依赖从工作中回来的内容。这项工作可能会在AzureWeb站点完成后触发一个SignalR Hub，这会将状态推回给受影响的各方。

参考资料： WebJobs：https://azure.microsoft.com/en-us/documentation/articles/web-sites-create-web-jobs/

SignalR：http://signalr.net/

Azure的Web应用程序：https://azure.microsoft.com/en-us/services/app-service/web/