阿里巴巴ServiceMesh落地的架構(gòu)與挑戰(zhàn)-創(chuàng)新互聯(lián)

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

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

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站建設(shè)、網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的赤坎網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

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

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

部署架構(gòu)

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

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

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

挑戰(zhàn)

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

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

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

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

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

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

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

路由

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

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

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

限流

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

3. Envoy 的資源開銷過大

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

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

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

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

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

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

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

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

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

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

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

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

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

展望

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

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

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

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

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

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

本書亮點

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

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

網(wǎng)頁標題：阿里巴巴ServiceMesh落地的架構(gòu)與挑戰(zhàn)-創(chuàng)新互聯(lián)
轉(zhuǎn)載源于：http://muchs.cn/article22/ddjjcc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供云服務(wù)器、App開發(fā)、靜態(tài)網(wǎng)站、做網(wǎng)站、網(wǎng)站導(dǎo)航、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)