阿里巴巴 Service Mesh 落地的架構(gòu)與挑戰(zhàn)

點(diǎn)擊下載《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》

本文節(jié)選自《不一樣的 雙11 技術(shù)：阿里巴巴經(jīng)濟(jì)體云原生實(shí)踐》一書，點(diǎn)擊上方圖片即可下載！

作者 | 方克明（溪翁）阿里云中間件技術(shù)部技術(shù)專家

導(dǎo)讀：云原生已成為整個(gè)阿里巴巴經(jīng)濟(jì)體構(gòu)建面向未來的技術(shù)基礎(chǔ)設(shè)施，Service Mesh 作為云原生的關(guān)鍵技術(shù)之一，順利完成在 雙11 核心應(yīng)用嚴(yán)苛而復(fù)雜場(chǎng)景下的落地驗(yàn)證。本文作者將與大家分享在完成這一目標(biāo)過程中我們所面臨和克服的挑戰(zhàn)。

部署架構(gòu)

切入主題前，需要交代一下在 雙11 核心應(yīng)用上落地的部署架構(gòu)，如下圖所示。在這篇文章中，我們主要聚焦于 Service A 和 Service B 之間 RPC 協(xié)議的 Mesh 化。

圖中示例說明了 Service Mesh 所包含的三大平面：即數(shù)據(jù)平面（Data Plane）、控制平面（Control Plane）和運(yùn)維平面（Operation Plane）。數(shù)據(jù)平面我們采用的是開源的 Envoy（上圖中的 Sidecar，請(qǐng)讀者注意這兩個(gè)詞在本文中可以互換使用），控制平面采用的是開源的 Istio（目前只使用了其中的 Pilot 組件），運(yùn)維平面則完全自研。

與半年前落地時(shí)不同，這次 雙11 核心應(yīng)用上落地我們采用了 Pilot 集群化部署的模式，即 Pilot 不再與 Envoy 一起部署到業(yè)務(wù)容器中，而是搭建了一個(gè)獨(dú)立的集群。這一變化使得控制平面的部署方式演進(jìn)到了 Service Mesh 應(yīng)有的終態(tài)。

挑戰(zhàn)

落地所選擇的 雙11 核心應(yīng)用都是采用 Java 編程語言實(shí)現(xiàn)的，在落地的過程中我們面臨了以下挑戰(zhàn)。

1. 在 SDK 無法升級(jí)的情形下如何實(shí)現(xiàn)應(yīng)用的 Mesh 化

在決定要在 雙11 的核心應(yīng)用上落地 Mesh 時(shí)，Java 應(yīng)用依賴的 RPC SDK 版本已經(jīng)定稿，為了 Mesh 化完全沒有時(shí)間去開發(fā)一個(gè)適用于 Mesh 的 RPC SDK 并做升級(jí)。那時(shí)，擺在團(tuán)隊(duì)面前的技術(shù)問題是：如何在不升級(jí) SDK 的情形下，實(shí)現(xiàn) RPC 協(xié)議的 Mesh 化？

熟悉 Istio 的讀者想必清楚，Istio 是通過 iptables 的 NAT 表去做流量透明攔截的，通過流量透明攔截可在應(yīng)用無感的情形下將流量劫持到 Envoy 中從而實(shí)現(xiàn) Mesh 化。但很不幸，NAT 表所使用到的 nf_contrack 內(nèi)核模塊因?yàn)樾屎艿?，在阿里巴巴的線上生產(chǎn)機(jī)器中被去除了，因此無法直接使用社區(qū)的方案。好在年初開始不久我們與阿里巴巴?OS 團(tuán)隊(duì)達(dá)成了合作共建，由他們負(fù)責(zé)承擔(dān) Service Mesh 所需的流量透明攔截和網(wǎng)絡(luò)加速這兩塊基礎(chǔ)能力的建設(shè)。經(jīng)過兩個(gè)團(tuán)隊(duì)的緊密合作，OS 團(tuán)隊(duì)探索了通過基于 userid 和 mark 標(biāo)識(shí)流量的透明攔截方案，基于 iptables 的 mangle 表實(shí)現(xiàn)了一個(gè)全新的透明攔截組件。

下圖示例說明了存在透明攔截組件的情形下，RPC 服務(wù)調(diào)用的流量走向。其中，Inbound 流量是指調(diào)進(jìn)來的流量（流量的接受者是 Provider 角色），而 Outbound 是指調(diào)出去的流量（流量的發(fā)出者是 Consumer 角色）。通常一個(gè)應(yīng)用會(huì)同時(shí)承擔(dān)兩個(gè)角色，所以有 Inbound 和 Outbound 兩股流量并存。

有了透明攔截組件之后，應(yīng)用的 Mesh 化完全能做到無感，這將極大地改善 Mesh 落地的便利性。當(dāng)然，由于 RPC 的 SDK 仍存在以前的服務(wù)發(fā)現(xiàn)和路由邏輯，而該流量被劫持到 Envoy 之后又會(huì)再做一次，這將導(dǎo)致 Outbound 的流量會(huì)因?yàn)榇嬖趦纱畏?wù)發(fā)現(xiàn)和路由而增加 RT，這在后面的數(shù)據(jù)部分也將有所體現(xiàn)。顯然，以終態(tài)落地 Service Mesh 時(shí)，需要去除 RPC SDK 中的服務(wù)發(fā)現(xiàn)與路由邏輯，將相應(yīng)的 CPU 和內(nèi)存開銷給節(jié)約下來。

2.短時(shí)間內(nèi)支持電商業(yè)務(wù)復(fù)雜的服務(wù)治理功能

路由

在阿里巴巴電商業(yè)務(wù)場(chǎng)景下的路由特性豐富多樣，除了要支持單元化、環(huán)境隔離等路由策略，還得根據(jù) RPC 請(qǐng)求的方法名、調(diào)用參數(shù)、應(yīng)用名等完成服務(wù)路由。阿里巴巴內(nèi)部的 Java?RPC 框架是通過嵌入 Groovy 腳本來支持這些路由策略的，業(yè)務(wù)方在運(yùn)維控制臺(tái)上配置 Groovy 路由模板，SDK 發(fā)起調(diào)用時(shí)會(huì)執(zhí)行該腳本完成路由策略的運(yùn)用。

未來的 Service Mesh 并不打算提供 Groovy 腳本那么靈活的路由策略定制方案，避免因?yàn)檫^于靈活而給 Service Mesh 自身的演進(jìn)帶去掣肘。因此，我們決定借 Mesh 化的機(jī)會(huì)去除?Groovy 腳本。通過落地應(yīng)用所使用 Groovy 腳本的場(chǎng)景分析，我們抽象出了一套符合云原生的解決方案：擴(kuò)展 Istio 原生的 CRD 中的 VirtualService 和 DestinationRule，增加 RPC 協(xié)議所需的路由配置段去表達(dá)路由策略。

目前阿里巴巴環(huán)境下的單元化、環(huán)境隔離等策略都是在 Istio/Envoy 的標(biāo)準(zhǔn)路由模塊內(nèi)做了定制開發(fā)，不可避免地存在一些 hack 邏輯。未來計(jì)劃在 Istio/Envoy 的標(biāo)準(zhǔn)路由策略之外，設(shè)計(jì)一套基于 Wasm 的路由插件方案，讓那些簡(jiǎn)單的路由策略以插件的形式存在。如此一來，既減少了對(duì)標(biāo)準(zhǔn)路由模塊的侵入，也在一定程度上滿足了業(yè)務(wù)方對(duì)服務(wù)路由定制的需要。設(shè)想的架構(gòu)如下圖所示：

限流

出于性能考慮，阿里巴巴內(nèi)部落地的 Service Mesh 方案并沒有采用 Istio 中的 Mixer 組件，限流這塊功能借助阿里巴巴內(nèi)部廣泛使用的?Sentinel 組件來實(shí)現(xiàn)，不僅可以與已經(jīng)開源的 Sentinel 形成合力，還可以減少阿里巴巴內(nèi)部用戶的遷移成本（直接兼容業(yè)務(wù)的現(xiàn)有配置來限流）。為了方便 Mesh 集成，內(nèi)部多個(gè)團(tuán)隊(duì)合作開發(fā)了 Sentinel 的?C++版本，整個(gè)限流的功能是通過 Envoy 的 Filter 機(jī)制來實(shí)現(xiàn)的，我們?cè)?Dubbo 協(xié)議之上構(gòu)建了相應(yīng)的 Filter（Envoy 中的術(shù)語，代表處理請(qǐng)求的一個(gè)獨(dú)立功能模塊），每個(gè)請(qǐng)求都會(huì)經(jīng)過 Sentinel Filter 做處理。限流所需的配置信息則是通過 Pilot 從 Nacos 中獲取，并通過 xDS 協(xié)議下發(fā)到 Envoy 中。

3. Envoy 的資源開銷過大

Envoy 誕生之初要解決的一個(gè)核心問題就是服務(wù)的可觀測(cè)性，因此 Envoy 一開始就內(nèi)置了大量的 stats（即統(tǒng)計(jì)信息），以便更好地對(duì)服務(wù)進(jìn)行觀測(cè)。

Envoy 的 stats 粒度很細(xì)，甚至細(xì)到整個(gè)集群的 IP 級(jí)別，在阿里巴巴環(huán)境下，某些電商應(yīng)用的 Consumer 和 Provider 服務(wù)加起來達(dá)到了幾十萬之多的 IP（每個(gè) IP 在不同的服務(wù)下攜帶的元信息不同，所以不同的服務(wù)下的相同 IP 是各自獨(dú)立的）。如此一來，Envoy 在這塊的內(nèi)存開銷甚是巨大。為此，我們給 Envoy 增加了 stats 開關(guān)，用于關(guān)閉或打開 IP 級(jí)別的 stats，關(guān)閉 IP 級(jí)別的 stats 直接帶來了內(nèi)存節(jié)約 30% 成果。下一步我們將跟進(jìn)社區(qū)的 stats symbol table 的方案來解決 stats 指標(biāo)字符串重復(fù)的問題，那時(shí)的內(nèi)存開銷將進(jìn)一步減少。

4. 解耦業(yè)務(wù)與基礎(chǔ)設(shè)施，實(shí)現(xiàn)基礎(chǔ)設(shè)施升級(jí)對(duì)業(yè)務(wù)無感

Service Mesh 落地的一項(xiàng)核心價(jià)值就是讓基礎(chǔ)設(shè)施與業(yè)務(wù)邏輯完全解耦，兩者可以獨(dú)立演進(jìn)。為了實(shí)現(xiàn)這個(gè)核心價(jià)值，Sidecar 需要具備熱升級(jí)能力，以便升級(jí)時(shí)不會(huì)造成業(yè)務(wù)流量中斷，這對(duì)方案設(shè)計(jì)和技術(shù)實(shí)現(xiàn)的挑戰(zhàn)還是蠻大的。

我們的熱升級(jí)采用雙進(jìn)程方案，先拉起新的 Sidecar 容器，由它與舊的 Sidecar 進(jìn)行運(yùn)行時(shí)數(shù)據(jù)交接，在新的 Sidecar 準(zhǔn)備發(fā)接管流量后，讓舊的 Sidecar 等待一定時(shí)間后退出，最終實(shí)現(xiàn)業(yè)務(wù)流量無損。核心技術(shù)主要是運(yùn)用了 Unix Domain?Socket 和 RPC 的節(jié)點(diǎn)優(yōu)雅下線功能。下圖大致示例了關(guān)鍵過程。

數(shù)據(jù)表現(xiàn)

公布性能數(shù)據(jù)一不小心就會(huì)引發(fā)爭(zhēng)議和誤解，因?yàn)樾阅軘?shù)據(jù)的場(chǎng)景存在很多變量。比如，并發(fā)度、QPS、payload 大小等對(duì)最終的數(shù)據(jù)表現(xiàn)將產(chǎn)生關(guān)鍵影響。也正因如此，Envoy 官方從來沒有提供過本文所列出的這些數(shù)據(jù)，背后的原因正是其作者 Matt Klein 擔(dān)心引發(fā)誤解。值得強(qiáng)調(diào)的是，在時(shí)間非常緊迫的情形下，我們所落地的 Service Mesh 并非處于最優(yōu)狀態(tài)，甚至不是最終方案（比如 Consumer 側(cè)存在兩次路由的問題）。我們之所以選擇分享出來，是希望讓更多的同行了解我們的進(jìn)展和狀態(tài)。

本文只列出了 雙11 所上線核心應(yīng)用中某一個(gè)的數(shù)據(jù)。從單機(jī) RT 抽樣的角度，部署了 Service Mesh 的某臺(tái)機(jī)器，其 Provider 側(cè)的 RT 均值是 5.6ms，Consumer 側(cè)的是 10.36ms。該機(jī)器在 雙11 零點(diǎn)附近的 RT 表現(xiàn)如下圖所示：

沒有部署 Service Mesh 的某臺(tái)機(jī)器，Provider 側(cè)的均值為 5.34ms，Consumer 側(cè)的則是 9.31ms。下圖示例了該機(jī)器在 雙11 零點(diǎn)附件的 RT 表現(xiàn)。

相比之下，Provider 側(cè)的 RT 在 Mesh 化前后增加了 0.26ms，Consumer 側(cè)則增加了 1.05ms。注意，這個(gè) RT 差是包含了業(yè)務(wù)應(yīng)用到 Sidecar，以及 Sidecar 處理的所有時(shí)間在內(nèi)的，下圖示例說明了帶來時(shí)延增加的鏈路。

整體上，該核心應(yīng)用所有上線了 Service Mesh 的機(jī)器和沒有上線 Service Mesh 的機(jī)器在某個(gè)時(shí)間段的整體均值數(shù)據(jù)做了對(duì)比。Provider 側(cè) Mesh 化后的 RT 增加了 0.52ms，而 Consumer 側(cè)增加了 1.63ms。

在 CPU 和內(nèi)存開銷方面，Mesh 化之后，Envoy 所消耗的 CPU 在所有核心應(yīng)用上都維持在 0.1 核左右，會(huì)隨著 Pilot 推送數(shù)據(jù)而產(chǎn)生毛刺。未來需要借助 Pilot 和 Envoy 之間的增量推送去對(duì)毛刺做優(yōu)化。內(nèi)存的開銷隨著應(yīng)用的服務(wù)和集群規(guī)模不同而存在巨大差異，目前看來 Envoy 在內(nèi)存的使用上仍存在很大的優(yōu)化空間。

從所有雙11 上線的核心應(yīng)用的數(shù)據(jù)表現(xiàn)來看，Service Mesh 的引入對(duì)于 RT 的影響和帶來的 CPU 開銷是基本一樣的，而內(nèi)存開銷則因?yàn)橐蕾嚪?wù)和集群規(guī)模的不同而有相當(dāng)大的差異。

展望

在云原生的浪潮下，阿里巴巴借這波技術(shù)浪潮致力于打造面向未來的技術(shù)基礎(chǔ)設(shè)施。在發(fā)展的道路上將貫徹“借力開源，反哺開源”的發(fā)展思路，通過開源實(shí)現(xiàn)技術(shù)普惠，為未來的云原生技術(shù)在更大范圍的普及做出自己的貢獻(xiàn)。

接下來，我們的整體技術(shù)著力點(diǎn)在于：

• 與 Istio 開源社區(qū)共同增強(qiáng) Pilot 的數(shù)據(jù)推送能力。在阿里巴巴具備 雙11 這種超大規(guī)模的應(yīng)用場(chǎng)景下，我們對(duì)于Pilot 的數(shù)據(jù)推送能力有著極致的要求，相信在追求極致的過程中，能與開源社區(qū)一道加速全球事實(shí)標(biāo)準(zhǔn)的共建。從阿里巴巴內(nèi)部來看，我們目前拉通了與 Nacos 團(tuán)隊(duì)的共建，將通過社區(qū)的 MCP 協(xié)議與 Nacos 對(duì)接，讓阿里巴巴所開源的各種技術(shù)組件能體系化地協(xié)同工作；

• 以 Istio 和 Envoy 為一體，進(jìn)一步優(yōu)化兩者的協(xié)議以及各自的管理數(shù)據(jù)結(jié)構(gòu)，通過更加精煉、更加合理的數(shù)據(jù)結(jié)構(gòu)去減少各自的內(nèi)存開銷；

• 著力解決大規(guī)模 Sidecar 的運(yùn)維能力建設(shè)。讓 Sidecar 的升級(jí)做到可灰度、可監(jiān)控和可回滾；

• 兌現(xiàn) Service Mesh 的價(jià)值，讓業(yè)務(wù)與技術(shù)設(shè)施能以更高的效率彼此獨(dú)立演進(jìn)。

本書亮點(diǎn)

• 雙11 超大規(guī)模 K8s 集群實(shí)踐中，遇到的問題及解決方法詳述
• 云原生化最佳組合：Kubernetes+容器+神龍，實(shí)現(xiàn)核心系統(tǒng) 100% 上云的技術(shù)細(xì)節(jié)
• 雙 11 Service Mesh 超大規(guī)模落地解決方案

“阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)?！?/p>