昨天有提到以目前專案的規模，其實我們並不需要做到 appmesh 這一層，因為我們並沒有在實行金絲雀部署或是 a/b test，那究竟為什麼當初會掛上 appmesh呢？原來是因為我們 pod 跟 pod 間的溝通是使用 gRPC，而在過去的 k8s 上，gRPC 並沒有實踐 load balance 的機制。我們先來理解此方法

gRPC 連線的影響

gRPC（全名為 gRPC Remote Procedure Calls）是一個高效、靈活且跨語言的遠端程序調用（Remote Procedure Call, RPC）框架。

gRPC 是以 HTTP/2 作為傳輸協定，而 HTTP/2 的特點是持久連線。如果今天我們已經有固定的連線了，這時 pod 開始進行擴展，那原本連線並不會斷掉。

這邊官方有提到，那為什麼同樣強調 long-lived connections 的 HTTP/1.1 沒有影響呢？相較起 HTTP/2， HTTP/1.1 無法做到 multiplex requests。當使用者打了一個 request，一個 request-respond 即被建立。且此時沒有其他 requests 可以被 issued 到此 connection

通常情況下，我們希望可以同時處理多個請求。因此，要實現HTTP/1.1的並發請求，需要建立多個HTTP/1.1連接，並在這些連接之間分配請求。此外，HTTP/1.1的長連接通常在一定時間後就會到期並被關閉。這兩個因素共同確保了HTTP/1.1請求通常在多個TCP連接之間循環使用，因此連接級別的平衡可以正常工作。

如何解決 - service mesh

正如我們所說，在流量進入之前，先讓他過一層 layer（sidecar），藉此管理流量的連接跟走向，就是我們 service mesh 的任務。這方法也被稱作 lightweight proxy。

其他還有自架loadbalance，並配置不同的 gRPC。但 pod 是動態的，調整很麻煩

或是在 k8s內部署 headless 服務，也就是 k8s 針對服務的DNS導向多個 A 紀錄，但此方法限定了使用特定 gRPC client

官方雖然使用 Linkerd，但因為我們服務都在 eks 上，使用 AWS App Mesh 自然有相容的方便性。而 App Mesh 也支持 HTTP/1.x、HTTP/2 和 gRPC 的 L7 負載均衡。針對退出和進入流量提供路由控制和重試策略。它還在不同 AWS 服務之間進行相互 TLS 加密，提供更嚴格的安全性。雖然他使用的是 Envoy 代理，雖然可進行的操作比較強大，但也帶來較高的資源消耗。

ref: https://kubernetes.io/blog/2018/11/07/grpc-load-balancing-on-kubernetes-without-tears/