視頻平臺設計思路大灌頂

抖出乾貨，一句話， 無論多大規模、多麼複雜，任何Web應用都是立足於Request/Reply的通訊模式而解決一個問題，這個問題是，如何把這個Request投送到未知規模的設備集羣中進行求解，而後做爲Reply返回。這裏的Request是邏輯Request，即不僅僅說HTTP Request，或者是SQL Request，而是Business Request。

 

好了，以上這段話能夠涵蓋目前世界上全部接觸到的Web應用，從搜索引擎到短視頻應用，涵蓋全部系統的後端核心思路。

 

這裏具體結合實際狀況來展開論述。

 

首先存在幾個來自現實世界中的約束

1. 任何的商業都是但願本身的業務規模能夠無暫停的無限增加。
2. 隨着業務量的增加，圍繞業務邏輯的計算量也在增長。
3. 機器資源老是有限的，包括任何一臺設備的IO帶寬、CPU、內存、存儲等。

對於視頻平臺的應用來講，其實能夠分2大類

• 視頻點播類(VOD)
• 實時直播類(Live)

固然一個網站固然能夠提供2種服務，可是在實際世界中，這兩個類別存在交集以及不一樣的點。

 

這裏的業務請求邏輯主要分爲兩大類

• 內容發佈者
• 內容觀看者

內容請求者的類別又有兩個大類

• 預製做內容上傳
• 實時流媒體上傳 

預製做內容上傳

這個問題能夠概括爲，如何收集完整的用戶內容，提供給後續的處理程序。這裏的問題是

• 用戶不須要理睬數據的流向，只有一個入口。
• 服務器系統必需要保證待處理的數據的完整性。

這裏的解決方案能夠採用，準備若干強大的高帶寬高速網絡傳輸節點。以用戶上傳請求做爲一個Session，根據後端處理節點的資源空閒程度，從前端直接經過Broker輸入到某個後端的某處理節點。後端處理節點的特點是，計算能力能夠很強，存儲空間很大。當用戶全部的內容上傳完畢以後，則告知處理節點開始處理，同時處理節點發布Session的處理進度，進而前端獲取並推送給用戶。當處理完畢以後，轉碼也完成，能夠告知後續節點生成永久性的播放地址，刷新CDN，將新通知發往前端。前端刷新一次，得到更新後的網頁，直接點擊播放。

 

實時流媒體上傳

這個問題能夠概括爲，如何把用戶持續性的數據分配給內部處理程序進行。

• 用戶通常來講有固定的輸入點，譬如RTMP的URL。
• 可能須要多協議的支持，譬如WebRTC。 

這裏同樣須要高帶寬、兼容某種協議的網絡前端節點，做爲固定的資源分配給用戶，譬如Twitch，每個註冊用戶都知曉本身的RTMP URL。每當用戶開始發送數據的時候，根據視頻帶寬和碼率的差別，須要從後端分配一個或者共享計算節點進行流媒體的實時編解碼。每個計算節點在計算量容許的狀況下可能能夠執行若干轉碼工做處理幾路視頻。每個程序的執行各自獨立，在處理的過程當中會不停的向Broker發送每個Session的處理狀態，同時直接將處理後的原始媒體數據交給後續的處理環節，在這個過程當中已經生成了MP4片斷，而且能夠直接發送給CDN。同時前端的播放器直接不停的抓取最新的生成片斷用來播放。

 

那麼全部的短視頻應用其實都是屬於第一大類，而近年來興起的網絡直播平臺如Twitch則屬於1+2類。

 

寥寥幾語，已經把這個地方歸納完畢。至於用什麼多媒體庫如FFmpeg、x264作什麼的這些內容，都是具體的執行細節，在此不闡述。由於這些都是具體節點的工做邏輯，能夠和架構的設計完全解耦合，成爲功能獨立的程序，只要穩定執行，就沒有問題。至於具體的媒體問題，譬如H26四、H26五、AV1，AAC音頻處理等具體媒體相關的處理，仍是HLS或者DASH，本質上這個獨立的程序均可以完成。而且這個程序必定能夠在不一樣的硬件環境下經過媒體片斷進行測試，獲知系統綜合性能，進而優化系統的資源利用率和開銷。

 

對於播放來講，雖然也有兩大類

• 觀看已經錄製的視頻內容
• 觀看正在直播的視頻內容

可是對於播放端來講，只是一個Request/Reply抓取數據的過程。其實任何的網絡視頻應用都是不斷的抓取片斷，丟入本地的緩衝進行播放。不管是MPEG-Dash仍是HLS，本質上都是定義了一組媒體文件序列，由客戶端不斷的抓取。可是對於播放這一個動做來講，不管是來自VOD仍是直播的內容，本質上並無任何區別，由於數據都是須要處理後按照次序丟入CDN，客戶端經過HLS或者MPEG-DASH的索引進行下載。這個地方的設計主要在於客戶端的設計和編碼，並沒有過多的技術難度。

 

抖音類別的短視頻，其實都是第1類。快手視頻直播是第2類。又有錄播又有直播的算1+2，通常是傳統視頻平臺。有沒有純粹屬於第2類的呢，固然也有，並且通常應用場合爲B2B，非C2C。