本文根據(jù)美團(tuán)基礎(chǔ)架構(gòu)部服務(wù)治理團(tuán)隊工程師郭繼東在2019 QCon（全球軟件開發(fā)大會）上的演講內(nèi)容整理而成，主要闡述美團(tuán)大規(guī)模治理體系結(jié)合 Service Mesh 演進(jìn)的探索實(shí)踐，希望對從事此領(lǐng)域的同學(xué)有所幫助。

一、OCTO 現(xiàn)狀分析

OCTO 是美團(tuán)標(biāo)準(zhǔn)化的服務(wù)治理基礎(chǔ)設(shè)施，治理能力統(tǒng)一、性能及易用性表現(xiàn)優(yōu)異、治理能力生態(tài)豐富，已廣泛應(yīng)用于美團(tuán)各事業(yè)線。關(guān)于 OCTO 的現(xiàn)狀，可整體概括為：

• 已成為美團(tuán)高度統(tǒng)一的服務(wù)治理技術(shù)棧，覆蓋了公司90%的應(yīng)用，日均調(diào)用超萬億次。
• 經(jīng)歷過大規(guī)模的技術(shù)考驗(yàn)，覆蓋數(shù)萬個服務(wù)/數(shù)十萬個節(jié)點(diǎn)。
• 協(xié)同周邊治理生態(tài)提供的治理能力較為豐富，包含但不限于 SET 化、鏈路級復(fù)雜路由、全鏈路壓測、鑒權(quán)加密、限流熔斷等治理能力。
• 一套系統(tǒng)支撐著多元業(yè)務(wù)，覆蓋公司所有事業(yè)線。

目前美團(tuán)已經(jīng)具備了相對完善的治理體系，但仍有較多的痛點(diǎn)及挑戰(zhàn)：

• 對多語言支持不夠好。美團(tuán)技術(shù)棧使用的語言主要是 Java，占比到達(dá)80%以上，上面介紹的諸多治理能力也集中在 Java 體系。 但美團(tuán)同時還有其他近10種后臺服務(wù)語言在使用，這些語言的治理生態(tài)均十分薄弱，同時在多元業(yè)務(wù)的模式下必然會有增長的多語言需求，為每一種語言都建設(shè)一套完善的治理體系成本很高，也不太可能落地。
• 中間件和業(yè)務(wù)綁定在一起，制約著彼此迭代。一般來說，核心的治理能力主要由通信框架承載，雖然做到了邏輯隔離，但中間件的邏輯不可避免會和業(yè)務(wù)在物理上耦合在一起。這種模式下，中間件引入Bug需要所有業(yè)務(wù)配合升級，這對業(yè)務(wù)的研發(fā)效率也會造成損害；新特性的發(fā)布也依賴業(yè)務(wù)逐個升級，不具備自主的控制能力。
• 異構(gòu)治理體系技術(shù)融合成本很高。
• 治理決策比較分散。每個節(jié)點(diǎn)只能根據(jù)自己的狀態(tài)進(jìn)行決策，無法與其他節(jié)點(diǎn)協(xié)同仲裁。

針對以上痛點(diǎn)，我們考慮依托于 Service Mesh 解決。Service Mesh 模式下會為每個業(yè)務(wù)實(shí)例部署一個 Sidecar 代理，所有進(jìn)出應(yīng)用的業(yè)務(wù)流量統(tǒng)一由 Sidecar 承載，同時服務(wù)治理的工作也主要由 Sidecar 執(zhí)行，而所有的 Sidecar 由統(tǒng)一的中心化控制大腦控制面來進(jìn)行全局管控。這種模式如何解決上述四個問題的呢？

• Service Mesh 模式下，各語言的通信框架一般僅負(fù)責(zé)編解碼，而編解碼的邏輯往往是不變的。核心的治理功能（如路由、限流等）主要由 Sidecar 代理和控制大腦協(xié)同完成，從而實(shí)現(xiàn)一套治理體系，所有語言通用。
• 中間件易變的邏輯盡量下沉到 Sidecar 和控制大腦中，后續(xù)升級中間件基本不需要業(yè)務(wù)配合。SDK 主要包含很輕薄且不易變的邏輯，從而實(shí)現(xiàn)了業(yè)務(wù)和中間件的解耦。
• 新融入的異構(gòu)技術(shù)體系可以通過輕薄的 SDK 接入美團(tuán)治理體系（技術(shù)體系難兼容，本質(zhì)是它們各自有獨(dú)立的運(yùn)行規(guī)范，在 Service Mesh 模式下運(yùn)行規(guī)范核心內(nèi)容就是控制面和Sidecar），目前美團(tuán)線上也有這樣的案例。
• 控制大腦集中掌控了所有節(jié)點(diǎn)的信息，進(jìn)而可以做一些全局最優(yōu)的決策，比如服務(wù)預(yù)熱、根據(jù)負(fù)載動態(tài)調(diào)整路由等能力。

總結(jié)一下，在當(dāng)前治理體系進(jìn)行 Mesh 化改造可以進(jìn)一步提升治理能力，美團(tuán)也將 Mesh 化改造后的 OCTO 定義為下一代服務(wù)治理系統(tǒng) OCTO2.0（內(nèi)部名字是OCTO Mesh）。

二、技術(shù)選型及架構(gòu)設(shè)計

2.1 OCTO Mesh 技術(shù)選型

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

• OCTO 體系已經(jīng)歷近5年的迭代，形成了一系列的標(biāo)準(zhǔn)與規(guī)范，進(jìn)行 Service Mesh 改造治理體系架構(gòu)的升級范圍會很大，在確保技術(shù)方案可以落地的同時，也要屏蔽技術(shù)升級或只需要業(yè)務(wù)做很低成本的改動。
• 治理能力不能減弱，在保證對齊的基礎(chǔ)上逐漸提供更精細(xì)化、更易用的運(yùn)營能力。
• 能應(yīng)對超大規(guī)模的挑戰(zhàn)，技術(shù)方案務(wù)必能確保支撐當(dāng)前量級甚至當(dāng)前N倍的增量，系統(tǒng)自身也不能成為整個治理體系的瓶頸。
• 盡量與社區(qū)保持親和，一定程度上與社區(qū)協(xié)同演進(jìn)。

針對上述考量，我們選擇的方式是數(shù)據(jù)面基于 Envoy 二次開發(fā)，控制面自研為主。

數(shù)據(jù)面方面，當(dāng)時 Envoy 有機(jī)會成為數(shù)據(jù)面的事實(shí)標(biāo)準(zhǔn)，同時 Filter 模式及 xDS 的設(shè)計對擴(kuò)展比較友好，未來功能的豐富、性能優(yōu)化也與標(biāo)準(zhǔn)關(guān)系較弱。

控制面自研為主的決策需要考量的內(nèi)容就比較復(fù)雜了，總體而言需要考慮如下幾個方面：

• 截止發(fā)稿前，美團(tuán)容器化主要采用富容器的模式，這種模式下強(qiáng)行與 Istio 及 Kubernetes 的數(shù)據(jù)模型匹配改造成本極高，同時 Istio API也尚未確定。
• 截止發(fā)稿前，Istio 在集群規(guī)模變大時較容易出現(xiàn)性能問題，無法支撐美團(tuán)數(shù)萬應(yīng)用、數(shù)十萬節(jié)點(diǎn)的的體量，同時數(shù)十萬節(jié)點(diǎn)規(guī)模的 Kubernetes 集群也需要持續(xù)優(yōu)化探索。
• Istio 的功能無法滿足 OCTO 復(fù)雜精細(xì)的治理需求，如流量錄制回放壓測、更復(fù)雜的路由策略等。
• 項目啟動時非容器應(yīng)用占比較高，技術(shù)方案需要兼容存量非容器應(yīng)用。

2.2 OCTO Mesh 架構(gòu)設(shè)計

上面這張圖展示了 OCTO Mesh 的整體架構(gòu)。從下至上來看，邏輯上分為業(yè)務(wù)進(jìn)程及通信框架 SDK 層、數(shù)據(jù)平面層、控制平面層、治理體系協(xié)作的所有周邊生態(tài)層。

先來重點(diǎn)介紹下業(yè)務(wù)進(jìn)程及SDK層、數(shù)據(jù)平面層：

• OCTO Proxy （數(shù)據(jù)面Sidecar代理內(nèi)部叫OCTO Proxy）與業(yè)務(wù)進(jìn)程采用1對1的方式部署。
• OCTO Proxy 與業(yè)務(wù)進(jìn)程采用 UNIX Domain Socket 做進(jìn)程間通信（這里沒有選擇使用 Istio 默認(rèn)的 iptables 流量劫持，主要考慮美團(tuán)內(nèi)部基本是使用的統(tǒng)一化私有協(xié)議通信，富容器模式?jīng)]有用 Kubernetes 的命名服務(wù)模型，iptables 管理起來會很復(fù)雜，而 iptables 復(fù)雜后性能會出現(xiàn)較高的損耗。）；OCTO Proxy 間跨節(jié)點(diǎn)采用 TCP 通信，采用和進(jìn)程間同樣的協(xié)議，保證了客戶端和服務(wù)端具備獨(dú)立升級的能力。
• 為了提升效率同時減少人為錯誤，我們獨(dú)立建設(shè)了 OCTO Proxy 管理系統(tǒng)，部署在每個實(shí)例上的 LEGO Agent 負(fù)責(zé) OCTO Proxy 的保活和熱升級，類似于 Istio 的 Pilot Agent，這種方式可以將人工干預(yù)降到較低，提升運(yùn)維效率。
• 數(shù)據(jù)面與控制面通過雙向流式通信。路由部分交互方式是增強(qiáng)語義的 xDS，增強(qiáng)語義是因?yàn)楫?dāng)前的 xDS 無法滿足美團(tuán)更復(fù)雜的路由需求；除路由外，該通道承載著眾多的治理功能的指令及配置下發(fā)，我們設(shè)計了一系列的自定義協(xié)議。

控制面（內(nèi)部名字是Adcore）自研為主，整體分為：Adcore Pilot、Adcore Dispatcher、集中式健康檢查系統(tǒng)、節(jié)點(diǎn)管理模塊、監(jiān)控預(yù)警模塊。此外獨(dú)立建設(shè)了統(tǒng)一元數(shù)據(jù)管理及 Mesh 體系內(nèi)的服務(wù)注冊發(fā)現(xiàn)系統(tǒng) Meta Server 模塊。每個模塊的具體職責(zé)如下：

• Adcore Pilot 是個獨(dú)立集群，模塊承載著大部分核心治理功能的管控，相當(dāng)于整個系統(tǒng)的大腦，也是直接與數(shù)據(jù)面交互的模塊。
• Adcore Dispatcher 也是獨(dú)立集群，該模塊是供治理體系協(xié)作的眾多子系統(tǒng)便捷接入 Mesh 體系的接入中心。
• 不同于 Envoy 的 P2P 節(jié)點(diǎn)健康檢查模式，OCTO Mesh 體系使用的是集中式健康檢查。
• 控制面會節(jié)點(diǎn)管理系統(tǒng)負(fù)責(zé)采集每個節(jié)點(diǎn)的運(yùn)行時信息，并根據(jù)節(jié)點(diǎn)的狀態(tài)做全局性的最優(yōu)治理的決策和執(zhí)行。
• 監(jiān)控預(yù)警系統(tǒng)是保障 Mesh 自身穩(wěn)定性而建設(shè)的模塊，實(shí)現(xiàn)了自身的可觀測性，當(dāng)出現(xiàn)故障時能快速定位，同時也會對整個系統(tǒng)做實(shí)時巡檢。
• 與Istio 基于 Kubernetes 來做尋址和元數(shù)據(jù)管理不同，OCTO Mesh 由獨(dú)立的 Meta Server 負(fù)責(zé) Mesh 自身眾多元信息的管理和命名服務(wù)。

三、關(guān)鍵設(shè)計解析

大規(guī)模治理體系 Mesh 化建設(shè)成功落地的關(guān)鍵點(diǎn)有：

• 系統(tǒng)水平擴(kuò)展能力方面，可以支撐數(shù)萬應(yīng)用/百萬級節(jié)點(diǎn)的治理。
• 功能擴(kuò)展性方面，可以支持各類異構(gòu)治理子系統(tǒng)融合打通。
• 能應(yīng)對 Mesh 化改造后鏈路復(fù)雜的可用性、可靠性要求。
• 具備成熟完善的 Mesh 運(yùn)維體系。

圍繞這四點(diǎn)，便可以在系統(tǒng)能力、治理能力、穩(wěn)定性、運(yùn)營效率方面支撐美團(tuán)當(dāng)前多倍體量的新架構(gòu)落地。

3.1 大規(guī)模系統(tǒng) Mesh 化系統(tǒng)能力建設(shè)

對于社區(qū) Istio 方案，要想實(shí)現(xiàn)超大規(guī)模應(yīng)用集群落地，需要完成較多的技術(shù)改造。主要是因?yàn)?Istio 水平擴(kuò)展能力相對薄弱，內(nèi)部冗余操作較多，整體穩(wěn)定性建設(shè)較為薄弱。針對上述問題，我們的解決思路如下：

• 控制面每個節(jié)點(diǎn)并不承載所有治理數(shù)據(jù)，系統(tǒng)整體做水平擴(kuò)展，在此基礎(chǔ)上提升每個實(shí)例的整體吞吐量和性能。
• 當(dāng)出現(xiàn)機(jī)房斷網(wǎng)等異常情況時，可以應(yīng)對瞬時流量驟增的能力。
• 只做必要的 P2P 模式健康檢查，配合集中式健康檢查進(jìn)行百萬級節(jié)點(diǎn)管理。

按需加載和數(shù)據(jù)分片主要由 Adcore Pilot 配合 Meta Server 實(shí)現(xiàn)。

Pilot 的邏輯架構(gòu)分為 SessionMgr、Snapshot、Diplomat 三個部分，其中 SessionMgr 管理每個數(shù)據(jù)面會話的全生命周期、會話的創(chuàng)建、交互及銷毀等一系列動作及流程；Snapshot 維護(hù)數(shù)據(jù)最新的一致性快照，對下將資源的更新同步給 SessionMgr 處理，對上響應(yīng)各平臺的數(shù)據(jù)變更通知，進(jìn)行計算并將存在關(guān)聯(lián)關(guān)系的一組數(shù)據(jù)做快照緩存。Diplomat 模塊負(fù)責(zé)與服務(wù)治理系統(tǒng)的眾多平臺對接，只有該模塊會與第三方平臺直接產(chǎn)生依賴。

控制面每個 Pilot 節(jié)點(diǎn)并不會把整個注冊中心及其他數(shù)據(jù)都加載進(jìn)來，而是按需加載自己管控的 Sidecar 所需要的相關(guān)治理數(shù)據(jù)，即從 SessionMgr 請求的應(yīng)用所負(fù)責(zé)的相關(guān)治理數(shù)據(jù)，以及該應(yīng)用關(guān)注的對端服務(wù)注冊信息。另外同一個應(yīng)用的所有 OCTO Proxy 應(yīng)該由同一個Pilot 實(shí)例管控，否則全局狀態(tài)下又容易趨近于全量了。具體是怎么實(shí)現(xiàn)的呢？答案是 Meta Server，自己實(shí)現(xiàn)控制面機(jī)器服務(wù)發(fā)現(xiàn)的同時精細(xì)化控制路由規(guī)則，從而在應(yīng)用層面實(shí)現(xiàn)了數(shù)據(jù)分片。

Meta Server 管控每個Pilot節(jié)點(diǎn)負(fù)責(zé)應(yīng)用 OCTO Proxy的歸屬關(guān)系。當(dāng) Pilot 實(shí)例啟動會注冊到 Meta Server，此后定時發(fā)送心跳進(jìn)行續(xù)租，長時間心跳異常會自動剔除。在 Meta Server 內(nèi)部實(shí)現(xiàn)了較為復(fù)雜的一致性哈希策略，會綜合節(jié)點(diǎn)的應(yīng)用、機(jī)房、負(fù)載等信息進(jìn)行分組。當(dāng)一個 Pilot 節(jié)點(diǎn)異常或發(fā)布時，隸屬該 Pilot 的 OCTO Proxy 都會有規(guī)律的連接到接替節(jié)點(diǎn)，而不會全局隨機(jī)連接對后端注冊中心造成風(fēng)暴。當(dāng)異常或發(fā)布后的節(jié)點(diǎn)恢復(fù)后，劃分出去的 OCTO Proxy 又會有規(guī)則的重新歸屬當(dāng)前 Pilot 實(shí)例管理。對于關(guān)注節(jié)點(diǎn)特別多的應(yīng)用 OCTO Proxy，也可以獨(dú)立部署 Pilot，通過 Meta Server 統(tǒng)一進(jìn)行路由管理。

Mesh體系的命名服務(wù)需要 Pilot 與注冊中心打通，常規(guī)的實(shí)現(xiàn)方式如左圖所示（以 Zookeeper為例），每個 OCTO Proxy 與 Pilot 建立會話時，作為客戶端角色會向注冊中心訂閱自身所關(guān)注的服務(wù)端變更監(jiān)聽器，假設(shè)這個服務(wù)需要訪問100個應(yīng)用，則至少需要注冊100個 Watcher 。假設(shè)該應(yīng)用存在1000個實(shí)例同時運(yùn)行，就會注冊 100*1000 = 100000 個 Watcher，超過1000個節(jié)點(diǎn)的應(yīng)用在美團(tuán)內(nèi)部還是蠻多的。另外還有很多應(yīng)用關(guān)注的對端節(jié)點(diǎn)相同，會造成大量的冗余監(jiān)聽。當(dāng)規(guī)模較大后，網(wǎng)絡(luò)抖動或業(yè)務(wù)集中發(fā)布時，很容易引發(fā)風(fēng)暴效應(yīng)把控制面和后端的注冊中心打掛。

針對這個問題，我們采用分層訂閱的方案解決。每個 OCTO Proxy 的會話并不直接與注冊中心或其他的發(fā)布訂閱系統(tǒng)交互，變更的通知全部由 Snapshot 快照層管理。Snapshot 內(nèi)部又劃分為3層，Data Cache 層對接并緩存注冊中心及其他系統(tǒng)的原始數(shù)據(jù)，粒度是應(yīng)用；Node Snapshot 層則是保留經(jīng)過計算的節(jié)點(diǎn)粒度的數(shù)據(jù)；Ability Manager 層內(nèi)部會做索引和映射的管理，當(dāng)注冊中心存在節(jié)點(diǎn)狀態(tài)變更時，會通過索引將變更推送給關(guān)注變更的 OCTO Proxy。

對于剛剛提到的場景，隔離一層后1000個節(jié)點(diǎn)僅需注冊100個 Watcher，一個 Watcher 變更后僅會有一條變更信息到 Data Cache 層，再根據(jù)索引向1000個 OCTO Proxy 通知，從而極大的降低了注冊中心及 Pilot 的負(fù)載。

Snapshot 層除了減少不必要交互提升性能外，也會將計算后的數(shù)據(jù)格式化緩存下來，一方面瞬時大量相同的請求會在快照層被緩存擋住，另一方面也便于將存在關(guān)聯(lián)的數(shù)據(jù)統(tǒng)一打包到一起，避免并發(fā)問題。這里參考了Envoy-Control-Plane的設(shè)計，Envoy-Control-Plane會將包含xDS的所有數(shù)據(jù)全部打包在一起，而我們是將數(shù)據(jù)隔離開，如路由、鑒權(quán)完全獨(dú)立，當(dāng)路由數(shù)據(jù)變更時不會去拉取并更新鑒權(quán)信息。

預(yù)加載主要目的是提升服務(wù)冷啟動性能，Meta Server 的路由規(guī)則由我們制定，所以這里提前在 Pilot 節(jié)點(diǎn)中加載好最新的數(shù)據(jù)，當(dāng)業(yè)務(wù)進(jìn)程啟動時，Proxy 就可以立即從 Snapshot 中獲取到數(shù)據(jù)，避免了首次訪問慢的問題。

Istio 默認(rèn)每個 Envoy 代理對整個集群中所有其余 Envoy 進(jìn)行 P2P 健康檢測，當(dāng)集群有N個節(jié)點(diǎn)時，一個檢測周期內(nèi)（往往不會很長）就需要做N的平方次檢測，另外當(dāng)集群規(guī)模變大時所有節(jié)點(diǎn)的負(fù)載就會相應(yīng)提高，這都將成為擴(kuò)展部署的極大障礙。

不同于全集群掃描，美團(tuán)采用了集中式的健康檢查方式，同時配合必要的P2P檢測。具體實(shí)現(xiàn)方式是：由中心服務(wù) Scanner 監(jiān)測所有節(jié)點(diǎn)的狀態(tài)，當(dāng) Scanner 主動檢測到節(jié)點(diǎn)異常或 Pilot 感知連接變化通知 Scanner 掃描確認(rèn)節(jié)點(diǎn)異常時， Pilot 立刻通過 eDS 更新節(jié)點(diǎn)狀態(tài)給 Proxy，這種模式下檢測周期內(nèi)僅需要檢測 N 次。Google 的Traffic Director 也采用了類似的設(shè)計，但大規(guī)模使用需要一些技巧：第一個是為了避免機(jī)房自治的影響而選擇了同機(jī)房檢測方式，第二個是為了減少中心檢測機(jī)器因自己 GC 或網(wǎng)絡(luò)異常造成誤判，而采用了Double Check 的機(jī)制。

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

3.2 異構(gòu)治理系統(tǒng)融合設(shè)計

OCTO Mesh 需要對齊當(dāng)前體系的核心治理能力，這就不可避免的將 Mesh 與治理生態(tài)的所有周邊子系統(tǒng)打通。Istio 和 Kubernetes 將所有的數(shù)據(jù)存儲、發(fā)布訂閱機(jī)制都依賴 Etcd 統(tǒng)一實(shí)現(xiàn)，但美團(tuán)的10余個治理子系統(tǒng)功能各異、存儲各異、發(fā)布訂閱模式各異，呈現(xiàn)出明顯的異構(gòu)特征，如果接入一個功能就需要平臺進(jìn)行存儲或其他大規(guī)模改造，這樣是完全不可行的。一個思路是由一個模塊來解耦治理子系統(tǒng)與 Pilot ，這個模塊承載所有的變更并將這個變更下發(fā)給 Pilot，但這種方式也有一些問題需要考慮，之前介紹每個 Pilot 節(jié)點(diǎn)關(guān)注的數(shù)據(jù)并不同，而且分片的規(guī)則也可能時刻變化，有一套機(jī)制能將消息發(fā)送給關(guān)注的Pilot節(jié)點(diǎn)。

總體而言需要實(shí)現(xiàn)三個子目標(biāo)：打通所有系統(tǒng)，治理能力對齊；快速應(yīng)對未來新系統(tǒng)的接入；變更發(fā)送給關(guān)注節(jié)點(diǎn)。我們解法是：獨(dú)立的統(tǒng)一接入中心，屏蔽所有異構(gòu)系統(tǒng)的存儲、發(fā)布訂閱機(jī)制；Meta Server 承擔(dān)實(shí)時分片規(guī)則的元數(shù)據(jù)管理。

具體執(zhí)行機(jī)制如上圖所示：各系統(tǒng)變更時使用客戶端將變更通知推送到消息隊列，只推送變更但不包含具體值（當(dāng)Pilot接收到變更通知是會主動Fetch全量數(shù)據(jù)，這種方式一方面確保Mafka的消息足夠小，另一方面多個變更不需要在隊列中保序解決版本沖突問題）；Adcore Dispatcher 消費(fèi)信息并根據(jù)索引將變更推送到關(guān)注的 Pilot 機(jī)器，當(dāng) Pilot 管控的 Proxy 變更時會同步給 Meta Server，Meta Server 實(shí)時將索引關(guān)系更新并同步給Dispatcher。為了解決 Pilot 與應(yīng)用的映射變更間隙出現(xiàn)消息丟失，Dispatcher 使用回溯檢驗(yàn)變更丟失的模式進(jìn)行補(bǔ)償，以提升系統(tǒng)的可靠性。

3.3 穩(wěn)定性保障設(shè)計

Service Mesh 改造的系統(tǒng)避不開“新”和“復(fù)雜”兩個特征，其中任意一個特征都可能會給系統(tǒng)帶來穩(wěn)定性風(fēng)險，所以必須提前做好整個鏈路的可用性及可靠性建設(shè)，才能游刃有余的推廣。美團(tuán)主要是圍繞控制故障影響范圍、異常實(shí)時自愈、可實(shí)時回滾、柔性可用、提升自身可觀測性及回歸能力進(jìn)行建設(shè)。

這里單獨(dú)介紹控制面的測試問題，這塊業(yè)界可借鑒的內(nèi)容不多。xDS 雙向通信比較復(fù)雜，很難像傳統(tǒng)接口那樣進(jìn)行功能測試，定制多個 Envoy 來模擬數(shù)據(jù)面進(jìn)行測試成本也很高。 我們開發(fā)了 Mock-Sidecar 來模擬真正數(shù)據(jù)面的行為來對控制面進(jìn)行測試，對于控制面來說它跟數(shù)據(jù)面毫無區(qū)別。Mock-Sidecar 把數(shù)據(jù)面的整體行為拆分為一個個可組合的 Step，機(jī)制與策略分離。執(zhí)行引擎就是所謂的機(jī)制，只需要按步驟執(zhí)行 Step 即可。YAML 文件就是 Step 的組合，用于描述策略。我們?nèi)斯?gòu)造各種 YAML 來模擬真正 Sidecar 的行為，對控制面進(jìn)行回歸驗(yàn)證，同時不同 YAML 文件執(zhí)行是并行的，可以進(jìn)行壓力測試。

3.4 運(yùn)維體系設(shè)計

為了應(yīng)對未來百萬級 Proxy 的運(yùn)維壓力，美團(tuán)獨(dú)立建設(shè)了 OCTO Proxy 運(yùn)維系統(tǒng) LEGO，除 Proxy 保活外也統(tǒng)一集中控制發(fā)版。具體的操作流程是：運(yùn)維人員在 LEGO 平臺發(fā)版，確定發(fā)版的范圍及版本，新版本資源內(nèi)容上傳至資源倉庫，并更新規(guī)則及發(fā)版范圍至 DB，發(fā)升級指令下發(fā)至所要發(fā)布的范圍，收到發(fā)版命令機(jī)器的 LEGO Agent 去資源倉庫拉取要更新的版本（中間如果有失敗，會有主動 Poll 機(jī)制保證升級成功），新版本下載成功后，由 LEGO Agent 啟動新版的 OCTO Proxy。

四、總結(jié)與展望

4.1 經(jīng)驗(yàn)總結(jié)

• 服務(wù)治理建設(shè)應(yīng)該圍繞體系標(biāo)準(zhǔn)化、易用性、高性能三個方面開展。

• 大規(guī)模治理體系 Mesh 化應(yīng)該關(guān)注以下內(nèi)容：

  • 適配公司技術(shù)體系比新潮技術(shù)更重要，重點(diǎn)關(guān)注容器化 & 治理體系兼容打通。

    • 建設(shè)系統(tǒng)化的穩(wěn)定性保障體系及運(yùn)維體系。

• OCTO Mesh 控制面4大法寶：Meta Server 管控 Mesh 內(nèi)部服務(wù)注冊發(fā)現(xiàn)及元數(shù)據(jù)、分層分片設(shè)計、統(tǒng)一接入中心解耦并打通 Mesh 與現(xiàn)有治理子系統(tǒng)、集中式健康檢查。

4.2 未來展望

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

• 完善體系：逐漸豐富的 OCTO Mesh 治理體系，探索其他流量類型，全面提升服務(wù)治理效率。
• 大規(guī)模落地：持續(xù)打造健壯的 OCTO Mesh 治理體系，穩(wěn)步推動在公司的大規(guī)模落地。
• 中心化治理能力探索：新治理模式的中心化管控下，全局最優(yōu)治理能力探索。

作者簡介

繼東，基礎(chǔ)架構(gòu)部服務(wù)治理團(tuán)隊。

招聘信息

美團(tuán)點(diǎn)評基礎(chǔ)架構(gòu)團(tuán)隊誠招高級、資深技術(shù)專家，Base 北京、上海。我們致力于建設(shè)美團(tuán)點(diǎn)評全公司統(tǒng)一的高并發(fā)高性能分布式基礎(chǔ)架構(gòu)平臺，涵蓋數(shù)據(jù)庫、分布式監(jiān)控、服務(wù)治理、高性能通信、消息中間件、基礎(chǔ)存儲、容器化、集群調(diào)度等基礎(chǔ)架構(gòu)主要的技術(shù)領(lǐng)域。歡迎有興趣的同學(xué)投送簡歷到 tech@meituan.com（郵件標(biāo)題注明：美團(tuán)點(diǎn)評基礎(chǔ)架構(gòu)團(tuán)隊）。

總結(jié)

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

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