阿里巴巴在 Envoy Gateway 的演進歷程淺析
作者:耿蕾蕾(如葑):阿里雲研發工程師,從 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 也是增長最快的,社群接受度高。
在 2020 年 5 月,我們啟動了 Envoy Gateway 1.0 的研發,同年成功支撐了雙 11 大促,且成為核心重保的業務鏈路。
Envoy Gateway 1.0 主要是應用於東西向流量的 RPC 互通,其架構部署如下圖:
這個時期,我們面對未來演進了 Dubbo3.0 的 Triple 協議,基於 Envoy,演進了閘道器的服務管理能力,支撐了當年雙十一本地生活戰役數十萬 TPS 的流量洪峰。
Envoy Gateway 2.0(成長期)
隨著阿里巴巴上雲戰役的推進,越來越多的場景找到我們,如雲上雲下業務互通,由於 Tengine 服務管理弱導致阿里內部大量二層微服務閘道器需要收斂,因此從業務上我們需要做 Tengine+Envoy 兩層閘道器的演進,承擔南北向閘道器流量。在 2020 年 12 月份我們開始了 2.0 架構的演進,下面以優酷場景為例說明演進過程如下圖:
Envoy Gateway 2.0 南北向的架構圖如下:
在兩層架構中,Envoy 閘道器更多承擔了微服務閘道器和微服務治理的需求,和 Tengine 流量閘道器完成了整合。在這個過程中,我們提升了服務治理和高可用能力,並且支撐優酷內部多個二層微服務閘道器統一,大幅提升效能和運維效率。
2.0 階段,Envoy Gateway 完成了東西向、南北向全域流量的排程分發,東西向上不僅支援跨業務域的螞蟻 RPC 互通,更是擴充套件到了混合雲的雲上雲下的 RPC 互通場景,包括釘釘文件、阿里影片雲、達摩院的店小蜜、智慧數字人等,2.0 階段的業務大圖如下(雲上雲下互通場景,以釘釘為例說明):
隨著 Envoy Gateway 業務的快速鋪開,在跟優酷持續合作時大家不約而同的提出了一個問題:Tengine Gateway(承擔流量閘道器角色) + Envoy Gateway(承擔微服務閘道器角色)的兩層閘道器是否可以合併,使用 Envoy Gateway?答案是肯定的,而且我們也合作設計了新的架構圖,如下:
這個方案的演進,讓我們看到了閘道器新的發展態勢,尤其在以 K8s 主導的容器化背景下,K8s 叢集內外網路的天然隔離性,使用者也需要一款兼顧高效能與安全性、以及強大服務治理能力的入口閘道器,這也為我們走向 3.0 提供了很好的積累。
Envoy Gateway 3.0(成熟期)
隨著阿里巴巴大量場景的打磨,Envoy 閘道器效能、穩定性都獲得了很好的發展。2021 年,阿里巴巴開啟了中介軟體三位一體戰役,用雲產品支撐集團業務,因此我們也將孵化成熟的技術通過 MSE 雲原生閘道器來服務集團。
點選此處,瞭解 MSE 更多詳情
此時,我們通過 Envoy 將流量閘道器 + 微服務網關合二為一的同時,還通過硬體加速、核心優化等手段,在效能不打折的情況下,持續優化閘道器的資源部署成本。
技術架構決定技術優勢,Envoy 天然的可擴充套件性,還能將豐富的安全認證和微服務治理能力進行整合,體現了雲原生閘道器高聚合的優勢,例如:
- 閘道器直連業務 PodIP,不經過傳統 Cluster IP,RT 更低
- 支援 HTTPS 硬體加速,QPS 提升 80%
- 支援 Wasm 外掛市場,外掛熱載入,滿足多語言自定義外掛需求
- 自研 Multi-Ingress Controller 元件支援多叢集 Ingress 複用同一個閘道器例項
- 原生相容 K8s Ingress 規範,且支援 Nginx Ingress 核心功能註解的無縫轉化
回饋社群
我們在對 Envoy Gateway 進行演進的過程中,也提了很多社群 issue,包括:dubbo_proxy、wasm、cryptomb 等,未來我們會陸續回饋社群,作出更多貢獻,和社群共同打造下一代閘道器。
- 啟動!阿里巴巴程式設計之夏2022
- 雲原生混部最後一道防線:節點水位線設計
- OpenKruise v1.2:新增 PersistentPodState 實現有狀態 Pod 拓撲固定與 IP 複用
- Serverless Job——傳統任務新變革
- 首評 | 阿里雲順利完成國內首個雲原生安全成熟度評估
- Serverless Job——傳統任務新變革
- 阿里雲釋出效能測試 PTS 2.0:低成本、高效率、多場景壓測,業務穩定性保障利器
- ZooKeeper 在阿里巴巴的服務形態演進
- OpenYurt v0.7.0 版本解讀:無侵入的跨網路域解決方案 Raven
- K8s 閘道器選型初判:Nginx 還是 Envoy?
- K8s 閘道器選型初判:Nginx 還是 Envoy?
- ZooKeeper 在阿里巴巴的服務形態演進
- 面向高校 | “雲原生技術應用與實踐”示範課程專案開放申報
- 硬之城獲阿里雲首批產品生態整合認證,攜手阿里雲共建新合作
- 基於阿里雲 ASK 的 Istio 微服務應用部署初探
- Seata 1.5.1 重磅釋出,支援使用者控制檯,企業版正式免費公測
- OpenYurt v0.7.0 版本解讀:無侵入的跨網路域解決方案 Raven
- 最佳實踐|從Producer 到 Consumer,如何有效監控 Kafka
- 報名進入尾聲,趕快申請加入 sealer 開源之夏吧!
- OpenClusterManagement 開源之夏 2022 來了