本文轉自：http://www.servicemesh.cn/?/article/41

作者：MIKE WHITE

翻譯：姚炳雄

原文：Using Envoy to Load Balance gRPC Traffic


針對 Bugsnag（一款bug自動檢測工具），我們最近啟動了一個專門用來跟蹤軟件發布健康狀況的發布儀表板項目。 這是個大任務，當我們在構建後臺時，特別關註了它的性能。其中的關鍵領域之一是和後端服務調用相關的延遲，在最後，我們決定用 Google 的超級快速的 gRPC 框架替換REST。


為了成功遷移到 gRPC，需要重新思考我們的負載均衡策略，以確保它很好地支持 gRPC 流量。 這篇博文概述了我們如何最終達成目標，去將 Lyft 功能豐富的 Envoy Proxy 添加到堆棧以及它又是如何來適應 Bugsnag 架構的。



Bugsnag體系結構的背景

在背後，Bugsnag 有一個微服務管道，負責處理從客戶那裏收到的錯誤信息，這些錯誤信息稍後展示在儀表板上。 這條管道目前每天處理數以億計的事件。為了支持新的發布儀表板，我們需要擴展管道接收用戶會話信息，這意味著流量將大幅增加。性能將成為是這個項目成功的關鍵，也是我們采用gRPC框架的主要原因之一。


部署方面，Bugsnag 的微服務是通過 Kubernetes 以 Docker 容器方式部署在雲上。 Kubernetes 通過它的 kube-proxy 建立了負載均衡，可以很好地處理 HTTP / 1.1 流量，但是當你把 HTTP / 2 請求也扔進去混合到一起時，事情會變得很有意思。




HTTP / 2 – 一個負載均衡頭痛的難題

gRPC 使用了性能加速的HTTP / 2協議。 HTTP / 2的實現比起以前的版本，在諸多降低延遲的方法中，一種利用了單一的長 TCP 連接（single long-lived TCP connection），並在該連接上能交叉傳遞請求/響應。 這給4層（L4）負載均衡器帶來了問題，因為它們的操作在太低的層上，以致無法根據它接收到的流量類型做出路由決策。 因此，一個L4負載平衡器試著負載平衡HTTP / 2流量，必然會打開一個單一長TCP連接，並將所有連續的流量都路由到這個單一長TCP連接，這實際上是取消了負載平衡。

Kubernetes 的 kube-proxy 本質上是一個L4負載平衡器，所以我們不能依靠它來負載平衡微服務之間的gRPC調用。



為什麽不讓客戶做這項工作？

我們探索的其中一個選項是使用 gRPC 客戶端負載均衡器，它被打包在gRPC客戶端庫中。 這樣，每個客戶端微服務可以執行自己的負載平衡。 然而，由此產生的客戶端最終是脆弱的，並需要大量的客戶化代碼來提供所有形式的彈性、度量或日誌記錄，所有這些需要重復幾次在管道中使用每種不同的語言。


我們真正需要的是更智能的負載均衡器。



選擇更智能的負載平衡器

我們需要一個L7負載均衡器，因為它們作用在應用層，能檢測流量，以便做出路由決策。 最重要的是，他們可以支持HTTP / 2協議。


對於L7負載平衡器的選擇，包括 NGINX 和 HAProxy 在內，有許多可選的產品。但這其中的大多數都因為過於厚重而不易采納進微服務架構。 我們縮小範圍，選擇了兩個關鍵的競爭者 —— Envoy 和 Linkerd。兩者都是秉承微服務體系結構理念開發的，都支持gRPC。


雖然這兩個代理都有很多不錯的功能，但最根本的決定因素取決於代理的足跡。這樣贏家就很明顯了。 Envo 非常小，用 C ++ 11編寫，不像用 Java 編寫用於企業級的 Linkerd 那麽重。


一旦決定使用 Envoy，開始深入到它的功能集中，會發現有很多想要的東西。




Envoy憑什麽表現這麽好？

Envoy 由 Lyft 編寫和開源，是多年來與微服務體系結構中常見的復雜路由問題作鬥爭的直接結果。 它本質上是為了適應我們的問題而設計的，

• 一流的雙向支持HTTP / 2和SSL
• 具備優秀的度量指標並高度透明
• 成熟的文檔集
• 不依賴於任何給定的語言

最後一個，也是最重要的一個，它與Bugsnag的polyglot微服務架構融為一體。




Envoy進入基礎設施

在 Kubernetes 中，一個或多個容器組成一組稱為 pod。Pod 能被復制多個，以提供彈性擴展，這些 pod 被包裝抽象成服務，該服務擁有固定的IP，通過該服務可以訪問底層的 pod。從 Kubernetes 1.2開始，當訪問服務IP時，kubernetes 會隨機返回後端的某個pod。也可以將服務重新配置為無人值守（headless），以便服務IP不再返回可用的pod IP整個列表，而是允許執行自己的服務發現。


Envoy 被設計成 Sidecar Container 方式運行，與客戶端容器並排放置，以模塊化方式來補充其功能。在 Kubernetes 中，這轉化為在同一個 pod 中運行客戶的容器和 Envoy 容器。我們將我們的服務配置為無人值守（headless）模式以供 Envoy 來做服務發現的端點。而且，依賴於Envoy大量的度量數據的輸出，我們能夠輕松觀察到持續的gRPC調用的輪詢調度的負載均衡，來確認其按預期工作。


當我們選擇為每個gRPC客戶端運行一個 Envoy 邊車，像 Lyft 公司為所有微服務都運行一個Envoy sidecar，形成服務網格。這種方法非常強大，可以在域級別調整流量參數，這也是我們想在Bugsnag上能看到的。



可選方案


雖然Envoy能夠滿足需求，但還是有一些值得一提的替代方案。其中一些是我們探討的，但是他們或者太不成熟，或者不太適合當時的架構：


· Istio - IBM，Google 和 Lyft 聯合開發，形成了一個完整的微服務負載均衡解決方案。Envoy 作為核心，在 Kubernete s平臺上“開箱即用”方式運行。


· Ribbon - 來自 Netflix 的開源 IPC 庫，這家公司已經被證明是微服務相關 DevOps 工具的重量級公司。


· Kubernetes Ingress controllers - 雖然此功能依賴於Beta Kuberenetes資源，但它代表了在 Kuberenete s中實現L7負載均衡的可能性。


總的來說，Envoy 給我們留下了深刻的印象，在後續的Bugsnag的開發和拓展中，我們將繼續探索其特色。有一件事是肯定的，現在這方面是 DevOps 的一個熱點，我們非常關註下一步它將如何發展。


Bugsnag會自動監視應用程序是否存在有害錯誤，並告警，可視化到軟件內部。您可以將我們看成軟件質量的中控臺。免費試用14天的Bugsnag，包括用於跟蹤發布健康狀況的發布儀表板。


原文地址：https://blog.bugsnag.com/envoy/

Envoy如何打敗Linkerd成為L7負載平衡器的最佳選擇？