阿里巴巴重磅開源雲原生閘道器: Higress

11月5日，2022 杭州 · 雲棲大會-雲原生峰會現場，阿里巴巴研究員、阿里雲智慧雲原生應用平臺總經理丁宇宣佈：雲原生閘道器 Higress 正式開源，Higress 是一款標準化、高整合、易擴充套件、熱更新的雲原生閘道器。

Higress 源自阿里巴巴內部電商、交易等核心生產場景的實踐沉澱，遵循 Ingress/Gateway API 標準，將流量閘道器、微服務閘道器、安全閘道器三合一，並在此基礎上擴充套件了服務管理外掛、安全類外掛和自定義外掛，高度整合 K8s 和微服務生態，包括 Nacos 註冊和配置、Sentinel 限流降級等能力，並支援規則變更毫秒級生效等熱更新能力。

Higress 的前世今生

誕生背景

Higress 的建立源於阿里內部的“本地生活戰役”，該戰役始於“支付寶 2020 合作伙伴大會”，在此大會上支付寶宣佈升級為數字生活開放平臺。該戰役的核心技術目標，是實現阿里巴巴業務域與螞蟻業務域之間 RPC 直接呼叫，但因阿里巴巴與螞蟻業務域網路是隔離的，即網路是不通的，很自然想到利用閘道器來解決此問題。

技術選型

利用閘道器來解決阿里巴巴與螞蟻跨業務域 RPC 互通問題，首先要對閘道器做技術選型。

相信大家也都或多或少知道，阿里巴巴開源的反向代理程式 Tengine。Tengine 在阿里內部統一接入閘道器 AServer 中被使用，我們團隊就是負責其開發運維，同時我們團隊也在負責阿里巴巴 Service Mesh 的落地，不管是對 Tengine 還是對 Istio + Envoy 這套架構都比較熟悉。

在選型時，雖然也調研過一些其他的軟體，但考慮到閘道器對效能、可靠性的高要求，在結合我們自身的閘道器運維經驗，決定看看 Tengine 與 Envoy 是否可以滿足我們的業務需求，在對比時我們羅列了四個關鍵要點，其對比如下：

這裡提一下“為什麼我們認為配置的熱更新，是非常重要的”？

Tengine/Nginx 的配置更新需要 reload，reload 需要重啟 worker 程序，重啟時會引起流量抖動，對長連線影響尤為明顯。在閘道器的叢集規模非常大時，更是不能隨意的做 reload，這時就會引發一個矛盾點：業務向閘道器提交配置後，希望能快速驗證，但受限於 reload 機制和穩定性要求，無法滿足業務快速驗證與快速試錯的訴求。

現在已經有很多主流應用選擇採用長連線，HTTP 1.1 一般預設會使用 Keep-Alive 去保持長連線，後續 HTTP 2 以及 HTTP 3 也是如此，隨著網路協議的發展，未來使用長連線會變得更加普遍。而配置熱更新天然對長連線非常友好。

如何解決這點呢？

一是採用兩層閘道器，即流量閘道器 + 業務閘道器；二是實現閘道器原生支援配置熱更新。除了對比不同方案的優劣勢，我們也調研了 Envoy 作為閘道器在業界的趨勢，結論是目前 Envoy 作為 K8s 中的 Ingress Provider 增長最快的事實（Ingress Provider 指 K8s Ingress 規範具體實現，因 K8s Ingress 自身只是規範定義，是 K8s 下外部流量進入叢集內部的閘道器規範定義），我們最終選擇了 Envoy 來實現兩層閘道器。

發展歷程

Higress 從最初社群的 Istio + Envoy，到經歷阿里巴巴內部的自研擴充套件，再到大規模生成驗證，最後完成商業化產品的釋出，其整個過程介紹如下：

下面的章節會對 Higress 的各個階段做進一步的詳細說明。

Higress(2020.05-2020.11)

此階段的大目標是為了滿足集團與螞蟻 RPC 互通，降低全鏈路的 RT，解決原 s2s 鏈路因 RT 過高帶來的使用者體驗差及無法滿足更多集團與螞蟻協同場景要求。s2s 鏈路是走公網鏈路，協議採用 HTTP。與螞蟻互通閘道器的架構圖如下，這裡以上海雲單元為背景說明。

上圖主要展示的是集團側的架構，最終採用了 Istio+Envoy 的方案，在部署的時候又分成了出口叢集和入口叢集。之所以拆成兩個叢集，一方面是當時兩邊互訪，螞蟻調集團的流量要遠遠大於集團調螞蟻的流量，上下行特別不均等；另一方面是分開之後兩個叢集可以各自維護，穩定性會更好。

Higress 從開始立項到完成第一期研發，閘道器改造的核心工作差不多兩個人投入了一個半月左右，其中還涉及到大量網路、安全等協調部門的工作。Higress 架構並沒有完全按照社群方案來設計，社群版本中配置變更和服務發現使用的是 K8s，在阿里內部龐大的服務規模及配置量下社群原生方案不管在穩定性及效能上都無法滿足要求，因此阿里這套方案重點對服務發現、配置儲存元件做了替換，及優化 xDS 推送效能。

Higress 上線後，順利達成了最初的業務訴求，目前螞蟻互通閘道器鏈路已經成為集團與螞蟻互通的首選方案，一些支付鏈路也遷移到了該方案，例如充值中心等，具體達到的成果簡述如下：

• 螞蟻呼叫集團鏈路相比原鏈路 RT 降低 50%，閘道器自身 RT 0.3ms。
• Higress 成功複製到集團與螞蟻的訊息互通，目前集團與螞蟻的訊息互通也是走的 Higress Triple 鏈路。
• 微服務閘道器從 5 月份上線，目前已經成為集團與螞蟻東西向流量的核心鏈路，飛豬、手淘、口碑、餓了麼、1688、部分導購應用、商品庫、評價等業務已成功上線，而且圓滿支撐了 618 大促、支付寶 717 夏至大促。
• 在 2020 雙 11 大促每秒 數十萬 的請求流量，圓滿支撐了雙 11 城市生活狂歡節的互動會場。
• 在技術側完成了 Higress 在東西向流量分發的探索。 

Higress(2020.12-2021.10)

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

Higress  南北向的架構圖如下：

在兩層架構中，Higress 閘道器更多承擔了微服務閘道器和微服務治理的需求，和 Tengine 流量閘道器完成了整合。在這個過程裡，團隊支撐優酷內部多個二層微服務閘道器統一的工作，大幅提升了效能和運維效率。

在這一階段，Higress Gateway 實現了東西向、南北向全域流量的排程分發，東西向上不僅支援跨業務域的螞蟻 RPC 互通，也擴充套件到了混合雲的雲上雲下 RPC 互通場景，覆蓋釘釘文件、阿里視訊雲、達摩院的店小蜜、智慧數字人等。該階段的業務大圖如下（雲上雲下互通場景，以釘釘為例說明）：

隨著 Higress Gateway 覆蓋的業務場景越來多，在跟優酷持續合作的過程中，雙方團隊不約而同提出了一個設想：Tengine Gateway（承擔流量閘道器角色） + Higress Gateway（承擔微服務閘道器角色）的兩層閘道器是否可以合併為一層 Higress Gateway？

我們對這一想法做了調研，答案是肯定的，並且當時大家也合作設計了新的架構方案，如下圖：

雖然由於各種各樣的原因，這個方案最終沒有跟優酷繼續往下推進。但這個演進方向讓團隊明確了閘道器新的發展趨勢：在以 K8s 主導的容器化背景下，由於 K8s 叢集內外網路的天然隔離性，使用者需要一款兼顧高效能與安全性，以及強大服務治理能力的入口閘道器。這也為後續團隊將技術沉澱變成雲產品、推進 Higress 的誕生打下了基礎。

2021 年，阿里巴巴開啟了中介軟體三位一體戰役，目標是用雲產品支撐集團業務。我們開始將孵化成熟的 Higress 技術沉澱為雲產品，即目前阿里雲上提供的 MSE 雲原生閘道器，一方面面向廣大的公有云使用者提供託管的閘道器服務，另一方面也對內服務集團。MSE 雲原生閘道器的技術架構簡圖如下：

Higress(2021.11-2022.11)

隨著 Higress 成為雲產品服務於更多外部使用者，我們逐步發現使用者對 Higress 提出了更高的要求，其中反饋較多的大的需求點是外掛擴充套件、Waf 防護、多註冊中心、Nginx Ingress 註解相容以及 HTTP 轉 Dubbo 協議，當然也有很多小的需求點在此就不一一列出，因此該階段我們重點發力在上述使用者反饋的高頻需求。

Higress 提供的外掛市場，其一階段支援 Wasm 外掛，滿足追求高效能、高安全的使用者對閘道器的擴充套件訴求，二階段會支援 Lua 外掛，滿足傳統使用者使用 Lua 的擴充套件的訴求，如 Nginx 使用者，三階段會支援程序外外掛，滿足多語言使用者訴求，尤其是 Java 使用者因現階段 Java 社群對 WebAssembly 支援尚不完善但又希望對閘道器進行擴充套件的訴求。

Higress 也支援了 Nginx Ingress 註解平滑遷移的能力，滿足部分使用者期望遷移到 Higress 但又不希望重新配置閘道器的訴求，同時 Higress 打破了 Nginx Ingress 只能關聯單個 K8s 叢集的限制，支援關聯多個 K8s 叢集，即可以將 Higress 作為統一接入閘道器使用，同時又可以享受 Ingress 的紅利。

對於傳統使用 Dubbo 的微服務使用者希望使用原生 RPC 方式暴露對外服務，但通常提供外部訪問的服務以使用 HTTP 為主，為了幫助 Dubbo 使用者降低服務暴露的開發成本，Higress 提供了 HTTP 轉 Dubbo 協議功能，且通過 Console 為使用者提供白屏化的配置方式，某客戶使用後反饋“這是業界完成度最高的 HTTP 轉 Dubbo 協議”功能。

在雲原生的浪潮下，開源已經成為軟體發展的必然趨勢與快速路徑，因為社群的力量是非常強大的。

因此我們將這套經過內部實踐沉澱下來的閘道器方案 Higress 正式對外開源，以 Kubernetes Ingress 閘道器為契機帶來了流量閘道器與微服務閘道器融合的可能性，結合阿里內部實踐沉澱 Higress 實現了流量閘道器 + 微服務閘道器 + 安全閘道器三合一的高整合能力，同時深度集成了 Dubbo、Nacos、Sentinel 等，能夠幫助使用者極大的降低閘道器的部署及運維成本，而且能力不打折。

Higress 未來展望

雖然目前雲原生已經成為必然趨勢，但現實是有很大一部分使用者處於遷移上雲的過程中，在從傳統架構向以 Kubernetes 為代表的容器化雲原生架構遷移，可預見這在未來很長一段時間會一直持續，因此 Higress 後續會重點支援非 Kubernetes 部署架構，以 Higress + Nacos 的組合形式為使用者提供最小集執行環境，同時滿足使用者服務註冊、配置管理、微服務治理的訴求。

在以 Kubernetes 為代表的容器化雲原生方向，我們在相容好現有 Ingress 標準的基礎上，會重點發力下一代的 Ingress 標準 Gateway API，利用 Gateway API 帶來的契機打通南北向與東西向的全域流量排程，幫助使用者使用一套架構架構同時管理外部與內部流量，降低部署運維成本、提升開發及運維效率。

搭把手

國內雲原生閘道器的開源專案並不多，Higress 今天剛開源，看看文章底部的閱讀量，您就是這條街 Topxxxx 關注 Higress 的。如果再走近一步，例如貢獻一份文件、提交一段程式碼，您就有可能成為 Higress  的第一批 Contributor 甚至 Committer。目前，我們建立了 1 個釘群和 1 個微信群，加入我們，聯絡群主或群管，共建雲原生閘道器吧。