B站直播的極速排障建設-全鏈路Trace追蹤
一、概述
直播業務具有實時性強，復雜度高，排查鏈路長，影響面大等特征，線上問題如果不能立刻排查處理，分分秒秒都在影響用戶的觀看體驗、主播的收入。
但各端的問題可能都只是表象，例如，一個看似簡單的畫面卡頓問題，可能涉及到編碼器配置、網絡帶寬分配、服務器負載等多個方面，各個團隊經常在等待合作方的反饋，一整套流程下來，一個線上問題的定位可能要消耗掉數小時的人力。
我們迫切的需要一套高效的跨端實時排障系統！
為此我們采取了以下措施：
- 關鍵業務監控：聯合各協作方，對關鍵業務的接口、廣播和核心處理邏輯實施了實時埋點監控，并附加了相關場景信息，確保了問題定位的準確性和全面性。
- 統一追蹤系統：為了實現單個業務鏈路所有埋點的跨端聯絡，我們設計了統一的trace_id字段，并在數據層進行串聯，通過看板直觀展示，極大地提升了問題追蹤和定位的效率。
這些措施帶來了顯著的成效：
- 跨部門協作效率提升：通過實時數據共享和統一追蹤系統，直播移動端、PC端、Web端、服務端以及流媒體等各個團隊協作效率大幅提升。在開播、視頻連線等9個核心業務的故障排查中，排障率達到了91%，異常定位的平均時間從2小時縮短至僅需5分鐘。兄弟部門也采納了我們的方案，有效減輕了工作壓力。
- 系統穩定性增強：這些措施還幫助我們優化了開播異常斷流、連麥發布訂閱失敗等多項關鍵業務問題，確保了系統的高效運行，減少了因技術問題導致的用戶流失。
- 用戶體驗改善：我們的快速響應和問題解決能力極大地提升了主播和用戶的直播體驗。用戶和主播的正面反饋絡繹不絕，間接提高了主播收入穩定性，增強了平臺的吸引力。
二、技術方案詳解
1. 方案設計
圖片
如上圖所示，整體全鏈路排障建設可以分為數據采集、數據處理&存儲、可視化工具建設3大塊。
在開始介紹實現方案之前，需要簡單介紹一下OpenTracing，它是業內實現分布式鏈路追蹤系統通常會采用的方案，我們在后續的埋點和上報組件設計也對它進行了一些參考。OpenTracing定義了追蹤數據所需要的操作和數據結構，幫助開發人員實現分布式追蹤的能力。OpenTracing里面有兩個比較核心的概念，簡單說明一下：
Trace：Trace代表一條追蹤路徑，它由多個Span組成，存在一個唯一ID
Span：Span代表追蹤路徑中的一個時間跨度，包括操作名稱、開始時間、結束時間等信息，由SpanID作為標識。由多個 Span 可以形成一條追蹤路徑。Span還定義了父子、跟隨兩種關系。在Span上下文中，記錄和維護了Trace的ID和當前Span的ID。
下圖是OpenTracing的模型圖，它描述了由多個Span組成一條追蹤路徑：
圖片
OpenTracing在服務端得到了廣泛的使用，但是面臨客戶端業務現狀和問題，我們調整了最終方案的實現方式
- 直播場景用戶行為一般都是即時操作，時間片段的設計并太不合適
- OpenTracing是跨編程語言的標準，一些API的設計比較抽象，在業務中使用不友好
考慮到這些，我們借鑒了OpenTracing中核心的概念：trace_id和事件上下文，并簡化了OpenTracing中Span的概念，嘗試復用端上已有的埋點，擴展字段來實現全鏈路Trace的能力。下面我們開始介紹。
首先要確認的是必須上報的埋點字段。為了減輕理解和上報的成本，在設計上我們希望盡可能簡單。實際上，這些字段的設計也是為了解決幾個關鍵的問題：
1.1 如何將各端的埋點關聯起來？
trace_id：一個復雜的事件鏈路往往并不是單端閉環的。拿邀請上麥舉例，它涉及到主播客戶端A -> 業務服務 -> 廣播服務 -> 觀眾客戶端B -> RTC。我們希望將這一次事件鏈路中相關的日志都能聚合起來呈現，而不是各端查各端的。為了解決這個問題，我們生成一個全鏈路都會透傳的唯一ID，在每個端的上報中都會攜帶這個ID，然后通過這個ID，把這次事件關聯的上報檢索出來，一起展示。
1.2 如何解決日志中缺失的上下文？
extends：我們在上報中增加了擴展數據，用于攜帶上下文以及自己關心的信息，同時在可視化工具中展示出來。
1.3 如何快速的找到異常的環節？
level：我們給每一個上報定義了3種狀態，正常、警告和異常。在可視化工具中，針對警告和異常狀態的上報，用黃色和紅色展示出來，這樣可以第一時間定位到出現問題的地方，找到負責的端和同學。
1.4 如何衡量這次的事件是否正常？
type：我們給每一個上報節點定義了3種類型，起始、過程和結束。一次事件執行中，會有一個起始節點，一個結束節點和多個過程節點。如果這次事件執行鏈路里面，有結束節點，并且所有節點的狀態都是正常的，那我們就認為這次事件執行是正常，否則就是異常的
到這里，最主要的埋點字段就介紹完了，接下來就只需要各端在關鍵路徑上添加上報即可。
在上線驗證階段，移動端先通過透傳trace_id的方式快速上線并打通了整條鏈路，驗證了可行性。但是這種方式弊端很大，代碼入侵嚴重而且健壯性差，對于業務同學來說這是非常勸退的，所以我們針對上報組件做了一些設計，目的是降低接入和維護成本，減少代碼入侵。
2. 上報組件設計
上報組件隨項目發展共迭代了三個版本，每一版都比上一版更加易用和完善。下面介紹我們的迭代過程，共分為“快速驗證可行性”、“大幅提升易用性” 和 “繼續增強魯棒性”。
2.1 快速驗證可行性
在項目初期，為了快速驗證鏈路可行性，上報組件未做過多設計，僅實現了最基礎的功能：
將上述的基礎字段（trace_id, level, type等）、業務方自定義參數以及公共參數（房間信息、網絡、推流、設備、外設情況、線程id等）進行上報。
在最初版中，我們將所有的非公共參數都寫到了函數入參中，并在業務層透傳了trace_id。如圖所示：
圖片
2.2 大幅提升易用性
2.2.1 快速方案遇到的問題
基礎功能上線后，驗證了我們通過trace_id串聯起多個埋點的想法是可行的。隨著越來越多的業務接入，顯而易見的兩個問題便浮上水面：
- 上報代碼過于繁雜：由于需要8個參數，需要多行代碼才能完成一次上報，在業務代碼中插入這一塊又一塊的和業務無關的代碼，會嚴重降低可讀性和可維護性；
- 業務入侵性大：在低耦合的代碼架構下，一個功能點的實現經常橫跨1～3個模塊、縱深5～10層方法調用，想要做到精確的全鏈路追蹤，勢必要將trace_id透傳，這樣就需要在每個方法的入參都增加一個trace_id的參數，不僅寫起來麻煩，還對業務的入侵性巨大；
這里舉兩個實際的代碼例子：
圖片
圖片
接下來我們就這兩個問題對埋點組件進行優化：
2.2.2 解決埋點代碼冗長
需要在業務層和上報層中間插入一個埋點聚合層，負責組裝參數，并針對每一個節點向外提供一個簡明的方法，在業務層就只需要一行簡短的代碼就可以完成上報了。
在埋點聚合層中，我們也做了一些簡單的設計，旨在減少業務方的代碼量：
- 盡力減少上報方法傳參的數量，將需要的參數都封裝進一個事件模型類中，并針對起始節點提供便利構造方法。且將入參node_type、trace_id、level、extends字段加上默認值，這樣對于大部分的節點，就不再需要攜帶所有的參數了。
- 針對每個業務類型都額外做了一層封裝，這樣就不用每次都填寫event_type字段了，進一步的減少了代碼量。至此，對于普通節點，甚至只需要指定key和log兩個字段就可以完成上報了。
下面是解決第一個問題（埋點代碼冗長）的簡單圖示：
2.2.3 解決業務入侵性
業內流行使用插樁的方式來進行非入侵式的埋點，但切面的形式很難獲取業務上下文，無法解決方法A調用方法B的trace_id透傳問題，因此并不適用于這個場景。
對于trace_id透傳的問題，解決方案是把trace_id緩存一下。但是需要解決以下場景的問題：
- 多線程并發：并行啟動了多次同一個事件，且他們的完成時間也不固定，如同時上傳了多張大小不一的封面。
- 事件中斷：前一次事件因為某些原因中斷了，永遠的停留在了某個節點。
為此，我們首先引入狀態機的概念，將所有節點使用有向圖進行表示，這樣我們便能清晰的感知到事件的發生到結束，以及某個節點后續可以流轉至哪些節點、是否發生錯誤中斷。
圖片
下面舉一個具體的例子，上麥流程圖和其對應的有向圖：
圖片
圖中使用了虛實線來區分跨端或者跨線程的動作，其必要性可參見下文第(2)點。
（1）自動化尋找trace_id
當一個起始節點準備上報時：
- 為其創建一個上報實例
- 在實例中記錄trace_id、當前的節點，以及它之后可能會流轉到的節點
- 將這個實例扔到池子中
當一個非起始節點準備上報時：
- 組件會根據有向圖去池子中查找需要流轉到的節點
- 使用實例的trace_id進行上報
- 更新實例的時間戳
- 將實例流轉到下一個節點，若無后續節點，則移除實例
（2）解決多線程問題
這個方案似乎很完美，但從B到E是一個網絡接口請求，如果先后很快地發出了兩次請求，很可能會出現下面的情況：
圖片
如果遵照上述的方案，B和E之間就會被錯誤的關聯起來。為了規避這個問題，trace_id會在跨線程時從埋點組件中外拋，需要業務方短暫記錄，并傳遞到下一個節點。當然，針對常用的網絡請求，我們也做了易用的封裝，詳見2.3.1。
于是之前上麥的有向圖會變為：
圖片
在多線程問題解決之后，當一個含有trace_id的節點進入上報組件時，即會為其創建一個上報實例，按上文記錄字段后放到池子里。
至于無trace_id的上報則完全相同，唯一的區別就是在查找節點時，加上線程id的校驗，這樣可以防止同一事件在不同的線程中同時啟動。
在trace_id已經被自動化后，整體的上報流程圖如下：
圖片
2.2.4 提升易用性后的代碼架構
圖片
2.3 繼續增強魯棒性
2.3.1 對“接口與廣播”的封裝
在端上遇到的跨線程/跨端場景絕大多數都是網絡請求和廣播，因此，為了避免出錯和降低復雜度，我們做了一套易用的封裝：
1. 網絡請求
（1）組件會在發起指定請求之前通過有向圖自動尋路獲取此次trace_id
（2）使用該trace_id上報請求事件，并會自動帶上所有的業務請求參數
（3）將trace_id置于請求頭，用于串聯服務端節點
（4）在接口返回后，自動上報響應數據，若接口錯誤，會將該節點標記為error
2. 廣播
（1）組件會在指定廣播到達時，嘗試去獲取trace_id字段。
（2）若獲取成功，則自動進行上報，若沒有，則會走自動化上報流程。
這樣，業務方即使遇到跨線程/跨端，也無需關心trace_id了，在這兩種場景下徹底做到了業務無感。
2.3.2 對“抗風險能力”的補足
當業務鏈路與對應的有向圖不符時，trace_id的自動化管理便會失效。為此我們設計了特殊異常case的監控：
1. 事件跟蹤上下文丟失
自動化尋找trace_id失敗，此種情況多發生在上報的埋點與有向圖描述不符，此時埋點組件會上報一個警告埋點觸達開發及時修改鏈路。
2. 事件跟蹤超時
即上次單線程的流轉還未結束，新的節點就已到達。此種情況多發生在流轉過程被意外打斷，如check失敗后直接return。此時原事件在看板中會表現為鏈路中斷的錯誤。同樣的，會上報一個警告埋點。
2.4 上報組件整體概覽
圖片
3. 數據處理和存儲
在處理上報的海量數據時，需要清洗掉錯誤的數據，并解析各個終端上報的不同數據結構，轉化為統一數據模型。由于數據是逐條上報的，必須將這些離散數據串聯成完整的事件鏈路，這樣就知道用戶操作了什么、經歷了哪些端、哪些節點出了問題或漏了哪些節點。
3.1 事件串聯
（1）單trace_id串聯：事件由唯一的trace_id串聯整個流程。
（2）多trace_id串聯：事件由多端各自的trace_id組合而成。
為兼容業務服務和廣播服務各自獨立的trace追蹤系統，我們實現了一套多重映射算法，且無縫兼容了單trace_id方案，最終溯源成事件開始的原始trace_id。
圖片
3.2 數據清洗與存儲
為應對直播的實時性要求，我們采用流計算技術。先快速篩選出trace相關事件，再清洗掉異常數據，在單次流計算執行過程中進行映射建立關系并落表存儲，實現小于5min級別的數據響應處理。數據表支持靈活的定制化查詢和分析需求。
圖片
4. 數據可視化
可視化簡化了查詢過程，能快速準確地捕捉異常和關鍵信息。適用于開發、測試、產品、運營、客服等角色。
4.1 覆蓋場景
從App啟動到退出，從開播到關播，從上麥到下麥，從PK發起到結束等關鍵業務場景。
圖片
4.2 落地效果
在日常業務中，已經有效解決了很多實際問題，以下是遇到的一些案例查詢：
圖片
三、結束語
不知何時起，“用關鍵鏈路查一下”已經成了身邊同事常說的口頭禪，整套排障體系的價值，也得到了驗證。
未來還有許多要做的事，我們將致力于拓展業務覆蓋面、建立業務健康度監控體系、提升上下文信息的有效性等。
我們相信，通過不斷的技術創新和服務優化，我們的業務能夠迎接更大的挑戰，為用戶創造更大的價值。
