我們是否還需要一個連接池來支持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做的那樣）。