閱讀前的小說明：

近些年，由於容器技術的崛起，微服務架構流行了起來。而面對微服務的服務網格( Service Mesh )架構，如何選擇每一個微服務的通信 proxy 變得至關重要。

本文翻譯自 Datawire CEO Richard Li 的英文博客: 「 Envoy vs NGINX vs HAProxy: Why the open source Ambassador API Gateway chose Envoy 「。博客中對於微服務中 proxy 的選擇做了諸多考量，我個人認為非常值得一讀，故特此翻譯，供各位參閱。

此外，由於本人的英文功底著實較為薄弱，因此文中若如果出現部分翻譯不當或翻譯錯誤，也希望大家批評指正，不吝賜教！

原文鏈接：blog.getambassador.io/e

翻譯By : 田同學 || Contact me : [email protected] github.com/XinyaoTian註明原出處及譯者信息，歡迎轉載。

Nginx, HAProxy 和 Envoy 都是久經沙場的 L4 和 L7 代理。我們最終選擇了 Envoy 作為我們各種應用以及「開源工具 Ambassador API 」的一部分，並部署進 Kubernetes 的原因到底是什麼？

當今的主宰是 L7

在今天這個以雲為中心的世界上，業務邏輯基本都是分佈在許多轉瞬即逝的微服務之中。這些服務需要通過網路與其他服務進行交流。而被這些服務所運用的核心網路協議被稱為「 七層網路協議( Layer 7 Protocols )」 ，它們包括: HTTP, HTTP/2, gRPC, Kafka, MongoDB 等等。這些協議建立在經典的傳輸層協議( 比如TCP )之上。由於很大一部分應用的語義( semantics )和恢復工作( resiliency )都依靠 L7 傳輸，因此管理和觀測 L7 對於任何雲應用都是至關重要的。

Proxy 大戰

Ambassador 從設計之初就是沖著 L7 和麪向服務去的，而且我們最初只決定在 Kubernetes 上創建。我們清楚地明白必須避免自己從頭寫一個 proxy ，所以我們考慮了 HAProxy , Nginx 和 Envoy 作為可選項。在很多方面，這三個 proxy 都是高可靠、經過考驗的，其中 Envoy 還是他們之中最年輕的那個。

評估這三個 Proxy

我們從評估這三個 proxy 的不同特點開始。很快我們就意識到 L7 代理在很多方面都是一個「商業架構」。所有 proxy 都很出色，而且在路由 L7 傳輸時都非常可靠、高效，用在這裡甚至還有點小題大做。以及儘管他們在特性上略有出入，我們依然覺得我們應該、或者必須親手實現一些這些 proxy 本身沒有的重要特性。畢竟，它們都是開源工具！

我們退了一步並重新考慮起我們的評估標準。在它們的功能特性上已然有了一個初步認識，我們將評估的重點重新聚焦在了這三個方面：準確來講，我們主要參考每個 proxy 的社區、迭代速度和設計哲學。我們關注社區是因為，一個生機勃勃的社區可以使我們貢獻代碼更加輕鬆方便。關於社區，我們還想看到這款 proxy 有一個良好的迭代頻率，這顯示出這款 proxy 能夠快速進化發展出用戶需要的功能。最後，我們想要這款 proxy 能夠儘可能緊密地貼合我們微服務世界中以 L7 為中心的願景。

HAProxy

很多年前，我們當中有人在 Baker Street 工作，一個基於 HAProxy 的客戶端負載均衡器被 AirBnbs SmartStack 發明出來了。HAProxy 是一個非常可靠，迅速而且經歷考驗的 proxy 。儘管我們使用 HAProxy 很開心，但我們對於 HAProxy 由更為長久的考量。HAProxy 的首個版本於 2006 年發布，而當時的互聯網工作方式與今天的差別很大。HAProxy 社區的迭代速度看起來並不快。舉個例子， v1.5 版本在 4 年後才加入了 SSL 功能。我們已經經歷過了熱部署( 無需重啟服務就能讓你的新配置載入 )的挑戰，而這個挑戰直到 2017 年年底也沒有被完全解決( 儘管坊間流傳它們的代碼庫被 Joey at Yelp 給駭了一把 )。在 v1.8 這個版本， HAProxy 的團隊已經開始趕製微服務架構所需要的最基本功能，但是直到 2017 年 11 月這個 v1.8 版本還是沒被鼓搗出來。

Nginx

Nginx 是一個高性能的 web server 並且支持熱部署。 Nginx 最初被設計成一個 web server，並且時過境遷逐漸進化成了一個支持更加傳統的 proxy 用例。 Nginx 有兩個版本——收費的商業版本 Nginx Plus 和免費的開源版本 Nginx open source 。對於 Nginx ， Nginx Plus 是 「擁有前置負載均衡器和應用傳遞控制的擴展版 Nginx 」。聽起來棒極了！但是很不幸，我們想要讓 Ambassador 完全開源，而 Nginx Plus 並不是我們的菜。

Nginx open source 有一些限制，其中包括了「可觀測性」和「健康診斷」。為了規避這些 Nginx open source 的限制，我們在 Yelp 的朋友實際上將 HAProxy 和 Nginx 部署在一起了。

更通俗的來講，儘管 Nginx 比 HAProxy 迭代速度快很多，我們擔心很多我們需要的特性都鎖在了 Nginx Plus 中。Nginx 的商業模型使得 Nginx open source 和 Nginx Plus 之間的繼承關係有不少矛盾，而且如果向上遊貢獻代碼，我們並不確定我們的勁頭會被如何榨乾。( 注意 HAProxy 同樣是有「企業版」的，但是它的「企業版」和「社區版」的差別看起來並沒有 Nginx 這麼大 )

Envoy Proxy

Envoy 在我們的選項中是最年輕的，但它已經被 Lyft，Apple，Salesforce，Google 和其他大型IT企業用於生產環境。在很多方面，Envoy 於 2016 年 9 月的發布觸發了代理領域的一輪激烈創新和競爭。

Envoy 自底向上都是為了微服務而設計的，具有諸如熱部署，可觀測性，可恢復性和先進的負載均衡等特徵。Envoy 同樣擁抱分散式架構，應用最終一致性( eventual consistency )作為核心設計原則以及為配置項暴露動態 API (dynamic API)。傳統意義上，proxy 應該被靜態的配置文件所配置。然而 Envoy 不但支持靜態配置文件的模型，而且允許通過 gRPC 和 protobuf API 進行配置。這會使得在擴容時的管理變得異常簡單，而且也會允許 Envoy 更好的在轉瞬即逝的微服務環境中工作。

我們愛死 Envoy 這一系列特性和產品版本超前的設計理念了。我們也發現 Envoy 的社區相較 HAProxy 和 Nginx 是獨特的。不像其他兩個 proxy，Enovy 並不被任何商業實體所擁有。Envoy 最早是由 Lyft 創建的，因此同樣地，Lyft 也沒必要用 Envoy 直接賺錢。Envoy 的創造者 Matt Klein 明確表示他不會為 Envoy 成立一個公司來賺錢。並沒有任何經濟壓力需要 Envoy 的所有者整出來個 「Envoy Plus」 或者 「Envoy EE」 。因此，Envoy的社區只專註於「如何用最好的代碼開發出正確的功能」，而不需要總把心思放在怎麼賺錢上。最後，Lyft 將整個 Envoy 工程捐贈給了 CNCF ( Cloud Native Computing Foundation)。CNCF 給 Envoy 提供了一個獨立的家，來確保 Envoy 專註於建設最棒的 L7 proxy 並始終保持其領先地位。

選擇了 Envoy 的一年之後...

沒有什麼能比決定使用 Envoy 來創建 Ambassador 更令我們開心的了。其豐富的特性集讓我們快速地添加 gRPC、速率限制( rate limiting )、隱匿功能( shadowing )、金絲雀測試( canary routing )和可觀測性等一系列功能的支持。對於那些 Envoy 的特性沒能滿足我們需求的部分( 比如許可權問題 )，我們已經能和 Envoy 社區一起工作並實現必要的功能特性了。

Envoy 的代碼庫以一種難以置信的節奏大步向前邁進著，我們對 Envoy 持續提供給 Ambassador 的好處非常激動。保持這個節奏，我們將會繼續利用 Envoy 迭代 Ambassador！

翻譯By 田同學

希望對您的工作學習有所幫助，謝謝。


推薦閱讀：
相關文章