阿裡巴巴三位一體戰略解讀之雲原生網關開源、自研、商業化，目前雲原生網關已正式商業化，旨在為使用者提供更可靠的、成本更低、效率更高的符合K8s Ingress标準的企業級網關産品。
*作者：如葑
阿裡巴巴三位一體戰略解讀之雲原生網關開源、自研、商業化，目前雲原生網關已正式商業化，旨在為使用者提供更可靠的、成本更低、效率更高的符合K8s Ingress标準的企業級網關産品，更多詳情将在10月26日下午15:00直播間詳細為您講解，詳情戳：https://yqh.aliyun.com/live/detail/26605
阿裡雲雲原生三位一體總體戰略解讀
目前開源軟體已經成為企業軟體創新發展的主要平台，在此大背景下阿裡巴巴雲原生提出了三位一體戰略，即開源、自研與商業化，希望以開源做核心、結合阿裡集團内部業務需求做自研進一步打磨軟體的性能與高可用、然後以商業化産品的方式向所有使用者開放，同時也會向開源社群持續貢獻，最終形成三位一體的旋轉飛輪。整體政策簡介如下圖：
雲原生團隊業務整體上分為三層：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 可加入使用者群交流、答疑。