在私有云集群環(huán)境下建設(shè) Service Mesh ，往往需要對(duì)現(xiàn)有技術(shù)架構(gòu)做較大范圍的改造，同時(shí)會(huì)面臨諸如兼容困難、規(guī)模化支撐技術(shù)挑戰(zhàn)大、推廣困境多等一系列復(fù)雜性問題。本文會(huì)系統(tǒng)性地講解在美團(tuán)在落地 Service Mesh 過程中，我們面臨的一些挑戰(zhàn)及實(shí)踐經(jīng)驗(yàn)，希望能對(duì)大家有所啟發(fā)或者幫助。

一、美團(tuán)服務(wù)治理建設(shè)進(jìn)展

1.1 服務(wù)治理發(fā)展史

首先講一下 OCTO，此前美團(tuán)技術(shù)團(tuán)隊(duì)博客也分享過很多相關(guān)的文章，它是美團(tuán)標(biāo)準(zhǔn)化的服務(wù)治理基礎(chǔ)設(shè)施，現(xiàn)應(yīng)用于美團(tuán)所有事業(yè)線。OCTO 的治理生態(tài)非常豐富，性能及易用性表現(xiàn)也很優(yōu)異，可整體概括為 3 個(gè)特征：

屬于公司級(jí)的標(biāo)準(zhǔn)化基礎(chǔ)設(shè)施。技術(shù)棧高度統(tǒng)一，覆蓋了公司 90% 以上的應(yīng)用，日均調(diào)用量達(dá)數(shù)萬億次。

經(jīng)歷過較大規(guī)模的技術(shù)考驗(yàn)。覆蓋數(shù)萬個(gè)服務(wù)、數(shù)十萬個(gè)節(jié)點(diǎn)。

治理能力豐富。協(xié)同周邊治理生態(tài)，實(shí)現(xiàn)了 SET 化、鏈路級(jí)復(fù)雜路由、全鏈路壓測(cè)、鑒權(quán)加密、限流熔斷等治理能力。

回顧美團(tuán)服務(wù)治理體系的發(fā)展史，歷程整體上劃分為四個(gè)階段：

第一階段是基礎(chǔ)治理能力統(tǒng)一。實(shí)現(xiàn)通信框架及注冊(cè)中心的統(tǒng)一，由統(tǒng)一的治理平臺(tái)支撐節(jié)點(diǎn)管理、流量管理、監(jiān)控預(yù)警等運(yùn)營能力。

第二階段重點(diǎn)提升性能及易用性。4 核 4GB 環(huán)境下使用 1KB 數(shù)據(jù)進(jìn)行 echo 測(cè)試，QPS 從 2 萬提升至接近 10 萬，99 分位線 1ms；也建設(shè)了分布式鏈路追蹤、分階段耗時(shí)精細(xì)埋點(diǎn)等功能。

第三階段是全方位豐富治理能力。落地了全鏈路壓測(cè)平臺(tái)、性能診斷優(yōu)化平臺(tái)、穩(wěn)定性保障平臺(tái)、鑒權(quán)加密等一系列平臺(tái)，也實(shí)現(xiàn)了鏈路級(jí)別的流量治理，如全鏈路灰度發(fā)布等。

第四階段是建設(shè)了跨地域的容災(zāi)及擴(kuò)展能力。在每天數(shù)千萬訂單量級(jí)下實(shí)現(xiàn)了單元化，也實(shí)現(xiàn)了所有 PaaS 層組件及核心存儲(chǔ)系統(tǒng)的打通。

1.2 服務(wù)治理體系的困境

目前，美團(tuán)已具備了較完善的治理體系，但仍有較多的痛點(diǎn)及挑戰(zhàn)。大的背景是公司業(yè)務(wù)蓬勃發(fā)展，業(yè)務(wù)愈發(fā)多元化，治理也愈發(fā)精細(xì)化，這帶來了較多新的問題：

業(yè)務(wù)與中間件強(qiáng)耦合，制約彼此迭代。當(dāng)中間件引入 Bug，可能成百上千、甚至數(shù)千個(gè)業(yè)務(wù)需要做配合升級(jí)，中間件的新特性也依賴業(yè)務(wù)升級(jí)后才能使用，成本很高。

中間件版本碎片化嚴(yán)重。發(fā)布出去的組件基本托管在業(yè)務(wù)側(cè)，很難統(tǒng)一進(jìn)行管控，這也頻繁造成業(yè)務(wù)多類的問題。

異構(gòu)體系融合難。新融入公司的技術(shù)體系往往與美團(tuán)不兼容，治理體系打通的成本很高，難度也很大。此前，美團(tuán)與大眾點(diǎn)評(píng)打通治理，不包含業(yè)務(wù)遷移，就歷時(shí) 1 年半的時(shí)間；近期，摩拜使用的 gRPC 框架也無法與系統(tǒng)進(jìn)行通信，但打通迫在眉睫。

非 Java 語言治理體系能力弱，多個(gè)主流語言無官方 SDK。多元業(yè)務(wù)場(chǎng)景下，未來多語言也是個(gè)趨勢(shì)，比如在機(jī)器學(xué)習(xí)領(lǐng)域，Python 語言不太可能被其他語言完全代替。

二、服務(wù)治理體系優(yōu)化的思路與挑戰(zhàn)

2.1 優(yōu)化思路

總結(jié)來看，OCTO 在服務(wù)層實(shí)現(xiàn)了統(tǒng)一抽象來支撐業(yè)務(wù)發(fā)展，但它并未解決這層架構(gòu)可以獨(dú)立演進(jìn)的問題。

1.2節(jié)中問題1與問題2的本質(zhì)是“耦合”，問題3與問題4的本質(zhì)是“缺乏標(biāo)準(zhǔn)服務(wù)治理運(yùn)行時(shí)”。在理想的架構(gòu)中，異構(gòu)語言、異構(gòu)治理體系可以共用統(tǒng)一的標(biāo)準(zhǔn)治理運(yùn)行時(shí)，僅在業(yè)務(wù)使用的 SDK 部分有輕微差異。

所以，我們整體的優(yōu)化思路分為三步：隔離解耦，在隔離出的基礎(chǔ)設(shè)施層建設(shè)標(biāo)準(zhǔn)化治理運(yùn)行時(shí)，標(biāo)準(zhǔn)之上建體系。

上述解決方案所對(duì)應(yīng)的新架構(gòu)模式下，各業(yè)務(wù)進(jìn)程會(huì)附屬一個(gè) Proxy 進(jìn)程，SDK 發(fā)出以及接收的流量均會(huì)被附屬的 Proxy 攔截。像限流、路由等治理功能均由 Proxy 和中心化的控制大腦完成，并由控制面對(duì)接所有治理子系統(tǒng)集成。這種模式下 SDK 很輕薄，異構(gòu)的語言、異構(gòu)的治理體系就很容易互通，從而實(shí)現(xiàn)了物理解耦，業(yè)界將這種模式稱為 Service Mesh（其中 Proxy 被稱為數(shù)據(jù)面、中心化控制大腦被稱為控制面）。

2.2 復(fù)雜性挑戰(zhàn)

美團(tuán)在實(shí)踐中所面臨的復(fù)雜性劃主要包括以下4類：

兼容性：技術(shù)改造涉及范圍較大，一方面需要通過保證現(xiàn)有通信方式及平臺(tái)使用方式不變，從而來保障業(yè)務(wù)研發(fā)效率，另一方面也要解決運(yùn)行載體多樣性、運(yùn)維體系兼容等問題。

異構(gòu)性：第一是多語言互通問題；第二是打通治理體系內(nèi)的眾多治理子系統(tǒng)，像服務(wù)鑒權(quán)、注冊(cè)中心等系統(tǒng)的存儲(chǔ)及發(fā)布訂閱機(jī)制都是不同的；第三是快速打通新融入公司的異構(gòu)治理體系。

大規(guī)模支撐：出于性能方面考慮，開源 Istio 等產(chǎn)品不宜直接應(yīng)用于大規(guī)模的生產(chǎn)環(huán)境，美團(tuán)控制面需具備百萬級(jí)鏈接下高吞吐、低延遲、高精確的系統(tǒng)能力。

重交易型業(yè)務(wù)容錯(cuò)性低：交易型業(yè)務(wù)場(chǎng)景下，業(yè)務(wù)對(duì) Service Mesh 的性能、穩(wěn)定性往往持懷疑態(tài)度；美團(tuán)基礎(chǔ)架構(gòu)團(tuán)隊(duì)也強(qiáng)調(diào)在業(yè)務(wù)價(jià)值導(dǎo)向下，基于實(shí)際業(yè)務(wù)價(jià)值進(jìn)行運(yùn)營推廣，而不是采用從上至下的偏政策性推廣方式。

三、美團(tuán)落地 Service Mesh 的解決方案

3.1 整體架構(gòu)

美團(tuán)采用數(shù)據(jù)面基于 Envoy 二次開發(fā)、控制面自研為主、SDK 協(xié)同升級(jí)的方案（內(nèi)部項(xiàng)目名是 OCTO Mesh?）。架構(gòu)簡介如下：

• 各語言輕薄的 SDK 與 Proxy 通過 UDS（Unix Domain Socket）交互，主要出發(fā)點(diǎn)是考慮到相比透明流量劫持，UDS 性能與可運(yùn)維性更好。

• 控制面與 Proxy 通過雙向流通信，控制面與治理生態(tài)的多個(gè)子系統(tǒng)交互，并將計(jì)算處理過的治理數(shù)據(jù)及策略數(shù)據(jù)下發(fā)給 Proxy 執(zhí)行，協(xié)同配合完成路由、限流等所有核心治理功能。

• 控制面內(nèi)部的 5 個(gè)模塊都是自研的獨(dú)立服務(wù)。

• • Pilot 承載核心治理能力，與 Proxy 直接交互。

  • Dispatcher 負(fù)責(zé)屏蔽異構(gòu)子系統(tǒng)差異。

  • 集中式健康檢查管理節(jié)點(diǎn)狀態(tài)。

  • Config Server 管理 Mesh 體系內(nèi)相關(guān)的策略，并將 Pilot 有狀態(tài)的部分盡量遷移出來。

  • 監(jiān)控及巡檢系統(tǒng)負(fù)責(zé)提升穩(wěn)定性。

• 自研了的 Meta Server 系統(tǒng)實(shí)現(xiàn) Mesh 體系內(nèi)部的節(jié)點(diǎn)注冊(cè)和尋址，通過管理控制面與數(shù)據(jù)面的鏈接關(guān)系，也實(shí)現(xiàn)了按事業(yè)群隔離、水平擴(kuò)展等能力。

3.2 兼容性解決方案

兼容性的目標(biāo)及特征用一句話來總結(jié)就是：業(yè)務(wù)接入無感知。為此，我們做了以下三件事情：

(1) 與現(xiàn)有基礎(chǔ)設(shè)施及治理體系兼容

• 將 Service Mesh 與 OCTO 深度打通，確保各治理子系統(tǒng)的使用方式都不變。

• 運(yùn)行載體方面，同時(shí)支持容器、虛擬機(jī)、物理機(jī)。

• 打通運(yùn)維體系，保證服務(wù)治理基礎(chǔ)設(shè)施處于可管理、可監(jiān)測(cè)的狀態(tài)。

(2) 協(xié)議兼容

• 服務(wù)間調(diào)用往往是多對(duì)多的關(guān)系，一般調(diào)用端與服務(wù)端無法同時(shí)升級(jí)，為支持 Mesh 與非 Mesh 的互通，增強(qiáng)后的協(xié)議對(duì)業(yè)務(wù)完全透明。

• 與語義相關(guān)的所有內(nèi)容（比如異常等），均在 SDK 與 Proxy 之間達(dá)成共識(shí)，保證兼容。

• 無法在控制面及數(shù)據(jù)面中實(shí)現(xiàn)的能力，在 SDK 中執(zhí)行并通過上下文傳遞給 Proxy，保障功能完全對(duì)齊，當(dāng)然這種情況應(yīng)該盡量避免的。

(3) Mesh 與非 Mesh 模式的無縫切換

• 基于 UDS 通信必然需要業(yè)務(wù)升級(jí)一次 SDK 版本，我們?cè)?2020 年初時(shí)預(yù)先發(fā)布早做部署，確保當(dāng)前大部分業(yè)務(wù)已經(jīng)升級(jí)到新版本，但默認(rèn)仍是不開啟 Mesh 的狀態(tài)。

• 在可視化平臺(tái)上面通過開關(guān)操作，幾乎無成本實(shí)現(xiàn)從 Mesh 模式與非 Mesh 模式的切換，并具備實(shí)時(shí)生效的能力。

3.3 異構(gòu)性解決方案

異構(gòu)性的目標(biāo)及特征用一句話總結(jié)就是：標(biāo)準(zhǔn)化服務(wù)治理運(yùn)行時(shí)。具體可拆分為3個(gè)子目標(biāo)：

• 標(biāo)準(zhǔn)化美團(tuán)內(nèi)部 6 種語言的治理體系。

• 架構(gòu)層面由控制面統(tǒng)一對(duì)接各個(gè)治理子系統(tǒng)，屏蔽注冊(cè)中心、鑒權(quán)、限流等系統(tǒng)具體實(shí)現(xiàn)機(jī)制的異構(gòu)性。

• 支持摩拜及未來新融入公司的異構(gòu)治理體系與公司整體的快速融合。

針對(duì)上述3個(gè)子目標(biāo)，我們所采取的方案如下：

• 將數(shù)據(jù)面 + 控制面定義為標(biāo)準(zhǔn)化的服務(wù)治理運(yùn)行時(shí)，在標(biāo)準(zhǔn)運(yùn)行時(shí)內(nèi)打通所有治理能力。

• 建設(shè)統(tǒng)一接入中心系統(tǒng) Dispatcher ，并由其對(duì)接并屏蔽治理子系統(tǒng)的異構(gòu)性，從而實(shí)現(xiàn)外部系統(tǒng)的差異對(duì) Pilot 透明；下圖中 Dispatcher 與 Pilot 直接交互，Meta Server 的作用是避免廣播降低冗余。

• 重構(gòu)或從零建設(shè) SDK，目前使用的 6 種語言 SDK 均已落地并使用。

• 異構(gòu)語言、異構(gòu)體系均使用增強(qiáng)的統(tǒng)一協(xié)議交互，實(shí)現(xiàn)互通。

通過 Service Mesh 實(shí)現(xiàn)體系融合的前后對(duì)比如下：

• 引入 Service Mesh 前，單車向公司的流量以及公司向單車的流量，均是由中間的 adaptor 單點(diǎn)服務(wù)承接。除穩(wěn)定性有較大隱患外，所有交互邏輯均需要開發(fā)兩份代碼，效率較差。

• 引入 Service Mesh后，在一套服務(wù)治理設(shè)施內(nèi)打通并直接交互，消除了中心 adaptor 帶來的穩(wěn)定性及研發(fā)效率方面的缺陷；此外整個(gè)打通在1個(gè)月內(nèi)完成，異構(gòu)體系融合效率很高。

通過上述方案，針對(duì)異構(gòu)性方面取得了較好的效果：

• 標(biāo)準(zhǔn)化 6 種語言治理體系，非 Java 語言的核心治理能力基本對(duì)齊 Java；新語言也很容易融入，提供的官方 Python 語言、Golang 語言的通信框架新版本（依托于 OCTO Mesh），開發(fā)成本均控制在1個(gè)月左右。

• 支持異構(gòu)治理子系統(tǒng)通過統(tǒng)一接入中心快速融入，架構(gòu)簡潔、擴(kuò)展性強(qiáng)。

• 支持異構(gòu)治理體系快速融合并在單車側(cè)落地，異構(gòu)治理體系打通成本也從 1.5 年降低到 1 個(gè)月。

3.4 規(guī)模化解決方案

3.4.1 開源 Istio 問題分析

規(guī)模化的目標(biāo)及特征用一句話總結(jié)是：具備支撐數(shù)萬服務(wù)、百萬節(jié)點(diǎn)體量的系統(tǒng)能力，并支持水平擴(kuò)展。挑戰(zhàn)主要有3個(gè)：

• 美團(tuán)體量是最流行開源產(chǎn)品 Istio 上限的上千倍。

• 極高的實(shí)時(shí)性、準(zhǔn)確性要求；配置下發(fā)錯(cuò)誤或丟失會(huì)直接引發(fā)流量異常。

• 起步較早，業(yè)界參考信息很少。

經(jīng)過對(duì) Istio 架構(gòu)進(jìn)行深入分析，我們發(fā)現(xiàn)核心問題聚焦在以下3個(gè)瓶頸點(diǎn)：

• 每個(gè)控制面實(shí)例有 ETCD 存儲(chǔ)系統(tǒng)的全部數(shù)據(jù)，無法水平擴(kuò)展。

• 每個(gè) Proxy 鏈接相當(dāng)于獨(dú)立與 ETCD 交互，而同一個(gè)服務(wù)的 Proxy 請(qǐng)求內(nèi)容都相同，獨(dú)立交互有大量的 I/O 冗余。當(dāng) Proxy 批量發(fā)版或網(wǎng)絡(luò)抖動(dòng)時(shí)，瞬時(shí)風(fēng)暴很容易壓垮控制面及 ETCD。

• 每個(gè)節(jié)點(diǎn)都會(huì)探活所有其他節(jié)點(diǎn)。10 萬節(jié)點(diǎn)規(guī)模的集群，1 個(gè)檢測(cè)周期有 100 億次探活，會(huì)引發(fā)網(wǎng)絡(luò)風(fēng)暴。

3.4.2 措施一：橫向數(shù)據(jù)分片

針對(duì) Istio 控制面各實(shí)例承載全集群數(shù)據(jù)的問題，對(duì)應(yīng)的措施是通過橫向邏輯數(shù)據(jù)分片支持?jǐn)U展性，具體方案設(shè)計(jì)如下：

• Proxy 啟動(dòng)時(shí)會(huì)去向 Meta Server 系統(tǒng)請(qǐng)求需要連接的 Pilot IP，Meta Server 將相同服務(wù)的 Proxy 盡量落到同一個(gè)控制面節(jié)點(diǎn)（內(nèi)部策略更為復(fù)雜，還要考慮地域、負(fù)載等情況），這樣每個(gè) Pilot 實(shí)例按需加載而不必承載所有數(shù)據(jù)。

• 控制面節(jié)點(diǎn)異常或發(fā)布更新時(shí)，其所管理的 Proxy 也會(huì)有規(guī)律的遷移，恢復(fù)后在一定時(shí)間后還會(huì)接管其負(fù)責(zé)的 Proxy，從而實(shí)現(xiàn)了會(huì)話粘滯，也就實(shí)現(xiàn)邏輯上面的數(shù)據(jù)分片。

通過管理鏈接關(guān)系實(shí)現(xiàn)了按事業(yè)群隔離、按服務(wù)灰度等平臺(tái)能力，最關(guān)鍵的還是解決了 Mesh 體系水平擴(kuò)展的問題。

3.4.3 措施二：縱向分層訂閱

針對(duì) Istio 獨(dú)立管理各 Proxy 鏈接的 I/O 冗余問題，對(duì)應(yīng)的措施是通過分層訂閱減少冗余 I/O。Proxy 不直接與存儲(chǔ)等系統(tǒng)對(duì)接，而是在中間經(jīng)過一系列的處理，關(guān)鍵點(diǎn)有兩個(gè)：

• 關(guān)鍵點(diǎn) 1：基于快照緩存 + 索引的機(jī)制來減少 ZK watcher 同步。以注冊(cè)中心為例，常規(guī)實(shí)現(xiàn)方式下，如果每個(gè) Proxy 關(guān)注 100 個(gè)節(jié)點(diǎn)，1 萬個(gè)節(jié)點(diǎn)就會(huì)注冊(cè) 100 萬個(gè) watcher，相同服務(wù)的 Proxy 所關(guān)注內(nèi)容是相同的，另外不同服務(wù) Proxy 所關(guān)注的也有很多交集，其中包含大量的冗余。分層訂閱模式下，Proxy 不與注冊(cè)中心直接交互，通過中間的快照緩存與分層，確保每個(gè) Pilot 實(shí)例中 ZK 相同路徑的監(jiān)聽最多只用1個(gè) watcher，獲取到 watcher 通知后，Pilot 根據(jù)內(nèi)部的快照緩存 + 索引向所有關(guān)注者分發(fā)，大大降低了冗余。

• 關(guān)鍵點(diǎn) 2：治理能力層及會(huì)話管理層實(shí)現(xiàn)了類似于 I/O 多路復(fù)用能力，通過并發(fā)提升吞吐。

結(jié)果方面有效應(yīng)對(duì)了網(wǎng)絡(luò)抖動(dòng)或批量發(fā)版的瞬間風(fēng)暴壓力，壓測(cè)單 Pilot 實(shí)例可以承載 6 萬以上的鏈接，時(shí)延 TP99 線 < 2.3ms、數(shù)據(jù)零丟失。

3.4.4 措施三：集中式健康檢測(cè)

針對(duì)大規(guī)模集群內(nèi)指數(shù)級(jí)膨脹的節(jié)點(diǎn)間健康監(jiān)測(cè)次數(shù)，對(duì)應(yīng)的措施是摒棄了 P2P 檢測(cè)模式，我們參考并優(yōu)化了 Google 的 Traffic Drector 中心化管理的健康檢測(cè)模式。這種模式下檢測(cè)次數(shù)大大減少，一個(gè)周期內(nèi) 10 萬節(jié)點(diǎn)集群的檢測(cè)次數(shù)，從 100 億次下降到 10 萬次。

此外，當(dāng) Pilot 感知到 Proxy 異常時(shí)，會(huì)立即通知中心化健康檢測(cè)系統(tǒng)啟動(dòng)檢測(cè)，而不是等待檢測(cè)周期窗口的到來，這可以有效提升業(yè)務(wù)調(diào)用的成功率。

3.5 交易型場(chǎng)景困境下的解決方案

3.5.1 業(yè)務(wù)屬性分析

美團(tuán)內(nèi)部業(yè)務(wù)線較多，包括外賣、配送、酒店、旅游、單車、團(tuán)購等，其中絕大多數(shù)業(yè)務(wù)都帶有交易屬性，交易鏈路上一個(gè)流量異常就可能影響到訂單。業(yè)務(wù)系統(tǒng)對(duì)新技術(shù)領(lǐng)域的探索往往比較慎重，期望在新技術(shù)充分驗(yàn)證后再啟動(dòng)試點(diǎn)，所以除小語種及亟待與公司打通的單車業(yè)務(wù)外，推廣的難度是非常大的。此外，基礎(chǔ)架構(gòu)部秉承“以客戶為中心”的原則，研發(fā)、運(yùn)維、測(cè)試人員均是我們的“客戶”，所以技術(shù)升級(jí)會(huì)重點(diǎn)從業(yè)務(wù)價(jià)值入手，并非簡單依靠從上至下的政策推動(dòng)力。

所以，我們對(duì)外的承諾是：通信足夠快、系統(tǒng)足夠穩(wěn)定、接入足夠平滑高效。

3.5.2 精細(xì)化運(yùn)營體系建設(shè)

針對(duì)推廣的困境，我們首先做了兩件事情：

• 尋找具備強(qiáng)訴求的業(yè)務(wù)試點(diǎn)，客觀來說，美團(tuán)技術(shù)棧內(nèi)這類業(yè)務(wù)數(shù)量非常有限。

• 尋求標(biāo)桿核心業(yè)務(wù)試點(diǎn)，充分驗(yàn)證后推廣給其他業(yè)務(wù)，但效果并不理想，與業(yè)務(wù)穩(wěn)定性的訴求并不匹配。

針對(duì)上述困境，我們進(jìn)行深度思考后建立了一個(gè)精細(xì)化的運(yùn)營體系：

• 服務(wù)接入 Mesh 前。基于 SOA 分級(jí)將服務(wù)劃分為非核心與核心兩類，先針對(duì)非核心服務(wù)以及所有服務(wù)的線下環(huán)境進(jìn)行重點(diǎn)突破，實(shí)現(xiàn)了在廣泛的業(yè)務(wù)場(chǎng)景下，全面且充分的驗(yàn)證系統(tǒng)能力。

• 服務(wù)接入 Mesh 中。運(yùn)營系統(tǒng)通過校驗(yàn) SDK 版本、運(yùn)行時(shí)環(huán)境等信息，自動(dòng)篩選出滿足條件的服務(wù)，業(yè)務(wù)同學(xué)只需要在平臺(tái)上做（1）開啟開關(guān)、（2）選擇節(jié)點(diǎn)（3）指定 Mesh 流量比例三個(gè)步驟，就完成了到 Mesh 模式的切換，不需代碼改造也不需發(fā)布服務(wù)，整個(gè)過程基本在 1 分鐘左右完成；此外，通過與 IM 工具深度聯(lián)動(dòng)，提升了推廣與數(shù)據(jù)運(yùn)營的效率。

• 服務(wù)接入 Mesh 后。一方面，業(yè)務(wù)側(cè)包括架構(gòu)側(cè)的運(yùn)營有詳細(xì)的數(shù)據(jù)指標(biāo)做對(duì)比參考；另一方面，運(yùn)營系統(tǒng)支持預(yù)先設(shè)置穩(wěn)定性策略并做準(zhǔn)實(shí)時(shí)的檢測(cè)，當(dāng)某個(gè)接入服務(wù) Mesh 模式異常時(shí)，即時(shí)自動(dòng)切換回非 Mesh 模式。

運(yùn)營體系具備 “接入過程無感”、“精細(xì)化流量粒度灰度”、“異常自動(dòng)回滾恢復(fù)” 三個(gè)核心能力，在運(yùn)營體系建設(shè)后推廣運(yùn)營較為順利，目前線上接入的 600+ 服務(wù)、線下接入的 3500+ 服務(wù)中，90% 以上是依托運(yùn)營平臺(tái)接入 Mesh 的。

3.5.3 通信性能優(yōu)化

在性能損耗優(yōu)化這個(gè)方向，除使用 UDS 規(guī)避網(wǎng)絡(luò)棧外，我們也通過增量聚合下發(fā)、序列化優(yōu)化兩個(gè)措施減少不必要的解包，提升了通信性能。

經(jīng)過壓測(cè)，去除非核心功能在 2 核 4G 環(huán)境用 1KB 數(shù)據(jù)做 echo 測(cè)試，QPS 在 34000 以上，一跳平均延遲 0.207ms，時(shí)延TP99 線 0.4ms 左右。

3.5.4 流量多級(jí)保護(hù)

美團(tuán)落地 Service Mesh 在穩(wěn)定性保障方面建設(shè)投入較多，目前尚無 Service Mesh 引發(fā)的故障，具體包含三個(gè)方面：

• 首先做了流量多級(jí)保護(hù)

• • 一方面，當(dāng) Proxy 不可用時(shí)，流量會(huì)自動(dòng) fallback 到非 Mesh 模式；另一方面，支持最精細(xì)支持按單節(jié)點(diǎn)的 1/1000 比例灰度。下圖是具體的交互流程，當(dāng)然，這兩個(gè)特性與 Service Mesh 的最終形態(tài)是沖突的，只是作為系統(tǒng)建設(shè)初期優(yōu)先保證業(yè)務(wù)穩(wěn)定性的過渡性方案，長期來看必然是要去除的（包括美團(tuán)一些核心服務(wù)已經(jīng)完全去除）。

  • 基于 FD 遷移 + SDK 配合協(xié)議交互，實(shí)現(xiàn) Proxy 無損熱重啟的能力。

• 控制面下發(fā)錯(cuò)誤配置比停發(fā)配置的后果更為嚴(yán)重，我們建設(shè)了應(yīng)用層面及系統(tǒng)層面的周期巡檢，從端到端的應(yīng)用視角驗(yàn)證正確性，避免或減少因變更引發(fā)的異常。

• 系統(tǒng)交互方面，通過限流、熔斷對(duì)中心化控制面做服務(wù)保護(hù)；系統(tǒng)內(nèi)柔性可用，當(dāng)控制面全部異常時(shí)，緩存機(jī)制也能協(xié)助 Proxy 在一定時(shí)間內(nèi)可用。

四、總結(jié)

本文系統(tǒng)性的介紹美團(tuán)在 Service Mesh 落地進(jìn)程中面臨的“兼容性”、“異構(gòu)性”、“規(guī)模化”、“交易屬性業(yè)務(wù)容錯(cuò)性低”這四類復(fù)雜性挑戰(zhàn)，針對(duì)上述挑戰(zhàn)，我們也詳細(xì)介紹了大規(guī)模私有云集群場(chǎng)景下的優(yōu)化思考及實(shí)踐方案。

基于上述實(shí)踐，目前美團(tuán)線上落地服務(wù)數(shù)超過 600，線下服務(wù)數(shù)超過 3500+，初步驗(yàn)證了模式的可行性。短期價(jià)值方面，我們支持了摩拜等異構(gòu)治理體系的快速融合、多語言治理能力的統(tǒng)一；長期價(jià)值仍需在實(shí)踐中繼續(xù)探索與驗(yàn)證，但在標(biāo)準(zhǔn)化服務(wù)治理運(yùn)行時(shí)并與業(yè)務(wù)解耦、中心化管控下更豐富的治理能力輸出兩個(gè)方面，是非常值得期待的。

作者簡介

繼東、薛晨、業(yè)祥、張昀，均來自美團(tuán)基礎(chǔ)技術(shù)部-基礎(chǔ)架構(gòu)部。

----------? END? ----------

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過哦！

阿里技術(shù)精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術(shù)專家楚衡：架構(gòu)制圖的工具與方法論

螞蟻集團(tuán)技術(shù)專家山丘：性能優(yōu)化常見壓測(cè)模型及優(yōu)缺點(diǎn)

阿里文娛技術(shù)專家戰(zhàn)獒: 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構(gòu)整潔之道

阿里專家常昊：新人如何上手項(xiàng)目管理？

螞蟻集團(tuán)沈凋墨：Kubernetes-微內(nèi)核的分布式操作系統(tǒng)

阿里合伙人范禹：常掛在阿里技術(shù)人嘴邊的四句土話

阿里技術(shù)專家都鐸：一文搞懂技術(shù)債

支付寶研究員兼OceanBase總架構(gòu)師楊傳輝：我在數(shù)據(jù)庫夢(mèng)之隊(duì)的十年成長路

阿里技術(shù)專家麒燁：修煉測(cè)試基本功

阿里計(jì)算平臺(tái)掌門人賈揚(yáng)清：我對(duì)人工智能方向的一點(diǎn)淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護(hù)隱私的共享智能？

阿里高級(jí)技術(shù)專家簫逸：如何畫好一張架構(gòu)圖？

阿里高級(jí)技術(shù)專家張建飛：應(yīng)用架構(gòu)分離業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)之道

螞蟻科技 Service Mesh 落地實(shí)踐與挑戰(zhàn) | GIAC 實(shí)錄

阿里6年，我的技術(shù)蛻變之路！

螞蟻集團(tuán)涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質(zhì)量穩(wěn)定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個(gè)標(biāo)簽

阿里高工流生 | 云原生時(shí)代的 DevOps 之道

阿里高級(jí)技術(shù)專家邱小俠：微服務(wù)架構(gòu)的理論基礎(chǔ) - 康威定律

阿里P9專家右軍：以終為始的架構(gòu)設(shè)計(jì)

阿里P8架構(gòu)師：淘寶技術(shù)架構(gòu)從1.0到4.0的架構(gòu)變遷！12頁P(yáng)PT詳解

阿里技術(shù)：如何畫出一張合格的技術(shù)架構(gòu)圖？

螞蟻資深技術(shù)專家王旭：開源項(xiàng)目是如何讓這個(gè)世界更安全的？

阿里資深技術(shù)專家崮德：8 個(gè)影響我職業(yè)生涯的重要技能

儒梟：我看技術(shù)人的成長路徑

阿里高級(jí)技術(shù)專家宋意：平凡人在阿里十年的成長之旅

阿里技術(shù)專家甘盤：淺談雙十一背后的支付寶LDC架構(gòu)和其CAP分析

阿里技術(shù)專家光錐：億級(jí)長連網(wǎng)關(guān)的云原生演進(jìn)之路

阿里云原生張羽辰：服務(wù)發(fā)現(xiàn)技術(shù)選型那點(diǎn)事兒

螞蟻研究員玉伯：做一個(gè)簡單自由有愛的技術(shù)人

阿里高級(jí)技術(shù)專家至簡: Service Mesh 在超大規(guī)模場(chǎng)景下的落地挑戰(zhàn)

阿里巴巴山獵：手把手教你玩轉(zhuǎn)全鏈路監(jiān)控

阿里涉江：你真的會(huì)學(xué)習(xí)嗎？從結(jié)構(gòu)化思維說起

螞蟻金服資深技術(shù)專家經(jīng)國：云原生時(shí)代微服務(wù)的高可用架構(gòu)設(shè)計(jì)

深入分布式緩存之EVCache探秘開局篇

? ?END ? ?? #架構(gòu)師必備#點(diǎn)分享點(diǎn)點(diǎn)贊點(diǎn)在看

總結(jié)

以上是生活随笔為你收集整理的美团技术：复杂环境下落地 Service Mesh 的挑战与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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