作者：胡濟麟

1、背景介紹

1.1 直播業務特點

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

1.2 直播 CDN 面臨的困難

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

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

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

1.3 解決方案

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

 

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

• 內容平臺：內容平臺的核心目的就是提高質量，只有提高質量流量才有保障，一套精細化的排程系統，能夠做到精確接入，提升網路覆蓋的準確度，快速處理短時故障，降低流量流失風險。
• 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 業務架構

排程系統分為統一接入、運管平臺、資源排程、資訊採集、紀錄檔系統五個部分。

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

 

3.2 資訊採集系統

資訊採集系統作為排程系統的資料底座，主要功能是從運維繫統收集裝置資源情況、從業務系統收集串流媒體資訊，經過資料整合之後提供給資源排程使用。

資訊採集系統通過主動定時呼叫運維繫統介面採集裝置執行資料，包括 CPU 使用率、記憶體使用率、磁碟 IO、網路 IO 等資訊，用於評價裝置的服務能力。採集節點頻寬用量等資訊，用於評價節點承載能力。

通過主動定時呼叫監控系統介面採集鏈路質量資料，包括 RTT，丟包率等資訊，用於評價網路質量。

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

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

聚合資料最終會通過查詢介面提供給資源排程系統。

3.3 資源排程系統

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

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

通過查詢資訊採集介面，查詢串流媒體資源位置及描述資訊。通過匹配排程策略，生成動態排程計劃。

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

3.4 技術架構

3.5 部署方案