有一个遗留实现（在某种程度上公司专有的Pascal，C有一些java宏），它处理来自TCP客户端应用程序的基于TCP Socket的请求。它支持通过TCP Socket连接的多个客户端应用程序（大约5K），但是，它仅支持与后端（数据库）的单个套接字连接。服务器有两个实例，因此总共支持10K客户端应用程序通过两个TCP Socket连接数据库。所有与数据库相关的通信都通过单插槽连接以同步方式进行此应用程序存在大量问题，尤其是较高的RTT（往返时间）和由于背压导致的偶尔中断。我们有一个针对此类问题的运营团队。他们主要通过重新启动服务器来解决它们。很难，我们团队中的人员知道此应用程序的编码细节，并且没有太多文档。由于这是一个关键的应用程序，我们无法负担得起它。我们现在至少不想触摸代码。由于业务优先级的转变，这甚至变得更加重要。需要使用此设置添加另一个业务的另一个30K客户端应用程序。
我们面前的任务是将其与另一个基于微服务架构的应用程序集成，使用RabbitMQ构建中间件。这是面向客户的应用程序，对更高的QoS敏感。我们负担不起停电和停机时间。作为此集成的一部分，需要在将它们传递给数据库之前，通过TCP套接字处理来自上述遗留应用程序的请求消息。换句话说，我们想要引入一个组件，它可以在移交给数据库之前处理遗留应用程序的请求。此附加流程是我们客户请求的一部分。在CPU周期，内存和插槽i / o方面，一些处理要求非常密集且资源匮乏。结果，有可能这样的处理可能导致服务器停机和更高的RTT。我们这一层非常灵活，我们可以轻松添加更多服务器或更换有问题的服务器。但是，这在集成中听起来并不高效，因为我们受遗留应用程序的单插槽连接限制。所以总共最多，我们只能有2个（新的30k客户端应用程序为+6）服务器。这是我们关注的问题。
我想知道，有哪些不同的可能选项可用于解决此类集成的高可用性，可伸缩性和延迟问题？特别是对于单个TCP套接字连接的限制，我们如何才能使这种集成更有效，能够处理背压，更好的应用正常运行时间等。
我们正在考虑利用RabbitMQ，第4层负载均衡器（如haProxy，NginX），IPVS，NAT等。但是所有这些都导致在遗留代码中进行一些更改（或者不是非常有效的技术），我们不会＃ 39;不要。