我们还需要一个连接池来连接 HTTP2 的微服务吗？

Question

由于 HTTP2 支持多路复用，我们还需要一个连接池来进行微服务通信吗？如果是，拥有这样的游泳池有什么好处？

示例：服务 A => 服务 B

以上两种服务都只有一个实例可用。

多个连接可能有助于克服每个连接（套接字）的操作系统缓冲区大小限制？还有什么？

Answer 1

是的，您在联系微服务的客户端中仍然需要连接池。

首先，通常是服务器控制多路复用的数量。一个特定的微服务服务器可能会决定它不能允许非常小的多路复用。
如果客户端想要以更高的负载使用该微服务，则需要准备打开多个连接，这就是连接池派上用场的地方。这对于处理负载尖峰也很有用。

其次，HTTP/2 具有流量控制，这可能会严重限制单个连接上的数据吞吐量。如果流量控制窗口很小（HTTP/2 规范定义的默认值为 65535 字节，这对于微服务来说通常非常小）那么客户端和服务器将花费大量时间交换WINDOW_UPDATE帧以扩大流量控制窗口，并且这不利于吞吐量。
为了克服这个问题，您要么需要更多的连接（并且客户端应该为此做好准备），要么需要更大的流量控制窗口。

第三，在大型 HTTP/2 流量控制窗口的情况下，您可能会遇到 TCP 拥塞（这与套接字缓冲区大小不同），因为消费者比生产者慢。它可能是客户端上传的慢服务器（具有大负载的 REST 请求），或者是服务器下载的慢客户端（具有大负载的 REST 响应）。
再次克服 TCP 拥塞的解决方案是打开多个连接。

将 HTTP/1.1 与 HTTP/2 的微服务用例进行比较，通常 HTTP/1.1 连接池比 HTTP/2 连接池大得多（例如 10x-50x），但您仍然希望 HTTP/2 中的连接池用于上面的原因。

[免责声明，我是Jetty 中的 HTTP/2 实现者]。
我们有一个初始实现，其中 JettyHttpClient使用 HTTP/2 传输，每个域都有一个硬编码的单个连接，因为这是 HTTP/2 为浏览器所宣扬的。
当接触到现实世界的用例时——尤其是微服务——我们很快意识到这是一个多么糟糕的想法，并切换回使用 HTTP/2 的连接池（就像HttpClientHTTP/1.1 一直做的那样）。