一、概述

直播業(yè)務具有實時性強，復雜度高，排查鏈路長，影響面大等特征，線上問題如果不能立刻排查處理，分分秒秒都在影響用戶的觀看體驗、主播的收入。

但各端的問題可能都只是表象，例如，一個看似簡單的畫面卡頓問題，可能涉及到編碼器配置、網(wǎng)絡帶寬分配、服務器負載等多個方面，各個團隊經常在等待合作方的反饋，一整套流程下來，一個線上問題的定位可能要消耗掉數(shù)小時的人力。

我們迫切的需要一套高效的跨端實時排障系統(tǒng)！

為此我們采取了以下措施：

1. 關鍵業(yè)務監(jiān)控：聯(lián)合各協(xié)作方，對關鍵業(yè)務的接口、廣播和核心處理邏輯實施了實時埋點監(jiān)控，并附加了相關場景信息，確保了問題定位的準確性和全面性。
2. 統(tǒng)一追蹤系統(tǒng)：為了實現(xiàn)單個業(yè)務鏈路所有埋點的跨端聯(lián)絡，我們設計了統(tǒng)一的trace_id字段，并在數(shù)據(jù)層進行串聯(lián)，通過看板直觀展示，極大地提升了問題追蹤和定位的效率。

這些措施帶來了顯著的成效：

• 跨部門協(xié)作效率提升：通過實時數(shù)據(jù)共享和統(tǒng)一追蹤系統(tǒng)，直播移動端、PC端、Web端、服務端以及流媒體等各個團隊協(xié)作效率大幅提升。在開播、視頻連線等9個核心業(yè)務的故障排查中，排障率達到了91%，異常定位的平均時間從2小時縮短至僅需5分鐘。兄弟部門也采納了我們的方案，有效減輕了工作壓力。
• 系統(tǒng)穩(wěn)定性增強：這些措施還幫助我們優(yōu)化了開播異常斷流、連麥發(fā)布訂閱失敗等多項關鍵業(yè)務問題，確保了系統(tǒng)的高效運行，減少了因技術問題導致的用戶流失。
• 用戶體驗改善：我們的快速響應和問題解決能力極大地提升了主播和用戶的直播體驗。用戶和主播的正面反饋絡繹不絕，間接提高了主播收入穩(wěn)定性，增強了平臺的吸引力。

二、技術方案詳解

1. 方案設計

圖片

如上圖所示，整體全鏈路排障建設可以分為數(shù)據(jù)采集、數(shù)據(jù)處理&存儲、可視化工具建設3大塊。

在開始介紹實現(xiàn)方案之前，需要簡單介紹一下OpenTracing，它是業(yè)內實現(xiàn)分布式鏈路追蹤系統(tǒng)通常會采用的方案，我們在后續(xù)的埋點和上報組件設計也對它進行了一些參考。OpenTracing定義了追蹤數(shù)據(jù)所需要的操作和數(shù)據(jù)結構，幫助開發(fā)人員實現(xiàn)分布式追蹤的能力。OpenTracing里面有兩個比較核心的概念，簡單說明一下：

Trace：Trace代表一條追蹤路徑，它由多個Span組成，存在一個唯一ID

Span：Span代表追蹤路徑中的一個時間跨度，包括操作名稱、開始時間、結束時間等信息，由SpanID作為標識。由多個 Span 可以形成一條追蹤路徑。Span還定義了父子、跟隨兩種關系。在Span上下文中，記錄和維護了Trace的ID和當前Span的ID。

下圖是OpenTracing的模型圖，它描述了由多個Span組成一條追蹤路徑：

圖片

OpenTracing在服務端得到了廣泛的使用，但是面臨客戶端業(yè)務現(xiàn)狀和問題，我們調整了最終方案的實現(xiàn)方式

• 直播場景用戶行為一般都是即時操作，時間片段的設計并太不合適
• OpenTracing是跨編程語言的標準，一些API的設計比較抽象，在業(yè)務中使用不友好

考慮到這些，我們借鑒了OpenTracing中核心的概念：trace_id和事件上下文，并簡化了OpenTracing中Span的概念，嘗試復用端上已有的埋點，擴展字段來實現(xiàn)全鏈路Trace的能力。下面我們開始介紹。

首先要確認的是必須上報的埋點字段。為了減輕理解和上報的成本，在設計上我們希望盡可能簡單。實際上，這些字段的設計也是為了解決幾個關鍵的問題：

1.1 如何將各端的埋點關聯(lián)起來？

trace_id：一個復雜的事件鏈路往往并不是單端閉環(huán)的。拿邀請上麥舉例，它涉及到主播客戶端A -> 業(yè)務服務 -> 廣播服務 -> 觀眾客戶端B -> RTC。我們希望將這一次事件鏈路中相關的日志都能聚合起來呈現(xiàn)，而不是各端查各端的。為了解決這個問題，我們生成一個全鏈路都會透傳的唯一ID，在每個端的上報中都會攜帶這個ID，然后通過這個ID，把這次事件關聯(lián)的上報檢索出來，一起展示。

1.2 如何解決日志中缺失的上下文？

extends：我們在上報中增加了擴展數(shù)據(jù)，用于攜帶上下文以及自己關心的信息，同時在可視化工具中展示出來。

1.3 如何快速的找到異常的環(huán)節(jié)？

level：我們給每一個上報定義了3種狀態(tài)，正常、警告和異常。在可視化工具中，針對警告和異常狀態(tài)的上報，用黃色和紅色展示出來，這樣可以第一時間定位到出現(xiàn)問題的地方，找到負責的端和同學。

1.4 如何衡量這次的事件是否正常？

type：我們給每一個上報節(jié)點定義了3種類型，起始、過程和結束。一次事件執(zhí)行中，會有一個起始節(jié)點，一個結束節(jié)點和多個過程節(jié)點。如果這次事件執(zhí)行鏈路里面，有結束節(jié)點，并且所有節(jié)點的狀態(tài)都是正常的，那我們就認為這次事件執(zhí)行是正常，否則就是異常的

到這里，最主要的埋點字段就介紹完了，接下來就只需要各端在關鍵路徑上添加上報即可。

在上線驗證階段，移動端先通過透傳trace_id的方式快速上線并打通了整條鏈路，驗證了可行性。但是這種方式弊端很大，代碼入侵嚴重而且健壯性差，對于業(yè)務同學來說這是非常勸退的，所以我們針對上報組件做了一些設計，目的是降低接入和維護成本，減少代碼入侵。

2. 上報組件設計

上報組件隨項目發(fā)展共迭代了三個版本，每一版都比上一版更加易用和完善。下面介紹我們的迭代過程，共分為“快速驗證可行性”、“大幅提升易用性” 和 “繼續(xù)增強魯棒性”。

2.1 快速驗證可行性

在項目初期，為了快速驗證鏈路可行性，上報組件未做過多設計，僅實現(xiàn)了最基礎的功能：

將上述的基礎字段（trace_id, level, type等）、業(yè)務方自定義參數(shù)以及公共參數(shù)（房間信息、網(wǎng)絡、推流、設備、外設情況、線程id等）進行上報。

在最初版中，我們將所有的非公共參數(shù)都寫到了函數(shù)入?yún)⒅?，并在業(yè)務層透傳了trace_id。如圖所示：

圖片

2.2 大幅提升易用性

2.2.1 快速方案遇到的問題

基礎功能上線后，驗證了我們通過trace_id串聯(lián)起多個埋點的想法是可行的。隨著越來越多的業(yè)務接入，顯而易見的兩個問題便浮上水面：

1. 上報代碼過于繁雜：由于需要8個參數(shù)，需要多行代碼才能完成一次上報，在業(yè)務代碼中插入這一塊又一塊的和業(yè)務無關的代碼，會嚴重降低可讀性和可維護性；
2. 業(yè)務入侵性大：在低耦合的代碼架構下，一個功能點的實現(xiàn)經常橫跨1～3個模塊、縱深5～10層方法調用，想要做到精確的全鏈路追蹤，勢必要將trace_id透傳，這樣就需要在每個方法的入?yún)⒍荚黾右粋€trace_id的參數(shù)，不僅寫起來麻煩，還對業(yè)務的入侵性巨大；

這里舉兩個實際的代碼例子：

圖片

圖片

接下來我們就這兩個問題對埋點組件進行優(yōu)化：

2.2.2 解決埋點代碼冗長

需要在業(yè)務層和上報層中間插入一個埋點聚合層，負責組裝參數(shù)，并針對每一個節(jié)點向外提供一個簡明的方法，在業(yè)務層就只需要一行簡短的代碼就可以完成上報了。

在埋點聚合層中，我們也做了一些簡單的設計，旨在減少業(yè)務方的代碼量：

1. 盡力減少上報方法傳參的數(shù)量，將需要的參數(shù)都封裝進一個事件模型類中，并針對起始節(jié)點提供便利構造方法。且將入?yún)ode_type、trace_id、level、extends字段加上默認值，這樣對于大部分的節(jié)點，就不再需要攜帶所有的參數(shù)了。
2. 針對每個業(yè)務類型都額外做了一層封裝，這樣就不用每次都填寫event_type字段了，進一步的減少了代碼量。至此，對于普通節(jié)點，甚至只需要指定key和log兩個字段就可以完成上報了。

下面是解決第一個問題（埋點代碼冗長）的簡單圖示：

2.2.3 解決業(yè)務入侵性

業(yè)內流行使用插樁的方式來進行非入侵式的埋點，但切面的形式很難獲取業(yè)務上下文，無法解決方法A調用方法B的trace_id透傳問題，因此并不適用于這個場景。

對于trace_id透傳的問題，解決方案是把trace_id緩存一下。但是需要解決以下場景的問題：

1. 多線程并發(fā)：并行啟動了多次同一個事件，且他們的完成時間也不固定，如同時上傳了多張大小不一的封面。
2. 事件中斷：前一次事件因為某些原因中斷了，永遠的停留在了某個節(jié)點。

為此，我們首先引入狀態(tài)機的概念，將所有節(jié)點使用有向圖進行表示，這樣我們便能清晰的感知到事件的發(fā)生到結束，以及某個節(jié)點后續(xù)可以流轉至哪些節(jié)點、是否發(fā)生錯誤中斷。

圖片

下面舉一個具體的例子，上麥流程圖和其對應的有向圖：

圖片

圖中使用了虛實線來區(qū)分跨端或者跨線程的動作，其必要性可參見下文第(2)點。

（1）自動化尋找trace_id

當一個起始節(jié)點準備上報時：

1. 為其創(chuàng)建一個上報實例
2. 在實例中記錄trace_id、當前的節(jié)點，以及它之后可能會流轉到的節(jié)點
3. 將這個實例扔到池子中

當一個非起始節(jié)點準備上報時：

1. 組件會根據(jù)有向圖去池子中查找需要流轉到的節(jié)點
2. 使用實例的trace_id進行上報
3. 更新實例的時間戳
4. 將實例流轉到下一個節(jié)點，若無后續(xù)節(jié)點，則移除實例

（2）解決多線程問題

這個方案似乎很完美，但從B到E是一個網(wǎng)絡接口請求，如果先后很快地發(fā)出了兩次請求，很可能會出現(xiàn)下面的情況：

圖片

如果遵照上述的方案，B和E之間就會被錯誤的關聯(lián)起來。為了規(guī)避這個問題，trace_id會在跨線程時從埋點組件中外拋，需要業(yè)務方短暫記錄，并傳遞到下一個節(jié)點。當然，針對常用的網(wǎng)絡請求，我們也做了易用的封裝，詳見2.3.1。

于是之前上麥的有向圖會變?yōu)椋?/p>

圖片

在多線程問題解決之后，當一個含有trace_id的節(jié)點進入上報組件時，即會為其創(chuàng)建一個上報實例，按上文記錄字段后放到池子里。

至于無trace_id的上報則完全相同，唯一的區(qū)別就是在查找節(jié)點時，加上線程id的校驗，這樣可以防止同一事件在不同的線程中同時啟動。

在trace_id已經被自動化后，整體的上報流程圖如下：

圖片

2.2.4 提升易用性后的代碼架構

圖片

2.3 繼續(xù)增強魯棒性

2.3.1 對“接口與廣播”的封裝

在端上遇到的跨線程/跨端場景絕大多數(shù)都是網(wǎng)絡請求和廣播，因此，為了避免出錯和降低復雜度，我們做了一套易用的封裝：

1.  網(wǎng)絡請求

（1）組件會在發(fā)起指定請求之前通過有向圖自動尋路獲取此次trace_id

（2）使用該trace_id上報請求事件，并會自動帶上所有的業(yè)務請求參數(shù)

（3）將trace_id置于請求頭，用于串聯(lián)服務端節(jié)點

（4）在接口返回后，自動上報響應數(shù)據(jù)，若接口錯誤，會將該節(jié)點標記為error

2.  廣播

（1）組件會在指定廣播到達時，嘗試去獲取trace_id字段。

（2）若獲取成功，則自動進行上報，若沒有，則會走自動化上報流程。

這樣，業(yè)務方即使遇到跨線程/跨端，也無需關心trace_id了，在這兩種場景下徹底做到了業(yè)務無感。

2.3.2 對“抗風險能力”的補足

當業(yè)務鏈路與對應的有向圖不符時，trace_id的自動化管理便會失效。為此我們設計了特殊異常case的監(jiān)控：

1.  事件跟蹤上下文丟失

自動化尋找trace_id失敗，此種情況多發(fā)生在上報的埋點與有向圖描述不符，此時埋點組件會上報一個警告埋點觸達開發(fā)及時修改鏈路。

2.  事件跟蹤超時

即上次單線程的流轉還未結束，新的節(jié)點就已到達。此種情況多發(fā)生在流轉過程被意外打斷，如check失敗后直接return。此時原事件在看板中會表現(xiàn)為鏈路中斷的錯誤。同樣的，會上報一個警告埋點。

2.4 上報組件整體概覽

圖片

3. 數(shù)據(jù)處理和存儲

在處理上報的海量數(shù)據(jù)時，需要清洗掉錯誤的數(shù)據(jù)，并解析各個終端上報的不同數(shù)據(jù)結構，轉化為統(tǒng)一數(shù)據(jù)模型。由于數(shù)據(jù)是逐條上報的，必須將這些離散數(shù)據(jù)串聯(lián)成完整的事件鏈路，這樣就知道用戶操作了什么、經歷了哪些端、哪些節(jié)點出了問題或漏了哪些節(jié)點。

3.1 事件串聯(lián)

（1）單trace_id串聯(lián)：事件由唯一的trace_id串聯(lián)整個流程。

（2）多trace_id串聯(lián)：事件由多端各自的trace_id組合而成。

為兼容業(yè)務服務和廣播服務各自獨立的trace追蹤系統(tǒng)，我們實現(xiàn)了一套多重映射算法，且無縫兼容了單trace_id方案，最終溯源成事件開始的原始trace_id。

圖片

3.2 數(shù)據(jù)清洗與存儲

為應對直播的實時性要求，我們采用流計算技術。先快速篩選出trace相關事件，再清洗掉異常數(shù)據(jù)，在單次流計算執(zhí)行過程中進行映射建立關系并落表存儲，實現(xiàn)小于5min級別的數(shù)據(jù)響應處理。數(shù)據(jù)表支持靈活的定制化查詢和分析需求。

圖片

4. 數(shù)據(jù)可視化

可視化簡化了查詢過程，能快速準確地捕捉異常和關鍵信息。適用于開發(fā)、測試、產品、運營、客服等角色。

4.1 覆蓋場景

從App啟動到退出，從開播到關播，從上麥到下麥，從PK發(fā)起到結束等關鍵業(yè)務場景。

圖片

4.2 落地效果

在日常業(yè)務中，已經有效解決了很多實際問題，以下是遇到的一些案例查詢：

圖片

三、結束語

不知何時起，“用關鍵鏈路查一下”已經成了身邊同事常說的口頭禪，整套排障體系的價值，也得到了驗證。

未來還有許多要做的事，我們將致力于拓展業(yè)務覆蓋面、建立業(yè)務健康度監(jiān)控體系、提升上下文信息的有效性等。

我們相信，通過不斷的技術創(chuàng)新和服務優(yōu)化，我們的業(yè)務能夠迎接更大的挑戰(zhàn)，為用戶創(chuàng)造更大的價值。