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