gRPC使用粘性連接

gRPC連接是粘性的。這意味着當從客戶端到服務器建立連接時，相同的連接將被盡可能長時間地用於許多請求（多路復用）。這樣做是為了避免所有最初的時間和資源花費在TCP握手上。因此，當客戶端獲取與服務器實例的連接時，它將保持連接。

現在，當同一客戶端開始發送大量請求時，它們都將轉到同一服務器實例。而這正是問題所在，將沒有機會將負載分配給其他實例。他們都去同一個實例。

這就是為什么粘性連接會使負載平衡變得非常困難。

以下是一些負載均衡gRPC相互通信的方法，以及每種方法的一些細節。

1.服務器端

當在服務器端完成負載均衡時，會使客戶端非常精簡，並且完全不知道如何在服務器上處理負載：

網絡負載均衡器

網絡負載均衡器在OSI (Open Systems Interconnection) 模型的第4層運行。因此，它非常快，可以處理更多的連接。當出現新的TCP通信連接時，負載均衡器將選擇一個實例，並且在連接有效期內將連接路由到該單個實例。

現在請記住，gRPC連接是粘性的和持久的，因此它會在負載均衡器后面的客戶端和同一服務器實例之間保持相同的連接，只要它可以。

現在這是問題所在：

粘性連接和自動縮放

如果單個服務器實例上的負載（內存或cpu）高於自動伸縮策略，則將導致在該目標組中啟動一個新實例。

但是，目標組中的新實例將無濟於事。為什么？同樣，因為gRPC連接是持久的且具有粘性。正在發送大量請求的客戶端，將繼續將它們發送到與其連接的同一服務器實例。

因此，新的服務器實例被啟動，但是沒有請求過載將流向新的實例。利用率高的同一台單服務器實例仍在接收來自客戶端的請求負載（因為客戶端一直在重用相同的連接）。

自動伸縮策略可能會不斷觸發並向目標組添加新實例（因為單個實例的cpu /內存過載）。但是這些新實例接收的流量幾乎為零。自動縮放策略可能會繼續觸發並可能最大化目標組中允許的實例，而實際上並未從發送到新實例的請求中受益。

如何使用gRPC粘性連接分配負載？

為了基本上有機會分配負載，我們必須使用以下方法之一放棄粘性和持久連接：

1.客戶端定期重新連接

如果您可以控制連接的gRPC客戶端，則可以強制客戶端定期斷開連接並重新連接。此行為將迫使客戶端向負載均衡器發送新請求，並且作為對此請求的響應，這次將返回更健康的實例。

2.服務器定期強制斷開客戶端連接

如果您無法控制連接的gRPC客戶端，則可以在服務器端實現類似的邏輯。使服務器在一段時間后強行關閉連接，當它們重新連接時，它會自動使新連接進入更健康的實例。

這些方法中的任何一種都丟失了gRPC的基本優勢：可重用的連接。

DNS服務發現

同樣，我們可以將服務器實例放置在DNS服務發現之后，而不是在Elastic Load Balancer后面。服務發現本質上是一種DNS服務，當請求進入時，它將以隨機順序返回其后面所有實例（或正常實例的子集）的IP地址列表。因此，當客戶端選擇要連接到的服務器並進行DNS查找時，服務發現將返回排序后的實例的IP地址。

網絡負載均衡器的所有問題幾乎都適用於DNS服務發現負載均衡。當客戶端獲取到單個實例的連接時，它將堅持並繼續重用它。