簡介：三位一體是阿里巴巴“自研”、“開源”、“商業化”採用的統一技術體系，希望以開源做核心、結合阿里巴巴內部豐富的業態和業務需求，通過自研進一步打磨軟體的效能與高可用性，最終形成三位一體的旋轉飛輪。
作者 | 如葑
三位一體是阿里巴巴“自研”、“開源”、“商業化”採用的統一技術體系，希望以開源做核心、結合阿里巴巴內部豐富的業態和業務需求，通過自研進一步打磨軟體的效能與高可用性，然後以雲上商業化服務的形式，向所有使用者開放，同時也會向開源社群持續貢獻，最終形成三位一體的旋轉飛輪。阿里云云原生團隊所支撐的集團業務，分為三層：BaaS、Runtime、Serverless，各層以開源軟體為核心，在開源核心上進行整合和擴充套件，經大規模生產驗證後，推向商業化。
開源具有生態、開放的優勢，自研具有效能高、可用性強的優勢，而商業化則具有易用、安全的優勢，基於三位一體的技術體系，可以將開源、自研與商業化都有其各自的優點結合在一起，發揮出最大的優勢。
雲原生閘道器在阿里巴巴的發展軌跡
1、誕生背景
雲原生閘道器的建立，源於集團內部的“本地生活戰役”，該戰役始於“支付寶 2020 合作伙伴大會”，在此大會上支付寶宣佈升級為數字生活開放平臺。該戰役的核心技術目標，是實現阿里巴巴業務域與螞蟻業務域之間 RPC 直接呼叫，但因阿里巴巴與螞蟻業務域網路是隔離的，即網路是不通的，很自然想到利用閘道器來解決此問題。
2、技術選型
利用閘道器來解決阿里巴巴與螞蟻跨業務域 RPC 互通問題，首先要對閘道器做技術選型。
相信大家也都或多或少知道，阿里巴巴開源的反向代理程式 Tengine。Tengine 在阿里內部統一接入閘道器 AServer 中被使用，我們團隊當時就是負責開發運維 AServer 的，同時我們團隊也在負責阿里巴巴 Service Mesh 的落地，不管是對 Tengine 還是對 Istio + Envoy 這套架構都比較熟悉。
在選型時，雖然也調研過一些其他的軟體，但考慮到閘道器對效能、可靠性的高要求，在結合我們自身的閘道器運維經驗，決定看看 Tengine 與 Envoy 是否可以滿足我們的業務需求，在對比時我們羅列了四個關鍵要點，其對比如下：
這裡提一下“為什麼我們認為配置的熱更新，是非常重要的”？
Tengine/Nginx 的配置更新需要 reload，reload 需要重啟 worker 程式，重啟時會引起流量抖動，對長連線影響尤為明顯。在閘道器的叢集規模非常大時，更是不能隨意的做 reload，這時就會引發一個矛盾點：業務向閘道器提交配置後，希望能快速驗證，但受限於 reload 機制和穩定性要求，無法滿足業務快速驗證與快速試錯的訴求。
如何解決這點呢？
一是採用兩層閘道器，即流量閘道器 + 業務閘道器；二是實現閘道器原生支援配置熱更新。除了對比不同方案的優劣勢，我們也調研了 Envoy 作為閘道器在業界的趨勢，結論是目前 Envoy 作為 K8s 中的 Ingress Provider 增長最快的事實（Ingress Provider 指 K8s Ingress 規範具體實現，因 K8s Ingress 自身只是規範定義，是 K8s 下外部流量進入叢集內部的閘道器規範定義），我們最終選擇了 Envoy 來實現兩層閘道器。
3、發展歷程
雲原生閘道器從最初社群的 Istio + Envoy，到經歷阿里巴巴內部的自研擴充套件，再到大規模生成驗證，最後完成商業化產品的釋出，其整個過程介紹如下：
這個過程中，我們也正持續的、堅定的向開源社群貢獻自己的力量，例如向 Envoy 社群提交了 Dubbo 支援、RocketMQ 支援，並解決了一些社群 issue 等。
雲原生閘道器為何被稱為下一代閘道器
1、傳統閘道器分類及部署模式
行業中通常把閘道器分為兩個大類：流量閘道器與業務閘道器。
流量閘道器，主要提供全域性性的、與後端業務無關的策略配置，例如，阿里內部的的統一接入閘道器 Tengine 就是典型的流量閘道器；業務閘道器，顧名思義主要提供獨立業務域級別的、與後端業務緊耦合策略配置。隨著應用架構模式從單體演進到現在的分散式微服務，業務閘道器也有了新的叫法 - 微服務閘道器（圖示說明如下）。
2、下一代閘道器應該具備哪些核心因素
在容器技術與 K8s 主導的雲原生時代，下一代的閘道器模式仍然會是傳統的流量閘道器與微服務閘道器的兩層架構嗎？
帶著這個問題，並結合阿里巴巴內部沉澱的閘道器技術與運維經驗，我們嘗試來回答下，什麼是下一代閘道器。
我們對其中幾個非常核心的要素展開說明下：
- 雲原生：要支援標準 K8s Ingress、K8s Gateway API 以及 K8s 服務發現，在雲原生時代，K8s 已經成為雲 OS，而 K8s 原生叢集內外部的網路是隔離的，負責外部流量進入，K8s 叢集的規範定義就是 K8s Ingress，K8s Gateway API 是 K8s Ingress 的進一步演化，基於此，作為下一代閘道器，勢必要支援這種特性。
- 擁抱開源：要基於開源生態構建閘道器，藉助開源並助力開源，相信這點大家應該都不陌生。
- 高擴充套件：任何一個閘道器的能力都不可能覆蓋所有的使用者訴求，要具備可擴充套件能力，例如 K8s 的蓬勃發展其開放的擴充套件能力功不可沒。
- 服務治理：隨著應用架構演進到分散式微服務，閘道器本身就是為後端業務提供流量排程能力，其支援基本的服務治理能力也就順其自然了。
- 豐富的可觀測性：分散式微服務架構帶來協同效率提升等益處的同時，對於問題排查及運維帶來了更大的挑戰，作為流量橋頭堡的閘道器需要具備豐富的可觀測資料，幫助使用者來定位問題。
基於以上的分析和實踐，我們認為，在虛擬化時期的微服務架構下，業務通常採用流量閘道器 + 微服務閘道器的兩層架構，流量閘道器負責南北向流量排程和安全防護，微服務閘道器負責東西向流量排程和服務治理，而在容器和 K8s 主導的雲原生時代，Ingress 成為 K8s 生態的閘道器標準，賦予了閘道器新的使命，使得流量閘道器 + 微服務閘道器合二為一成為可能。
MSE - 雲原生閘道器的優勢
1、更經濟：將流量閘道器與微服務閘道器合二為一，使用者資源成本直降50%
MSE - 雲原生閘道器在能力不打折的情況下，將兩層閘道器變為一層，不僅可以節省 50% 的資源成本，還可以降低運維及使用成本。部署結構示意圖如下，左邊為傳統閘道器模式，右圖為下一代雲原生閘道器模式。
在微服務的大背景下，豐富的可觀測能力也是使用者的基礎核心訴求，MSE - 雲原生閘道器基於此預設整合了阿里雲應用實時監控服務 ARMS，提供豐富的可觀測資料，且該功能對使用者免費。
2、更安全：提供豐富的認證鑑權能力，降低客戶的安全接入成本
認證鑑權是客戶對閘道器的剛需，MSE - 雲原生閘道器不僅提供常規的 JWT 認證，也提供基於授權開放網路標準 OAuth 2.0 的 OIDC 認證。同時，MSE - 雲原生閘道器天然支援阿里雲的應用身份服務 IDaaS 幫助客戶實現支付寶、淘寶、天貓等第三方認證登陸，並以外掛的方式支援來擴充套件認證鑑權功能，以降低客戶的安全接入成本。現有認證鑑權功能如下圖：
3、更統一：閘道器直連後端服務，打通 Nacos/Eureka/K8s 多種服務來源，並且率先支援 Apache Dubbo3.0 協議
開源已經成為推動軟體發展的源動力之一，面向社群標準、開放的商業產品更有生命力。
Envoy 是最受 K8s 社群歡迎的 Ingress 實現之一，正成為雲原生時代流量入口的標準技術方案。MSE 雲原生閘道器依託於 Envoy 和 Istio 進行構建，實現了統一的控制面管控，並直連後端服務，支援了 Dubbo3.0、Nacos，打通阿里雲容器服務 ACK，自動同步服務註冊資訊。MSE 雲原生閘道器對 Dubbo 3.0 與 Nacos 的支援，已經率先在釘釘業務中上線，下圖是釘釘 Dubbo 3.0 落地的部署簡圖如下：
4、更穩定：技術積澱已久，歷經2020雙11考驗，每秒承載數10萬筆請求
商用產品並非一朝一夕。
MSE 雲原生閘道器早已在阿里巴巴內部經歷千錘百煉。目前已經在支付寶、釘釘、淘寶、天貓、優酷、飛豬、口碑等阿里各業務系統中使用，並經過 2020 雙11 海量請求的考驗，大促日可輕鬆承載每秒數 10萬 筆請求，日請求量達到百億級別。
雲原生閘道器目前可以涵蓋南北向、東西向全業務場景，即可以支援傳統的註冊中心，例如 Nacos，也可以支援 K8s Service，同時也可以支援傳統 ECS，下面通過圖示說明如下：
Nginx 閘道器遷移雲原生閘道器實踐案例
1、優酷 Nginx 閘道器遷移案例
優酷業務內部有三個利用 Nginx 構建的閘道器，使用 Lua 指令碼做了一些業務擴充套件，但是隨著人員迭代，閘道器的運維變得越來越困難，主要包括 Lua 指令碼維護難、配置變更不實時、多閘道器運維難以及配置變更 reload 與業務快速迭代的矛盾越來越多。因此，我們配合業務一起完成了 Nginx 閘道器到雲原生閘道器的平滑遷移，為了保障遷移平滑、低成本，在雲原生閘道器中專門針對 Nginx 的 error page 等功能做了擴充套件。如下圖：
看到上面這幅圖讀者可能問為什麼採用了兩層閘道器結構？即 AServer（流量閘道器） + 業務自建閘道器。
這是因為對於阿里巴巴這種超大流量的業務，採用兩層架構，由流量閘道器統一負責安全防護、全域性流量排程成本會更低，不需要每個業務 BU 都做重複的事情，業務自建閘道器掛在流量閘道器之後，又可以滿足業務自身快速迭代的要求；但是對於非超大規模的業務，使用兩層架構反而會帶來運維複雜度的上升。
2、Ingress-nginx 遷移方案
在 K8s Ingress Provider 中雖然使用 Envoy 架構的使用者增長排在第一位，但不可否認的是，目前 Ingress-nginx 仍佔據 K8s Ingress Provider 最大的份額，那麼雲原生閘道器是否可以相容 Ingress-nginx 配置，為使用者提供低成本甚至零成本的遷移方案呢？
帶著這個問題我們也做了探索，Ingress-nginx 並沒有採用定義新 CRD 的方式來擴充套件標準 K8s Ingress 能力，而是利用 Annotation 的方式，首先我們分析了 Ingress-nginx 的 Annotation 列表，如下：
依據使用者使用度對齊做了優先順序排序，其中處於高、中的 Annotation 雲原生閘道器已經支援自動轉換，剩餘的除了插入程式碼片段等這些跟 Nginx 內部實現相關的 Annotation 外，我們也正在逐步的支援轉換，目標就是做到零成本的遷移。轉換流程簡圖如下：
寫在最後
MSE - 雲原生閘道器，旨在為使用者提供更可靠的、成本更低、效率更高的，符合 K8s Ingress 標準的企業級閘道器產品，更多釋出詳情移步直播間觀看：https://yqh.aliyun.com/live/detail/26484
MSE - 雲原生閘道器提供後付費和包年包月兩類付費模式，支援杭州、上海、北京、深圳 4 個 region，並會逐步開放其他 region。
版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。