溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章將為大家詳細講解有關如何實現OCTO2.0 的探索與實踐，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
已成為美團高度統一的服務治理技術棧，覆蓋了公司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）。
OCTO 體系已經歷近5年的迭代，形成了一系列的標準與規范，進行 Service Mesh 改造治理體系架構的升級范圍會很大，在確保技術方案可以落地的同時，也要屏蔽技術升級或只需要業務做很低成本的改動。
治理能力不能減弱，在保證對齊的基礎上逐漸提供更精細化、更易用的運營能力。
能應對超大規模的挑戰，技術方案務必能確保支撐當前量級甚至當前N倍的增量，系統自身也不能成為整個治理體系的瓶頸。
針對上述考量，我們選擇的方式是數據面基于 Envoy 二次開發，控制面自研為主。
截止發稿前，美團容器化主要采用富容器的模式，這種模式下強行與 Istio 及 Kubernetes 的數據模型匹配改造成本極高，同時 Istio API也尚未確定。
截止發稿前，Istio 在集群規模變大時較容易出現性能問題，無法支撐美團數萬應用、數十萬節點的的體量，同時數十萬節點規模的 Kubernetes 集群也需要持續優化探索。
Istio 的功能無法滿足 OCTO 復雜精細的治理需求，如流量錄制回放壓測、更復雜的路由策略等。
項目啟動時非容器應用占比較高，技術方案需要兼容存量非容器應用。
上面這張圖展示了 OCTO Mesh 的整體架構。從下至上來看，邏輯上分為業務進程及通信框架 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，這種方式可以將人工干預降到較低，提升運維效率。
控制面（美團內部名稱為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 運維體系。
圍繞這四點，便可以在系統能力、治理能力、穩定性、運營效率方面支撐美團當前多倍體量的新架構落地。
對于社區 Istio 方案，要想實現超大規模應用集群落地，需要完成較多的技術改造。主要是因為 Istio 水平擴展能力相對薄弱，內部冗余操作較多，整體穩定性建設較為薄弱。針對上述問題，我們的解決思路如下：
控制面每個節點并不承載所有治理數據，系統整體做水平擴展，在此基礎上提升每個實例的整體吞吐量和性能。
當出現機房斷網等異常情況時，可以應對瞬時流量驟增的能力。
按需加載和數據分片主要由 Adcore 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 統一進行路由管理。
對于剛剛提到的場景，隔離一層后1000個節點僅需注冊100個 Watcher，一個 Watcher 變更后僅會有一條變更信息到 Data Cache 層，再根據索引向1000個 OCTO Proxy 通知，從而極大的降低了注冊中心及 Pilot 的負載。
Snapshot 層除了減少不必要交互提升性能外，也會將計算后的數據格式化緩存下來，一方面瞬時大量相同的請求會在快照層被緩存擋住，另一方面也便于將存在關聯的數據統一打包到一起，避免并發問題。這里參考了Envoy-Control-Plane的設計，Envoy-Control-Plane會將包含xDS的所有數據全部打包在一起，而我們是將數據隔離開，如路由、鑒權完全獨立，當路由數據變更時不會去拉取并更新鑒權信息。
Istio 默認每個 Envoy 代理對整個集群中所有其余 Envoy 進行 P2P 健康檢測，當集群有N個節點時，一個檢測周期內（往往不會很長）就需要做N的平方次檢測，另外當集群規模變大時所有節點的負載就會相應提高，這都將成為擴展部署的極大障礙。
OCTO Mesh 需要對齊當前體系的核心治理能力，這就不可避免的將 Mesh 與治理生態的所有周邊子系統打通。Istio 和 Kubernetes 將所有的數據存儲、發布訂閱機制都依賴 Etcd 統一實現，但美團的10余個治理子系統功能各異、存儲各異、發布訂閱模式各異，呈現出明顯的異構特征，如果接入一個功能就需要平臺進行存儲或其他大規模改造，這樣是完全不可行的。一個思路是由一個模塊來解耦治理子系統與 Pilot ，這個模塊承載所有的變更并將這個變更下發給 Pilot，但這種方式也有一些問題需要考慮，之前介紹每個 Pilot 節點關注的數據并不同，而且分片的規則也可能時刻變化，有一套機制能將消息發送給關注的Pilot節點。
具體執行機制如上圖所示：各系統變更時使用客戶端將變更通知推送到消息隊列，只推送變更但不包含具體值（當Pilot接收到變更通知會主動Fetch全量數據，這種方式一方面確保Mafka的消息足夠小，另一方面多個變更不需要在隊列中保序解決版本沖突問題。）；Adcore Dispatcher 消費信息并根據索引將變更推送到關注的 Pilot 機器，當 Pilot 管控的 Proxy 變更時會同步給 Meta Server，Meta Server 實時將索引關系更新并同步給Dispatcher。為了解決 Pilot 與應用的映射變更間隙出現消息丟失，Dispatcher 使用回溯檢驗變更丟失的模式進行補償，以提升系統的可靠性。
Service Mesh 改造的系統避不開“新”和“復雜”兩個特征，其中任意一個特征都可能會給系統帶來穩定性風險，所以必須提前做好整個鏈路的可用性及可靠性建設，才能游刃有余的推廣。美團主要是圍繞控制故障影響范圍、異常實時自愈、可實時回滾、柔性可用、提升自身可觀測性及回歸能力進行建設。
這里單獨介紹控制面的測試問題，這塊業界可借鑒的內容不多。xDS 雙向通信比較復雜，很難像傳統接口那樣進行功能測試，定制多個 Envoy 來模擬數據面進行測試成本也很高。我們開發了 Mock-Sidecar 來模擬真正數據面的行為來對控制面進行測試，對于控制面來說它跟數據面毫無區別。Mock-Sidecar 把數據面的整體行為拆分為一個個可組合的 Step，機制與策略分離。執行引擎就是所謂的機制，只需要按步驟執行 Step 即可。YAML 文件就是 Step 的組合，用于描述策略。我們人工構造各種 YAML 來模擬真正 Sidecar 的行為，對控制面進行回歸驗證，同時不同 YAML 文件執行是并行的，可以進行壓力測試。
為了應對未來百萬級 Proxy 的運維壓力，美團獨立建設了 OCTO Proxy 運維系統 LEGO，除 Proxy 保活外也統一集中控制發版。具體的操作流程是：運維人員在 LEGO 平臺發版，確定發版的范圍及版本，新版本資源內容上傳至資源倉庫，并更新規則及發版范圍至 DB，發升級指令下發至所要發布的范圍，收到發版命令機器的 LEGO Agent 去資源倉庫拉取要更新的版本（中間如果有失敗，會有主動 Poll 機制保證升級成功），新版本下載成功后，由 LEGO Agent 啟動新版的 OCTO Proxy。
服務治理建設應該圍繞體系標準化、易用性、高性能三個方面開展。
大規模治理體系 Mesh 化應該關注以下內容：
適配公司技術體系比新潮技術更重要，重點關注容器化 & 治理體系兼容打通。
建設系統化的穩定性保障體系及運維體系。
OCTO Mesh 控制面4大法寶：Meta Server 管控 Mesh 內部服務注冊發現及元數據、分層分片設計、統一接入中心解耦并打通 Mesh 與現有治理子系統、集中式健康檢查。
完善體系：逐漸豐富的 OCTO Mesh 治理體系，探索其他流量類型，全面提升服務治理效率。
大規模落地：持續打造健壯的 OCTO Mesh 治理體系，穩步推動在公司的大規模落地。
中心化治理能力探索：新治理模式的中心化管控下，全局最優治理能力探索。
關于如何實現OCTO2.0 的探索與實踐就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
