流量入口代理作為互聯網系統的門戶組件，具備眾多選型：從老牌代理 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 網關等多個項目在網易集團落地及商業化產品輸出。