這篇文章將為大家詳細(xì)講解有關(guān)如何實(shí)現(xiàn)OCTO2.0 的探索與實(shí)踐，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

為玉門(mén)等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及玉門(mén)網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì)、玉門(mén)網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

一、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)用超萬(wàn)億次。

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

• 協(xié)同周邊治理生態(tài)提供的治理能力較為豐富，包含但不限于 SET 化、鏈路級(jí)復(fù)雜路由、全鏈路壓測(cè)、鑒權(quán)加密、限流熔斷等治理能力。

• 一套系統(tǒng)支撐著多元業(yè)務(wù)，覆蓋公司所有事業(yè)線。

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

• 對(duì)多語(yǔ)言支持不夠好。美團(tuán)技術(shù)棧使用的語(yǔ)言主要是 Java，占比到達(dá)80%以上，上面介紹的諸多治理能力也集中在 Java 體系。但美團(tuán)同時(shí)還有其他近10種后臺(tái)服務(wù)語(yǔ)言在使用，這些語(yǔ)言的治理生態(tài)均十分薄弱，同時(shí)在多元業(yè)務(wù)的模式下必然會(huì)有增長(zhǎng)的多語(yǔ)言需求，為每一種語(yǔ)言都建設(shè)一套完善的治理體系成本很高，也不太可能落地。

• 中間件和業(yè)務(wù)綁定在一起，制約著彼此迭代。一般來(lái)說(shuō)，核心的治理能力主要由通信框架承載，雖然做到了邏輯隔離，但中間件的邏輯不可避免會(huì)和業(yè)務(wù)在物理上耦合在一起。這種模式下，中間件引入Bug需要所有業(yè)務(wù)配合升級(jí)，這對(duì)業(yè)務(wù)的研發(fā)效率也會(huì)造成損害；新特性的發(fā)布也依賴業(yè)務(wù)逐個(gè)升級(jí)，不具備自主的控制能力。

• 異構(gòu)治理體系技術(shù)融合成本很高。

• 治理決策比較分散。每個(gè)節(jié)點(diǎn)只能根據(jù)自己的狀態(tài)進(jìn)行決策，無(wú)法與其他節(jié)點(diǎn)協(xié)同仲裁。

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

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

• 中間件易變的邏輯盡量下沉到 Sidecar 和控制大腦中，后續(xù)升級(jí)中間件基本不需要業(yè)務(wù)配合。SDK 主要包含很輕薄且不易變的邏輯，從而實(shí)現(xiàn)了業(yè)務(wù)和中間件的解耦。

• 新融入的異構(gòu)技術(shù)體系可以通過(guò)輕薄的 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ù)載動(dòng)態(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è)計(jì)

2.1 OCTO Mesh 技術(shù)選型

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

• OCTO 體系已經(jīng)歷近5年的迭代，形成了一系列的標(biāo)準(zhǔn)與規(guī)范，進(jìn)行 Service Mesh 改造治理體系架構(gòu)的升級(jí)范圍會(huì)很大，在確保技術(shù)方案可以落地的同時(shí)，也要屏蔽技術(shù)升級(jí)或只需要業(yè)務(wù)做很低成本的改動(dòng)。

• 治理能力不能減弱，在保證對(duì)齊的基礎(chǔ)上逐漸提供更精細(xì)化、更易用的運(yùn)營(yíng)能力。

• 能應(yīng)對(duì)超大規(guī)模的挑戰(zhàn)，技術(shù)方案務(wù)必能確保支撐當(dāng)前量級(jí)甚至當(dāng)前N倍的增量，系統(tǒng)自身也不能成為整個(gè)治理體系的瓶頸。

• 盡量與社區(qū)保持親和，一定程度上與社區(qū)協(xié)同演進(jìn)。

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

數(shù)據(jù)面方面，當(dāng)時(shí) Envoy 有機(jī)會(huì)成為數(shù)據(jù)面的事實(shí)標(biāo)準(zhǔn)，同時(shí) Filter 模式及 xDS 的設(shè)計(jì)對(duì)擴(kuò)展比較友好，未來(lái)功能的豐富、性能優(yōu)化也與標(biāo)準(zhǔn)關(guān)系較弱?？刂泼孀匝袨橹鞯臎Q策需要考量的內(nèi)容就比較復(fù)雜了，總體而言需要考慮如下幾個(gè)方面：

• 截止發(fā)稿前，美團(tuán)容器化主要采用富容器的模式，這種模式下強(qiáng)行與 Istio 及 Kubernetes 的數(shù)據(jù)模型匹配改造成本極高，同時(shí) Istio API也尚未確定。

• 截止發(fā)稿前，Istio 在集群規(guī)模變大時(shí)較容易出現(xiàn)性能問(wèn)題，無(wú)法支撐美團(tuán)數(shù)萬(wàn)應(yīng)用、數(shù)十萬(wàn)節(jié)點(diǎn)的的體量，同時(shí)數(shù)十萬(wàn)節(jié)點(diǎn)規(guī)模的 Kubernetes 集群也需要持續(xù)優(yōu)化探索。

• Istio 的功能無(wú)法滿足 OCTO 復(fù)雜精細(xì)的治理需求，如流量錄制回放壓測(cè)、更復(fù)雜的路由策略等。

• 項(xiàng)目啟動(dòng)時(shí)非容器應(yīng)用占比較高，技術(shù)方案需要兼容存量非容器應(yīng)用。

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

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

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

• OCTO Proxy （數(shù)據(jù)面Sidecar代理內(nèi)部叫OCTO Proxy）與業(yè)務(wù)進(jìn)程采用1對(duì)1的方式部署。

• OCTO Proxy 與業(yè)務(wù)進(jìn)程采用 UNIX Domain Socket 做進(jìn)程間通信（這里沒(méi)有選擇使用 Istio 默認(rèn)的 iptables 流量劫持，主要考慮美團(tuán)內(nèi)部基本是使用的統(tǒng)一化私有協(xié)議通信，富容器模式?jīng)]有用 Kubernetes 的命名服務(wù)模型，iptables 管理起來(lái)會(huì)很復(fù)雜，而 iptables 復(fù)雜后性能會(huì)出現(xiàn)較高的損耗。）；OCTO Proxy 間跨節(jié)點(diǎn)采用 TCP 通信，采用和進(jìn)程間同樣的協(xié)議，保證了客戶端和服務(wù)端具備獨(dú)立升級(jí)的能力。

• 為了提升效率同時(shí)減少人為錯(cuò)誤，我們獨(dú)立建設(shè)了 OCTO Proxy 管理系統(tǒng)，部署在每個(gè)實(shí)例上的 LEGO Agent 負(fù)責(zé) OCTO Proxy 的?；詈蜔嵘?jí)，類似于 Istio 的 Pilot Agent，這種方式可以將人工干預(yù)降到較低，提升運(yùn)維效率。

• 數(shù)據(jù)面與控制面通過(guò)雙向流式通信。路由部分交互方式是增強(qiáng)語(yǔ)義的 xDS，增強(qiáng)語(yǔ)義是因?yàn)楫?dāng)前的 xDS 無(wú)法滿足美團(tuán)更復(fù)雜的路由需求；除路由外，該通道承載著眾多的治理功能的指令及配置下發(fā)，我們?cè)O(shè)計(jì)了一系列的自定義協(xié)議。

控制面（美團(tuán)內(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ù)注冊(cè)發(fā)現(xiàn)系統(tǒng) Meta Server 模塊。每個(gè)模塊的具體職責(zé)如下：

• Adcore Pilot 是個(gè)獨(dú)立集群，模塊承載著大部分核心治理功能的管控，相當(dāng)于整個(gè)系統(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é)采集每個(gè)節(jié)點(diǎn)的運(yùn)行時(shí)信息，并根據(jù)節(jié)點(diǎn)的狀態(tài)做全局性的最優(yōu)治理的決策和執(zhí)行。

• 監(jiān)控預(yù)警系統(tǒng)是保障 Mesh 自身穩(wěn)定性而建設(shè)的模塊，實(shí)現(xiàn)了自身的可觀測(cè)性，當(dāng)出現(xiàn)故障時(shí)能快速定位，同時(shí)也會(huì)對(duì)整個(gè)系統(tǒng)做實(shí)時(shí)巡檢。

• 與Istio 基于 Kubernetes 來(lái)做尋址和元數(shù)據(jù)管理不同，OCTO Mesh 由獨(dú)立的 Meta Server 負(fù)責(zé) Mesh 自身眾多元信息的管理和命名服務(wù)。

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

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

• 系統(tǒng)水平擴(kuò)展能力方面，可以支撐數(shù)萬(wàn)應(yīng)用/百萬(wàn)級(jí)節(jié)點(diǎn)的治理。

• 功能擴(kuò)展性方面，可以支持各類異構(gòu)治理子系統(tǒng)融合打通。

• 能應(yīng)對(duì) Mesh 化改造后鏈路復(fù)雜的可用性、可靠性要求。

• 具備成熟完善的 Mesh 運(yùn)維體系。

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

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

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

• 控制面每個(gè)節(jié)點(diǎn)并不承載所有治理數(shù)據(jù)，系統(tǒng)整體做水平擴(kuò)展，在此基礎(chǔ)上提升每個(gè)實(shí)例的整體吞吐量和性能。

• 當(dāng)出現(xiàn)機(jī)房斷網(wǎng)等異常情況時(shí)，可以應(yīng)對(duì)瞬時(shí)流量驟增的能力。

• 只做必要的 P2P 模式健康檢查，配合集中式健康檢查進(jìn)行百萬(wàn)級(jí)節(jié)點(diǎn)管理。

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

Pilot 的邏輯架構(gòu)分為 SessionMgr、Snapshot、Diplomat 三個(gè)部分，其中 SessionMgr 管理每個(gè)數(shù)據(jù)面會(huì)話的全生命周期、會(huì)話的創(chuàng)建、交互及銷毀等一系列動(dòng)作及流程；Snapshot 維護(hù)數(shù)據(jù)最新的一致性快照，對(duì)下將資源的更新同步給 SessionMgr 處理，對(duì)上響應(yīng)各平臺(tái)的數(shù)據(jù)變更通知，進(jìn)行計(jì)算并將存在關(guān)聯(lián)關(guān)系的一組數(shù)據(jù)做快照緩存。Diplomat 模塊負(fù)責(zé)與服務(wù)治理系統(tǒng)的眾多平臺(tái)對(duì)接，只有該模塊會(huì)與第三方平臺(tái)直接產(chǎn)生依賴?？刂泼婷總€(gè) Pilot 節(jié)點(diǎn)并不會(huì)把整個(gè)注冊(cè)中心及其他數(shù)據(jù)都加載進(jìn)來(lái)，而是按需加載自己管控的 Sidecar 所需要的相關(guān)治理數(shù)據(jù)，即從 SessionMgr 請(qǐng)求的應(yīng)用所負(fù)責(zé)的相關(guān)治理數(shù)據(jù)，以及該應(yīng)用關(guān)注的對(duì)端服務(wù)注冊(cè)信息。另外同一個(gè)應(yīng)用的所有 OCTO Proxy 應(yīng)該由同一個(gè)Pilot 實(shí)例管控，否則全局狀態(tài)下又容易趨近于全量了。具體是怎么實(shí)現(xiàn)的呢？答案是 Meta Server，自己實(shí)現(xiàn)控制面機(jī)器服務(wù)發(fā)現(xiàn)的同時(shí)精細(xì)化控制路由規(guī)則，從而在應(yīng)用層面實(shí)現(xiàn)了數(shù)據(jù)分片。

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

Mesh體系的命名服務(wù)需要 Pilot 與注冊(cè)中心打通，常規(guī)的實(shí)現(xiàn)方式如左圖所示（以 Zookeeper為例），每個(gè) OCTO Proxy 與 Pilot 建立會(huì)話時(shí)，作為客戶端角色會(huì)向注冊(cè)中心訂閱自身所關(guān)注的服務(wù)端變更監(jiān)聽(tīng)器，假設(shè)這個(gè)服務(wù)需要訪問(wèn)100個(gè)應(yīng)用，則至少需要注冊(cè)100個(gè) Watcher 。假設(shè)該應(yīng)用存在1000個(gè)實(shí)例同時(shí)運(yùn)行，就會(huì)注冊(cè) 100*1000 = 100000 個(gè) Watcher，超過(guò)1000個(gè)節(jié)點(diǎn)的應(yīng)用在美團(tuán)內(nèi)部還是蠻多的。另外還有很多應(yīng)用關(guān)注的對(duì)端節(jié)點(diǎn)相同，會(huì)造成大量的冗余監(jiān)聽(tīng)。當(dāng)規(guī)模較大后，網(wǎng)絡(luò)抖動(dòng)或業(yè)務(wù)集中發(fā)布時(shí)，很容易引發(fā)風(fēng)暴效應(yīng)把控制面和后端的注冊(cè)中心打掛。
針對(duì)這個(gè)問(wèn)題，我們采用分層訂閱的方案解決。每個(gè) OCTO Proxy 的會(huì)話并不直接與注冊(cè)中心或其他的發(fā)布訂閱系統(tǒng)交互，變更的通知全部由 Snapshot 快照層管理。Snapshot 內(nèi)部又劃分為3層，Data Cache 層對(duì)接并緩存注冊(cè)中心及其他系統(tǒng)的原始數(shù)據(jù)，粒度是應(yīng)用；Node Snapshot 層則是保留經(jīng)過(guò)計(jì)算的節(jié)點(diǎn)粒度的數(shù)據(jù)；Ability Manager 層內(nèi)部會(huì)做索引和映射的管理，當(dāng)注冊(cè)中心存在節(jié)點(diǎn)狀態(tài)變更時(shí)，會(huì)通過(guò)索引將變更推送給關(guān)注變更的 OCTO Proxy。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、總結(jié)與展望

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

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

• 大規(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ù)注冊(cè)發(fā)現(xiàn)及元數(shù)據(jù)、分層分片設(shè)計(jì)、統(tǒng)一接入中心解耦并打通 Mesh 與現(xiàn)有治理子系統(tǒng)、集中式健康檢查。

4.2 未來(lái)展望

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

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

• 大規(guī)模落地：持續(xù)打造健壯的 OCTO Mesh 治理體系，穩(wěn)步推動(dòng)在公司的大規(guī)模落地。

• 中心化治理能力探索：新治理模式的中心化管控下，全局最優(yōu)治理能力探索。

關(guān)于如何實(shí)現(xiàn)OCTO2.0 的探索與實(shí)踐就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

當(dāng)前名稱：如何實(shí)現(xiàn)OCTO2.0的探索與實(shí)踐-創(chuàng)新互聯(lián)
本文URL：http://www.rwnh.cn/article48/coighp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、網(wǎng)站設(shè)計(jì)公司、軟件開(kāi)發(fā)、網(wǎng)頁(yè)設(shè)計(jì)公司、虛擬主機(jī)、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)