对于使用HTTP2的微服务，我们仍然需要一个连接池吗？ [英] Do we still need a connection pool for microservices talking HTTP2?

问题描述

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

As HTTP2 supports multiplexing, do we need still a pool of connections for microservice communication? If yes, what are the benefits of having such a pool?

例如：
服务A =>服务B

Example: Service A => Service B

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

Both the above services have only one instance available.

多个连接可能有助于克服每个Connection（Socket）的OS缓冲区大小限制？还有什么？

Multiple connections may help overcome OS buffer size limitation for each Connection(Socket)? What else?

推荐答案

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

Yes, you still need connection pool in a client contacting a microservice.

首先，通常是由服务器控制多路复用的数量。特定的微服务服务器可能会决定它不能允许进行非常小的复用。

如果客户端希望以更高的负载使用该微服务，则需要准备打开多个连接，并且在这里，连接池很方便。
这对于处理负载峰值也很有用。

First, in general it's the server that controls the amount of multiplexing. A particular microservice server may decide that it cannot allow beyond a very small multiplexing.
If a client wants to use that microservice with a higher load, it needs to be prepared to open multiple connections and this is where the connection pool comes handy. This is also useful to handle load spikes.

第二，HTTP / 2具有流控制，可能严重限制单个连接上的数据吞吐量。如果流控制窗口很小（HTTP / 2规范定义的默认值为65535字节，对于微服务通常很小），则客户端和服务器将花费大量时间交换 WINDOW_UPDATE 框架扩大了流量控制窗口，这对吞吐量是有害的。

要克服这一点，您要么需要更多的连接（并且应该为此准备一个客户端），要么需要更大的流量控制窗口。

Second, HTTP/2 has flow control and that may severely limit the data throughput on a single connection. If the flow control window are small (the default defined by the HTTP/2 specification is 65535 bytes, which is typically very small for microservices) then client and server will spend a considerable amount of time exchanging WINDOW_UPDATE frames to enlarge the flow control windows, and this is detrimental to throughput.
To overcome this, you either need more connections (and again a client should be prepared for that), or you need larger flow control windows.

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

Third, in case of large HTTP/2 flow control windows, you may hit TCP congestion (and this is different from socket buffer size) because the consumer is slower than the producer. It may be a slow server for a client upload (REST request with a large payload), or a slow client for a server download (REST response with a large payload).
Again to overcome TCP congestion the solution is to open multiple connections.

对于微服务用例，将HTTP / 1.1与HTTP / 2进行比较，通常HTTP / 1.1连接池要大得多（例如10倍） -50x），而不是HTTP / 2连接池，但出于上述原因，您仍然希望使用HTTP / 2连接池。

Comparing HTTP/1.1 with HTTP/2 for the microservice use case, it's typical that the HTTP/1.1 connection pools are way larger (e.g. 10x-50x) than HTTP/2 connection pools, but you still want connection pools in HTTP/2 for the reasons above.

[免责声明，我是HTTP / 2实现者在码头]中。

我们有一个最初的实现，其中码头 HttpClient 使用HTTP / 2传输，并且每个域都使用硬编码的单个连接，因为这就是HTTP / 2向浏览器宣传的方式。

在现实世界中，特别是在微服务中，我们很快意识到这个主意多么糟糕，于是改回使用连接点针对HTTP / 2的查询（例如 HttpClient 始终针对HTTP / 1.1执行）。

[Disclaimer I'm the HTTP/2 implementer in Jetty].
We had an initial implementation where the Jetty HttpClient was using the HTTP/2 transport with an hardcoded single connection per domain because that's what HTTP/2 preached for browsers.
When exposed to real world use cases - especially microservices - we quickly realized how bad of an idea that was, and switched back to use connection pooling for HTTP/2 (like HttpClient always did for HTTP/1.1).

这篇关于对于使用HTTP2的微服务，我们仍然需要一个连接池吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！