*作者：如葑
阿里巴巴三位一體戰略解讀之雲原生網關開源、自研、商業化，目前雲原生網關已正式商業化，旨在為用戶提供更可靠的、成本更低、效率更高的符合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 可加入用戶群交流、答疑。
