c# - 高可用性TCP服务器应用程序

Question

在我的项目中，我有一个运行C#应用程序的云托管虚拟机，该虚拟机需要:

接受来自多个外部客户端(大约500个)的TCP连接

从连接的客户端异步接收数据(不是高频，大约每分钟1条消息)

对接收到的数据进行一些处理

将收到的数据转发给其他 Actor

回复连接的客户端，并可能进行一些异步发送(基于内部时间检查)

在我看来，设计非常简单。我提供了一个监听器，该监听器接受传入的TCP连接，在建立新连接时会产生一个新线程；该线程在循环中运行(执行 Activity 从2到5)，并检查相关的套接字 liveness (如果套接字已死，线程将退出循环并最终终止；稍后，将尝试从属于该套接字的外部客户端尝试建立新连接到)。

因此，现在的问题是，对于数量有限的外部客户端(我想说200/300)，所有设备都运行平稳，但是随着数量的增加(或当客户端以更高的频率发送数据时)，通信变得非常缓慢且受阻。

我在考虑一些更好的设计，例如:

使用任务而不是线程的

使用ThreadPool的

用1Thread10Socket

之类的东西替换1Thread1Socket

甚至一些扩展策略:

在同一个应用程序中打开两个不同的TCP监听器(不同的端口)(重新配置客户端，以便其中的一半针对每个监听器)

在同一个虚拟机上为两个相同的应用程序提供两个不同的TCP监听器(不同的端口)

设置两个不同的虚拟机，并在每个虚拟机上运行相同的应用程序(重新配置客户端，以使其中的一半针对每个虚拟机地址)

最后的问题是:当前的设计是差的还是天真的？您认为我处理交流的方式有什么重大的批评吗？您是否还有其他更健壮和有效的选择(在上述选择中，还是在其他选择中)？

谢谢

Answer 1

监听器的数量不太可能成为限制因素。在这里，在Stack Overflow中，每个实例可处理约60k个套接字，而我们需要多个监听器的唯一原因是，我们可以在多个端口上分配流量，以避免在负载均衡器处短暂的端口耗尽。同样，我应注意，每实例60k的套接字服务器基本上以零CPU运行，因此:考虑多个exe，VM等为时过早。这不是问题。问题是代码，而将不良的套接字基础结构分布在多个进程上只会掩盖问题。

编写高性能的套接字服务器很困难，但是好消息是:您可以避免大多数情况。 Kestrel(ASP.NET Core http服务器)可以充当完美的TCP服务器，为您处理大多数可怕的异步，套接字，缓冲区管理等方面，因此您只需要担心实际的数据处理。 “管道” API甚至还为您处理了后缓冲区，因此您无需担心过度读取。

在my 3-and-a-bit part blog series starting here中对此进行了广泛的演练-太多信息可以尝试在此处发布。但是它链接到演示服务器-虚拟redis服务器hosted via Kestrel。也可以使用Pipelines.Sockets.Unofficial在不使用Kestrel的情况下进行托管，但是坦率地说，我会使用Kestrel。此处显示的服务器与每个实例60k的Web套接字层大致相似(就广泛的初始化而言，而不是其实际工作)。