WCF或自定义套接字体系结构

Question

我正在编写一个客户端/服务器架构，其中可能有数百个客户端通过多个虚拟机，主要是在Intranet上，但有些在其他位置。

每个客户端将不断收集数据并每隔一秒左右向服务器发送一条消息。每条消息的长度大概可能大约为128个字符。

我的问题是，对于我在.NET中编写客户端/服务器的这个架构，我应该使用WCF还是我之前编写的一些套接字代码。我需要可伸缩性（插槽代码所考虑的），可靠性以及处理那么多消息的能力。

Answer 1

如果不进行一些概念验证，我不会做出最终决定。创建非常简单的服务，托管它并使用一些压力测试来获得真实的性能结果。而不是根据您的要求验证结果。您已经提到了大量的消息，但您没有提到预期的响应时间。目前在MSDN forum上讨论了类似的问题，该问题抱怨WCF与套接字的响应时间较慢。

您的帖子中没有直接提及其他要求，因此我会做出一些假设以获得最佳效果：

• 使用netTcpBinding - 最佳性能，二进制编码，需要.NET服务器/客户端。我想你将使用Net.Tcp，因为你的另一个选择是直接套接字编程。
• 如果您不需要，请不要使用安全性 - 降低性能。对于Intranet之外的客户端可能不可能。
• 尽可能在客户端重用代理。如果您重复使用相同的代理，则每个代理将具有单个连接，那么打开TCP连接会很昂贵。这将影响您的服务实例化 - 默认情况下，单个服务实例将处理来自单个代理的所有请求。
• 设置服务限制，以便您的服务主机为许多客户端做好准备

此外，您应该做出有关负载平衡的决定。 WCF net.tcp连接的负载平衡需要粘性会话（会话亲和性），以便在打开通道后，客户端始终在同一服务器上调用该服务（仅在单个服务器上创建该服务的实例）。

Answer 2

对于WCF服务，每秒100个请求听起来不是很多，特别是对于那么少的有效负载。但是使用WCF服务设置一个简单的设置应该很快，一个echo方法只返回输入，然后用一堆线程和一个循环挂接客户端。

如果您已经有一个有效的套接字实现，您可以保留它，但是否则您可以选择WCF并将您宝贵的开发时间花在其他地方。

Answer 3

根据我对WCF的经验，我可以告诉你它在高负载下的性能非常好。特别是您可以在多个绑定之间进行选择，以实现对不同场景的要求（用于外部通信的httpBinding，例如本地网络中的netPeerTcpBinding）。