簡介：三位一體是阿里巴巴“自研”、“開源”、“商業(yè)化”采用的統(tǒng)一技術(shù)體系，希望以開源做內(nèi)核、結(jié)合阿里巴巴內(nèi)部豐富的業(yè)態(tài)和業(yè)務(wù)需求，通過自研進一步打磨軟件的性能與高可用性，最終形成三位一體的旋轉(zhuǎn)飛輪。

作者 | 如葑

三位一體是阿里巴巴“自研”、“開源”、“商業(yè)化”采用的統(tǒng)一技術(shù)體系，希望以開源做內(nèi)核、結(jié)合阿里巴巴內(nèi)部豐富的業(yè)態(tài)和業(yè)務(wù)需求，通過自研進一步打磨軟件的性能與高可用性，然后以云上商業(yè)化服務(wù)的形式，向所有用戶開放，同時也會向開源社區(qū)持續(xù)貢獻，最終形成三位一體的旋轉(zhuǎn)飛輪。阿里云云原生團隊所支撐的集團業(yè)務(wù)，分為三層：BaaS、Runtime、Serverless，各層以開源軟件為內(nèi)核，在開源內(nèi)核上進行集成和擴展，經(jīng)大規(guī)模生產(chǎn)驗證后，推向商業(yè)化。

開源具有生態(tài)、開放的優(yōu)勢，自研具有性能高、可用性強的優(yōu)勢，而商業(yè)化則具有易用、安全的優(yōu)勢，基于三位一體的技術(shù)體系，可以將開源、自研與商業(yè)化都有其各自的優(yōu)點結(jié)合在一起，發(fā)揮出最大的優(yōu)勢。

云原生網(wǎng)關(guān)在阿里巴巴的發(fā)展軌跡

1、誕生背景

云原生網(wǎng)關(guān)的創(chuàng)建，源于集團內(nèi)部的“本地生活戰(zhàn)役”，該戰(zhàn)役始于“支付寶 2020 合作伙伴大會”，在此大會上支付寶宣布升級為數(shù)字生活開放平臺。該戰(zhàn)役的核心技術(shù)目標(biāo)，是實現(xiàn)阿里巴巴業(yè)務(wù)域與螞蟻業(yè)務(wù)域之間 RPC 直接調(diào)用，但因阿里巴巴與螞蟻業(yè)務(wù)域網(wǎng)絡(luò)是隔離的，即網(wǎng)絡(luò)是不通的，很自然想到利用網(wǎng)關(guān)來解決此問題。

2、技術(shù)選型

利用網(wǎng)關(guān)來解決阿里巴巴與螞蟻跨業(yè)務(wù)域 RPC 互通問題，首先要對網(wǎng)關(guān)做技術(shù)選型。

相信大家也都或多或少知道，阿里巴巴開源的反向代理程序 Tengine。Tengine 在阿里內(nèi)部統(tǒng)一接入網(wǎng)關(guān) AServer 中被使用，我們團隊當(dāng)時就是負(fù)責(zé)開發(fā)運維 AServer 的，同時我們團隊也在負(fù)責(zé)阿里巴巴 Service Mesh 的落地，不管是對 Tengine 還是對 Istio + Envoy 這套架構(gòu)都比較熟悉。

在選型時，雖然也調(diào)研過一些其他的軟件，但考慮到網(wǎng)關(guān)對性能、可靠性的高要求，在結(jié)合我們自身的網(wǎng)關(guān)運維經(jīng)驗，決定看看 Tengine 與 Envoy 是否可以滿足我們的業(yè)務(wù)需求，在對比時我們羅列了四個關(guān)鍵要點，其對比如下：

這里提一下“為什么我們認(rèn)為配置的熱更新，是非常重要的”？

Tengine/Nginx 的配置更新需要 reload，reload 需要重啟 worker 進程，重啟時會引起流量抖動，對長連接影響尤為明顯。在網(wǎng)關(guān)的集群規(guī)模非常大時，更是不能隨意的做 reload，這時就會引發(fā)一個矛盾點：業(yè)務(wù)向網(wǎng)關(guān)提交配置后，希望能快速驗證，但受限于 reload 機制和穩(wěn)定性要求，無法滿足業(yè)務(wù)快速驗證與快速試錯的訴求。

如何解決這點呢？

一是采用兩層網(wǎng)關(guān)，即流量網(wǎng)關(guān) + 業(yè)務(wù)網(wǎng)關(guān)；二是實現(xiàn)網(wǎng)關(guān)原生支持配置熱更新。除了對比不同方案的優(yōu)劣勢，我們也調(diào)研了 Envoy 作為網(wǎng)關(guān)在業(yè)界的趨勢，結(jié)論是目前 Envoy 作為 K8s 中的 Ingress Provider 增長最快的事實（Ingress Provider 指 K8s Ingress 規(guī)范具體實現(xiàn)，因 K8s Ingress 自身只是規(guī)范定義，是 K8s 下外部流量進入集群內(nèi)部的網(wǎng)關(guān)規(guī)范定義），我們最終選擇了 Envoy 來實現(xiàn)兩層網(wǎng)關(guān)。

3、發(fā)展歷程

云原生網(wǎng)關(guān)從最初社區(qū)的 Istio + Envoy，到經(jīng)歷阿里巴巴內(nèi)部的自研擴展，再到大規(guī)模生成驗證，最后完成商業(yè)化產(chǎn)品的發(fā)布，其整個過程介紹如下：

這個過程中，我們也正持續(xù)的、堅定的向開源社區(qū)貢獻自己的力量，例如向 Envoy 社區(qū)提交了 Dubbo 支持、RocketMQ 支持，并解決了一些社區(qū) issue 等。

云原生網(wǎng)關(guān)為何被稱為下一代網(wǎng)關(guān)

1、傳統(tǒng)網(wǎng)關(guān)分類及部署模式

行業(yè)中通常把網(wǎng)關(guān)分為兩個大類：流量網(wǎng)關(guān)與業(yè)務(wù)網(wǎng)關(guān)。

流量網(wǎng)關(guān)，主要提供全局性的、與后端業(yè)務(wù)無關(guān)的策略配置，例如，阿里內(nèi)部的的統(tǒng)一接入網(wǎng)關(guān) Tengine 就是典型的流量網(wǎng)關(guān)；業(yè)務(wù)網(wǎng)關(guān)，顧名思義主要提供獨立業(yè)務(wù)域級別的、與后端業(yè)務(wù)緊耦合策略配置。隨著應(yīng)用架構(gòu)模式從單體演進到現(xiàn)在的分布式微服務(wù)，業(yè)務(wù)網(wǎng)關(guān)也有了新的叫法 - 微服務(wù)網(wǎng)關(guān)（圖示說明如下）。

2、下一代網(wǎng)關(guān)應(yīng)該具備哪些核心因素

在容器技術(shù)與 K8s 主導(dǎo)的云原生時代，下一代的網(wǎng)關(guān)模式仍然會是傳統(tǒng)的流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)嗎？

帶著這個問題，并結(jié)合阿里巴巴內(nèi)部沉淀的網(wǎng)關(guān)技術(shù)與運維經(jīng)驗，我們嘗試來回答下，什么是下一代網(wǎng)關(guān)。

我們對其中幾個非常核心的要素展開說明下：

• 云原生：要支持標(biāo)準(zhǔn) K8s Ingress、K8s Gateway API 以及 K8s 服務(wù)發(fā)現(xiàn)，在云原生時代，K8s 已經(jīng)成為云 OS，而 K8s 原生集群內(nèi)外部的網(wǎng)絡(luò)是隔離的，負(fù)責(zé)外部流量進入，K8s 集群的規(guī)范定義就是 K8s Ingress，K8s Gateway API 是 K8s Ingress 的進一步演化，基于此，作為下一代網(wǎng)關(guān)，勢必要支持這種特性。
• 擁抱開源：要基于開源生態(tài)構(gòu)建網(wǎng)關(guān)，借助開源并助力開源，相信這點大家應(yīng)該都不陌生。
• 高擴展：任何一個網(wǎng)關(guān)的能力都不可能覆蓋所有的用戶訴求，要具備可擴展能力，例如 K8s 的蓬勃發(fā)展其開放的擴展能力功不可沒。
• 服務(wù)治理：隨著應(yīng)用架構(gòu)演進到分布式微服務(wù)，網(wǎng)關(guān)本身就是為后端業(yè)務(wù)提供流量調(diào)度能力，其支持基本的服務(wù)治理能力也就順其自然了。
• 豐富的可觀測性：分布式微服務(wù)架構(gòu)帶來協(xié)同效率提升等益處的同時，對于問題排查及運維帶來了更大的挑戰(zhàn)，作為流量橋頭堡的網(wǎng)關(guān)需要具備豐富的可觀測數(shù)據(jù)，幫助用戶來定位問題。

基于以上的分析和實踐，我們認(rèn)為，在虛擬化時期的微服務(wù)架構(gòu)下，業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)，流量網(wǎng)關(guān)負(fù)責(zé)南北向流量調(diào)度和安全防護，微服務(wù)網(wǎng)關(guān)負(fù)責(zé)東西向流量調(diào)度和服務(wù)治理，而在容器和 K8s 主導(dǎo)的云原生時代，Ingress 成為 K8s 生態(tài)的網(wǎng)關(guān)標(biāo)準(zhǔn)，賦予了網(wǎng)關(guān)新的使命，使得流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)合二為一成為可能。

MSE - 云原生網(wǎng)關(guān)的優(yōu)勢

1、更經(jīng)濟：將流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)合二為一，用戶資源成本直降50%

MSE - 云原生網(wǎng)關(guān)在能力不打折的情況下，將兩層網(wǎng)關(guān)變?yōu)橐粚?#xff0c;不僅可以節(jié)省 50% 的資源成本，還可以降低運維及使用成本。部署結(jié)構(gòu)示意圖如下，左邊為傳統(tǒng)網(wǎng)關(guān)模式，右圖為下一代云原生網(wǎng)關(guān)模式。

在微服務(wù)的大背景下，豐富的可觀測能力也是用戶的基礎(chǔ)核心訴求，MSE - 云原生網(wǎng)關(guān)基于此默認(rèn)集成了阿里云應(yīng)用實時監(jiān)控服務(wù) ARMS，提供豐富的可觀測數(shù)據(jù)，且該功能對用戶免費。

2、更安全：提供豐富的認(rèn)證鑒權(quán)能力，降低客戶的安全接入成本

認(rèn)證鑒權(quán)是客戶對網(wǎng)關(guān)的剛需，MSE - 云原生網(wǎng)關(guān)不僅提供常規(guī)的 JWT 認(rèn)證，也提供基于授權(quán)開放網(wǎng)絡(luò)標(biāo)準(zhǔn) OAuth 2.0 的 OIDC 認(rèn)證。同時，MSE - 云原生網(wǎng)關(guān)天然支持阿里云的應(yīng)用身份服務(wù)?IDaaS 幫助客戶實現(xiàn)支付寶、淘寶、天貓等第三方認(rèn)證登陸，并以插件的方式支持來擴展認(rèn)證鑒權(quán)功能，以降低客戶的安全接入成本。現(xiàn)有認(rèn)證鑒權(quán)功能如下圖：

3、更統(tǒng)一：網(wǎng)關(guān)直連后端服務(wù)，打通 Nacos/Eureka/K8s 多種服務(wù)來源，并且率先支持 Apache Dubbo3.0 協(xié)議

開源已經(jīng)成為推動軟件發(fā)展的源動力之一，面向社區(qū)標(biāo)準(zhǔn)、開放的商業(yè)產(chǎn)品更有生命力。

Envoy 是最受 K8s 社區(qū)歡迎的 Ingress 實現(xiàn)之一，正成為云原生時代流量入口的標(biāo)準(zhǔn)技術(shù)方案。MSE 云原生網(wǎng)關(guān)依托于 Envoy 和 Istio 進行構(gòu)建，實現(xiàn)了統(tǒng)一的控制面管控，并直連后端服務(wù)，支持了 Dubbo3.0、Nacos，打通阿里云容器服務(wù) ACK，自動同步服務(wù)注冊信息。MSE 云原生網(wǎng)關(guān)對 Dubbo 3.0 與 Nacos 的支持，已經(jīng)率先在釘釘業(yè)務(wù)中上線，下圖是釘釘 Dubbo 3.0 落地的部署簡圖如下：

4、更穩(wěn)定：技術(shù)積淀已久，歷經(jīng)2020雙11考驗，每秒承載數(shù)10萬筆請求

商用產(chǎn)品并非一朝一夕。

MSE 云原生網(wǎng)關(guān)早已在阿里巴巴內(nèi)部經(jīng)歷千錘百煉。目前已經(jīng)在支付寶、釘釘、淘寶、天貓、優(yōu)酷、飛豬、口碑等阿里各業(yè)務(wù)系統(tǒng)中使用，并經(jīng)過 2020 雙11 海量請求的考驗，大促日可輕松承載每秒數(shù) 10萬 筆請求，日請求量達(dá)到百億級別。

云原生網(wǎng)關(guān)目前可以涵蓋南北向、東西向全業(yè)務(wù)場景，即可以支持傳統(tǒng)的注冊中心，例如 Nacos，也可以支持 K8s Service，同時也可以支持傳統(tǒng) ECS，下面通過圖示說明如下：

Nginx 網(wǎng)關(guān)遷移云原生網(wǎng)關(guān)實踐案例

1、優(yōu)酷 Nginx 網(wǎng)關(guān)遷移案例

優(yōu)酷業(yè)務(wù)內(nèi)部有三個利用 Nginx 構(gòu)建的網(wǎng)關(guān)，使用 Lua 腳本做了一些業(yè)務(wù)擴展，但是隨著人員迭代，網(wǎng)關(guān)的運維變得越來越困難，主要包括 Lua 腳本維護難、配置變更不實時、多網(wǎng)關(guān)運維難以及配置變更 reload 與業(yè)務(wù)快速迭代的矛盾越來越多。因此，我們配合業(yè)務(wù)一起完成了 Nginx 網(wǎng)關(guān)到云原生網(wǎng)關(guān)的平滑遷移，為了保障遷移平滑、低成本，在云原生網(wǎng)關(guān)中專門針對 Nginx 的?error page?等功能做了擴展。如下圖：

看到上面這幅圖讀者可能問為什么采用了兩層網(wǎng)關(guān)結(jié)構(gòu)？即 AServer（流量網(wǎng)關(guān)） + 業(yè)務(wù)自建網(wǎng)關(guān)。

這是因為對于阿里巴巴這種超大流量的業(yè)務(wù)，采用兩層架構(gòu)，由流量網(wǎng)關(guān)統(tǒng)一負(fù)責(zé)安全防護、全局流量調(diào)度成本會更低，不需要每個業(yè)務(wù) BU 都做重復(fù)的事情，業(yè)務(wù)自建網(wǎng)關(guān)掛在流量網(wǎng)關(guān)之后，又可以滿足業(yè)務(wù)自身快速迭代的要求；但是對于非超大規(guī)模的業(yè)務(wù)，使用兩層架構(gòu)反而會帶來運維復(fù)雜度的上升。

2、Ingress-nginx 遷移方案

在 K8s Ingress Provider 中雖然使用 Envoy 架構(gòu)的用戶增長排在第一位，但不可否認(rèn)的是，目前 Ingress-nginx 仍占據(jù) K8s Ingress Provider 最大的份額，那么云原生網(wǎng)關(guān)是否可以兼容 Ingress-nginx 配置，為用戶提供低成本甚至零成本的遷移方案呢？

帶著這個問題我們也做了探索，Ingress-nginx 并沒有采用定義新 CRD 的方式來擴展標(biāo)準(zhǔn) K8s Ingress 能力，而是利用 Annotation 的方式，首先我們分析了 Ingress-nginx 的 Annotation 列表，如下：

依據(jù)用戶使用度對齊做了優(yōu)先級排序，其中處于高、中的 Annotation 云原生網(wǎng)關(guān)已經(jīng)支持自動轉(zhuǎn)換，剩余的除了插入代碼片段等這些跟 Nginx 內(nèi)部實現(xiàn)相關(guān)的 Annotation 外，我們也正在逐步的支持轉(zhuǎn)換，目標(biāo)就是做到零成本的遷移。轉(zhuǎn)換流程簡圖如下：

寫在最后

MSE - 云原生網(wǎng)關(guān)，旨在為用戶提供更可靠的、成本更低、效率更高的，符合 K8s Ingress 標(biāo)準(zhǔn)的企業(yè)級網(wǎng)關(guān)產(chǎn)品，更多發(fā)布詳情移步直播間觀看：https://yqh.aliyun.com/live/detail/26484

MSE - 云原生網(wǎng)關(guān)提供后付費和包年包月兩類付費模式，支持杭州、上海、北京、深圳 4?個 region，并會逐步開放其他 region。

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

版權(quán)聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權(quán)保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。