如何實現(xiàn)OCTO2.0的探索與實踐-創(chuàng)新互聯(lián)

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

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

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

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

• 已成為美團高度統(tǒng)一的服務治理技術(shù)棧，覆蓋了公司90%的應用，日均調(diào)用超萬億次。

• 經(jīng)歷過大規(guī)模的技術(shù)考驗，覆蓋數(shù)萬個服務/數(shù)十萬個節(jié)點。

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

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

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

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

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

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

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

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

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

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

• 新融入的異構(gòu)技術(shù)體系可以通過輕薄的 SDK 接入美團治理體系（技術(shù)體系難兼容，本質(zhì)是它們各自有獨立的運行規(guī)范，在 Service Mesh 模式下運行規(guī)范核心內(nèi)容就是控制面和Sidecar），目前美團線上也有這樣的案例。

• 控制大腦集中掌控了所有節(jié)點的信息，進而可以做一些全局最優(yōu)的決策，比如服務預熱、根據(jù)負載動態(tài)調(diào)整路由等能力。

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

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

2.1 OCTO Mesh 技術(shù)選型

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

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

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

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

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

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

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

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

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

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

• 項目啟動時非容器應用占比較高，技術(shù)方案需要兼容存量非容器應用。

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

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

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

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

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

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

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

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

• Adcore Pilot 是個獨立集群，模塊承載著大部分核心治理功能的管控，相當于整個系統(tǒng)的大腦，也是直接與數(shù)據(jù)面交互的模塊。

• Adcore Dispatcher 也是獨立集群，該模塊是供治理體系協(xié)作的眾多子系統(tǒng)便捷接入 Mesh 體系的接入中心。

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

• 控制面節(jié)點管理系統(tǒng)負責采集每個節(jié)點的運行時信息，并根據(jù)節(jié)點的狀態(tài)做全局性的最優(yōu)治理的決策和執(zhí)行。

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

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

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

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

• 系統(tǒng)水平擴展能力方面，可以支撐數(shù)萬應用/百萬級節(jié)點的治理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4 運維體系設計

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

四、總結(jié)與展望

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

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

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

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

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

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

4.2 未來展望

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

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

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

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

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

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

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

廣告

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