*作者：耿蕾蕾(如葑)：阿里雲研發工程師，從 2020 年 5 月負責 Envoy Gateway 的構建到推出 3.0，作為技術負責人主導了整個演進過程，在雲原生閘道器領域有著豐富的實踐。*

> 最近閱讀 《Envoy Gateway 來了》這篇文章，深感 Envoy 強大的可擴充套件性和基於 Envoy Gateway 帶來的易用性，在 K8s 架構下，Envoy 重新定義了閘道器的定位和能力，被譽為雲原生閘道器，甚至被稱之為下一代閘道器。阿里巴巴早在2018年就啟動了下一代閘道器的探索之路，本文將對這個探索歷程做一個簡單介紹。

阿里巴巴早在 2018 年，就開啟了雲原生上雲的序幕，將容器、服務網格作為核心技術點進行演進，並嘗試阿里巴巴和螞蟻透過這次技術演進，來統一雙方的中介軟體技術棧，讓業務更聚焦業務開發，遮蔽底層分散式複雜度。作為服務網格一個重要方向，我們開啟了下一代閘道器的探索之路。

## Envoy Gateway 1.0（孵化期）

上雲過程中，我們期望統一應用架構技術棧，但是螞蟻和阿里巴巴的 RPC 協議不同，存在互調鏈路長、協議轉換消耗大、Tengine Reload 訪問有損（接入生效快就需要不斷 reload 有損，如果控制 reload 影響，就要減少 reload 次數，接入服務生效慢）、Nginx 核心服務治理能力較弱等問題。因此，需要一個面對未來的閘道器解決方案。

當時，我們有兩個技術演進思路，一個是基於 Tengine 進行最佳化，一個是基於 Envoy 核心來擴充套件閘道器場景，考慮到 Tengine 解決這些場景架構變動太大，Envoy 作為閘道器的第二選項，能夠簡單的解決上述痛點，因此，我們選擇了 Envoy 核心作為下一代的閘道器演進方向，而且從 CNCF Ingress Provider 的統計資料來看，Envoy 也是增長最快的，社群接受度高。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/efc2a6df84414612a4f921fb4699468c~tplv-k3u1fbpfcp-zoom-1.image "1.png")

在 2020 年 5 月，我們啟動了 Envoy Gateway 1.0 的研發，同年成功支撐了雙 11 大促，且成為核心重保的業務鏈路。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13b28cbf63e94a0f95309f82aa485021~tplv-k3u1fbpfcp-zoom-1.image "2.png")

Envoy Gateway 1.0 主要是應用於東西向流量的 RPC 互通，其架構部署如下圖：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/85546572479a4a259a489d7eb0d2a22a~tplv-k3u1fbpfcp-zoom-1.image "3.png")

這個時期，我們面對未來演進了 Dubbo3.0 的 Triple 協議，基於 Envoy，演進了閘道器的服務管理能力，支撐了當年雙十一本地生活戰役數十萬 TPS 的流量洪峰。

## Envoy Gateway 2.0（成長期）

隨著阿里巴巴上雲戰役的推進，越來越多的場景找到我們，如雲上雲下業務互通，由於 Tengine 服務管理弱導致阿里內部大量二層微服務閘道器需要收斂，因此從業務上我們需要做 Tengine+Envoy 兩層閘道器的演進，承擔南北向閘道器流量。在 2020 年 12 月份我們開始了 2.0 架構的演進，下面以優酷場景為例說明演進過程如下圖：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c4b3a9ff372442389e23f739cb80654e~tplv-k3u1fbpfcp-zoom-1.image "4.png")

Envoy Gateway 2.0 南北向的架構圖如下：

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7a557c5e41914380b80c1cdf36624e91~tplv-k3u1fbpfcp-zoom-1.image "5.png")

在兩層架構中，Envoy 閘道器更多承擔了微服務閘道器和微服務治理的需求，和 Tengine 流量閘道器完成了整合。在這個過程中，我們提升了服務治理和高可用能力，並且支撐優酷內部多個二層微服務閘道器統一，大幅提升效能和運維效率。

2.0 階段，Envoy Gateway 完成了東西向、南北向全域流量的排程分發，東西向上不僅支援跨業務域的螞蟻 RPC 互通，更是擴充套件到了混合雲的雲上雲下的 RPC 互通場景，包括釘釘文件、阿里影片雲、達摩院的店小蜜、智慧數字人等，2.0 階段的業務大圖如下（雲上雲下互通場景，以釘釘為例說明）：

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c6d28c09d8ad4ab38eebd4ae04fb51be~tplv-k3u1fbpfcp-zoom-1.image "6.png")

隨著 Envoy Gateway 業務的快速鋪開，在跟優酷持續合作時大家不約而同的提出了一個問題：Tengine Gateway（承擔流量閘道器角色） + Envoy Gateway（承擔微服務閘道器角色）的兩層閘道器是否可以合併，使用 Envoy Gateway？答案是肯定的，而且我們也合作設計了新的架構圖，如下：

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2282fd48431f4787882caaf467d961b6~tplv-k3u1fbpfcp-zoom-1.image "7.png")

這個方案的演進，讓我們看到了閘道器新的發展態勢，尤其在以 K8s 主導的容器化背景下，K8s 叢集內外網路的天然隔離性，使用者也需要一款兼顧高效能與安全性、以及強大服務治理能力的入口閘道器，這也為我們走向 3.0 提供了很好的積累。

## Envoy Gateway 3.0（成熟期）

隨著阿里巴巴大量場景的打磨，Envoy 閘道器效能、穩定性都獲得了很好的發展。2021 年，阿里巴巴開啟了中介軟體三位一體戰役，用雲產品支撐集團業務，因此我們也將孵化成熟的技術透過 MSE 雲原生閘道器來服務集團。

點選[此處](https://www.aliyun.com/product/aliware/mse)，瞭解 MSE 更多詳情

此時，我們透過 Envoy 將流量閘道器 + 微服務閘道器合二為一的同時，還透過硬體加速、核心最佳化等手段，在效能不打折的情況下，持續最佳化閘道器的資源部署成本。

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f164efbfdb344da6ae13817ee2bb1eeb~tplv-k3u1fbpfcp-zoom-1.image "8.png")

技術架構決定技術優勢，Envoy 天然的可擴充套件性，還能將豐富的安全認證和微服務治理能力進行整合，體現了雲原生閘道器高聚合的優勢，例如：

-   閘道器直連業務 PodIP，不經過傳統 Cluster IP，RT 更低
-   支援 HTTPS 硬體加速，QPS 提升 80%
-   支援 Wasm 外掛市場，外掛熱載入，滿足多語言自定義外掛需求
-   自研 Multi-Ingress Controller 元件支援多叢集 Ingress 複用同一個閘道器例項
-   原生相容 K8s Ingress 規範，且支援 Nginx Ingress 核心功能註解的無縫轉化

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/73f61a074d1c4d7da9d0cffa977a3618~tplv-k3u1fbpfcp-zoom-1.image "9.png")

## 回饋社群

我們在對 Envoy Gateway 進行演進的過程中，也提了很多社群 issue，包括：dubbo_proxy、wasm、cryptomb 等，未來我們會陸續回饋社群，作出更多貢獻，和社群共同打造下一代閘道器。

阿里巴巴在 Envoy Gateway 的演進歷程淺析

相關文章