分散式系統關鍵路徑延遲分析實踐

作者 | 月色如海

導讀 

introduction

隨著對使用者體驗的不斷追求，延遲分析成為大型分散式系統中不可或缺的一環。本文介紹了目前線上服務中常用的延遲分析方法，重點講解了關鍵路徑分析的原理和技術實現方案，實踐表明此方案效果顯著，在耗時最佳化方面發揮了重要作用，希望這些內容能夠對有興趣的讀者產生啟發，並有所幫助。

全文4528字，預計閱讀時間12分鐘。

GEEK TALK

01

背景

近年來，網際網路服務的響應延遲(latency)對使用者體驗的影響愈發重要，然而當前對於服務介面的延遲分析卻沒有很好的手段。特別是網際網路業務迭代速度快，功能更新週期短，必須在最短的時間內定位到延遲瓶頸。然而，服務端一般都由分散式系統構成，內部存在著複雜的排程和併發呼叫關係，傳統的延遲分析方法效率低下，難以滿足當下網際網路服務的延遲分析需求。

關鍵路徑分析(Critical Path Tracing)作為近年來崛起的延遲分析方法，受到Google，Meta，Uber等公司的青睞，並在線上服務中獲得了廣泛應用。百度App推薦服務作為億級使用者量的大型分散式服務，也成功落地應用關鍵路徑延遲分析平臺，在最佳化產品延遲、保障使用者體驗方面發揮了重要的作用。本文介紹面向線上服務常用的延遲分析方法，並詳細介紹關鍵路徑分析的技術實現和平臺化方案，最後結合實際案例，說明如何在百度App推薦服務中收穫實際業務收益。

GEEK TALK

02

常用分散式系統延遲分析方法

當前業界常用的服務延遲分析有RPC監控(RPC telemetry)，CPU剖析(CPU Profiling)，分散式追蹤(Distributed Tracing)，下面以一個具體的系統結構進行舉例說明：

△圖1 系統結構示例

A、B、C、D、E分別為五個系統服務，A1到A4、B1到B5分別為A、B系統內的子元件(可以理解為A、B系統內部進一步的細化組成部分)，箭頭標識服務或元件之間的呼叫關係。

2.1 RPC監控

RPC是目前微服務系統之間常用的呼叫方式，業界主要開源的RPC框架有BRPC、GRPC、Thrift等。這些RPC框架通常都整合了統計列印功能，列印的資訊中含有特定的名稱和對應的耗時資訊，外部的監控系統（例如：Prometheus）會進行採集，並透過儀表盤進行展示。

△圖2 RPC耗時監控UI例項

此分析方式比較簡單直接，如果服務之間的呼叫關係比較簡單，則此方式是有效的，如果系統複雜，則基於RPC分析結果進行的最佳化往往不會有預期的效果。如圖1，A呼叫B，A2和A3是並行呼叫，A3內部進行復雜的CPU計算任務，如果A2的耗時高於A3，則分析A->B的RPC延時是有意義的，如果A3高於A2,則減少A->B的服務呼叫時間對總體耗時沒有任何影響。此外RPC分析無法檢測系統內部的子元件，對整體延遲的分析具有很大的侷限性。

2.2 CPU Profiling

CPU分析是將函式呼叫堆疊的樣本收集和聚合，高頻出現的函式認為是主要的延遲路徑，下圖是CPU火焰圖的展示效果：

△圖3 cpu火焰圖

水平的寬度表示抽樣的次數，垂直方向表示呼叫的關係，火焰圖通常是看頂層的哪個函式寬度最大，出現“平頂”表示該函式存在效能問題。

CPU Profiling可以解決上面說的RPC監控的不足，然而由於依然無法知曉並行的A2和A3誰的耗時高，因此按照RPC鏈路分析結果還是按照CPU分析的結果進行最佳化哪個真正有效果將變得不確定，最好的方式就是都進行最佳化，然而這在大型複雜的系統中成本將會變得很大。可見CPU Profiling同樣具有一定的侷限性。

2.3 分散式追蹤

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

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

分散式追蹤將要追蹤的“節點”透過span標識，將spans按照特定方式構建成trace，效果如圖4所示，從左到右表示時間線上的不同節點耗時，同一個起始點表示併發執行。這需要收集所有跨服務請求的資訊，包括具體的時間點以及呼叫的父子關係，從而在外部還原系統呼叫的拓撲關係，包含每個服務工作的開始和結束時間，以及服務間是並行執行還是序列執行的。

通常，大多數分散式跟蹤預設情況下包括RPC訪問，沒有服務內部子元件資訊，這需要開發人員根據自身系統的結構進行補全，然而系統內部自身執行的元件數目有時過於龐大，甚者達到成百上千個，這就使得成本成為了分散式跟蹤進行詳細延遲分析的主要障礙，為了在成本和資料量之間進行權衡，往往會放棄細粒度的追蹤元件，這就使得分析人員需要花費額外的精力去進一步分析延遲真正的“耗費點”。

下面介紹關鍵路徑分析的基本原理和實際的應用。

GEEK TALK

03

關鍵路徑分析

3.1 介紹

關鍵路徑在服務內部定義為一條耗時最長的路徑，如果將上面的子元件抽象成不同的節點，則關鍵路徑是由一組節點組成，這部分節點是分散式系統中請求處理速度最慢的有序集合。一個系統中可能有成百上千個子元件，但是關鍵路徑可能只有數十個節點，這樣數量級式的縮小使得成本大大降低。我們在上圖的基礎上加上各個子模組的耗時資訊。

△圖5 加上耗時資訊的示例系統結構

如圖5所示，在B中B1並行呼叫B3、B4、B5，延遲分別為100,150,120，然後再呼叫內部的B2，進行返回，關鍵路徑為B1->B4->B2，延遲為10 + 150 + 10 = 170，在A中A1並行呼叫A2，A3。A2和A3都完成後再呼叫A4，然後返回，關鍵路徑為A1->A2->A4，延遲為15 + 170 + 10 = 195 ，因此這個系統的關鍵路徑為紅色線條的路徑 A1->A2->B1->B4->B2->A4。

透過這個簡單的分散式系統結構表述出關鍵路徑，其描述了分散式系統中請求處理速度最慢步驟的有序列表。可見最佳化關鍵路徑上的節點肯定能達到降低整體耗時的目的。實際系統中的關鍵路徑遠比以上描述的複雜的多，下面進一步介紹關鍵路徑分析的技術實現和平臺化方案。

3.2 實際應用解決方案

關鍵路徑資料的採集到視覺化分析的流程如圖所示：

△圖6 資料處理流程

3.2.1 核心關鍵路徑的產出和上報

關鍵路徑由服務自身進行產出，一般大型分散式服務都會採用運算元化執行框架，只要整合到框架內部，所有依賴的服務都可以統一產出關鍵路徑。

對於運算元化執行框架，考慮到如下簡單的圖結構：

△圖7 一種簡單的圖結構

P1-P4是4個策略運算元，按照圖示排程執行。採集SDK收集每個運算元開始和結束的執行時刻，彙總為關鍵路徑基礎資料上報。

3.2.2 核心關鍵路徑的匯聚和計算

一個服務內部的關鍵路徑往往反映不了整個分散式系統延時的常態情況，這就需要將不同服務內部關鍵進行匯聚。這裡的匯聚是按照時間段進行匯聚，這就需要collector收到資料後按照上傳攜帶過來的時間點分到對應時間的視窗內，收集完成後進行各種延時指標的計算以及關鍵路徑的匯聚，這裡有三種匯聚方式:

1、節點關鍵路徑匯聚

這裡是將系統的關鍵路徑拼接到一起，組成一條完整路徑，將各個節點進行匯聚，選擇出現次數最多的路徑作為最“核心”的關鍵路徑。

2、服務關鍵路徑匯聚

節點關鍵路徑是節點粒度的表示形態，然而在一個系統中服務的路徑關係是怎樣的呢？這就需要服務關鍵路徑來表示。為了更好的表徵服務內部的耗時情況，對節點進行聚合抽象。將所有計算型節點統一歸為一個叫inner的節點，作為起始節點，其他訪問外部服務的節點不變，在重新轉換後的路徑中選擇出現次數最多的路徑作為服務關鍵路徑，聚合後的路徑可以標識服務“自身”和“外部”的延時分佈情況。

3、平鋪節點型別匯聚

這部分主要是對於核心路徑比較分散的子節點，例如B中B1訪問B3/B4/B5等多個下游（在實際的系統中可能有數十個節點出現在關鍵路徑中，但是沒有一個節點有絕對的核心佔比，各個節點在關鍵路徑中相對比較分散，且經常週期性改變）,對這種情況直接統計並篩選出核心佔比>x%（x%根據特定需求進行確定，x越小則收集到的關鍵節點越精細）的節點，需要注意的是這裡是平鋪取的節點，並不是一條“核心”的關鍵路徑。

3.2.3 核心關鍵路徑的儲存和展示

資料庫儲存的是計算好的結果，以時間、使用者型別、流量來源等作為查詢關鍵字，方便進行多維度分析。這裡使用OLAP Engine進行儲存，方便資料分析和查詢。

展示的內容主要有以下幾部分：

• 核心佔比：節點出現在關鍵路徑中的機率
  

• 核心貢獻度：節點出現在關鍵路徑中時，自身耗時佔整個路徑總耗時的比例

• 綜合貢獻度：核心佔比和核心貢獻度兩者相乘，作為綜合衡量的標準

• 均值：節點耗時的平均值
  

• 分位值：節點耗時的不同分位值。分位值是統計學中的概念，即把所有的數值從小到大排序，取前N%位置的值即為該分位的值，常用的有50分位、80分位、90分位等

核心佔比高貢獻度很低或者貢獻度高佔比很低的節點最佳化的效果往往不是很顯著，因此使用綜合貢獻度做為核心佔比和核心貢獻度的綜合考量，這個指標高的節點是我們需要重點關注的，也是最佳化收益較大的。

從耗時最佳化的角度出發，這裡有兩個主要的訴求，一個是查詢某個時間段的關鍵路徑，依此來指導進行特定節點或階段的最佳化。另一個是需要進行關鍵路徑的對比，找到diff的節點，挖掘具體的原因來進行最佳化，整體延時的退化往往是由於特定節點的惡化造成的，這裡的對比可以是不同時間、不同地域、甚至是不同流量成分的對比，這樣為延遲分析提供了多維度的指導依據。

關鍵路徑的效果如圖8所示，在頁面上可以按照特定維度進行排序，便於進一步的篩選。

△圖8 核心關鍵路徑示例

GEEK TALK

04

應用

百度App推薦系統內部建設了關鍵路徑延遲分析平臺Focus，已上線1年多，成功支援了日常的耗時分析和最佳化工作，保證了百度App Feed流推薦介面的毫秒級響應速度，提供使用者順滑的反饋體驗。獲得研發，運維和演算法團隊的一致好評。

以推薦服務的一個實際線上問題舉例，某天監控系統發現系統出口耗時突破監控閾值，關鍵路徑延遲分析平臺自動透過服務關鍵路徑定位到是某個服務B出了問題，然後透過觀察服務B的節點關鍵路徑發現是節點X有問題，然而節點X下游請求的是多個下游，這時透過平鋪節點型別發現平時耗時比較低的佇列Y延時突增，核心佔比和貢獻度都異常高，通知下游負責的owner進行定位，發現確實是服務本身異常，整個定位過程全自動化，無需人工按個模組排查。

△圖9 系統延遲異常後的自動定位分析過程

GEEK TALK

05

總結

在當下大型分散式系統中，服務介面的低響應延遲是保證使用者體驗的重要關鍵。各大公司也紛紛投入大量精力來最佳化延時，然而複雜的系統結構使得最佳化難度較大，這就需要藉助創新的最佳化方法。本文透過具體的例子介紹了關鍵路徑分析的原理，在百度App推薦系統中實際應用落地的平臺化方案，最後分享了實際案例。延遲耗時分析方向還有很多新的發展方向和創新空間，也歡迎對該方向感興趣的業界同仁一起探討。