作者：胡濟麟

1、背景介紹

1.1 直播業務特點

互聯網視頻直播是一種消息媒介形態，提供時產時消的內容，經過多年，已經發展出秀場、游戲、電商、體育等多種業務形態。主要特點是：內容實時產生實時消費，對時效性要求更高；流媒體內容占用帶寬大，對網路質量要求更苛刻；一人生產、多人消費，帶寬規模大。直播 CDN 目前是解決這種大規模分發場景最有效的技術途徑，主要特點是就近接入以提供良好的接入網環境，多層匯聚以降低中心資源的分發壓力，以此達到直播業務規模化和時效性的要求。

1.2 直播 CDN 面臨的困難

由於直播業務本身對於質量和時效性的要求，CDN 就需要在短時間內要找到並建立一條完整可靠的傳輸鏈路，對於鏈路穩定性有一定的要求。傳統依賴於旁路更新的、基於鏈路質量的策略，尋路演算法簡單，不消耗太多時間，時效性有保障。但隨著成本壓力越來越大和可用性的要求越來越高，基於鏈路質量的策略的缺點就逐漸體現出來：

一個是這種旁路策略第一策略時效性上存在一定的延遲，延遲大約 2-3 分鐘，對於偶發性的質量惡化或資源偏壓無法快速做出相應的策略調整；

第二是基於一套統一的鏈路質量數據，無法兼顧資源能效，對於一些能效低的內容無法基於成本考慮做出相應的尋路策略調整，對浮動成本的控制不夠精確。

1.3 解決方案

基於資源信息、鏈路狀態、流媒體信息等多維度數據，精確計算每一路流的分發效能，將計算粒度精確到流一級。通過對能效、質量的綜合計算，為每一路流動態計算接入和回源策略是解決困難的關鍵。

圖 1. 干係方

調度系統通過收集、結合資源信息、鏈路狀態、流媒體信息等，對直播接入和尋路進行控制，快速精確的調整策略，提供質量優先、成本優先、質量成本平衡等多種策略，對於在質量指標評價體系下提升分發系統的可用性和能效比提供更加精準和細粒度的控制。

• 內容平臺：內容平臺的核心目的就是提高質量，只有提高質量流量才有保障，一套精細化的調度系統，能夠做到精確接入，提升網路覆蓋的準確度，快速處理短時故障，降低流量流失風險。
• CDN：CDN 主要目標是提高質量，降低成本。調度系統能夠精確控制接入網準確度，提高接入質量，對流量進行精細化調度，提高資源復用率，降低浮動成本，進而執導建設規劃，降低固定成本。

2、主要問題及挑戰

2.1 時效性的要求

• 接入調度要求對業務阻塞時長不超過 50ms
• 尋路調度要求全路徑上阻塞時長不超過 50ms
• 流媒體信息同步延遲不超過 100ms
• 設備信息、網路質量同步延遲不超過 10s

2.1.1 調度延遲控制

延遲不超過 50ms，考慮到公網的網路本身的傳輸延遲，基本上不會有多餘的時間進行其他系統調用和計算，需要預先準備好響應的策略，並且調度接入位置要儘量靠近調用側。設計了策略推送、策略緩存、非同步更新三種功能。

• 策略推送功能在資源調度系統生成好調度策略之後，通過推送方式直接推送到接入層，接入層不主動調用其他系統，直接使用推送的調度計劃返回給業務方，接入層沒有業務處理延遲。
• 策略緩存功能在接入層收到推送調度計劃之後做記憶體緩存，本地不落磁碟，只有推送或者非同步更新觸發緩存更新，調度請求直接返回緩存數據。
• 非同步更新是在介面主動定時向資源調度發起請求獲取調度數據，防止推送失敗。

2.1.2 信息同步延遲控制

由於流媒體信息同步延遲要求 100ms，考慮公網網路傳輸的延遲，定時採集上報的方式無法滿足延遲要求，採用事件觸發實時 API 上報的方式同步數據。設備信息、節點信息為介面調用方式取回，對於時效性要求不高，採用任務分派機制，防止數據重覆取回。

• 事件觸發在開始、停止等事件邊沿上，同步調用 API 上送流媒體信息，保障流媒體信息同步的及時性。
• API 直連觸發後端業務處理，不再經過中間件，節省中間件處理延遲。
• 任務分派機制將數據查詢任務通過 MQ 分派給不同的服務實例，每個實例在認領完任務之後負責將數據取回。

2.2 可用性要求

• 客戶之間互不影響
• 詢源調度和接入調度互不影響
• 響應異常退化策略保障

2.2.1 介面可用性

隔離

用戶隔離

• 客戶一般採用 id 來區別身份，部分大客戶可能有獨立的接入功能變數名稱。以 id 和功能變數名稱為維度，部署獨立的計算資源，防止單個客戶訪問對全體客戶造成影響。
• 考慮到成本和可用性，大客戶除了獨立部署資源外，還需要在常規集群中也部署相應功能，提供主備資源保障。

業務隔離

• 回源調度和接入調度的業務方不同，對調度的響應能力和異常處理方式也不相同，調度失效的影響範圍和收益也不相同。因此按照業務方進行隔離，內容平臺和 CDN 分別在不同的接入實例上，方便對單個業務進行擴展，也可控制業務異常影響範圍。

限流

當系統負載過高時，保護系統服務，提升系統恢復速度，降低系統負載，需要對系統業務流量進行限制。

熔斷

併發熔斷

• 系統中存在很多介面調用的場景，比如統一接入調用資源調度介面獲取調度計劃，資源調度調用信息採集獲取基礎數據等。為保障後端業務服務穩定性，防止後端業務被突發增量打死，需要對後端業務併發數進行熔斷，超過額定併發之後，不再允許調用後端介面，監控系統拋出異常，前端業務依據故障處理機制容忍一定的故障請求，超過容忍額度則退化到兜底策略。

失敗率熔斷

• 後端業務可能短時處於不可用狀態，降低後端業務在短時不可用時的請求量，能夠加速後端業務恢復。當調用後端介面失敗率高於閥值後，一段時間內不再調用後端介面，超過額定時間則繼續探測後端業務可用性，直到業務恢復。

2.2.2 退化策略

無法在進行接入和詢源調度服務時，需要退化為預設兜底策略，接入退化為 DNS 解析方式，詢源退化為 CDN 固定詢源策略，不再依賴調度系統做策略選擇。

3、調度系統架構

3.1 業務架構

圖 2. 業務架構

調度系統分為統一接入、運管平臺、資源調度、信息採集、日誌系統五個部分。

• 統一接入：為內容平臺提供中心化標準接入能力。考慮性能及延遲消耗，為 CDN 的邊緣實例、二級源實例提供下沉 agent 接入能力。
• 運管平臺：運管平臺作為人工界面，主要提供配置能力和數據大屏。
• 資源調度：資源調度作為調度系統的核心單元，依據多種輸入條件，針對接入和詢源兩種業務模式，輸出不同的調度計劃。
• 信息採集：信息採集作為數據底座，為資源調度提供必要的質量、能力、位置等輸入信息。
• 日誌系統：日誌系統提供時序化的記錄方式用於記錄調度信息，主要用於復盤和評價調度策略。

3.2 信息採集系統

圖 3. 信息採集系統業務架構

信息採集系統作為調度系統的數據底座，主要功能是從運維繫統收集設備資源情況、從業務系統收集流媒體信息，經過數據整合之後提供給資源調度使用。

信息採集系統通過主動定時調用運維繫統介面採集設備運行數據，包括 CPU 使用率、記憶體使用率、磁碟 IO、網路 IO 等信息，用於評價設備的服務能力。採集節點帶寬用量等信息，用於評價節點承載能力。

通過主動定時調用監控系統介面採集鏈路質量數據，包括 RTT，丟包率等信息，用於評價網路質量。

通過被動等待 CDN 業務實例上報流媒體資源位置、下行併發、卡頓率等信息，用於評價服務質量和服務收益。

這些信息被收集上來之後通過分類整合，按照節點、地區、運營商、業務形式等不同維度，形成服務能力、服務質量、服務收益的聚合數據。

聚合數據最終會通過查詢介面提供給資源調度系統。

3.3 資源調度系統

圖 4. 資源調度系統業務架構

資源調度作為調度系統核心業務模塊，主要從信息採集收取必要調度依據，通過一套調度策略，輸出調度計劃提供給接入和詢源業務。

資源調度系統主要通過運管平臺將個性化調度配置信息落到資源調度系統。通過查詢信息採集介面，查詢所需要的服務能力、服務質量、服務收益等信息。通過匹配不同的調度策略，生成靜態調度計劃。

通過查詢信息採集介面，查詢流媒體資源位置及描述信息。通過匹配調度策略，生成動態調度計劃。

最終調度計劃會以介面方式提供給業務方使用。

3.4 技術架構

圖 5. 技術架構

3.5 部署方案

圖 6. 部署方案