流量入口代理作為網際網路系統的門戶組件，具備眾多選型：從老牌代理 HAProxy、Nginx，到微服務 API 網關 Kong、Zuul，再到容器化 Ingress 規範與實現，不同選型間功能、性能、可擴展性、適用場景參差不齊。當雲原生時代大浪襲來，Envoy 這一 CNCF 畢業數據面組件為更多人所知。那麼，優秀「畢業生」Envoy 能否成為雲原生時代下流量入口標準組件？
背景 —— 流量入口的眾多選型與場景
在網際網路體系下，凡是需要對外暴露的系統幾乎都需要網絡代理：較早出現的 HAProxy、Nginx 至今仍在流行；進入微服務時代後，功能更豐富、管控能力更強的 API 網關又成為流量入口必備組件；在進入容器時代後，Kubernetes Ingress 作為容器集群的入口，是容器時代微服務的流量入口代理標準。關於這三類典型的七層代理，核心能力對比如下：
從上述核心能力對比來看：
HAProxy&Nginx 在具備基礎路由功能基礎上，性能、穩定性經歷多年考驗。Nginx 的下遊社區 OpenResty 提供了完善的 Lua 擴展能力，使得 Nginx 可以更廣泛的應用與擴展，如 API 網關 Kong 即是基於 Nginx+OpenResty 實現。API 網關作為微服務對外 API 流量暴露的基礎組件，提供比較豐富的功能和動態管控能力。Ingress 作為 Kubernetes 入口流量的標準規範，具體能力視實現方式而定。如基於 Nginx 的 Ingress 實現能力更接近於 Nginx，Istio Ingress Gateway 基於 Envoy+Istio 控制面實現，功能上更加豐富（本質上 Istio Ingress Gateway 能力上強於通常的 Ingress 實現，但未按照 Ingress 規範實現）。那麼問題來了：同樣是流量入口，在雲原生技術趨勢下，能否找到一個能力全面的技術方案，讓流量入口標準化？
Envoy 核心能力介紹
Envoy 是一個為雲原生應用設計的開源邊緣與服務代理（ENVOY IS AN OPEN SOURCE EDGE AND SERVICE PROXY, DESIGNED FOR CLOUD-NATIVE APPLICATIONS，@envoyproxy.io），是雲原生計算基金會（CNCF）第三個畢業的項目，GitHub 目前有 13k+ Star。
Envoy 有以下主要特性：
基於現代 C++ 開發的 L4/L7 高性能代理。透明代理。流量管理。支持路由、流量複製、分流等功能。治理特性。支持健康檢查、熔斷、限流、超時、重試、故障注入。多協議支持。支持 HTTP/1.1，HTTP/2，GRPC，WebSocket 等協議代理與治理。負載均衡。加權輪詢、加權最少請求、Ring hash、Maglev、隨機等算法支持。支持區域感知路由、故障轉移等特性。動態配置 API。提供健壯的管控代理行為的接口，實現 Envoy 動態配置熱更新。可觀察性設計。提供七層流量高可觀察性，原生支持分布式追蹤。支持熱重啟。可實現 Envoy 的無縫升級。自定義插件能力。Lua 與多語言擴展沙箱 WebAssembly。總體來說，Envoy 是一個功能與性能都非常優秀的「雙優生」。在實際業務流量入口代理場景下，Envoy 具備先天優勢，可以作為雲原生技術趨勢流量入口的標準技術方案：
1. 較 HAProxy、Nginx 更豐富的功能
相較於 HAProxy、Nginx 提供流量代理所需的基本功能（更多高級功能通常需要通過擴展插件方式實現），Envoy 本身基於 C++ 已經實現了相當多代理所需高級功能，如高級負載均衡、熔斷、限流、故障注入、流量複製、可觀測性等。更為豐富的功能不僅讓 Envoy 天生就可以用於多種場景，原生 C++ 的實現相較經過擴展的實現方式性能優勢更為明顯。
2. 與 Nginx 相當，遠高於傳統 API 網關的性能
在性能方面，Envoy 與 Nginx 在常用協議代理（如 HTTP）上性能相當。與傳統 API 網關相比，性能優勢明顯。如下為 Envoy 與幾種業務常用的 API 網關選型在 8 核物理機容器運行環境下，簡單路由代理性能對比數據：（網易內部環境實測數據，僅供參考）
Envoy Gateway：
基於 Java 的異步化 API 網關：
Kong：
APISIX：
從以上性能數據可以看出，相同條件下：
Envoy 的 TPS 可以達到 12W 左右；基於 Java 的異步化 API 網關最高可到 2.8W 左右；基於 Nginx 的 Kong，TPS 可以到 5W 左右；基於 Nginx 並相較 Kong 有一定優化的 APISIX 可以到 9W 左右。可以看出：
簡單路由代理場景下，Envoy 性能優勢已經比較明顯；複雜路由與治理功能場景下，Envoy 原生 C++ 實現功能的性能較通過 Java Filter、OpenResty 等擴展相比，優勢會更加明顯。3. 動態管控能力強，具備數據面標準 xDS 協議
Envoy 具備靜態配置與動態 API 兩種配置模式。動態 API 方式靈活性更強，作為 Envoy 推薦的配置方式。Envoy 以 xDS（x Discovery Service）作為動態 API 的標準協議，其中包括了多種維度資源的發現協議：
LDS(Listener Discovery Service)RDS(Route Discovery Service)CDS(Cluster Discovery Service)EDS(Endpoint Discovery Service)ADS(Aggregated Discovery Service)xDS 的多種協議覆蓋了包括監聽器（Listener）、路由（Route）、後端集群（Cluster）、後端實例（Endpoint），可以通過協議對代理所需所有配置進行動態管控。其中 ADS 不是一個實際意義上的 xDS，它提供了一個匯聚的功能，以實現需要多個同步 xDS 訪問的時候可以在一個 stream 中完成的作用。
由於 Envoy 已經以 CNCF 畢業項目的姿態成為了雲原生數據面的事實標準組件，xDS 也相應成為雲原生數據面事實動態 API 標準。這裡不對 xDS 協議進行深入的介紹，感興趣的同學可以通過社區與博客深入了解。
4. 天然親和容器環境
Envoy 作為雲原生社區的數據面標準組件，其本身並沒有直接與 Kubernetes 或容器耦合。通過 xDS 協議的對接，Istio Pilot 等容器親和的控制面組件可以將服務、實例、路由等配置信息推送至 Envoy。即使是在容器環境，Envoy 也很快能實現服務發現，即實現容器環境服務的代理和治理。所以，Envoy 天然親和容器環境，可以作為容器環境 API 網關和 Ingress 的數據面選型。
5. 多語言擴展沙箱——WASM
WASM，即 WebAssembly，是由主流瀏覽器廠商組成的 W3C 社區團體制定的一個新的規範，首先看下來自 Mozilla 的官方定義：WebAssembly 是一種新的編碼方式，可以在現代的網絡瀏覽器中運行
它是一種低級的類彙編語言，具有緊湊的二進位格式，可以接近原生的性能運行，並為諸如 C/C ++ 等語言提供一個編譯目標，以便它們可以在 Web 上運行。它也被設計為可以與 JavaScript 共存，允許兩者一起工作。
使用 WebAssembly 擴展 Envoy 的好處是：
避免修改 Envoy；避免網絡遠程調用（check & report）；通過動態裝載（重載）來避免重啟 Envoy；隔離性；實時 A/B 測試；WASM 為 Envoy 帶來了使用多語言擴展數據面的能力，即可以不局限地通過 C++、Java、Lua、JS 等語言進行數據面擴展，這對於流量代理數據面將是一個巨大的彩蛋。該特性已在 2020 年正式發布落地。相信在不遠的未來，開發者使用自己最為擅長的語言進行流量入口能力擴展不再是夢想！
Envoy Gateway 設計解析
基於雲原生時代的技術趨勢以及 Envoy 的功能、性能的「雙優」特性，網易輕舟雲原生團隊提出基於 Envoy 實現標準的流量入口設計，並基於此進行了大規模業務生產落地。
邏輯架構
邏輯架構設計如下圖所示：
整體架構主要包括數據面、控制面兩部分，實現方面則是擴展了 Istio ingressgateway：
數據面以 Envoy 作為數據面組件，負責南北向數據流量的代理、路由、治理、遙測等；通過 filterchain 進行擴展，目前支持基於 Lua、C++ 語言編寫插件，WASM 落地後支持多語言方式擴展；通過 xDS 與控制面組件進行配置下發等動態控制。
控制面以 Istio Pilot 作為基本控制面組件，同時提供 API 層、控制臺供用戶或第三方平臺接入。
Istio Pilot 在這裡主要包括如下作用：
1、作為 xDS Server。與 Envoy 的 xDS Client 建立 GRPC 通信連接，是與 Envoy 交互的基礎控制面。可支持控制不同場景下 Envoy(ServiceMesh Sidecar & API 網關 Gateway & Ingress & 入口七層代理)。2、對接註冊中心（Discovery）。支持對接 Kubernetes API Server（K8S 註冊中心能力），具備擴展 Consul、Eureka 等其他註冊中心能力。支持同時對接多種註冊中心，並將註冊信息經過配置轉換，下發至 Envoy。3、配置處理（Config）。對於要下發至 Envoy 的所有配置，均通過 Pilot 進行配置處理，再下發至 Envoy。4、模型抽象與接口封裝 (Mesh Configuration Protocol & Service Mesh Interface，簡稱 MCP & SMI)。Pilot 對 Envoy 的基礎模型進行了抽象，並進行基礎接口的封裝，使得其他平臺對 Envoy 的控制可以更加清晰與優雅。對外暴露的接口包括 GRPC 與 Kubernetes CRD 兩種形式。
API Plane 作為 API 平面，主要於對 K8S CRD、MCP 或 SMI 接口做面向業務功能的 API 組合、轉換處理。
管理控制臺是控制面最上層組件，也是研發、運維人員直接操作的平臺組件。
場景地圖
在 Envoy Gateway 技術棧基礎上，可以適應入口七層代理、API 網關、Ingress、單元化機房路由、FaaS 函數路由等多種場景落地應用。
1、入口七層代理
在流量入口場景下，可以承擔 HAProxy、Nginx 等傳統代理職責。
2、API 網關
在微服務場景下，承擔分解流量、路由、治理、審計等豐富職責。
3、Ingress
在容器化場景下，可以作為能力更豐富的 Ingress 實現。
4、通用網關
在完整使用 Envoy Gateway 方案下，可以省去原有入口七層代理 -> API 網關 /Ingress 的鏈路，由一層通用網關（Envoy Gateway）完成。
落地路線
目前 Envoy 以兩類角色在業界落地：一是作為 Service Mesh 數據面組件選型，目前在 Istio 等多種服務網格框架落地；二是作為流量入口代理，目前較多的是以 API 網關形式實現，如 Gloo、Ambassador 等。網易內部多個業務團隊已經實現了數據面技術棧從 Java 異步化代理、Kong 到 Envoy 的升級，基於網易輕舟 Envoy Gateway 作為流量入口標準組件。
由於 Envoy Gateway 與 Service Mesh 使用了相同的 Envoy+Istio 技術棧，使得不論 Envoy 作為 Gateway，或 Service Mesh 中的 Sidecar，都可以被統控制面管控，在提升了該技術棧整體可維護性基礎上，還可以幫助業務逐步演進到 Service Mesh 架構：如果業務對 Service Mesh 架構尚存疑慮，可以先落地 Envoy Gateway，後續待時機成熟再引入 Service Mesh 架構，完成整體微服務技術架構的演進與統一。
網易輕舟 Envoy Gateway 大規模落地
基於以上背景與設計，網易輕舟雲原生團隊實現了 Envoy Gateway，並且已經在網易多個核心業務大規模落地：
網易傳媒（新聞）已經實現全站流量通過輕舟 Envoy Gateway 暴露網易嚴選已經實現上雲服務全部流量通過輕舟 Envoy Gateway 暴露網易有道、雲信、Lofter 等網易核心網際網路業務流量通過輕舟 Envoy Gateway 暴露如下為網易輕舟 Envoy Gateway 控制臺部分線上業務管理視圖：
寫在最後
Envoy Gateway 能否真正意義成為雲原生時代流量入口標準目前尚不得知，但在業務落地過程中，我們已經看到了這套技術棧為業務所能帶來的架構、性能、治理、可觀測性等方面的紅利。在越來越多業務接入 Envoy Gateway、Service Mesh 過程中，相關的工程化平臺建設、排障工具等也在不斷完善，我們拭目以待。
參考連結
Envoy 官方文檔： https://www.envoyproxy.io/docsIstio 官方文檔： https://istio.io/docsEnvoy 實踐： https://www.jianshu.com/p/90f9ee98ce70WebAssembly 中文官方文檔： https://www.wasm.com.cnService Mesh 發展趨勢 (續)：棋到中盤路往何方： https://msd.misuland.com/pd/3545776840385758572_
作者簡介：
裴斐，網易杭州研究院輕舟雲原生技術專家、架構師。10 年企業級平臺架構和開發經驗，目前主要負責網易輕舟微服務治理團隊，專注於企業微服務架構及雲原生技術的研究與落地工作。帶領團隊完成網易輕舟 Service Mesh、微服務框架 NSF、API 網關等多個項目在網易集團落地及商業化產品輸出。