美團(tuán)分布式服務(wù)治理框架OCTO之一：服務(wù)治理

寫在前面

之前的文章介紹過美團(tuán)的中間件leaf-code，今天介紹另一款非常強(qiáng)的中間件系統(tǒng)Octo，其實Octo算不上是中間件系統(tǒng)，應(yīng)該是一整套分布式服務(wù)治理平臺，美團(tuán)的很多中間件能力都是通過Octo暴露出來的，比如配置中心MCC、服務(wù)注冊與發(fā)現(xiàn)、Trace系統(tǒng)、日志系統(tǒng)、監(jiān)控告警系統(tǒng)、負(fù)載均衡、容錯降級處理、灰度發(fā)布等。

這樣設(shè)計的一個好處是，RD通過一個平臺就可以做所有自己需要做的事情，不像有的公司每個服務(wù)治理能力獨立一個系統(tǒng)，搞一件事情需要去N個平臺。這件事本身反映了美團(tuán)的一個底層價值觀，就是注重效率，有的公司談提效，只是在嘴上。

Octo核心組件包括RPC、NS、Portal等。

Ocot誕生于2014年，隨著美團(tuán)發(fā)展越來越好，服務(wù)數(shù)量也越來越多，服務(wù)鏈路越來越復(fù)雜，保留出了很多問題，如：

• 研發(fā)效率低：缺乏標(biāo)準(zhǔn)的服務(wù)治理框架和組件，不少團(tuán)隊重復(fù)造輪子，導(dǎo)致研發(fā)資源浪費，治理參差不齊，整體可用性不高；

• 運維成本高：缺乏完善、便捷的體系化運維手段，難以進(jìn)行準(zhǔn)確的告警監(jiān)控，對涉及多級鏈路故障定位困難；

• 服務(wù)運營難：服務(wù)指標(biāo)數(shù)據(jù)收集困難，缺乏自動化深度分析，難以滿足業(yè)務(wù)快速對指標(biāo)的評估及決策的要求。

抽象歸納起來，痛點是：提升研發(fā)效率和質(zhì)量，降低運營成本，對于支撐業(yè)務(wù)快速穩(wěn)定發(fā)展非常重要。

由于服務(wù)治理是個大而全的事情，為降低開發(fā)成本，提升穩(wěn)定性。Octo依托低耦合、模塊化、單元化系統(tǒng)架構(gòu)，滿足了各種復(fù)雜業(yè)務(wù)場景需求，實現(xiàn)了異地多活等容災(zāi)目標(biāo)。

Octo為什么做的好，很重要的一點是其設(shè)計圍繞于目的本身。既然作為覆蓋研發(fā)全生命周期的治理系統(tǒng)，Octo功能涵蓋了服務(wù)定義、開發(fā)、測試、部署、運維、優(yōu)化、下線服務(wù)的全生命周期，打造了一系列的組件和系統(tǒng)，方便研發(fā)同學(xué)專注于自身業(yè)務(wù)的全生命周期。

比如，在開發(fā)階段提供了高性能、高可用、功能模塊化的通信框架為服務(wù)之間提供接入的便利性；在測試階段提供了SET化、泳道、服務(wù)分組等各種灰度策略，幫助業(yè)務(wù)快速無損試錯；在運維階段提供機(jī)器級別、框架級別、業(yè)務(wù)級別等層級分明的監(jiān)控告警能力，幫助業(yè)務(wù)快速發(fā)現(xiàn)問題，定位問題；在優(yōu)化階段提供了詳盡的指標(biāo)自定義分析報表；

Octo架構(gòu)

上面提到了Octo功能很多，細(xì)化下來，功能包括：

• 命名服務(wù)：服務(wù)注冊/發(fā)現(xiàn)。

• 服務(wù)管理：服務(wù)狀態(tài)監(jiān)測；服務(wù)啟動、停止；服務(wù)負(fù)載均衡。

• 容錯處理：實時屏蔽異常的服務(wù)，自動調(diào)配請求流量。

• 流量分發(fā)：灰度發(fā)布、節(jié)點動態(tài)流量分配等場景。

• 數(shù)據(jù)可視化：服務(wù)調(diào)用統(tǒng)計上報分析，提供清晰的數(shù)據(jù)圖表展示，直觀定位服務(wù)間依賴關(guān)系。

• 服務(wù)分組：支持服務(wù)動態(tài)自動歸組與不同場景下的自定義分組，解決在多機(jī)房場景下跨機(jī)房調(diào)用穿透、沙盒測試等問題。

• 服務(wù)監(jiān)控報警：支持服務(wù)與接口級別多指標(biāo)、多維度的監(jiān)控，支持多種報警方式。

• 統(tǒng)一配置管理：支持服務(wù)配置統(tǒng)一管理，靈活設(shè)置不同環(huán)境間差異，支持歷史版本，配置項變更后實時下發(fā)。

• 分布式服務(wù)跟蹤：輕松診斷服務(wù)訪問慢、異常抖動等問題。

• 過載保護(hù)：靈活定義分配給上游服務(wù)消費者的配額，當(dāng)服務(wù)調(diào)用量超出最大閥值時，基于不同服務(wù)消費者進(jìn)行QoS區(qū)分，觸發(fā)流控進(jìn)行過載保護(hù)。

• 服務(wù)訪問控制：支持多粒度、多階段的鑒權(quán)方式。

整體架構(gòu)如下：

• OCTO-RPC（開源Java/C++）：分布式RPC通信框架，支持Java、C++、Node.js等多種語言。

• SGAgent：部署在各服務(wù)節(jié)點，承擔(dān)服務(wù)注冊/發(fā)現(xiàn)、動態(tài)路由解析、負(fù)載均衡、配置傳輸、性能數(shù)據(jù)上報等功能。

• Oceanus（待開源）：HTTP定制化路由負(fù)載器，具體可參考《Oceanus：美團(tuán)HTTP流量定制化路由的實踐》一文。

• OCTO-NS：包括SDK（Java/C++）、基礎(chǔ)代理SGAgent、命名服務(wù)緩存NSC、健康檢查服務(wù)Scanner等組件，提供命名服務(wù)，服務(wù)注冊等信息的存儲，服務(wù)狀態(tài)檢測的掃描等功能。

• Watt（待開源）：統(tǒng)計鏈路信息，計算服務(wù)各類指標(biāo)作為監(jiān)控報警依據(jù)。

• MCC（待開源）：統(tǒng)一配置中心，可進(jìn)行服務(wù)配置的管理下發(fā)。

• OCTO-Portal：服務(wù)注冊、管理、診斷、配置、配額等功能的一站式管理平臺。s

數(shù)據(jù)中心

前面提到了Octo是服務(wù)治理的一整套平臺，通過報表頁面可以看到所有請求的時延、TP99~TP999、QPS、成功率等一系列核心指標(biāo)，粒度可以精確到秒、分鐘、小時、天級別，檢索維度可以支持按照調(diào)用端IP+服務(wù)各接口查詢，也可以通過制定主機(jī)+接口查詢指標(biāo)。

這種維度的數(shù)據(jù)可以幫助開發(fā)人員全面掌控系統(tǒng)運行情況、快速定位問題，但海量的數(shù)據(jù)同樣給Octo的數(shù)據(jù)中心設(shè)計帶來了巨大的挑戰(zhàn)。

原始數(shù)據(jù)架構(gòu)

1. 采集層：每個業(yè)務(wù)應(yīng)用實例部署一個采集代理，代理通過將采集數(shù)據(jù)用批量 RPC 的方式發(fā)送給路由節(jié)點。

2. 路由層：每個路由節(jié)點隨機(jī)收到各服務(wù)的數(shù)據(jù)后，將同一服務(wù)的所有數(shù)據(jù)，用類似 IP 直連的方式通過 RPC 發(fā)送到計算層的同一個計算節(jié)點。同服務(wù)數(shù)據(jù)匯總到同計算節(jié)點才能進(jìn)行特定服務(wù)各個維度的聚合計算。

3. 計算層：每個計算節(jié)點采用 Akka 模型，節(jié)點同時負(fù)責(zé)分鐘、小時、天粒度的數(shù)據(jù)計算集。每個計算集里面又有10個子計算 actor，每個子計算 actor 對應(yīng)的是一個維度。采用“先計算指標(biāo)，再存儲數(shù)據(jù)”的準(zhǔn)實時模式。

4. 存儲層：準(zhǔn)實時數(shù)據(jù)使用 HBase 存儲，元數(shù)據(jù)及較大數(shù)據(jù)采用 KV 存儲（美團(tuán)內(nèi)部系統(tǒng)Cellar）及 MySQL 存儲。

這個原始架構(gòu)面對以下幾個問題：

1. 計算節(jié)點有狀態(tài)，異常無法自動化遷移。計算層部署的每個節(jié)點平均負(fù)責(zé)200+服務(wù)的統(tǒng)計。一個節(jié)點 OOM 或宕機(jī)時，其管理的200個服務(wù)的數(shù)據(jù)會丟失或波動，報警等依托數(shù)據(jù)的治理功能也會異常。此外計算節(jié)點 OOM 時也不宜自動遷移受影響的服務(wù)，需人工介入處理（異常的原因可能是計算節(jié)點無法承載涌入的數(shù)據(jù)量，簡單的遷移易引發(fā)“雪崩”），每周投入的運維時間近20小時。

2. 系統(tǒng)不支持水平擴(kuò)展。計算節(jié)點的壓力由其管理的服務(wù)調(diào)用量、服務(wù)內(nèi)維度復(fù)雜度等因素決定。大體量的服務(wù)需單獨分配高配機(jī)器，業(yè)務(wù)數(shù)據(jù)膨脹計算節(jié)點能力不匹配時，只能替換更高性能的機(jī)器。

3. 系統(tǒng)整體穩(wěn)定性不高。數(shù)據(jù)傳輸采用 RPC，單計算節(jié)點響應(yīng)慢時，易拖垮所有路由層的節(jié)點并引發(fā)系統(tǒng)“雪崩”。

4. 熱點及數(shù)據(jù)傾斜明顯，策略管理復(fù)雜。按服務(wù)劃分熱點明顯，存在一個服務(wù)數(shù)據(jù)量比整個計算節(jié)點200個服務(wù)總數(shù)多的情況，部分機(jī)器的 CPU 利用率不到10%，部分利用率在90%+。改變路由策略易引發(fā)新的熱點機(jī)器，大體量服務(wù)數(shù)據(jù)增長時需要縱向擴(kuò)容解決。舊架構(gòu)是人工維護(hù)160余個大服務(wù)到計算節(jié)點的映射關(guān)系供路由層使用。

正是由于以上一些問題，導(dǎo)致系統(tǒng)會出現(xiàn)告警丟失、誤報、數(shù)據(jù)不準(zhǔn)、告警延遲等問題，于是著手開發(fā)了新的架構(gòu)。

新架構(gòu)有以下幾個目標(biāo)：

1. 高吞吐、高度擴(kuò)展能力。具備20倍+的水平擴(kuò)展能力，支持日10萬億數(shù)據(jù)的處理能力。

2. 數(shù)據(jù)高度精確。解決節(jié)點宕機(jī)后自愈、解決數(shù)據(jù)丟失問題。

3. 高可靠、高可用。無計算單點，所有計算節(jié)點無狀態(tài)；1/3計算節(jié)點宕機(jī)無影響；具備削峰能力。

4. 延時低。秒級指標(biāo)延遲TP99<10s；分鐘指標(biāo)延遲TP99<2min。

由于整個Octo服務(wù)治理系統(tǒng)數(shù)據(jù)體量巨大，近萬億級，實現(xiàn)高效、準(zhǔn)確、快速的數(shù)據(jù)架構(gòu)挑戰(zhàn)巨大。

5. TP 數(shù)據(jù)是衡量服務(wù)最核心的指標(biāo)之一，但在萬億規(guī)模下，精確的準(zhǔn)實時多維度分布式 TP 數(shù)據(jù)是一個難題，原因詳細(xì)解釋下：

• 假設(shè)計算得出 IP1 的 TP99 是100ms、QPS 為50；IP2 的 TP99 是10ms、QPS 為50；IP3 的 TP99 是1ms，QPS為50。那么該服務(wù)整體 TP99 是（100ms x 50 + 10ms x 50 + 1ms x 50）/ (50 + 50 + 50) = 37ms嗎？并非如此，該服務(wù)的真實 TP99 可能是 100ms，在沒有全量樣本情況下無法保證準(zhǔn)確的TP值。

• 假設(shè)不需要服務(wù)全局精確的時延 TP 數(shù)據(jù)，也不可以忽略該問題。按上述方式拆分并合并后，服務(wù)按接口維度計算的 TP 數(shù)據(jù)也失去了準(zhǔn)確性。進(jìn)一步說，只要不包含 IP 查詢條件的所有 TP 數(shù)據(jù)都失真了。分位數(shù)這類必須建立在全局樣本之上才能有正確計算的統(tǒng)計值。

這套高效的數(shù)據(jù)中心系統(tǒng)架構(gòu)需要基于實時計算或離線計算技術(shù)體系實現(xiàn)，參考業(yè)界主流數(shù)據(jù)處理方案，對比如下：

設(shè)計思路：

1. 解決穩(wěn)定性問題，思路是（1）將計算節(jié)點無狀態(tài)化（2）基于心跳機(jī)制自動剔除異常節(jié)點并由新節(jié)點承載任務(wù)（3）消息隊列削峰。
2. 解決海量數(shù)據(jù)計算問題，思路是（1）在線&離線計算隔離，兩者的公共子計算前置只計算一次（2）高并發(fā)高吞吐能力設(shè)計（3）理論無上限的水平擴(kuò)展能力設(shè)計。
3. 解決熱點問題，思路是（1）優(yōu)化計算量分配算法，如均衡 Hash（2）理論無上限的水平擴(kuò)展能力設(shè)計。
4. 解決水平擴(kuò)展問題，思路（1）是將單節(jié)點無法承載的計算模式改為局部分布式子計算并匯總，但這種方式可能會對數(shù)據(jù)準(zhǔn)確性造成較大影響，數(shù)據(jù)統(tǒng)計領(lǐng)域精確的分布式分位數(shù)才是最難問題，另外多維條件組織對分布式改造也相當(dāng)不利。（備注：其中在1.2.3第五條有詳細(xì)的解釋）

5. 解決海量數(shù)據(jù)分布式多維精確 TP 計算，采用局部分布式計算，然后基于拓?fù)錁浣M織數(shù)據(jù)計算流，在前置的計算結(jié)果精度不丟失的前提下，多階段逐級降維得到所有的計算結(jié)果。

技術(shù)方案：

數(shù)據(jù)流解析

系統(tǒng)根據(jù)待統(tǒng)計的維度構(gòu)建了一棵遞推拓?fù)錁洌缦聢D所示。其中黃色的部分代表消息隊列（每個矩形代表一個 topic），綠色部分代表一個計算子集群（消費前置 topic 多個 partition，統(tǒng)計自己負(fù)責(zé)維度的數(shù)據(jù)指標(biāo)并存儲，同時聚合壓縮向后繼續(xù)發(fā)）。除“原始采集數(shù)據(jù) topic 外”，其他 topic 和 consumer 所在維度對應(yīng)數(shù)據(jù)的檢索條件（如標(biāo)紅二級 topic ：主機(jī)+接口，代表同時指定主機(jī)和接口的指標(biāo)查詢數(shù)據(jù)），紅色箭頭代表數(shù)據(jù)流向。

拓?fù)錁湫谓Y(jié)構(gòu)的各個子集群所對應(yīng)的維度標(biāo)識集合，必為其父計算集群對應(yīng)維度標(biāo)識集合的真子集（如下圖最上面鏈路，“主機(jī)+接口+遠(yuǎn)程服務(wù)”3個維度一定包含“主機(jī)+接口”兩個維度。“主機(jī)+接口”兩個維度包含“主機(jī)”維度）。集群間數(shù)據(jù)傳輸，采用批量聚合壓縮后在消息隊列媒介上通信完成，在計算過程中實現(xiàn)降維。

計算模式解析

下面詳細(xì)介紹數(shù)據(jù)拓?fù)錁渲蟹植际阶蛹旱挠嬎隳Ｊ剑?/span>

首先，維度值相同的所有數(shù)據(jù)會在本層級集群內(nèi)落到同一計算節(jié)點。每個計算子集群中的各計算節(jié)點，從消息隊列消費得到數(shù)據(jù)并按自身維度進(jìn)行聚合（前置集群已經(jīng)按當(dāng)前集群維度指定分發(fā)，所以聚合率很高），得到若干計數(shù)卡表（計數(shù)卡表即指定維度的時延、錯誤數(shù)等指標(biāo)與具體計數(shù)的映射 Map）。

其次，將聚合后的計數(shù)卡表與現(xiàn)有的相同維度合并計算，并在時間窗口存儲指標(biāo)。

若計算集群有后續(xù)的子計算集群，則基于后繼集群的目標(biāo)維度，根據(jù)目標(biāo)維度屬性做散列計算，并將相同散列碼的計數(shù)卡表聚合壓縮后發(fā)到后繼 partition。

離線的天級計算復(fù)用了三級維度、二級維度的多項結(jié)果，各環(huán)節(jié)前面計算的結(jié)果為后面多個計算集群復(fù)用，任何一個服務(wù)的數(shù)據(jù)都是在分布式計算。此外，整個計算過程中維護(hù)著技術(shù)卡表的映射關(guān)系，對于 TP 數(shù)據(jù)來說就是精確計算的，不會失真。

整個計算過程中，前置計算結(jié)果會被多個直接及間接后續(xù)子計算復(fù)用（如三級聚合計算對二級和一級都是有效的），在很大程度上減少了計算量。

1. 高吞吐 & 擴(kuò)展性關(guān)鍵設(shè)計

• 去計算熱點：組織多級散列數(shù)據(jù)流，逐級降維。

• 降計算量：前置子計算結(jié)果復(fù)用，分布式多路歸并。

• 將網(wǎng)絡(luò)IO，磁盤IO：優(yōu)化 PB 序列化算法，自管理 MQ 批量。

• 去存儲熱點：消除 HBase Rowkey 熱點。

• 無鎖處理：自研線程分桶的流、批處理模型，全局無鎖。

• 全環(huán)節(jié)水平擴(kuò)展：計算、傳輸、存儲均水平擴(kuò)展。

2. 系統(tǒng)高可靠、低運維、數(shù)據(jù)準(zhǔn)確性高于5個9關(guān)鍵設(shè)計

• 無狀態(tài)化 + 快速自愈：節(jié)點無狀態(tài)化，宕機(jī)秒級感知自愈。

• 異常實時感知：異常節(jié)點通過心跳摘除，異常數(shù)據(jù)遷移回溯。

• 故障隔離容災(zāi)：各維度獨立隔離故障范圍；多機(jī)房容災(zāi)。

• 逐級降維過程中數(shù)據(jù)不失真，精確的 TP 計算模式。

3. 提升實時性關(guān)鍵設(shè)計

• 流式拓?fù)淠Ｐ停植际阶佑嬎憬Y(jié)果復(fù)用，計算量逐級遞減。

• 無鎖處理：自研線程分桶的流、批處理模型，全局無鎖。

• 異常實時監(jiān)測自愈：計算節(jié)點異常時迅速 Rebalance，及時自愈。

• 秒級計算流獨立，內(nèi)存存儲。

新數(shù)據(jù)中心架構(gòu)收益

1. 目前日均處理數(shù)據(jù)量超萬億，系統(tǒng)可支撐日10萬億+量級并具備良好的擴(kuò)展能力；秒峰值可處理5億+數(shù)據(jù)；單服務(wù)日吞吐上限提升1000倍+，單服務(wù)可以支撐5000億數(shù)據(jù)計算。
2. 最大時延從4小時+降低到2min-，秒級指標(biāo)時延 TP99 達(dá)到 6s；平均時延從4.7分+降低到1.5分-，秒級指標(biāo)平均時延6s。
3. 上線后集群未發(fā)生雪崩，同時宕機(jī)1/3實例2秒內(nèi)自動化自愈。
4. 支持多維度的準(zhǔn)實時精確 TP 計算，最高支持到 TP 6個9；支持所有服務(wù)所有維度統(tǒng)計。

5. 千余節(jié)點集群運維投入從周20小時+降低至10分以下。

Octo系統(tǒng)是非常龐大與復(fù)雜的架構(gòu)，可以發(fā)現(xiàn)整個架構(gòu)中的任意幾個環(huán)節(jié)都是值得大家學(xué)習(xí)與深挖的，巨大體量下的架構(gòu)問題總會有很多相通的問題，解決方案也類似，只有不斷揣摩、參考這種業(yè)界成熟的解決方案，我們才可以在自己系統(tǒng)架構(gòu)設(shè)計過程中游刃有余。