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

作者 | 如葑

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

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

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

1、誕生背景

云原生網(wǎng)關(guān)的創(chuàng)建，源于集團(tuán)內(nèi)部的“本地生活戰(zhàn)役”，該戰(zhàn)役始于“支付寶 2020 合作伙伴大會(huì)”，在此大會(huì)上支付寶宣布升級(jí)為數(shù)字生活開放平臺(tái)。該戰(zhàn)役的核心技術(shù)目標(biāo)，是實(shí)現(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 互通問題，首先要對(duì)網(wǎng)關(guān)做技術(shù)選型。

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

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

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

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

如何解決這點(diǎn)呢？

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

3、發(fā)展歷程

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

這個(gè)過程中，我們也正持續(xù)的、堅(jiān)定的向開源社區(qū)貢獻(xiàn)自己的力量，例如向 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)分為兩個(gè)大類：流量網(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)，顧名思義主要提供獨(dú)立業(yè)務(wù)域級(jí)別的、與后端業(yè)務(wù)緊耦合策略配置。隨著應(yīng)用架構(gòu)模式從單體演進(jìn)到現(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)的云原生時(shí)代，下一代的網(wǎng)關(guān)模式仍然會(huì)是傳統(tǒng)的流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)嗎？

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

我們對(duì)其中幾個(gè)非常核心的要素展開說明下：

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

基于以上的分析和實(shí)踐，我們認(rèn)為，在虛擬化時(shí)期的微服務(wù)架構(gòu)下，業(yè)務(wù)通常采用流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)的兩層架構(gòu)，流量網(wǎng)關(guān)負(fù)責(zé)南北向流量調(diào)度和安全防護(hù)，微服務(wù)網(wǎng)關(guān)負(fù)責(zé)東西向流量調(diào)度和服務(wù)治理，而在容器和 K8s 主導(dǎo)的云原生時(shí)代，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)勢(shì)

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

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

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

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

認(rèn)證鑒權(quán)是客戶對(duì)網(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)證。同時(shí)，MSE - 云原生網(wǎng)關(guān)天然支持阿里云的應(yīng)用身份服務(wù)?IDaaS 幫助客戶實(shí)現(xiàn)支付寶、淘寶、天貓等第三方認(rèn)證登陸，并以插件的方式支持來擴(kuò)展認(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)成為推動(dòng)軟件發(fā)展的源動(dòng)力之一，面向社區(qū)標(biāo)準(zhǔn)、開放的商業(yè)產(chǎn)品更有生命力。

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

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

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

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

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

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

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

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

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

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

2、Ingress-nginx 遷移方案

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

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

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

寫在最后

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

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

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

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

總結(jié)

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

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