微服务架构| 无法分配请求的地址

Question

我们具有微服务架构，其中来自公共（移动应用）的单个请求在内部导致对不同服务的4个HTTP调用。

我观察到的这一副作用之一是，在高负载下，我们开始遇到错误“无法分配请求的地址”。

运行netstat -tunp | wc -l netstat -tunp | wc -l显示计数约为60k，而通常徘徊在3k附近。

看来我快要用尽港口了。 我的应用程序是使用Apache HTTP Client用Java编写的。

解决此问题的最佳方法是什么？ 我没有几个解决方案，但是我不确定它是否正确：

• 使用保持活跃
• 使用Apache HTTP池（ http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/conn/PoolingClientConnectionManager.html ）

有任何想法吗？

Answer 1

有几个原因可能会耗尽可用的端口。 （为避免混淆，我将您面向用户的服务器称为“应用程序”。）：

1. 如果只有一个具有一个IP地址的应用程序实例，则从该一台计算机到您的四个微服务中的任何一个的最大连接数将受到临时端口数的限制。 默认的临时端口范围因操作系统而异，但可以设置为最高65535（所有端口都可作为临时端口使用，尽管这非常不常见）。
2. 如果您的微服务的响应正在发送Connection: close ，或者您的应用程序不支持保持活动状态，则该应用程序将在每次请求后关闭TCP连接。 当TCP连接关闭时，关闭方进入TIME_WAIT进行2xMSL（请参阅RFC 1122第4.2.2.13节 ）。 默认的MSL再次因操作系统而异，但是常见的默认值为30s。 这意味着应用程序将无法使用该端口与同一微服务通信60秒钟。
3. 相反，如果微服务正在关闭连接（可能是因为应用程序正在发送Connection: close ），它们将进入TIME_WAIT，您可能最终会在微服务侧耗尽端口。

解决端口耗尽问题的方法取决于上述情况。 这是我会尝试的方法：

• 在应用程序和微服务之间启用保持活动状态，并使用连接池。 这将大大减少应用程序和微服务之间打开和关闭的连接数，避免由于TIME_WAIT而导致端口耗尽。
• 一个应用程序实例和一个微服务之间有65k多个并发连接。 如果达到此限制，则可能需要通过添加虚拟IP地址来增加单个应用程序实例可用于发出请求的IP地址数量。 您还可以添加应用程序实例，并将其放在负载均衡器之后。
• 您可以增加微服务可用的IP地址数量，并使用DNS轮循等系统来平衡IP地址之间的负载。
• 您可以在操作系统级别为您的应用程序和/或微服务调整MSL，以减少TIME_WAIT中的套接字数量。 不过，我不建议这样做； 存在潜在的负面影响，并且在几乎所有情况下，如果这是解决问题的唯一方法，则您的应用程序或体系结构是错误的。

我建议先从保持活动和连接池开始。