我们是否仍需要使用HTTP2的微服务连接池？

Question

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

示例： 服务A =>服务B

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

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

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实现者。]
我们有一个初始实现，其中Jetty HttpClient使用HTTP / 2传输，每个域都使用硬编码的单个连接，因为这就是HTTP / 2向浏览器宣传的方式。
当接触到现实世界的用例（尤其是微服务）时，我们很快意识到这个想法有多糟糕，然后转而使用HTTP / 2连接池（就像HttpClient总是对HTTP / 1.1那样）。