【實踐案例】複雜環境下落地Service Mesh的挑戰與實踐

OCTO是美團内部的服務治理平台，包含服務通信架構、命名服務、服務資料中心和使用者管理平台等元件，為公司内全部服務提供了整套的服務治理方案和統一的服務治理體驗。我們在之前的幾篇文章中分别從不同的角度介紹了OCTO平台的建設情況。包括：

• 《美團命名服務的挑戰與演進》介紹了美團命名服務（MNS）從1.0到2.0演進的初衷、實作方案以及落地的效果，并介紹了命名服務作為一個技術中台元件，對業務的重要價值以及推動業務更新的一些成果。
• 《美團OCTO萬億級資料中心計算引擎技術解析》介紹了美團自研的 OCTO資料中心計算引擎的演進曆程及架構設計，同時詳細地介紹其全面提升計算能力、吞吐能力、降低運維成本所采用的各項技術方案。
• 《團大規模微服務通信架構及治理體系OCTO核心元件開源》介紹了OCTO的核心元件OCTO-RPC（JAVA通信架構）、OCTO-NS（命名服務）和OCTO-Portal（使用者管理平台）的開源情況。
• 《複雜環境下落地Service Mesh的挑戰與實踐》從更高的視角介紹了美團目前的服務治理系統的發展史、所面臨的困境和優化思路。對Service Mesh在美團大規模複雜服務場景下的落地做了深入的分析。
• 《OCTO 2.0：美團基于Service Mesh的服務治理系統詳解》介紹在Service Mesh化演進方面的工作，主要從資料面的角度，詳細介紹各項技術方案的設計思路

在私有雲叢集環境下建設 Service Mesh ，往往需要對現有技術架構做較大範圍的改造，同時會面臨諸如相容困難、規模化支撐技術挑戰大、推廣困境多等一系列複雜性問題。本文會系統性地講解在美團在落地 Service Mesh 過程中，我們面臨的一些挑戰及實踐經驗，希望能對大家有所啟發或者幫助。

1. 美團服務治理建設進展

1.1 服務治理發展史

首先講一下 OCTO，此前美團技術團隊公衆号也分享過很相關的文章，它是美團标準化的服務治理基礎設施，現應用于美團所有事業線。OCTO 的治理生态非常豐富，性能及易用性表現也很優異，可整體概括為 3 個特征：

1. 屬于公司級的标準化基礎設施。技術棧高度統一，覆寫了公司 90% 以上的應用，日均調用量達數萬億次。
2. 經曆過較大規模的技術考驗。覆寫數萬個服務、數十萬個節點。
3. 治理能力豐富。協同周邊治理生态，實作了 SET 化、鍊路級複雜路由、全鍊路壓測、鑒權加密、限流熔斷等治理能力。

回顧美團服務治理體系的發展史，曆程整體上劃分為四個階段：

1. 第一階段是基礎治理能力統一。實作通信架構及注冊中心的統一，由統一的治理平台支撐節點管理、流量管理、監控預警等營運能力。
2. 第二階段重點提升性能及易用性。4 核 4GB 環境下使用 1KB 資料進行 echo 測試，QPS 從 2 萬提升至接近 10 萬，99 分位線 1ms；也建設了分布式鍊路追蹤、分階段耗時精細埋點等功能。
3. 第三階段是全方位豐富治理能力。落地了全鍊路壓測平台、性能診斷優化平台、穩定性保障平台、鑒權加密等一系列平台，也實作了鍊路級别的流量治理，如全鍊路灰階釋出等。
4. 第四階段是建設了跨地域的容災及擴充能力。在每天數千萬訂單量級下實作了單元化，也實作了所有 PaaS 層元件及核心存儲系統的打通。

1.2  服務治理體系的困境

目前，美團已具備了較完善的治理體系，但仍有較多的痛點及挑戰。大的背景是公司業務蓬勃發展，業務愈發多元化，治理也愈發精細化，這帶來了較多新的問題：

1. 業務與中間件強耦合，制約彼此疊代。當中間件引入 Bug，可能成百上千、甚至數千個業務需要做配合更新，中間件的新特性也依賴業務更新後才能使用，成本很高。
2. 中間件版本碎片化嚴重。釋出出去的元件基本托管在業務側，很難統一進行管控，這也頻繁造成業務多類的問題。
3. 異構體系融合難。新融入公司的技術體系往往與美團不相容，治理體系打通的成本很高，難度也很大。此前，美團與大衆點評打通治理，不包含業務遷移，就曆時 1 年半的時間；近期，摩拜使用的 gRPC 架構也無法與系統進行通信，但打通迫在眉睫。
4. 非 Java 語言治理體系能力弱，多個主流語言無官方 SDK。多元業務場景下，未來多語言也是個趨勢，比如在機器學習領域，Python 語言不太可能被其他語言完全代替。

2. 服務治理體系優化的思路與挑戰

2.1 優化思路

總結來看，OCTO 在服務層實作了統一抽象來支撐業務發展，但它并未解決這層架構可以獨立演進的問題。

• 1.2節中問題1與問題2的本質是“耦合”，
• 問題3與問題4的本質是“缺乏标準服務治理運作時”。

在理想的架構中，異構語言、異構治理體系可以共用統一的标準治理運作時，僅在業務使用的 SDK 部分有輕微差異。是以，我們整體的優化思路分為三步：隔離解耦，在隔離出的基礎設施層建設标準化治理運作時，标準之上建體系。

上述解決方案所對應的新架構模式下，各業務程序會附屬一個 Proxy 程序，SDK 發出以及接收的流量均會被附屬的 Proxy 攔截。像限流、路由等治理功能均由 Proxy 和中心化的控制大腦完成，并由控制面對接所有治理子系統內建。這種模式下 SDK 很輕薄，異構的語言、異構的治理體系就很容易互通，進而實作了實體解耦，業界将這種模式稱為 Service Mesh（其中 Proxy 被稱為資料面、中心化控制大腦被稱為控制面）。

2.2 複雜性挑戰

美團在實踐中所面臨的複雜性劃主要包括以下4類：

1. 相容性：技術改造涉及範圍較大，一方面需要通過保證現有通信方式及平台使用方式不變，進而來保障業務研發效率，另一方面也要解決運作載體多樣性、運維體系相容等問題。
2. 異構性：第一是多語言互通問題；第二是打通治理體系内的衆多治理子系統，像服務鑒權、注冊中心等系統的存儲及釋出訂閱機制都是不同的；第三是快速打通新融入公司的異構治理體系。
3. 大規模支撐：出于性能方面考慮，開源 Istio 等産品不宜直接應用于大規模的生産環境，美團控制面需具備百萬級連結下高吞吐、低延遲、高精确的系統能力。
4. 重交易型業務容錯性低：交易型業務場景下，業務對 Service Mesh 的性能、穩定性往往持懷疑态度；美團基礎架構團隊也強調在業務價值導向下，基于實際業務價值進行營運推廣，而不是采用從上至下的偏政策性推廣方式。

3. 美團落地 Service Mesh 的解決方案

3.1 整體架構

美團采用資料面基于 Envoy 二次開發、控制面自研為主、SDK 協同更新的方案（内部項目名是 OCTO Mesh ）。架構簡介如下：

（1）各語言輕薄的 SDK 與 Proxy 通過 UDS（Unix Domain Socket）互動，主要出發點是考慮到相比透明流量劫持，UDS 性能與可運維性更好。

（2）控制面與 Proxy 通過雙向流通信，控制面與治理生态的多個子系統互動，并将計算處理過的治理資料及政策資料下發給 Proxy 執行，協同配合完成路由、限流等所有核心治理功能。

（3）控制面内部的 5 個子產品都是自研的獨立服務。

• Pilot 承載核心治理能力，與 Proxy 直接互動。
• Dispatcher 負責屏蔽異構子系統差異。
• 集中式健康檢查管理節點狀态。
• Config Server 管理 Mesh 體系内相關的政策，并将 Pilot 有狀态的部分盡量遷移出來。
• 監控及巡檢系統負責提升穩定性。

（5）自研了的 Meta Server 系統實作 Mesh 體系内部的節點注冊和尋址，通過管理控制面與資料面的連結關系，也實作了按事業群隔離、水準擴充等能力。

3.2 相容性解決方案

相容性的目标及特征用一句話來總結就是：業務接入無感覺。為此，我們做了以下三件事情：

(1) 與現有基礎設施及治理體系相容

• 将 Service Mesh 與 OCTO 深度打通，確定各治理子系統的使用方式都不變。
• 運作載體方面，同時支援容器、虛拟機、實體機。
• 打通運維體系，保證服務治理基礎設施處于可管理、可監測的狀态。

(2) 協定相容

• 服務間調用往往是多對多的關系，一般調用端與服務端無法同時更新，為支援 Mesh 與非 Mesh 的互通，增強後的協定對業務完全透明。
• 與語義相關的所有内容（比如異常等），均在 SDK 與 Proxy 之間達成共識，保證相容。
• 無法在控制面及資料面中實作的能力，在 SDK 中執行并通過上下文傳遞給 Proxy，保障功能完全對齊，當然這種情況應該盡量避免的。

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

• 基于 UDS 通信必然需要業務更新一次 SDK 版本，我們在 2020 年初時預先釋出早做部署，確定目前大部分業務已經更新到新版本，但預設仍是不開啟 Mesh 的狀态。
• 在可視化平台上面通過開關操作，幾乎無成本實作從 Mesh 模式與非 Mesh 模式的切換，并具備實時生效的能力。

3.3 異構性解決方案

異構性的目标及特征用一句話總結就是：标準化服務治理運作時。具體可拆分為3個子目标：

• 标準化美團内部 6 種語言的治理體系。
• 架構層面由控制面統一對接各個治理子系統，屏蔽注冊中心、鑒權、限流等系統具體實作機制的異構性。
• 支援摩拜及未來新融入公司的異構治理體系與公司整體的快速融合。

針對上述3個子目标，我們所采取的方案如下：

• 将資料面 + 控制面定義為标準化的服務治理運作時，在标準運作時内打通所有治理能力。
• 建設統一接入中心系統 Dispatcher ，并由其對接并屏蔽治理子系統的異構性，進而實作外部系統的差異對 Pilot 透明；下圖中 Dispatcher 與 Pilot 直接互動，Meta Server 的作用是避免廣播降低備援。
• 重構或從零建設 SDK，目前使用的 6 種語言 SDK 均已落地并使用。
• 異構語言、異構體系均使用增強的統一協定互動，實作互通。

通過 Service Mesh 實作體系融合的前後對比如下：

• 引入 Service Mesh 前，單車向公司的流量以及公司向單車的流量，均是由中間的 adaptor 單點服務承接。除穩定性有較大隐患外，所有互動邏輯均需要開發兩份代碼，效率較差。
• 引入 Service Mesh後，在一套服務治理設施内打通并直接互動，消除了中心 adaptor 帶來的穩定性及研發效率方面的缺陷；此外整個打通在1個月内完成，異構體系融合效率很高。

通過上述方案，針對異構性方面取得了較好的效果：

• 标準化 6 種語言治理體系，非 Java 語言的核心治理能力基本對齊 Java；新語言也很容易融入，提供的官方 Python 語言、Golang 語言的通信架構新版本（依托于 OCTO Mesh），開發成本均控制在1個月左右。
• 支援異構治理子系統通過統一接入中心快速融入，架構簡潔、擴充性強。
• 支援異構治理體系快速融合并在單車側落地，異構治理體系打通成本也從 1.5 年降低到 1 個月。

3.4 規模化解決方案

3.4.1 開源 Istio 問題分析

規模化的目标及特征用一句話總結是：具備支撐數萬服務、百萬節點體量的系統能力，并支援水準擴充。挑戰主要有3個：

• 美團體量是最流行開源産品 Istio 上限的上千倍。
• 極高的實時性、準确性要求；配置下發錯誤或丢失會直接引發流量異常。
• 起步較早，業界參考資訊很少。

經過對 Istio 架構進行深入分析，我們發現核心問題聚焦在以下3個瓶頸點：

• 每個控制面執行個體有 ETCD 存儲系統的全部資料，無法水準擴充。
• 每個 Proxy 連結相當于獨立與 ETCD 互動，而同一個服務的 Proxy 請求内容都相同，獨立互動有大量的 I/O 備援。當 Proxy 批量發版或網絡抖動時，瞬時風暴很容易壓垮控制面及 ETCD。
• 每個節點都會探活所有其他節點。10 萬節點規模的叢集，1 個檢測周期有 100 億次探活，會引發網絡風暴。

3.4.2 措施一：橫向資料分片

針對 Istio 控制面各執行個體承載全叢集資料的問題，對應的措施是通過橫向邏輯資料分片支援擴充性，具體方案設計如下：

• Proxy 啟動時會去向 Meta Server 系統請求需要連接配接的 Pilot IP，Meta Server 将相同服務的 Proxy 盡量落到同一個控制面節點（内部政策更為複雜，還要考慮地域、負載等情況），這樣每個 Pilot 執行個體按需加載而不必承載所有資料。
• 控制面節點異常或釋出更新時，其所管理的 Proxy 也會有規律的遷移，恢複後在一定時間後還會接管其負責的 Proxy，進而實作了會話粘滞，也就實作邏輯上面的資料分片。

通過管理連結關系實作了按事業群隔離、按服務灰階等平台能力，最關鍵的還是解決了 Mesh 體系水準擴充的問題。

3.4.3 措施二：縱向分層訂閱

針對 Istio 獨立管理各 Proxy 連結的 I/O 備援問題，對應的措施是通過分層訂閱減少備援 I/O。Proxy 不直接與存儲等系統對接，而是在中間經過一系列的處理，關鍵點有兩個：

• 關鍵點 1：基于快照緩存 + 索引的機制來減少 ZK watcher 同步。以注冊中心為例，正常實作方式下，如果每個 Proxy 關注 100 個節點，1 萬個節點就會注冊 100 萬個 watcher，相同服務的 Proxy 所關注内容是相同的，另外不同服務 Proxy 所關注的也有很多交集，其中包含大量的備援。分層訂閱模式下，Proxy 不與注冊中心直接互動，通過中間的快照緩存與分層，確定每個 Pilot 執行個體中 ZK 相同路徑的監聽最多隻用1個 watcher，擷取到 watcher 通知後，Pilot 根據内部的快照緩存 + 索引向所有關注者分發，大大降低了備援。
• 關鍵點 2：治理能力層及會話管理層實作了類似于 I/O 多路複用能力，通過并發提升吞吐。

結果方面有效應對了網絡抖動或批量發版的瞬間風暴壓力，壓測單 Pilot 執行個體可以承載 6 萬以上的連結，時延 TP99 線 < 2.3ms、資料零丢失。

3.4.4 措施三：集中式健康檢測

針對大規模叢集内指數級膨脹的節點間健康監測次數，對應的措施是摒棄了 P2P 檢測模式，我們參考并優化了 Google 的 Traffic Drector 中心化管理的健康檢測模式。這種模式下檢測次數大大減少，一個周期内 10 萬節點叢集的檢測次數，從 100 億次下降到 10 萬次。

此外，當 Pilot 感覺到 Proxy 異常時，會立即通知中心化健康檢測系統啟動檢測，而不是等待檢測周期視窗的到來，這可以有效提升業務調用的成功率。

3.5 交易型場景困境下的解決方案

3.5.1 業務屬性分析

美團内部業務線較多，包括外賣、配送、酒店、旅遊、單車、團購等，其中絕大多數業務都帶有交易屬性，交易鍊路上一個流量異常就可能影響到訂單。業務系統對新技術領域的探索往往比較慎重，期望在新技術充分驗證後再啟動試點，是以除小語種及亟待與公司打通的單車業務外，推廣的難度是非常大的。此外，基礎架構部秉承“以客戶為中心”的原則，研發、運維、測試人員均是我們的“客戶”，是以技術更新會重點從業務價值入手，并非簡單依靠從上至下的政策推動力。

是以，我們對外的承諾是：通信足夠快、系統足夠穩定、接入足夠平滑高效。

3.5.2 精細化營運體系建設

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

• 尋找具備強訴求的業務試點，客觀來說，美團技術棧内這類業務數量非常有限。
• 尋求标杆核心業務試點，充分驗證後推廣給其他業務，但效果并不理想，與業務穩定性的訴求并不比對。

針對上述困境，我們進行深度思考後建立了一個精細化的營運體系：

• 服務接入 Mesh 前。基于 SOA 分級将服務劃分為非核心與核心兩類，先針對非核心服務以及所有服務的線下環境進行重點突破，實作了在廣泛的業務場景下，全面且充分的驗證系統能力。
• 服務接入 Mesh 中。營運系統通過校驗 SDK 版本、運作時環境等資訊，自動篩選出滿足條件的服務，業務同學隻需要在平台上做（1）開啟開關、（2）選擇節點（3）指定 Mesh 流量比例三個步驟，就完成了到 Mesh 模式的切換，不需代碼改造也不需釋出服務，整個過程基本在 1 分鐘左右完成；此外，通過與 IM 工具深度關聯，提升了推廣與資料營運的效率。
• 服務接入 Mesh 後。一方面，業務側包括架構側的營運有詳細的資料名額做對比參考；另一方面，營運系統支援預先設定穩定性政策并做準實時的檢測，當某個接入服務 Mesh 模式異常時，即時自動切換回非 Mesh 模式。

營運體系具備 “接入過程無感”、“精細化流量粒度灰階”、“異常自動復原恢複” 三個核心能力，在營運體系建設後推廣營運較為順利，目前線上接入的 600+ 服務、線下接入的 3500+ 服務中，90% 以上是依托營運平台接入 Mesh 的。

3.5.3 通信性能優化

在性能損耗優化這個方向，除使用 UDS 規避網絡棧外，我們也通過增量聚合下發、序列化優化兩個措施減少不必要的解包，提升了通信性能。

經過壓測，去除非核心功能在 2 核 4G 環境用 1KB 資料做 echo 測試，QPS 在 34000 以上，一跳平均延遲 0.207ms，時延TP99 線 0.4ms 左右。

3.5.4 流量多級保護

美團落地 Service Mesh 在穩定性保障方面建設投入較多，目前尚無 Service Mesh 引發的故障，具體包含三個方面

（1）首先做了流量多級保護

• 一方面，當 Proxy 不可用時，流量會自動 fallback 到非 Mesh 模式；另一方面，支援最精細支援按單節點的 1⁄1000 比例灰階。下圖是具體的互動流程，當然，這兩個特性與 Service Mesh 的最終形态是沖突的，隻是作為系統建設初期優先保證業務穩定性的過渡性方案，長期來看必然是要去除的（包括美團一些核心服務已經完全去除）。
• 基于 FD 遷移 + SDK 配合協定互動，實作 Proxy 無損熱重新開機的能力。

（2）控制面下發錯誤配置比停發配置的後果更為嚴重，我們建設了應用層面及系統層面的周期巡檢，從端到端的應用視角驗證正确性，避免或減少因變更引發的異常。

（3）系統互動方面，通過限流、熔斷對中心化控制面做服務保護；系統内柔性可用，當控制面全部異常時，緩存機制也能協助 Proxy 在一定時間内可用。

4. 總結

本文系統性的介紹美團在 Service Mesh 落地程序中面臨的“相容性”、“異構性”、“規模化”、“交易屬性業務容錯性低”這四類複雜性挑戰，針對上述挑戰，我們也詳細介紹了大規模私有雲叢集場景下的優化思考及實踐方案。

基于上述實踐，目前美團線上落地服務數超過 600，線下服務數超過 3500+，初步驗證了模式的可行性。短期價值方面，我們支援了摩拜等異構治理體系的快速融合、多語言治理能力的統一；長期價值仍需在實踐中繼續探索與驗證，但在标準化服務治理運作時并與業務解耦、中心化管控下更豐富的治理能力輸出兩個方面，是非常值得期待的。