隨著對(duì)用戶體驗(yàn)的不斷追求，延遲分析成為大型分布式系統(tǒng)中不可或缺的一環(huán)。本文介紹了目前在線服務(wù)中常用的延遲分析方法，重點(diǎn)講解了關(guān)鍵路徑分析的原理和技術(shù)實(shí)現(xiàn)方案，實(shí)踐表明此方案效果顯著，在耗時(shí)優(yōu)化方面發(fā)揮了重要作用，希望這些內(nèi)容能夠?qū)τ信d趣的讀者產(chǎn)生啟發(fā)，并有所幫助。? ? ??

背景

近年來，互聯(lián)網(wǎng)服務(wù)的響應(yīng)延遲(latency)對(duì)用戶體驗(yàn)的影響愈發(fā)重要，然而當(dāng)前對(duì)于服務(wù)接口的延遲分析卻沒有很好的手段。特別是互聯(lián)網(wǎng)業(yè)務(wù)迭代速度快，功能更新周期短，必須在最短的時(shí)間內(nèi)定位到延遲瓶頸。然而，服務(wù)端一般都由分布式系統(tǒng)構(gòu)成，內(nèi)部存在著復(fù)雜的調(diào)度和并發(fā)調(diào)用關(guān)系，傳統(tǒng)的延遲分析方法效率低下，難以滿足當(dāng)下互聯(lián)網(wǎng)服務(wù)的延遲分析需求。

關(guān)鍵路徑分析(Critical Path Tracing)作為近年來崛起的延遲分析方法，受到Google，Meta，Uber等公司的青睞，并在在線服務(wù)中獲得了廣泛應(yīng)用。百度App推薦服務(wù)作為億級(jí)用戶量的大型分布式服務(wù)，也成功落地應(yīng)用關(guān)鍵路徑延遲分析平臺(tái)，在優(yōu)化產(chǎn)品延遲、保障用戶體驗(yàn)方面發(fā)揮了重要的作用。本文介紹面向在線服務(wù)常用的延遲分析方法，并詳細(xì)介紹關(guān)鍵路徑分析的技術(shù)實(shí)現(xiàn)和平臺(tái)化方案，最后結(jié)合實(shí)際案例，說明如何在百度App推薦服務(wù)中收獲實(shí)際業(yè)務(wù)收益。

常用分布式系統(tǒng)延遲分析方法

當(dāng)前業(yè)界常用的服務(wù)延遲分析有RPC監(jiān)控(RPC telemetry)，CPU剖析(CPU Profiling)，分布式追蹤(Distributed Tracing)，下面以一個(gè)具體的系統(tǒng)結(jié)構(gòu)進(jìn)行舉例說明：

△圖1 系統(tǒng)結(jié)構(gòu)示例

A、B、C、D、E分別為五個(gè)系統(tǒng)服務(wù)，A1到A4、B1到B5分別為A、B系統(tǒng)內(nèi)的子組件(可以理解為A、B系統(tǒng)內(nèi)部進(jìn)一步的細(xì)化組成部分)，箭頭標(biāo)識(shí)服務(wù)或組件之間的調(diào)用關(guān)系。

2.1 RPC監(jiān)控

RPC是目前微服務(wù)系統(tǒng)之間常用的調(diào)用方式，業(yè)界主要開源的RPC框架有BRPC、GRPC、Thrift等。這些RPC框架通常都集成了統(tǒng)計(jì)打印功能，打印的信息中含有特定的名稱和對(duì)應(yīng)的耗時(shí)信息，外部的監(jiān)控系統(tǒng)（例如：Prometheus）會(huì)進(jìn)行采集，并通過儀表盤進(jìn)行展示。

△圖2 RPC耗時(shí)監(jiān)控UI實(shí)例

此分析方式比較簡(jiǎn)單直接，如果服務(wù)之間的調(diào)用關(guān)系比較簡(jiǎn)單，則此方式是有效的，如果系統(tǒng)復(fù)雜，則基于RPC分析結(jié)果進(jìn)行的優(yōu)化往往不會(huì)有預(yù)期的效果。如圖1，A調(diào)用B，A2和A3是并行調(diào)用，A3內(nèi)部進(jìn)行復(fù)雜的CPU計(jì)算任務(wù)，如果A2的耗時(shí)高于A3，則分析A->B的RPC延時(shí)是有意義的，如果A3高于A2,則減少A->B的服務(wù)調(diào)用時(shí)間對(duì)總體耗時(shí)沒有任何影響。此外RPC分析無法檢測(cè)系統(tǒng)內(nèi)部的子組件，對(duì)整體延遲的分析具有很大的局限性。

2.2 CPU?Profiling

CPU分析是將函數(shù)調(diào)用堆棧的樣本收集和聚合，高頻出現(xiàn)的函數(shù)認(rèn)為是主要的延遲路徑，下圖是CPU火焰圖的展示效果：

△圖3 cpu火焰圖

水平的寬度表示抽樣的次數(shù)，垂直方向表示調(diào)用的關(guān)系，火焰圖通常是看頂層的哪個(gè)函數(shù)寬度最大，出現(xiàn)“平頂”表示該函數(shù)存在性能問題。

CPU Profiling可以解決上面說的RPC監(jiān)控的不足，然而由于依然無法知曉并行的A2和A3誰(shuí)的耗時(shí)高，因此按照RPC鏈路分析結(jié)果還是按照CPU分析的結(jié)果進(jìn)行優(yōu)化哪個(gè)真正有效果將變得不確定，最好的方式就是都進(jìn)行優(yōu)化，然而這在大型復(fù)雜的系統(tǒng)中成本將會(huì)變得很大。可見CPU Profiling同樣具有一定的局限性。

2.3?分布式追蹤

分布式追蹤目前在各大公司都有了很好的實(shí)踐(例如Google的Dapper，Uber的Jaeger)。

△圖4 分布式追蹤效果示例

分布式追蹤將要追蹤的“節(jié)點(diǎn)”通過span標(biāo)識(shí)，將spans按照特定方式構(gòu)建成trace，效果如圖4所示，從左到右表示時(shí)間線上的不同節(jié)點(diǎn)耗時(shí)，同一個(gè)起始點(diǎn)表示并發(fā)執(zhí)行。這需要收集所有跨服務(wù)請(qǐng)求的信息，包括具體的時(shí)間點(diǎn)以及調(diào)用的父子關(guān)系，從而在外部還原系統(tǒng)調(diào)用的拓?fù)潢P(guān)系，包含每個(gè)服務(wù)工作的開始和結(jié)束時(shí)間，以及服務(wù)間是并行運(yùn)行還是串行運(yùn)行的。

通常，大多數(shù)分布式跟蹤默認(rèn)情況下包括RPC訪問，沒有服務(wù)內(nèi)部子組件信息，這需要開發(fā)人員根據(jù)自身系統(tǒng)的結(jié)構(gòu)進(jìn)行補(bǔ)全，然而系統(tǒng)內(nèi)部自身運(yùn)行的組件數(shù)目有時(shí)過于龐大，甚者達(dá)到成百上千個(gè)，這就使得成本成為了分布式跟蹤進(jìn)行詳細(xì)延遲分析的主要障礙，為了在成本和數(shù)據(jù)量之間進(jìn)行權(quán)衡，往往會(huì)放棄細(xì)粒度的追蹤組件，這就使得分析人員需要花費(fèi)額外的精力去進(jìn)一步分析延遲真正的“耗費(fèi)點(diǎn)”。

下面介紹關(guān)鍵路徑分析的基本原理和實(shí)際的應(yīng)用。

關(guān)鍵路徑分析

3.1 介紹

關(guān)鍵路徑在服務(wù)內(nèi)部定義為一條耗時(shí)最長(zhǎng)的路徑，如果將上面的子組件抽象成不同的節(jié)點(diǎn)，則關(guān)鍵路徑是由一組節(jié)點(diǎn)組成，這部分節(jié)點(diǎn)是分布式系統(tǒng)中請(qǐng)求處理速度最慢的有序集合。一個(gè)系統(tǒng)中可能有成百上千個(gè)子組件，但是關(guān)鍵路徑可能只有數(shù)十個(gè)節(jié)點(diǎn)，這樣數(shù)量級(jí)式的縮小使得成本大大降低。我們?cè)谏蠄D的基礎(chǔ)上加上各個(gè)子模塊的耗時(shí)信息。

△圖5 加上耗時(shí)信息的示例系統(tǒng)結(jié)構(gòu)

如圖5所示，在B中B1并行調(diào)用B3、B4、B5，延遲分別為100,150,120，然后再調(diào)用內(nèi)部的B2，進(jìn)行返回，關(guān)鍵路徑為B1->B4->B2，延遲為10 + 150 + 10 = 170，在A中A1并行調(diào)用A2，A3。A2和A3都完成后再調(diào)用A4，然后返回，關(guān)鍵路徑為A1->A2->A4，延遲為15 + 170 + 10 = 195 ，因此這個(gè)系統(tǒng)的關(guān)鍵路徑為紅色線條的路徑?A1->A2->B1->B4->B2->A4。

通過這個(gè)簡(jiǎn)單的分布式系統(tǒng)結(jié)構(gòu)表述出關(guān)鍵路徑，其描述了分布式系統(tǒng)中請(qǐng)求處理速度最慢步驟的有序列表。可見優(yōu)化關(guān)鍵路徑上的節(jié)點(diǎn)肯定能達(dá)到降低整體耗時(shí)的目的。實(shí)際系統(tǒng)中的關(guān)鍵路徑遠(yuǎn)比以上描述的復(fù)雜的多，下面進(jìn)一步介紹關(guān)鍵路徑分析的技術(shù)實(shí)現(xiàn)和平臺(tái)化方案。

3.2?實(shí)際應(yīng)用解決方案

關(guān)鍵路徑數(shù)據(jù)的采集到可視化分析的流程如圖所示：

△圖6 數(shù)據(jù)處理流程

3.2.1 核心關(guān)鍵路徑的產(chǎn)出和上報(bào)

關(guān)鍵路徑由服務(wù)自身進(jìn)行產(chǎn)出，一般大型分布式服務(wù)都會(huì)采用算子化執(zhí)行框架，只要集成到框架內(nèi)部，所有依賴的服務(wù)都可以統(tǒng)一產(chǎn)出關(guān)鍵路徑。

對(duì)于算子化執(zhí)行框架，考慮到如下簡(jiǎn)單的圖結(jié)構(gòu)：

△圖7 一種簡(jiǎn)單的圖結(jié)構(gòu)

P1-P4是4個(gè)策略算子，按照?qǐng)D示調(diào)度執(zhí)行。采集SDK收集每個(gè)算子開始和結(jié)束的運(yùn)行時(shí)刻，匯總為關(guān)鍵路徑基礎(chǔ)數(shù)據(jù)上報(bào)。

3.2.2 核心關(guān)鍵路徑的匯聚和計(jì)算

一個(gè)服務(wù)內(nèi)部的關(guān)鍵路徑往往反映不了整個(gè)分布式系統(tǒng)延時(shí)的常態(tài)情況，這就需要將不同服務(wù)內(nèi)部關(guān)鍵進(jìn)行匯聚。這里的匯聚是按照時(shí)間段進(jìn)行匯聚，這就需要collector收到數(shù)據(jù)后按照上傳攜帶過來的時(shí)間點(diǎn)分到對(duì)應(yīng)時(shí)間的窗口內(nèi)，收集完成后進(jìn)行各種延時(shí)指標(biāo)的計(jì)算以及關(guān)鍵路徑的匯聚，這里有三種匯聚方式:

1、節(jié)點(diǎn)關(guān)鍵路徑匯聚

這里是將系統(tǒng)的關(guān)鍵路徑拼接到一起，組成一條完整路徑，將各個(gè)節(jié)點(diǎn)進(jìn)行匯聚，選擇出現(xiàn)次數(shù)最多的路徑作為最“核心”的關(guān)鍵路徑。

2、服務(wù)關(guān)鍵路徑匯聚

節(jié)點(diǎn)關(guān)鍵路徑是節(jié)點(diǎn)粒度的表示形態(tài)，然而在一個(gè)系統(tǒng)中服務(wù)的路徑關(guān)系是怎樣的呢？這就需要服務(wù)關(guān)鍵路徑來表示。為了更好的表征服務(wù)內(nèi)部的耗時(shí)情況，對(duì)節(jié)點(diǎn)進(jìn)行聚合抽象。將所有計(jì)算型節(jié)點(diǎn)統(tǒng)一歸為一個(gè)叫inner的節(jié)點(diǎn)，作為起始節(jié)點(diǎn)，其他訪問外部服務(wù)的節(jié)點(diǎn)不變，在重新轉(zhuǎn)換后的路徑中選擇出現(xiàn)次數(shù)最多的路徑作為服務(wù)關(guān)鍵路徑，聚合后的路徑可以標(biāo)識(shí)服務(wù)“自身”和“外部”的延時(shí)分布情況。

3、平鋪節(jié)點(diǎn)類型匯聚

這部分主要是對(duì)于核心路徑比較分散的子節(jié)點(diǎn)，例如B中B1訪問B3/B4/B5等多個(gè)下游（在實(shí)際的系統(tǒng)中可能有數(shù)十個(gè)節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中，但是沒有一個(gè)節(jié)點(diǎn)有絕對(duì)的核心占比，各個(gè)節(jié)點(diǎn)在關(guān)鍵路徑中相對(duì)比較分散，且經(jīng)常周期性改變）,對(duì)這種情況直接統(tǒng)計(jì)并篩選出核心占比>x%（x%根據(jù)特定需求進(jìn)行確定，x越小則收集到的關(guān)鍵節(jié)點(diǎn)越精細(xì)）的節(jié)點(diǎn)，需要注意的是這里是平鋪取的節(jié)點(diǎn)，并不是一條“核心”的關(guān)鍵路徑。

3.2.3 核心關(guān)鍵路徑的存儲(chǔ)和展示

數(shù)據(jù)庫(kù)存儲(chǔ)的是計(jì)算好的結(jié)果，以時(shí)間、用戶類型、流量來源等作為查詢關(guān)鍵字，方便進(jìn)行多維度分析。這里使用OLAP Engine進(jìn)行存儲(chǔ)，方便數(shù)據(jù)分析和查詢。

展示的內(nèi)容主要有以下幾部分：

核心占比：節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中的概率

核心貢獻(xiàn)度：節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中時(shí)，自身耗時(shí)占整個(gè)路徑總耗時(shí)的比例

綜合貢獻(xiàn)度：核心占比和核心貢獻(xiàn)度兩者相乘，作為綜合衡量的標(biāo)準(zhǔn)

均值：節(jié)點(diǎn)耗時(shí)的平均值

分位值：節(jié)點(diǎn)耗時(shí)的不同分位值。分位值是統(tǒng)計(jì)學(xué)中的概念，即把所有的數(shù)值從小到大排序，取前N%位置的值即為該分位的值，常用的有50分位、80分位、90分位等

核心占比高貢獻(xiàn)度很低或者貢獻(xiàn)度高占比很低的節(jié)點(diǎn)優(yōu)化的效果往往不是很顯著，因此使用綜合貢獻(xiàn)度做為核心占比和核心貢獻(xiàn)度的綜合考量，這個(gè)指標(biāo)高的節(jié)點(diǎn)是我們需要重點(diǎn)關(guān)注的，也是優(yōu)化收益較大的。

從耗時(shí)優(yōu)化的角度出發(fā)，這里有兩個(gè)主要的訴求，一個(gè)是查詢某個(gè)時(shí)間段的關(guān)鍵路徑，依此來指導(dǎo)進(jìn)行特定節(jié)點(diǎn)或階段的優(yōu)化。另一個(gè)是需要進(jìn)行關(guān)鍵路徑的對(duì)比，找到diff的節(jié)點(diǎn)，挖掘具體的原因來進(jìn)行優(yōu)化，整體延時(shí)的退化往往是由于特定節(jié)點(diǎn)的惡化造成的，這里的對(duì)比可以是不同時(shí)間、不同地域、甚至是不同流量成分的對(duì)比，這樣為延遲分析提供了多維度的指導(dǎo)依據(jù)。

關(guān)鍵路徑的效果如圖8所示，在頁(yè)面上可以按照特定維度進(jìn)行排序，便于進(jìn)一步的篩選。

△圖8 核心關(guān)鍵路徑示例

應(yīng)用

百度App推薦系統(tǒng)內(nèi)部建設(shè)了關(guān)鍵路徑延遲分析平臺(tái)Focus，已上線1年多，成功支持了日常的耗時(shí)分析和優(yōu)化工作，保證了百度App Feed流推薦接口的毫秒級(jí)響應(yīng)速度，提供用戶順滑的反饋體驗(yàn)。獲得研發(fā)，運(yùn)維和算法團(tuán)隊(duì)的一致好評(píng)。

以推薦服務(wù)的一個(gè)實(shí)際線上問題舉例，某天監(jiān)控系統(tǒng)發(fā)現(xiàn)系統(tǒng)出口耗時(shí)突破監(jiān)控閾值，關(guān)鍵路徑延遲分析平臺(tái)自動(dòng)通過服務(wù)關(guān)鍵路徑定位到是某個(gè)服務(wù)B出了問題，然后通過觀察服務(wù)B的節(jié)點(diǎn)關(guān)鍵路徑發(fā)現(xiàn)是節(jié)點(diǎn)X有問題，然而節(jié)點(diǎn)X下游請(qǐng)求的是多個(gè)下游，這時(shí)通過平鋪節(jié)點(diǎn)類型發(fā)現(xiàn)平時(shí)耗時(shí)比較低的隊(duì)列Y延時(shí)突增，核心占比和貢獻(xiàn)度都異常高，通知下游負(fù)責(zé)的owner進(jìn)行定位，發(fā)現(xiàn)確實(shí)是服務(wù)本身異常，整個(gè)定位過程全自動(dòng)化，無需人工按個(gè)模塊排查。

△圖9 系統(tǒng)延遲異常后的自動(dòng)定位分析過程

總結(jié)

在當(dāng)下大型分布式系統(tǒng)中，服務(wù)接口的低響應(yīng)延遲是保證用戶體驗(yàn)的重要關(guān)鍵。各大公司也紛紛投入大量精力來優(yōu)化延時(shí)，然而復(fù)雜的系統(tǒng)結(jié)構(gòu)使得優(yōu)化難度較大，這就需要借助創(chuàng)新的優(yōu)化方法。本文通過具體的例子介紹了關(guān)鍵路徑分析的原理，在百度App推薦系統(tǒng)中實(shí)際應(yīng)用落地的平臺(tái)化方案，最后分享了實(shí)際案例。延遲耗時(shí)分析方向還有很多新的發(fā)展方向和創(chuàng)新空間，也歡迎對(duì)該方向感興趣的業(yè)界同仁一起探討。

編輯：黃飛

?