WCF 或自定义套接字架构

Question

我正在编写一个客户端/服务器架构，其中多个虚拟机上可能有数百个客户端，大部分位于 Intranet 上，但也有一些位于其他位置。

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

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

Answer 1

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

您的帖子中没有直接提到其他要求，因此我将做出一些最佳性能的假设：

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

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

Answer 2

对于 WCF 服务来说，每秒 100 个请求听起来并不算多，尤其是在有效负载很小的情况下。但是，使用 WCF 服务设置一个简单的设置应该非常快，其中一个 echo 方法仅返回输入，然后用一堆线程和一个循环连接客户端。

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

Answer 3

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