本文根據美團基礎架構部服務治理團隊工程師郭繼東在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 治理體系，穩步推動在公司的大規模落地。
• 中心化治理能力探索：新治理模式的中心化管控下，全局最優治理能力探索。

作者簡介

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

招聘信息

美團點評基礎架構團隊誠招高級、資深技術專家，Base 北京、上海。我們致力于建設美團點評全公司統一的高并發高性能分布式基礎架構平臺，涵蓋數據庫、分布式監控、服務治理、高性能通信、消息中間件、基礎存儲、容器化、集群調度等基礎架構主要的技術領域。歡迎有興趣的同學投送簡歷到 tech@meituan.com（郵件標題注明：美團點評基礎架構團隊）。

總結

以上是生活随笔為你收集整理的美团下一代服务治理系统 OCTO 2.0 的探索与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。