簡介：三位一體是阿里巴巴“自研”、“開源”、“商業化”采用的統一技術體系，希望以開源做內核、結合阿里巴巴內部豐富的業態和業務需求，通過自研進一步打磨軟件的性能與高可用性，最終形成三位一體的旋轉飛輪。

作者 | 如葑

三位一體是阿里巴巴“自研”、“開源”、“商業化”采用的統一技術體系，希望以開源做內核、結合阿里巴巴內部豐富的業態和業務需求，通過自研進一步打磨軟件的性能與高可用性，然后以云上商業化服務的形式，向所有用戶開放，同時也會向開源社區持續貢獻，最終形成三位一體的旋轉飛輪。阿里云云原生團隊所支撐的集團業務，分為三層：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。

原文鏈接：https://developer.aliyun.com/article/799535?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的MSE | 阿里巴巴云原生网关三位一体的选择与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。