本文根據美團基礎架構部服務治理團隊工程師郭繼東在2019 QCon（全球軟體開發大會）上的演講內容整理而成，主要闡述美團大規模治理體系結合 Service Mesh 演進的探索實踐，希望對從事此領域的同學有所幫助。

一、OCTO 現狀分析

OCTO 是美團標準化的服務治理基礎設施，治理能力統一、效能及易用性表現優異、治理能力生態豐富，已廣泛應用於美團各事業線。關於 OCTO 的現狀，可整體概括為：

• 已成為美團高度統一的服務治理技術棧，覆蓋了公司90%的應用，日均呼叫超萬億次。

• 經歷過大規模的技術考驗，覆蓋數萬個服務/數十萬個節點。

• 協同周邊治理生態提供的治理能力較為豐富，包含但不限於 SET 化、鏈路級複雜路由、全鏈路壓測、鑑權加密、限流熔斷等治理能力。

• 一套系統支撐著多元業務，覆蓋公司所有事業線。

目前美團已經具備了相對完善的治理體系，但仍有較多的痛點及挑戰：

• 對多語言支援不夠好。美團技術棧使用的語言主要是 Java，佔比到達80%以上，上面介紹的諸多治理能力也集中在 Java 體系。但美團同時還有其他近10種後臺服務語言在使用，這些語言的治理生態均十分薄弱，同時在多元業務的模式下必然會有增長的多語言需求，為每一種語言都建設一套完善的治理體系成本很高，也不太可能落地。

• 中介軟體和業務繫結在一起，制約著彼此迭代。一般來說，核心的治理能力主要由通訊框架承載，雖然做到了邏輯隔離，但中介軟體的邏輯不可避免會和業務在物理上耦合在一起。這種模式下，中介軟體引入Bug需要所有業務配合升級，這對業務的研發效率也會造成損害；新特性的釋出也依賴業務逐個升級，不具備自主的控制能力。

• 異構治理體系技術融合成本很高。

• 治理決策比較分散。每個節點只能根據自己的狀態進行決策，無法與其他節點協同仲裁。

針對以上痛點，我們考慮依託於 Service Mesh 解決。Service Mesh 模式下會為每個業務例項部署一個 Sidecar 代理，所有進出應用的業務流量統一由 Sidecar 承載，同時服務治理的工作也主要由 Sidecar 執行，而所有的 Sidecar 由統一的中心化控制大腦控制面來進行全域性管控。這種模式如何解決上述四個問題的呢？

• Service Mesh 模式下，各語言的通訊框架一般僅負責編解碼，而編解碼的邏輯往往是不變的。核心的治理功能（如路由、限流等）主要由 Sidecar 代理和控制大腦協同完成，從而實現一套治理體系，所有語言通用。

• 中介軟體易變的邏輯儘量下沉到 Sidecar 和控制大腦中，後續升級中介軟體基本不需要業務配合。SDK 主要包含很輕薄且不易變的邏輯，從而實現了業務和中介軟體的解耦。

• 新融入的異構技術體系可以透過輕薄的 SDK 接入美團治理體系（技術體系難相容，本質是它們各自有獨立的執行規範，在 Service Mesh 模式下執行規範核心內容就是控制面和Sidecar），目前美團線上也有這樣的案例。

• 控制大腦集中掌控了所有節點的資訊，進而可以做一些全域性最優的決策，比如服務預熱、根據負載動態調整路由等能力。

總結一下，在當前治理體系進行 Mesh 化改造可以進一步提升治理能力，美團也將 Mesh 化改造後的 OCTO 定義為下一代服務治理系統 OCTO2.0（內部名字是OCTO Mesh）。

二、技術選型及架構設計

2.1 OCTO Mesh 技術選型

美團的 Service Mesh 建設起步於2018年底，當時所面臨一個核心問題是整體方案最關鍵的考量應該關注哪幾個方面。在啟動設計階段時，我們有一個非常明確的意識：在大規模、同時治理能力豐富的前提下進行 Mesh 改造需要考慮的問題，與治理體系相對薄弱且期望依託於 Service Mesh 豐富治理能力的考量點，還是有非常大的差異的。總結下來，技術選型需要重點關注以下四個方面：

• OCTO 體系已經歷近5年的迭代，形成了一系列的標準與規範，進行 Service Mesh 改造治理體系架構的升級範圍會很大，在確保技術方案可以落地的同時，也要遮蔽技術升級或只需要業務做很低成本的改動。

• 治理能力不能減弱，在保證對齊的基礎上逐漸提供更精細化、更易用的運營能力。

• 能應對超大規模的挑戰，技術方案務必能確保支撐當前量級甚至當前N倍的增量，系統自身也不能成為整個治理體系的瓶頸。

• 儘量與社群保持親和，一定程度上與社群協同演進。

針對上述考量，我們選擇的方式是資料面基於 Envoy 二次開發，控制面自研為主。

資料面方面，當時 Envoy 有機會成為資料面的事實標準，同時 Filter 模式及 xDS 的設計對擴充套件比較友好，未來功能的豐富、效能最佳化也與標準關係較弱。

控制面自研為主的決策需要考量的內容就比較複雜了，總體而言需要考慮如下幾個方面：

• 截止發稿前，美團容器化主要採用富容器的模式，這種模式下強行與 Istio 及 Kubernetes 的資料模型匹配改造成本極高，同時 Istio API也尚未確定。

• 截止發稿前，Istio 在叢集規模變大時較容易出現效能問題，無法支撐美團數萬應用、數十萬節點的的體量，同時數十萬節點規模的 Kubernetes 叢集也需要持續最佳化探索。

• Istio 的功能無法滿足 OCTO 複雜精細的治理需求，如流量錄製回放壓測、更復雜的路由策略等。

• 專案啟動時非容器應用佔比較高，技術方案需要相容存量非容器應用。

2.2 OCTO Mesh 架構設計

上面這張圖展示了 OCTO Mesh 的整體架構。從下至上來看，邏輯上分為業務程式及通訊框架 SDK 層、資料平面層、控制平面層、治理體系協作的所有周邊生態層。

先來重點介紹下業務程式及SDK層、資料平面層：

• OCTO Proxy （資料面Sidecar代理內部叫OCTO Proxy）與業務程式採用1對1的方式部署。

• OCTO Proxy 與業務程式採用 UNIX Domain Socket 做程式間通訊（這裡沒有選擇使用 Istio 預設的 iptables 流量劫持，主要考慮美團內部基本是使用的統一化私有協議通訊，富容器模式沒有用 Kubernetes 的命名服務模型，iptables 管理起來會很複雜，而 iptables 複雜後效能會出現較高的損耗。）；OCTO Proxy 間跨節點採用 TCP 通訊，採用和程式間同樣的協議，保證了客戶端和服務端具備獨立升級的能力。

• 為了提升效率同時減少人為錯誤，我們獨立建設了 OCTO Proxy 管理系統，部署在每個例項上的 LEGO Agent 負責 OCTO Proxy 的保活和熱升級，類似於 Istio 的 Pilot Agent，這種方式可以將人工干預降到較低，提升運維效率。

• 資料面與控制面透過雙向流式通訊。路由部分互動方式是增強語義的 xDS，增強語義是因為當前的 xDS 無法滿足美團更復雜的路由需求；除路由外，該通道承載著眾多的治理功能的指令及配置下發，我們設計了一系列的自定義協議。

控制面（美團內部名稱為Adcore）自研為主，整體分為：Adcore Pilot、Adcore Dispatcher、集中式健康檢查系統、節點管理模組、監控預警模組。此外獨立建設了統一後設資料管理及 Mesh 體系內的服務註冊發現系統 Meta Server 模組。每個模組的具體職責如下：

• Adcore Pilot 是個獨立叢集，模組承載著大部分核心治理功能的管控，相當於整個系統的大腦，也是直接與資料面互動的模組。

• Adcore Dispatcher 也是獨立叢集，該模組是供治理體系協作的眾多子系統便捷接入 Mesh 體系的接入中心。

• 不同於 Envoy 的 P2P 節點健康檢查模式，OCTO Mesh 體系使用的是集中式健康檢查。

• 控制面節點管理系統負責採集每個節點的執行時資訊，並根據節點的狀態做全域性性的最優治理的決策和執行。

• 監控預警系統是保障 Mesh 自身穩定性而建設的模組，實現了自身的可觀測性，當出現故障時能快速定位，同時也會對整個系統做實時巡檢。

• 與Istio 基於 Kubernetes 來做定址和後設資料管理不同，OCTO Mesh 由獨立的 Meta Server 負責 Mesh 自身眾多元資訊的管理和命名服務。

三、關鍵設計解析

大規模治理體系 Mesh 化建設成功落地的關鍵點有：

• 系統水平擴充套件能力方面，可以支撐數萬應用/百萬級節點的治理。

• 功能擴充套件性方面，可以支援各類異構治理子系統融合打通。

• 能應對 Mesh 化改造後鏈路複雜的可用性、可靠性要求。

• 具備成熟完善的 Mesh 運維體系。

圍繞這四點，便可以在系統能力、治理能力、穩定性、運營效率方面支撐美團當前多倍體量的新架構落地。

3.1 大規模系統 Mesh 化系統能力建設

對於社群 Istio 方案，要想實現超大規模應用叢集落地，需要完成較多的技術改造。主要是因為 Istio 水平擴充套件能力相對薄弱，內部冗餘操作較多，整體穩定性建設較為薄弱。針對上述問題，我們的解決思路如下：

• 控制面每個節點並不承載所有治理資料，系統整體做水平擴充套件，在此基礎上提升每個例項的整體吞吐量和效能。

• 當出現機房斷網等異常情況時，可以應對瞬時流量驟增的能力。

• 只做必要的 P2P 模式健康檢查，配合集中式健康檢查進行百萬級節點管理。

按需載入和資料分片主要由 Adcore Pilot 配合 Meta Server 實現。

Pilot 的邏輯架構分為 SessionMgr、Snapshot、Diplomat 三個部分，其中 SessionMgr 管理每個資料面會話的全生命週期、會話的建立、互動及銷燬等一系列動作及流程；Snapshot 維護資料最新的一致性快照，對下將資源的更新同步給 SessionMgr 處理，對上響應各平臺的資料變更通知，進行計算並將存在關聯關係的一組資料做快照快取。Diplomat 模組負責與服務治理系統的眾多平臺對接，只有該模組會與第三方平臺直接產生依賴。

控制面每個 Pilot 節點並不會把整個註冊中心及其他資料都載入進來，而是按需載入自己管控的 Sidecar 所需要的相關治理資料，即從 SessionMgr 請求的應用所負責的相關治理資料，以及該應用關注的對端服務註冊資訊。另外同一個應用的所有 OCTO Proxy 應該由同一個Pilot 例項管控，否則全域性狀態下又容易趨近於全量了。具體是怎麼實現的呢？答案是 Meta Server，自己實現控制面機器服務發現的同時精細化控制路由規則，從而在應用層面實現了資料分片。

Meta Server 管控每個Pilot節點負責應用 OCTO Proxy的歸屬關係。當 Pilot 例項啟動會註冊到 Meta Server，此後定時傳送心跳進行續租，長時間心跳異常會自動剔除。在 Meta Server 內部實現了較為複雜的一致性雜湊策略，會綜合節點的應用、機房、負載等資訊進行分組。當一個 Pilot 節點異常或釋出時，隸屬該 Pilot 的 OCTO Proxy 都會有規律的連線到接替節點，而不會全域性隨機連線對後端註冊中心造成風暴。當異常或釋出後的節點恢復後，劃分出去的 OCTO Proxy 又會有規則的重新歸屬當前 Pilot 例項管理。對於關注節點特別多的應用 OCTO Proxy，也可以獨立部署 Pilot，透過 Meta Server 統一進行路由管理。

Mesh體系的命名服務需要 Pilot 與註冊中心打通，常規的實現方式如左圖所示（以 Zookeeper為例），每個 OCTO Proxy 與 Pilot 建立會話時，作為客戶端角色會向註冊中心訂閱自身所關注的服務端變更監聽器，假設這個服務需要訪問100個應用，則至少需要註冊100個 Watcher 。假設該應用存在1000個例項同時執行，就會註冊 100*1000 = 100000 個 Watcher，超過1000個節點的應用在美團內部還是蠻多的。另外還有很多應用關注的對端節點相同，會造成大量的冗餘監聽。當規模較大後，網路抖動或業務集中釋出時，很容易引發風暴效應把控制面和後端的註冊中心打掛。

針對這個問題，我們採用分層訂閱的方案解決。每個 OCTO Proxy 的會話並不直接與註冊中心或其他的釋出訂閱系統互動，變更的通知全部由 Snapshot 快照層管理。Snapshot 內部又劃分為3層，Data Cache 層對接並快取註冊中心及其他系統的原始資料，粒度是應用；Node Snapshot 層則是保留經過計算的節點粒度的資料；Ability Manager 層內部會做索引和對映的管理，當註冊中心存在節點狀態變更時，會透過索引將變更推送給關注變更的 OCTO Proxy。

對於剛剛提到的場景，隔離一層後1000個節點僅需註冊100個 Watcher，一個 Watcher 變更後僅會有一條變更資訊到 Data Cache 層，再根據索引向1000個 OCTO Proxy 通知，從而極大的降低了註冊中心及 Pilot 的負載。

Snapshot 層除了減少不必要互動提升效能外，也會將計算後的資料格式化快取下來，一方面瞬時大量相同的請求會在快照層被快取擋住，另一方面也便於將存在關聯的資料統一打包到一起，避免併發問題。這裡參考了Envoy-Control-Plane的設計，Envoy-Control-Plane會將包含xDS的所有資料全部打包在一起，而我們是將資料隔離開，如路由、鑑權完全獨立，當路由資料變更時不會去拉取並更新鑑權資訊。

預載入主要目的是提升服務冷啟動效能，Meta Server 的路由規則由我們制定，所以這裡提前在 Pilot 節點中載入好最新的資料，當業務程式啟動時，Proxy 就可以立即從 Snapshot 中獲取到資料，避免了首次訪問慢的問題。

Istio 預設每個 Envoy 代理對整個叢集中所有其餘 Envoy 進行 P2P 健康檢測，當叢集有N個節點時，一個檢測週期內（往往不會很長）就需要做N的平方次檢測，另外當叢集規模變大時所有節點的負載就會相應提高，這都將成為擴充套件部署的極大障礙。

不同於全叢集掃描，美團採用了集中式的健康檢查方式，同時配合必要的P2P檢測。具體實現方式是：由中心服務 Scanner 監測所有節點的狀態，當 Scanner 主動檢測到節點異常或 Pilot 感知連線變化通知 Scanner 掃描確認節點異常時， Pilot 立刻透過 eDS 更新節點狀態給 Proxy，這種模式下檢測週期內僅需要檢測 N 次。Google 的Traffic Director 也採用了類似的設計，但大規模使用需要一些技巧：第一個是為了避免機房自治的影響而選擇了同機房檢測方式，第二個是為了減少中心檢測機器因自己 GC 或網路異常造成誤判，而採用了Double Check 的機制。

此外除了集中健康檢查，還會對頻繁失敗的對端進行心跳探測，根據探測結果進行降權或摘除操作提升成功率。

3.2 異構治理系統融合設計

OCTO Mesh 需要對齊當前體系的核心治理能力，這就不可避免的將 Mesh 與治理生態的所有周邊子系統打通。Istio 和 Kubernetes 將所有的資料儲存、釋出訂閱機制都依賴 Etcd 統一實現，但美團的10餘個治理子系統功能各異、儲存各異、釋出訂閱模式各異，呈現出明顯的異構特徵，如果接入一個功能就需要平臺進行儲存或其他大規模改造，這樣是完全不可行的。一個思路是由一個模組來解耦治理子系統與 Pilot ，這個模組承載所有的變更並將這個變更下發給 Pilot，但這種方式也有一些問題需要考慮，之前介紹每個 Pilot 節點關注的資料並不同，而且分片的規則也可能時刻變化，有一套機制能將訊息傳送給關注的Pilot節點。

總體而言需要實現三個子目標：打通所有系統，治理能力對齊；快速應對未來新系統的接入；變更傳送給關注節點。我們解法是：獨立的統一接入中心，遮蔽所有異構系統的儲存、釋出訂閱機制；Meta Server 承擔實時分片規則的後設資料管理。

具體執行機制如上圖所示：各系統變更時使用客戶端將變更通知推送到訊息佇列，只推送變更但不包含具體值（當Pilot接收到變更通知會主動Fetch全量資料，這種方式一方面確保Mafka的訊息足夠小，另一方面多個變更不需要在佇列中保序解決版本衝突問題。）；Adcore Dispatcher 消費資訊並根據索引將變更推送到關注的 Pilot 機器，當 Pilot 管控的 Proxy 變更時會同步給 Meta Server，Meta Server 實時將索引關係更新並同步給Dispatcher。為了解決 Pilot 與應用的對映變更間隙出現訊息丟失，Dispatcher 使用回溯檢驗變更丟失的模式進行補償，以提升系統的可靠性。

3.3 穩定性保障設計

Service Mesh 改造的系統避不開“新”和“複雜”兩個特徵，其中任意一個特徵都可能會給系統帶來穩定性風險，所以必須提前做好整個鏈路的可用性及可靠性建設，才能遊刃有餘的推廣。美團主要是圍繞控制故障影響範圍、異常實時自愈、可實時回滾、柔性可用、提升自身可觀測性及迴歸能力進行建設。

這裡單獨介紹控制面的測試問題，這塊業界可借鑑的內容不多。xDS 雙向通訊比較複雜，很難像傳統介面那樣進行功能測試，定製多個 Envoy 來模擬資料面進行測試成本也很高。我們開發了 Mock-Sidecar 來模擬真正資料面的行為來對控制面進行測試，對於控制面來說它跟資料面毫無區別。Mock-Sidecar 把資料面的整體行為拆分為一個個可組合的 Step，機制與策略分離。執行引擎就是所謂的機制，只需要按步驟執行 Step 即可。YAML 檔案就是 Step 的組合，用於描述策略。我們人工構造各種 YAML 來模擬真正 Sidecar 的行為，對控制面進行迴歸驗證，同時不同 YAML 檔案執行是並行的，可以進行壓力測試。

3.4 運維體系設計

為了應對未來百萬級 Proxy 的運維壓力，美團獨立建設了 OCTO Proxy 運維繫統 LEGO，除 Proxy 保活外也統一集中控制發版。具體的操作流程是：運維人員在 LEGO 平臺發版，確定發版的範圍及版本，新版本資源內容上傳至資源倉庫，並更新規則及發版範圍至 DB，發升級指令下發至所要釋出的範圍，收到發版命令機器的 LEGO Agent 去資源倉庫拉取要更新的版本（中間如果有失敗，會有主動 Poll 機制保證升級成功），新版本下載成功後，由 LEGO Agent 啟動新版的 OCTO Proxy。

四、總結與展望

4.1 經驗總結

• 服務治理建設應該圍繞體系標準化、易用性、高效能三個方面開展。

• 大規模治理體系 Mesh 化應該關注以下內容：

• 適配公司技術體系比新潮技術更重要，重點關注容器化 & 治理體系相容打通。

• 建設系統化的穩定性保障體系及運維體系。

• OCTO Mesh 控制面4大法寶：Meta Server 管控 Mesh 內部服務註冊發現及後設資料、分層分片設計、統一接入中心解耦並打通 Mesh 與現有治理子系統、集中式健康檢查。

4.2 未來展望

未來，我們會繼續在 OCTO Mesh 道路上探索，包括但不限於以下幾個方面：

• 完善體系：逐漸豐富的 OCTO Mesh 治理體系，探索其他流量型別，全面提升服務治理效率。

• 大規模落地：持續打造健壯的 OCTO Mesh 治理體系，穩步推動在公司的大規模落地。

• 中心化治理能力探索：新治理模式的中心化管控下，全域性最優治理能力探索。

作者簡介

繼東，基礎架構部服務治理團隊工程師。