K8s 網(wǎng)關(guān)選型初判：Nginx 還是 Envoy？

為了避免混淆，我們先對一些關(guān)鍵定義做一些厘清：

本文將從性能和成本、可靠性、安全性 3 方面，對兩大開源實(shí)現(xiàn)進(jìn)行比對，希望對正在做 K8s 網(wǎng)關(guān)選型的企業(yè)有所借鑒。

性能和成本

MSE 云原生網(wǎng)關(guān)的吞吐性能幾乎是 Nginx Ingress Controller 的一倍，尤其是傳輸小文本時性能優(yōu)勢會更明顯，如下圖所示，網(wǎng)關(guān) CPU 使用率達(dá)到 30% 時的吞吐對比：

網(wǎng)關(guān)規(guī)格：16 核 32 G * 4 節(jié)點(diǎn)

ECS 型號：ecs.c7.8xlarge

當(dāng) CPU 負(fù)載升高時，吞吐差距會更加明顯，下圖是 CPU 使用率達(dá)到 70% 時的情況：

高負(fù)載下 Nginx Ingress Controller 吞吐下降原因是出現(xiàn)了 pod 重啟，詳情見下一節(jié)“可靠性”中的分析。

隨著網(wǎng)絡(luò)安全愈加受重視，現(xiàn)在互聯(lián)網(wǎng)上已經(jīng)普遍使用 HTTPS 進(jìn)行傳輸加密，在網(wǎng)關(guān)側(cè)，用于實(shí)現(xiàn) HTTPS 的 TLS 非對稱加密算法是占用 CPU 資源的大頭。針對此場景，MSE 云原生網(wǎng)關(guān)使用了 CPU SIMD 技術(shù)實(shí)現(xiàn)了 TLS 加解密算法的硬件加速：

從上圖壓測數(shù)據(jù)可以看出使用 TLS 硬件加速后，相比普通 HTTPS 請求 TLS 握手時延降低一倍，極限 QPS 提升 80%以上。

基于以上數(shù)據(jù)，使用 MSE 云原生網(wǎng)關(guān)，只需一半的資源，就能達(dá)到 Nginx Ingress Controller 的吞吐，在做過硬件加速優(yōu)化的 HTTPS 場景下，吞吐還能進(jìn)一步提升。

可靠性

前文提到高負(fù)載下，Nginx Ingress Controller 會出現(xiàn) pod 重啟導(dǎo)致吞吐下降，導(dǎo)致 pod 重啟的原因主要有 2 點(diǎn)：

這兩個問題，本質(zhì)上皆是由于 Nginx Ingress Controller 的部署架構(gòu)不合理導(dǎo)致。其控制面（Go 實(shí)現(xiàn)的 Controller）和數(shù)據(jù)面（Nginx）進(jìn)程混跑在一個容器內(nèi)，高負(fù)載下，數(shù)據(jù)面進(jìn)程和控制面進(jìn)程出現(xiàn)了 CPU 搶占。其中控制面進(jìn)程負(fù)責(zé)了健康檢查和監(jiān)控指標(biāo)采集，因?yàn)闆]有足夠的 CPU 導(dǎo)致請求積壓引起 OOM 以及健康檢查超時。

這種情況是極危險的，會在高負(fù)載下引發(fā)網(wǎng)關(guān)的雪崩效應(yīng)，對業(yè)務(wù)造成嚴(yán)重影響。MSE 云原生網(wǎng)關(guān)使用了數(shù)據(jù)面和控制面隔離的架構(gòu)，在架構(gòu)上具備可靠性優(yōu)勢：

從上圖可以看到，MSE 云原生網(wǎng)關(guān)并不部署在用戶的 K8s 集群中，而是純托管的模式，這種模式在可靠性上還有更多優(yōu)勢：

如果使用 Nginx Ingress Controller 要實(shí)現(xiàn)高可靠部署，一般需要獨(dú)占 ECS 節(jié)點(diǎn)，同時還需要部署多個 ECS 節(jié)點(diǎn)，來避免單點(diǎn)故障，這種情況下資源成本會直線上升。此外，Nginx Ingress Controller 因?yàn)椴渴鹪谟脩艏褐?，也無法提供網(wǎng)關(guān)可用性的 SLA 保障。

安全性

Nginx Ingress Controller 的不同版本都還存在著一些 CVE 漏洞隱患，具體影響版本見下表：

從 Nginx Ingress Controller 遷移到 MSE 云原生網(wǎng)關(guān)后，將一次性修復(fù)所有 CVE 漏洞隱患；并且，MSE 云原生網(wǎng)關(guān)提供了平滑升級方案，一旦出現(xiàn)新的安全漏洞，可以快速對網(wǎng)關(guān)版本進(jìn)行升級，同時確保升級過程對業(yè)務(wù)影響最小化。

此外，MSE 云原生網(wǎng)關(guān)內(nèi)置了阿里云 Web 應(yīng)用防火墻（WAF），相比傳統(tǒng) WAF 用戶請求鏈路更短、RT 更低，且相比Nginx Ingress Controller 可以做到細(xì)粒度路由級防護(hù)，使用成本是目前阿里云 Web 應(yīng)用防火墻架構(gòu)的 2/3。

MSE 云原生網(wǎng)關(guān)

阿里云容器服務(wù)應(yīng)用市場已經(jīng)上架 MSE 云原生網(wǎng)關(guān)，可用于替代默認(rèn)安裝的網(wǎng)關(guān)組件 Nginx Ingress Controller。

MSE 云原生網(wǎng)關(guān)在阿里集團(tuán)內(nèi)部作為網(wǎng)關(guān)中間件已經(jīng)大規(guī)模使用，其強(qiáng)勁的性能和可靠的穩(wěn)定性已被多年雙十一流量所驗(yàn)證。

在 K8s 容器服務(wù)場景下，對比默認(rèn)安裝的 Nginx Ingress Controller，主要有以下優(yōu)勢：

同時在路由策略、灰度治理、可觀測等方面提供了更豐富的功能，并且支持使用多種語言開發(fā)自定義的擴(kuò)展插件，詳細(xì)對比請參考：https://help.aliyun.com/document_detail/424833.html

平滑遷移方案

部署 MSE 云原生網(wǎng)關(guān)并不直接影響原有網(wǎng)關(guān)流量，通過 DNS 權(quán)重配置可以實(shí)現(xiàn)業(yè)務(wù)流量的平滑遷移，對后端業(yè)務(wù)完全無感知，核心的流量遷移過程如下圖所示：

完整步驟如下：

作者：張?zhí)硪?澄潭)

原文鏈接：http://click.aliyun.com/m/1000345146/

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

阿里巴巴云原生網(wǎng)關(guān) Higress：基于 Envoy，支持 Nginx Ingress 遷移

作者 | 蔡芳芳

近日，阿里巴巴正式開源云原生網(wǎng)關(guān)Higress。Higress 是基于阿里內(nèi)部兩年多的 Envoy Gateway 實(shí)踐沉淀、以開源 Istio + Envoy 為核心構(gòu)建的下一代云原生網(wǎng)關(guān)，在標(biāo)準(zhǔn)上全面支持 Ingress 與 Gateway API，積極擁抱云原生下的標(biāo)準(zhǔn) API 規(guī)范。此外，Higress Controller 支持 Nginx Ingress 平滑遷移，用戶可以幾乎零成本快速遷移到 Higress。

在容器化的云原生大背景下，Kubernetes 已經(jīng)成為了基礎(chǔ)設(shè)施與上層應(yīng)用的標(biāo)準(zhǔn)接口，而 Kubernetes Ingress 又標(biāo)準(zhǔn)化了入口網(wǎng)關(guān)，同時社區(qū)也在積極推進(jìn) Gateway API 的標(biāo)準(zhǔn)定義來解決目前 Ingress 標(biāo)準(zhǔn)存在的一些不足，如路由能力偏弱、配置不夠靈活等問題。

大家想到網(wǎng)關(guān)可能第一直覺會聯(lián)想到 API 網(wǎng)關(guān)，這里有一個挺有意思的問題：在網(wǎng)關(guān)或者 Web 流量場景下什么是 API 呢？

回歸到原始概念下，它代指一組具備某些特性的流量，用于描述該特征流量的規(guī)則稱為路由規(guī)則，在 API 管理領(lǐng)域稱為 API，在路由規(guī)則或者 API 之上可以附加很多策略，如熔斷、限流、降級、認(rèn)證與鑒權(quán)等等。在 Kubernetes 生態(tài)，Ingress 與 Gateway API 是用于定義路由規(guī)則的，因此 Ingress 與 Gateway API 事實(shí)上已經(jīng)成為云原生下的標(biāo)準(zhǔn) API 規(guī)范。

阿里巴巴從 2017-2018 年開始探索 Service Mesh，基于這些探索沉淀了大量 Istio 和 Envoy 的實(shí)踐經(jīng)驗(yàn)，不過早期這些實(shí)踐并不太涉及網(wǎng)關(guān)場景。

2020 年，在代號為“本地生活戰(zhàn)役”的項(xiàng)目背景下，阿里集團(tuán)和螞蟻集團(tuán)兩側(cè)有一些業(yè)務(wù)上互相訪問的訴求（比如支付寶首頁需要展示跟本地生活相關(guān)的推送、商品信息，而這些信息往往存儲在阿里側(cè)），出于安全性和業(yè)務(wù)快速迭代的考慮，雙方技術(shù)團(tuán)隊(duì)希望打造一個新的互通網(wǎng)關(guān)，通過走內(nèi)部 RPC 調(diào)用的方式實(shí)現(xiàn)互通，替代掉原來走公網(wǎng)的方式。同時，大家希望借這個機(jī)會把兩邊的 RPC 協(xié)議定義成一個統(tǒng)一規(guī)范。以此為契機(jī)，阿里開始了基于 Envoy 打造下一代云原生網(wǎng)關(guān)的探索。

本文出自 InfoQ 特別策劃的專題《Envoy 當(dāng)?shù)?？云原生時代的下一代網(wǎng)關(guān)選型和實(shí)踐》。 我們專訪了阿里云研發(fā)工程師耿蕾蕾（如葑），深入挖掘阿里巴巴針對云原生網(wǎng)關(guān)的技術(shù)選型思考和實(shí)踐路徑，希望能為想要進(jìn)一步了解 Envoy 和打造下一代網(wǎng)關(guān)的技術(shù)團(tuán)隊(duì)提供參考。

為什么基于 Envoy？

阿里內(nèi)部一直使用基于 Nginx 演進(jìn)而來的 Tengine 作為統(tǒng)一接入網(wǎng)關(guān)。因此最初做新網(wǎng)關(guān)技術(shù)選型時，其實(shí)有兩種演進(jìn)思路，一種是基于 Tengine 優(yōu)化，一種是基于 Envoy 內(nèi)核來擴(kuò)展網(wǎng)關(guān)場景。當(dāng)時，如葑所在團(tuán)隊(duì)本身就負(fù)責(zé) Tengine 的維護(hù)工作，同時也參與探索阿里內(nèi)部 Service Mesh 的落地，因此團(tuán)隊(duì)對 Tengine 和 Istio+Envoy 這兩套技術(shù)棧都比較熟悉，技術(shù)儲備上都不存在障礙。選型的關(guān)鍵在于，哪種技術(shù)方案可以更簡單地支持前文所述的統(tǒng)一 RPC 協(xié)議（這個由兩方團(tuán)隊(duì)合作定義出的統(tǒng)一 RPC 協(xié)議，即后來 Dubbo 3.0 中支持的 Triple 協(xié)議）。

據(jù)介紹，Triple 協(xié)議是一種類 gRPC 協(xié)議，它的大部分能力復(fù)用了 gRPC，比如序列化和通訊協(xié)議等。因此在選型網(wǎng)關(guān)時，首先需要新網(wǎng)關(guān)對 gRPC 支持友好，這樣后續(xù)支持 Triple 協(xié)議的研發(fā)工作難度會小很多。恰恰當(dāng)時 Tengine 上游對 gPRC 的支持并不完善，而 Envoy 誕生在 Tengine 之后，對 gRPC 的支持相對完善很多。如果選擇 Tengine 的技術(shù)路線，團(tuán)隊(duì)前期需要投入很大的人力把 Tengine 上游支持 gRPC 的能力補(bǔ)齊，如果選擇 Envoy 則不需要在這方面投入額外人力了。當(dāng)時基于這一點(diǎn)考慮，團(tuán)隊(duì)幾乎就要把 Tengine 這個思路 Pass 掉了。

此外，Tengine（和 Nginx）還存在 Reload 訪問有損的問題。由于不支持配置熱更新機(jī)制，Tengine 在做配置變更的時候需要 Reload，而 Reload 對于長連接會引起抖動，導(dǎo)致流量短暫中斷，但恰恰在 RPC 請求場景下大部分連接都是長連接。這意味著，如果要讓互通網(wǎng)關(guān)做到接入服務(wù)快速生效，就要頻繁做配置變更，Tengine 就要頻繁地 Reload，長連接會頻繁抖動，導(dǎo)致流量嚴(yán)重抖動。如果要控制 Reload 影響則只能減少 Reload 次數(shù)，但這又會導(dǎo)致接入服務(wù)生效變慢。相比之下，Envoy 原生通過 xDS 支持配置熱更新，就不存在這個問題。這也是團(tuán)隊(duì)在做技術(shù)選型時重點(diǎn)考量的一點(diǎn)。

當(dāng)然，也有團(tuán)隊(duì)成員對選型 Envoy 心存疑慮。畢竟 Tengine 脫胎于 Nginx，而 Nginx 作為老牌網(wǎng)關(guān)已經(jīng)在行業(yè)內(nèi)應(yīng)用多年，不管是業(yè)界口碑還是性能表現(xiàn)都很受推崇，相比之下 Envoy 只能算是初入江湖的“萌新”選手。被挑戰(zhàn)最多的一點(diǎn)是，Envoy 的性能是不是能夠達(dá)到 Nginx 同等水平？或者說，至少不能出現(xiàn)量級的差異。針對這一點(diǎn)，團(tuán)隊(duì)找了一些網(wǎng)關(guān)場景，針對 gRPC 協(xié)議專門做了壓測。壓測結(jié)果表明，未作任何優(yōu)化的情況下，Envoy 的性能確實(shí)不能完全跟 Nginx 或 Tengine 持平，但還在同一個量級上，并沒有出現(xiàn)跨量級的性能損失，而這種同一量級的性能差異是可以通過一定的性能優(yōu)化工作補(bǔ)齊的。

并且，在打造互通網(wǎng)關(guān)的項(xiàng)目中，原本就必須做一些整體的性能優(yōu)化工作。

還有另外一個因素堅(jiān)定了團(tuán)隊(duì)選擇 Envoy。當(dāng)時阿里內(nèi)部已經(jīng)在重點(diǎn)推進(jìn) Service Mesh 落地，而 Service Mesh 架構(gòu)本身就包括東西向使用 Sidecar 做服務(wù)治理，同時還有一個基于 Istio+Envoy 的 Gateway 負(fù)責(zé)做跨集群之間的流量互通。如果選擇 Envoy 作為網(wǎng)關(guān)，后續(xù)就有可能跟 Service Mesh 整合成一個大的流量調(diào)度方案，在阿里內(nèi)部實(shí)現(xiàn)以一套技術(shù)架構(gòu)同時調(diào)度南北向外部流量和東西向內(nèi)部流量。從長遠(yuǎn)來看，這是更有利于未來向統(tǒng)一應(yīng)用架構(gòu)技術(shù)棧演進(jìn)的選擇。

阿里巴巴 Envoy Gateway 演進(jìn)的三個階段

由于業(yè)務(wù)體量龐大，阿里對 Envoy Gateway 的探索主要通過對單點(diǎn)業(yè)務(wù)場景改造的方式來推進(jìn)。阿里和螞蟻的互通網(wǎng)關(guān)是第一個落地場景，如葑將其稱為Envoy Gateway 1.0階段。

這一階段 Envoy Gateway 要應(yīng)用于東西向流量的 RPC 互通，其架構(gòu)部署如下圖：

上圖主要展示的是集團(tuán)側(cè)的架構(gòu)，最終采用了 Istio+Envoy 的方案，在部署的時候又分成了出口集群和入口集群。之所以拆成兩個集群，一方面是當(dāng)時兩邊互訪，螞蟻調(diào)集團(tuán)的流量要遠(yuǎn)遠(yuǎn)大于集團(tuán)調(diào)螞蟻的流量，上下行特別不均等；另一方面是分開之后兩個集群可以各自維護(hù)，穩(wěn)定性會更好。

Envoy Gateway 1.0 從開始立項(xiàng)到完成第一期研發(fā)，網(wǎng)關(guān)改造的核心工作差不多兩個人投入了一個半月左右，其中還涉及到大量網(wǎng)絡(luò)、安全等協(xié)調(diào)部門的工作。1.0 架構(gòu)并沒有完全按照社區(qū)方案來設(shè)計(jì)，社區(qū)版本中配置變更和服務(wù)發(fā)現(xiàn)使用的是 K8s，在阿里內(nèi)部龐大的服務(wù)規(guī)模及配置量下社區(qū)原生方案不管在穩(wěn)定性及性能上都無法滿足要求，因此阿里這套方案重點(diǎn)對服務(wù)發(fā)現(xiàn)、配置存儲組件做了替換，及優(yōu)化 xDS 推送性能。

這一階段，團(tuán)隊(duì)基于 Envoy 演進(jìn)了網(wǎng)關(guān)的服務(wù)管理能力，支撐了當(dāng)年雙十一本地生活戰(zhàn)役數(shù)十萬 TPS 的流量洪峰?；?Envoy Gateway 的互通網(wǎng)關(guān)給業(yè)務(wù)帶來了實(shí)打?qū)嵉氖找?。一方面，基?RPC 調(diào)用方式，互訪請求的延時遠(yuǎn)遠(yuǎn)好于原來走公網(wǎng)的方式，并且對此專門做過壓測，整體延時降低了 50%-60%，同時在網(wǎng)關(guān)側(cè)的延時消耗幾乎可以忽略不計(jì)，對用戶體驗(yàn)的提升非常明顯。另一方面，業(yè)務(wù)上線迭代速度也加快了，原來螞蟻和阿里要調(diào)用對方一個業(yè)務(wù)，首先要走完一套安全合規(guī)的審批流程，然后配置變更走以前的統(tǒng)一接入網(wǎng)關(guān) Tengine，至少以天為單位，改造后走新的互通網(wǎng)關(guān)，業(yè)務(wù)上線時間可以縮短到小時級別，具體耗時主要取決于審批流程的快慢，網(wǎng)關(guān)側(cè)支持熱更新，一旦發(fā)出配置變更幾乎是秒級生效。

隨著阿里巴巴上云戰(zhàn)役的推進(jìn)，越來越多的場景找到如葑的團(tuán)隊(duì)。比如云上云下業(yè)務(wù)互通，由于 Tengine 服務(wù)管理弱導(dǎo)致阿里內(nèi)部大量二層微服務(wù)網(wǎng)關(guān)需要收斂，這就需要從業(yè)務(wù)上做 Tengine+Envoy 兩層網(wǎng)關(guān)的演進(jìn)，承擔(dān)南北向網(wǎng)關(guān)流量。在 2020 年 12 月份，團(tuán)隊(duì)開始了向 Envoy Gateway 2.0 架構(gòu)的演進(jìn)，以優(yōu)酷場景為例的演進(jìn)過程如下圖：

Envoy Gateway 2.0 南北向的架構(gòu)圖如下：

在兩層架構(gòu)中，Envoy 網(wǎng)關(guān)更多承擔(dān)了微服務(wù)網(wǎng)關(guān)和微服務(wù)治理的需求，和 Tengine 流量網(wǎng)關(guān)完成了整合。在這個過程里，團(tuán)隊(duì)支撐優(yōu)酷內(nèi)部多個二層微服務(wù)網(wǎng)關(guān)統(tǒng)一的工作，大幅提升了性能和運(yùn)維效率。

在這一階段，Envoy Gateway 實(shí)現(xiàn)了東西向、南北向全域流量的調(diào)度分發(fā)，東西向上不僅支持跨業(yè)務(wù)域的螞蟻 RPC 互通，也擴(kuò)展到了混合云的云上云下 RPC 互通場景，覆蓋釘釘文檔、阿里視頻云、達(dá)摩院的店小蜜、智慧數(shù)字人等。2.0 階段的業(yè)務(wù)大圖如下（云上云下互通場景，以釘釘為例說明）：

隨著 Envoy Gateway 覆蓋的業(yè)務(wù)場景越來多，在跟優(yōu)酷持續(xù)合作的過程中，雙方團(tuán)隊(duì)不約而同提出了一個設(shè)想：Tengine Gateway（承擔(dān)流量網(wǎng)關(guān)角色） + Envoy Gateway（承擔(dān)微服務(wù)網(wǎng)關(guān)角色）的兩層網(wǎng)關(guān)是否可以合并為一層 Envoy Gateway？

如葑和團(tuán)隊(duì)對這一想法做了調(diào)研，答案是肯定的，并且當(dāng)時大家也合作設(shè)計(jì)了新的架構(gòu)方案，如下圖：

雖然由于各種各樣的原因，這個方案最終沒有跟優(yōu)酷繼續(xù)往下推進(jìn)。但這個演進(jìn)方向讓如葑和團(tuán)隊(duì)明確了網(wǎng)關(guān)新的發(fā)展趨勢：在以 K8s 主導(dǎo)的容器化背景下，由于 K8s 集群內(nèi)外網(wǎng)絡(luò)的天然隔離性，用戶需要一款兼顧高性能與安全性，以及強(qiáng)大服務(wù)治理能力的入口網(wǎng)關(guān)。這也為后續(xù)團(tuán)隊(duì)將技術(shù)沉淀變成云產(chǎn)品、推進(jìn) Higress 的誕生打下了基礎(chǔ)。

2021 年，阿里巴巴開啟了中間件三位一體戰(zhàn)役，目標(biāo)是用云產(chǎn)品支撐集團(tuán)業(yè)務(wù)。如葑和團(tuán)隊(duì)開始將孵化成熟的技術(shù)沉淀為云產(chǎn)品，即目前阿里云上提供的 MSE 云原生網(wǎng)關(guān)，一方面面向廣大的公有云用戶提供托管的網(wǎng)關(guān)服務(wù)，另一方面也對內(nèi)服務(wù)集團(tuán)。

目前 MSE 云原生網(wǎng)關(guān)已經(jīng)支持通過 Envoy 將流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān)合二為一的技術(shù)方案。同時，通過硬件加速、內(nèi)核優(yōu)化等手段，團(tuán)隊(duì)也在持續(xù)不斷地優(yōu)化網(wǎng)關(guān)性能和網(wǎng)關(guān)資源部署成本。在功能擴(kuò)展性上，團(tuán)隊(duì)做了高可用流量防護(hù)組件 Sentinel 商業(yè)化版本的集成，并支持將 K8s 的 Ingress 資源自動轉(zhuǎn)換成 Enovy 網(wǎng)關(guān)能夠識別的配置，便于大家從 Nginx 遷移到 Envoy 網(wǎng)關(guān)。

如今，這套經(jīng)過內(nèi)部實(shí)踐沉淀下來的云原生網(wǎng)關(guān)方案 Higress 正式對外開源，以 Kubernetes Ingress 網(wǎng)關(guān)為契機(jī)帶來了流量網(wǎng)關(guān)與微服務(wù)網(wǎng)關(guān)融合的可能性，結(jié)合阿里內(nèi)部實(shí)踐沉淀 Higress 實(shí)現(xiàn)了流量網(wǎng)關(guān) + 微服務(wù)網(wǎng)關(guān) + 安全網(wǎng)關(guān)三合一的高集成能力，同時深度集成了 Dubbo、Nacos、Sentinel 等，能夠幫助用戶極大的降低網(wǎng)關(guān)的部署及運(yùn)維成本，而且能力不打折。

軟件的擴(kuò)展性是個持久的話題，Kubernetes 的成功離不開其強(qiáng)大 Controller 擴(kuò)展能力的支持。據(jù)如葑介紹，Higress 提供多種形式的擴(kuò)展機(jī)制，包括 Wasm 插件、Lua 插件、進(jìn)程外插件，通過豐富的插件擴(kuò)展機(jī)制，用戶就可以使用多語言編寫擴(kuò)展插件。這能有效降低插件編寫門檻，滿足用戶自定義的擴(kuò)展訴求。

下一代網(wǎng)關(guān)尚未形成事實(shí)標(biāo)準(zhǔn)，但 Envoy 是可能性之一

如何定義下一代云原生網(wǎng)關(guān)，大家可能看法各異。經(jīng)過這幾年在網(wǎng)關(guān)方向上的實(shí)踐，如葑及團(tuán)隊(duì)也有一些思考。

在他看來，下一代云原生網(wǎng)關(guān)首先一定要對 Kubernetes 友好，在云原生的大背景下，必須能原生地支持相應(yīng)特性，而不是依靠插件化的方式來支持，這是至關(guān)重要的一點(diǎn)。

其次，要具備豐富的可觀測性，不管是初始化狀態(tài)還是持續(xù)運(yùn)行狀態(tài)都要能提供豐富的指標(biāo)數(shù)據(jù)，用于觀測和后續(xù)的自動化運(yùn)維/AI 智能運(yùn)維。網(wǎng)關(guān)作為總的流量入口，對安全性、穩(wěn)定性和性能要求都很高，目前有一些可觀測解決方案通過添加 Sidecar 或者注入代碼來提取可觀測數(shù)據(jù)，這種方法對網(wǎng)關(guān)來說并不可行，更多還是要依靠網(wǎng)關(guān)自身來提供可觀測能力。

再次，過去傳統(tǒng)網(wǎng)關(guān)常常是流量網(wǎng)關(guān)+業(yè)務(wù)網(wǎng)關(guān)（或微服務(wù)網(wǎng)關(guān)）兩層架構(gòu)，不僅運(yùn)維成本高，資源部署成本也比較高。在云原生時代，K8s 已經(jīng)成為事實(shí)上的運(yùn)維底座，由于 K8s 集群網(wǎng)絡(luò)天然是隔離的，就誕生了 Ingress 網(wǎng)關(guān)，來解決流量入口的問題，而這個 Ingress 網(wǎng)關(guān)完全可以將過去的兩層網(wǎng)關(guān)架構(gòu)合二為一，成為一個功能更強(qiáng)大的網(wǎng)關(guān)。

生于云原生時代的“后浪”Envoy 天然能滿足以上三點(diǎn)需求。

如葑表示，雖然國內(nèi)目前使用 Envoy 作為網(wǎng)關(guān)的開源項(xiàng)目或商業(yè)化產(chǎn)品不多，但是國外使用 Envoy 作為網(wǎng)關(guān)的產(chǎn)品或案例并不少，比如Tetrate、Gloo Edge、Ambassador（網(wǎng)關(guān)改名為 Emissary-ingress）等，雖然有的使用 Istio 作為控制面，有的選擇自建控制面板，但大家都不約而同地把 Envoy 作為未來演進(jìn)路線的一種選擇。知名企業(yè)如 Twitter、Lyft 等也都在使用 Envoy 作為網(wǎng)關(guān)或者把網(wǎng)關(guān)往 Envoy 上面遷移。

這首先得益于 Envoy 原生支持配置熱更新，在如葑看來，這是一個非常重要的特性。現(xiàn)在已經(jīng)有很多主流應(yīng)用選擇采用長連接，現(xiàn)在的 HTTP 1.1 一般默認(rèn)會使用 Keep-Alive 去保持長連接，后續(xù) HTTP 2 以及 HTTP 3 也是如此，隨著網(wǎng)絡(luò)協(xié)議的發(fā)展，未來使用長連接會變得更加普遍。而配置熱更新天然對長連接非常友好。

其次也得益于 Envoy 的 xDS 能力，xDS 作為一個通用的配置請求協(xié)議規(guī)范，基于它可以做靈活地?cái)U(kuò)展，對數(shù)據(jù)面+控制面的架構(gòu)天然友好。

反觀 Nginx，它更多推崇的是使用本地的指令配置來做配置變更，雖然作為代理程序來說很便捷高效，但用作網(wǎng)關(guān)則不盡然。另外，Nginx 原生不支持配置熱更新，常見的做法是使用 Lua 腳本來支持，但這會帶來非常大的性能衰減，如果配置熱更新、可觀測性等全部使用 Lua 實(shí)現(xiàn)，整體性能損失相比原生 Nginx 最高可能達(dá)到 70-80%，社區(qū)中針對這一問題還有一個專門的 Issue：Poor performance in benchmark。

當(dāng)然，下一代云原生網(wǎng)關(guān)這個方向目前還沒有形成一個事實(shí)上的標(biāo)準(zhǔn)，除了 Envoy，業(yè)內(nèi)還有很多企業(yè)在探索這個方向，大家其實(shí)都想要搶占先機(jī)。

國外如traefik、Kong，甚至包括 Nginx 背后的廠商 F5，都在做相關(guān)嘗試。如葑認(rèn)為，每種產(chǎn)品可能會有不同的用戶群體。

比如traefik，因?yàn)樗怯?Golang 開發(fā)的，包括擴(kuò)展機(jī)制也支持用 Golang 編寫，所以對于使用 Golang 的群體來說可能相對更友好，同理還有國內(nèi)百度開源的 BFE。有些客戶確實(shí)會因?yàn)?Golang 的入門門檻比 Nginx 的 C、或 Envoy 的 C++低很多，而選擇嘗試基于 Golang 的網(wǎng)關(guān)方案。如葑認(rèn)為這類方案可能比較適合的場景是，規(guī)模不是特別大，且對性能的要求沒有那么高，同時又希望有一個能夠快速上手的開源網(wǎng)關(guān)產(chǎn)品或者商業(yè)化產(chǎn)品。但一些對性能或延時要求比較高的場景，比如電商或游戲場景，可能還是選擇基于 C 或者 C++的網(wǎng)關(guān)產(chǎn)品更好。因?yàn)榛?Golang 的網(wǎng)關(guān)方案，包括現(xiàn)在很流行的 Java 體系的 Spring Cloud Gateway，都避免不了 GC 抖動的問題。

國內(nèi)如 APISIX 也正在云原生網(wǎng)關(guān)方向做一些探索。APISIX 基于 OpenResty 開發(fā)，主要采用的還是 Nginx+Lua 的方案，但對這套方案做了很多改造，使其能夠更好地貼合目前云原生化的需求。如葑認(rèn)為 APISIX 選擇的切入點(diǎn)也很好，并且目前在國內(nèi)確實(shí)算是做得比較成功的一個開源項(xiàng)目。

如葑表示，大家其實(shí)選擇了不同的路線，現(xiàn)在很難明確地說哪一條路線一定會勝出。當(dāng)然他自己還是更看好 Envoy，除了前文所述技術(shù)選型的考慮，和團(tuán)隊(duì)過去幾年維護(hù) Tengine 和 Envoy 的經(jīng)驗(yàn)總結(jié)，還有一部分是出于對技術(shù)生態(tài)和技術(shù)影響力的考量。在他看來，目前 Nginx 生態(tài)已經(jīng)成熟到有點(diǎn)固化，不管是社區(qū)活躍度還是增長其實(shí)都到了一定的瓶頸，這時候投入很多人力優(yōu)化和擴(kuò)展現(xiàn)有項(xiàng)目，對團(tuán)隊(duì)來說并不是一個特別好的選擇，不如選擇一個新方向。

另一方面團(tuán)隊(duì)更加看重的是 Envoy Gateway 與 Service Mesh 統(tǒng)一技術(shù)架構(gòu)帶來的長遠(yuǎn)價值。原來對中間件團(tuán)隊(duì)來說，有一個很大的痛點(diǎn)是，中間件架構(gòu)演進(jìn)無法獨(dú)立于應(yīng)用演進(jìn)，而一定要依賴業(yè)務(wù)幫忙做升級。Service Mesh 架構(gòu)提供了一個新的可能，可以把中間件所有的通用能力下沉到 Sidecar，更方便地為業(yè)務(wù)提供增量特性，縮短新業(yè)務(wù)上線的時間。這對團(tuán)隊(duì)來說有更大的意義。

Envoy Gateway：現(xiàn)有格局的沖擊者？

今年 5 月份，新項(xiàng)目Envoy Gateway正式開源，在業(yè)內(nèi)引發(fā)了一波討論。

在如葑看來，Envoy Gateway 的開源，相當(dāng)于從社區(qū)官方角度明確認(rèn)可了使用 Envoy 作為網(wǎng)關(guān)這件事。以前大家可能更熟悉 Envoy 用作 Sidecar 的場景，一提到 Envoy，第一個想到的就是 Service Mesh 里的 Sidecar。Envoy Gateway 這個項(xiàng)目發(fā)起之后，大家可能慢慢會改變認(rèn)知并逐步接受，Envoy 也可以用作網(wǎng)關(guān)并且是網(wǎng)關(guān)場景一個比較好的選擇。

如葑補(bǔ)充道，新開源的 Envoy Gateway 也可能對現(xiàn)有的格局造成一些沖擊。他認(rèn)為，其實(shí)在 Istio+Envoy 這個組合里，話語權(quán)更大的是 Envoy。現(xiàn)在國內(nèi)外使用 Envoy 作為網(wǎng)關(guān)主要有兩個分支，一個是使用 Istio+Envoy 這套基礎(chǔ)架構(gòu)，另一個是使用自建的控制面+Envoy 組成一套架構(gòu)。剛開源的 Envoy Gateway 背后兩家創(chuàng)始企業(yè)都選擇的是自建控制面+Envoy 這種方式，并沒有使用 Istio。目前社區(qū)圍繞新建一個能夠完全貼合網(wǎng)關(guān)的控制面這個話題也在做一些討論。隨之而來還有更多問題引發(fā)社區(qū)討論，比如：為什么 Envoy Gateway 不首選目前已經(jīng)成型的 Istio，而是要再新建一個控制面？新的控制面以后跟 Istio 之間的關(guān)系會是什么樣的？后續(xù)是否會支持 Istio 一鍵遷移？接下來 Envoy Gateway 社區(qū)走向值得我們長期關(guān)注。

回到 Envoy 本身，也有一些需要改進(jìn)的地方。眾所周知，Envoy 并不是一個容易上手使用的軟件，它的復(fù)雜性勸退了很多開發(fā)者。雖然如葑所在團(tuán)隊(duì)因?yàn)橛辛饲捌诘募夹g(shù)沉淀，復(fù)雜性并沒有給他們造成明顯困擾，但他也坦言，對于從未接觸過 Envoy 或者對 C/C++不熟悉的開發(fā)者來說，Envoy 確實(shí)上手門檻比較高。

對于想要嘗試 Envoy 的技術(shù)團(tuán)隊(duì)，團(tuán)隊(duì)中最好能有一定的 Envoy 技術(shù)儲備，如果團(tuán)隊(duì)中完全沒有熟悉 Envoy 或 C++的人，想要很簡單地把 Envoy 用起來，或者平穩(wěn)地把 Envoy 放到生產(chǎn)環(huán)境上使用，會面臨比較大的挑戰(zhàn)。在易用性和上手門檻方面，Envoy 確實(shí)做得沒有 Nginx 好。

好的一面是，Envoy 的技術(shù)架構(gòu)，包括多線程模型等，都設(shè)計(jì)得比較優(yōu)雅和規(guī)范。如葑建議，開發(fā)者在上手之前可以先到 Envoy 官方博客上看一看它的技術(shù)架構(gòu)和設(shè)計(jì)思想，了解完這些之后再去讀代碼，可能會覺得容易一些。另外，得益于 Envoy 的 Filter 擴(kuò)展機(jī)制，開發(fā)者其實(shí)不需要對 Envoy 里面所有的細(xì)節(jié)都了解得非常清楚，如果想快速上手，重點(diǎn)了解一下它的 Filter 擴(kuò)展機(jī)制大概是什么樣子，然后參照社區(qū)里的 Example，就可以快速寫出一個 Demo 的 Filter 并運(yùn)行起來，這跟基于 Tengine 開發(fā)一個 module 的難易度是差不多的。

當(dāng)然，如葑還是希望 Envoy 社區(qū)能夠做一些嘗試，適當(dāng)?shù)亟档腿腴T門檻，從而更好地把 Envoy 推廣出去，讓更多人能夠把 Envoy 應(yīng)用到業(yè)務(wù)中。此外，隨著 Envoy 社區(qū)活躍度越來越高，參與的人越來越多，如葑覺得 Envoy 整體架構(gòu)的復(fù)雜度其實(shí)是在不斷膨脹的，后續(xù)社區(qū)也需要考慮如何在控制架構(gòu)復(fù)雜度和新增功能兩個方向上取得一定平衡。

采訪嘉賓介紹：

耿蕾蕾（如葑），阿里云研發(fā)工程師，從 2020 年 5 月負(fù)責(zé) Envoy Gateway 的構(gòu)建到推出 3.0，作為技術(shù)負(fù)責(zé)人主導(dǎo)了整個演進(jìn)過程，在云原生網(wǎng)關(guān)領(lǐng)域有著豐富的實(shí)踐。

相關(guān)問答

求H...技術(shù)選型1、最早計(jì)劃采用Netty來做,但由于gRPC的proto模板不是我們定義的,所以解析成本很高,另外還要讀取請求Header中的數(shù)據(jù),開發(fā)難度較大,所以這個...

使用網(wǎng)絡(luò)容器,Apache,tomcat,nginx?；蛘呤褂镁W(wǎng)絡(luò)庫實(shí)現(xiàn),netty等。使用網(wǎng)絡(luò)容器,Apache,tomcat,nginx?；蛘呤褂镁W(wǎng)絡(luò)庫實(shí)現(xiàn),netty等。

在我們講的微服務(wù)架構(gòu)下的API網(wǎng)關(guān),一般指的是前三類使用場景。即,主要是把企業(yè)內(nèi)部的API能力,暴露給其他應(yīng)用或合作伙伴使用。網(wǎng)關(guān)層作為客戶端與服務(wù)端的一層...

在Docker的默認(rèn)網(wǎng)絡(luò)配置下,有兩種方式可以實(shí)現(xiàn):使用自定義橋接網(wǎng)絡(luò)。同一個橋接網(wǎng)絡(luò)種的容器之間可以通過域名(默認(rèn)為容器名稱)來訪問。比如我有兩個容器,...

01前言Nginx("enginex")是一款是由俄羅斯的程序設(shè)計(jì)師IgorSysoev所開發(fā)高性能的Web和反向代理服務(wù)器,也是一個IMAP/POP3/SMTP代理...

sion里面,...token的生成一般是采用uuid保證唯一性,當(dāng)用戶登錄時為其生成唯一的token,存儲一般保存在數(shù)據(jù)庫中。token過期時間采用把token二次保存在cookie...

nginx跨域報(bào)504錯誤。Nginx504錯誤(Gatewaytime-out網(wǎng)關(guān)超時)的含義是所請求的網(wǎng)關(guān)沒有請求到,簡單來說就是沒有請求到可以執(zhí)行的PHP-CGI一般看來,這種情...

配置中心提供:了統(tǒng)一的配置信息管理服務(wù),可以實(shí)時的通知各個服務(wù)獲取最新的配置信息鏈路追蹤技術(shù):可以將所有的請求數(shù)據(jù)記錄下來,方便我們進(jìn)行后續(xù)分析各個...

為什么這么多人在學(xué)Python呢?很多小白都聽說Python很火,簡單易學(xué),學(xué)起來很容易,學(xué)習(xí)周期短,可是為啥要學(xué)Python呢?,下面談?wù)勎覍ython的感悟。在PC時代...應(yīng)用...

在Docker中安裝一個Consul1.拉取鏡像dockerpullconsul2.啟動Server啟動前,先建立/consul/data文件夾,保存consul的數(shù)據(jù)mkd...