?1、背景

近年來，互聯(lián)網(wǎng)服務(wù)的響應(yīng)延遲(latency)對用戶體驗的影響愈發(fā)重要，然而當(dāng)前對于服務(wù)接口的延遲分析卻沒有很好的手段。特別是互聯(lián)網(wǎng)業(yè)務(wù)迭代速度快，功能更新周期短，必須在最短的時間內(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ù)作為億級用戶量的大型分布式服務(wù)，也成功落地應(yīng)用關(guān)鍵路徑延遲分析平臺，在優(yōu)化產(chǎn)品延遲、保障用戶體驗方面發(fā)揮了重要的作用。本文介紹面向在線服務(wù)常用的延遲分析方法，并詳細(xì)介紹關(guān)鍵路徑分析的技術(shù)實(shí)現(xiàn)和平臺化方案，最后結(jié)合實(shí)際案例，說明如何在百度App推薦服務(wù)中收獲實(shí)際業(yè)務(wù)收益。

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

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

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

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

2.1 RPC監(jiān)控

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

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

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

2.2 CPU Profiling

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

△圖3 cpu火焰圖

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

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

2.3 分布式追蹤

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

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

分布式追蹤將要追蹤的“節(jié)點(diǎn)”通過span標(biāo)識，將spans按照特定方式構(gòu)建成trace，效果如圖4所示，從左到右表示時間線上的不同節(jié)點(diǎn)耗時，同一個起始點(diǎn)表示并發(fā)執(zhí)行。這需要收集所有跨服務(wù)請求的信息，包括具體的時間點(diǎn)以及調(diào)用的父子關(guān)系，從而在外部還原系統(tǒng)調(diào)用的拓?fù)潢P(guān)系，包含每個服務(wù)工作的開始和結(jié)束時間，以及服務(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ù)目有時過于龐大，甚者達(dá)到成百上千個，這就使得成本成為了分布式跟蹤進(jìn)行詳細(xì)延遲分析的主要障礙，為了在成本和數(shù)據(jù)量之間進(jìn)行權(quán)衡，往往會放棄細(xì)粒度的追蹤組件，這就使得分析人員需要花費(fèi)額外的精力去進(jìn)一步分析延遲真正的“耗費(fèi)點(diǎn)”。

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

3、關(guān)鍵路徑分析

3.1 介紹

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

△圖5 加上耗時信息的示例系統(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 ，因此這個系統(tǒng)的關(guān)鍵路徑為紅色線條的路徑 A1->A2->B1->B4->B2->A4。

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

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

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

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

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

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

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

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

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

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

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

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

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

• 服務(wù)關(guān)鍵路徑匯聚?

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

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

這部分主要是對于核心路徑比較分散的子節(jié)點(diǎn)，例如B中B1訪問B3/B4/B5等多個下游（在實(shí)際的系統(tǒng)中可能有數(shù)十個節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中，但是沒有一個節(jié)點(diǎn)有絕對的核心占比，各個節(jié)點(diǎn)在關(guān)鍵路徑中相對比較分散，且經(jīng)常周期性改變）,對這種情況直接統(tǒng)計并篩選出核心占比>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)鍵路徑的存儲和展示

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

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

• 核心占比：節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中的概率
• 核心貢獻(xiàn)度：節(jié)點(diǎn)出現(xiàn)在關(guān)鍵路徑中時，自身耗時占整個路徑總耗時的比例
• 綜合貢獻(xiàn)度：核心占比和核心貢獻(xiàn)度兩者相乘，作為綜合衡量的標(biāo)準(zhǔn)
• 均值：節(jié)點(diǎn)耗時的平均值
• 分位值：節(jié)點(diǎn)耗時的不同分位值。分位值是統(tǒng)計學(xué)中的概念，即把所有的數(shù)值從小到大排序，取前N%位置的值即為該分位的值，常用的有50分位、80分位、90分位等

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

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

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

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

4、應(yīng)用

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

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

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

5、總結(jié)

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