大規模實時流處理平臺架構-zz

隨着不一樣網絡質量下接入終端設備種類的增多，服務端轉碼已經成爲視頻點播和直播產品中必備的能力之一。直播產品講究時效性，但願在必定的時間內讓全部終端看到不一樣尺寸甚至是不一樣質量的視頻，所以對轉碼的實時性要求也較高。上次卜赫分享了咱們實時流網絡 LiveNet 的架構，它在整個流分發的環節中起着流傳輸通道和網絡骨幹的做用。理論上它和傳輸內容的類型是無關的，能夠傳輸音頻和視頻數據，也能夠傳輸其它數據包，所以涉及到編碼和轉碼相關的內容比較多。今天個人分享主要集中於七牛直播雲實時流處理平臺的架構。

通用直播模型

這是一個通用的直播模型，你們可能對直播產品的架構已經很是熟悉了。不管是本身去建設，仍是使用第三方雲服務，它的通用架構都差很少是這樣的。一個生產環境可用的直播產品應該包含一個主播方，它是產生視頻流的源頭。主播播出去的視頻，最直接的訴求就是但願被觀衆觀看到，咱們稱之爲播放端。

咱們知道，通常來說，內容產生方和消費方通常都不是一一對應的。對於一個直播產品來說，最直觀的體現就是一個主播可能會有不少粉絲。所以，咱們不能直接讓主播端和全部播放端進行點對點通訊，這在技術上是作不到或者頗有難度的。主播方播出的視頻在到達播放端以前，須要通過一系列的中間環節，也就是圖中的「直播服務器」端，它可以把主播方的能力放大，提供更增強大的通訊通道供主播方和全部播放端進行對話。

這是一個看起來很是簡單的模型，實際上不管是主播端仍是播放端，他們的訴求都不會僅僅是拍攝視頻和播放視頻這麼簡單。在這個核心訴求被知足以後，還有不少關鍵訴求須要被知足。接下來咱們再看看，實現一個基於這個簡單模型的消費級直播產品還須要作哪些事情。

七牛直播雲方案

首先，在主播端，他須要經過必定的設備來拍攝視頻，咱們稱之爲採集。而後，將採集的這些視頻進行一系列的處理，好比水印、美顏和特效濾鏡等處理。最後將處理後的結果視頻進行編碼壓縮成可觀看可傳輸的視頻流，再經過網絡通道傳輸出去。

對於一個社交直播產品來講，在觀衆端，他但願可以實時的看到主播端推過來的視頻流，而且和主播以及其餘觀衆產生必定的互動，好比點贊、聊天、彈幕甚至是一些高級道具。這就是播放端所需作的事情。

咱們前面說過，主播端不太可能直接和播放端進行鏈接，在這個過程當中還有一箇中間環節，幫助主播把能力放大，以知足更多的觀衆，這就是「直播服務器」端。

一般來說，直播服務器端提供的最核心功能是收集主播端的視頻推流，並將其放大後推送給全部觀衆端。直播服務端由一系列的網絡節點構成，它們都可以進行收流和分發視頻流，這個流式傳輸的網絡結構咱們在上一次分享中卜赫重點介紹過了。除了這個核心功能以外，還有不少運營級別的訴求須要在這個服務端知足，好比鑑權認證，視頻連線和實時轉碼，自動鑑黃，多屏合一，以及雲端錄製存儲等功能。另外，對於一個主播端推出的視頻流，中間須要通過一些環節才能到達播放端，所以對中間環節的質量進行監控，以及根據這些監控來進行智能調度，也是很是重要的訴求。

七牛直播雲平臺框架

接下來咱們分享這個流分發網絡中涉及到的實時流處理平臺的架構。

這裏咱們先簡單的來看下這個實時流處理平臺包含哪些內容。這是咱們「直播雲平臺」的框架圖，咱們今天分享的內容主要集中於「存儲與回訪」、「轉碼和內容處理」以及「內容識別」平臺的架構，同時它還包含實時轉存儲的能力，也就是圖中間的綠色部分所表示的模塊。

爲何須要實時轉碼？

在分享實時轉碼平臺架構以前，咱們先來回答一個問題，爲何須要對視頻流進行實時轉碼？

從字面上看，實時性的要求是直播場景決定的，它須要保證比較低的延時。那麼，爲何須要轉碼？

1. 編碼器的多樣性：咱們知道，通過 30 年的長時間發展，市場上出現了無數多的音視頻編碼器和編碼格式。同時，如今主流的終端設備和操做系統有好幾個，它們對於不一樣編碼解碼器的支持都不同。這就致使了在不一樣設備不一樣平臺之間播放相同的視頻可能存在差別。

2. 帶寬限制：如今移動 3G 和 4G 網絡已經很是普及了，他們的速度也相對較快，但仍是存在不少弱網環境，好比偏遠地區戶外，或者大型活動現場。要保證在不一樣網絡條件下都能流暢的在線觀看視頻，網絡自適應的傳輸不一樣碼率的視頻是目前最好的選擇。

3. 終端設備的多樣性還體如今另一方面，也即它們尺寸的多樣性。設備屏幕尺寸的大小決定了在它們上面呈現視頻的最佳分辨率，所以爲了在不一樣設備下都能得到最佳用戶體驗，須要在服務端準備多種不一樣尺寸的視頻流。

大規模實時轉碼面臨的挑戰

回答了爲何須要實時轉碼以後，咱們再來看一下它面臨哪些挑戰。網絡方面的架構以前卜赫已經分享過，咱們假設轉碼所需數據可以經過 LiveNet 實時流網絡獲取到，同時轉碼結果也可以經過實時流網絡 LiveNet 實時傳輸出去。所以，這裏講的第一個挑戰「低延時」只涉及到編解碼效率和內部路由環節。

其次，直播雲服務須要向不少企業級公司提供服務，面臨很是大的終端用戶量，這是另一個挑戰。

最後，應國家有關部門和業務的需求，直播過程當中產生的數據須要存檔。在某些業務場景教育直播，直播過程產生的數據具備很是大的存檔價值。面對海量的直播流，如何將其實時存儲起來是另外一個較大的挑戰。

低延時帶來的挑戰

咱們先來看一下「低延時」帶來的挑戰。要作到較低的延時，首先意味着轉碼性能需提高，也即，要麼使用性能更好的硬件（好比 GPU），要麼優化編碼解碼器的能力，下降編碼延遲。或者，減小關鍵幀間隔，增長關鍵幀出現的頻率，這樣可以讓播放器以較高頻率獲取到關鍵幀，直接解碼播放，下降等待關鍵幀的延時。固然，這樣作也有它的風險，關鍵幀的增長會增大視頻流的編碼碼率，或者在碼率恆定的狀況下會下降關鍵幀的編碼質量，影響關鍵幀進而影響整個視頻流的質量。

「低延時」帶來的第二個挑戰在於，需儘可能縮短流在服務端內的傳輸路徑，動態調整流在服務端內的轉發路由。這在傳統的樹狀網絡結構下是難以作到的，以前卜赫分享過實時流網絡 LiveNet 中流的最優傳輸路徑的選擇，這裏面再也不介紹。

海量終端用戶帶來的挑戰

接下來咱們再看看，海量終端用戶對於對於實時流處理服務來講意味着什麼。

1. 高併發、高在線：大量用戶同時直播和訪問，意味着同時有大量併發請求須要處理。直播是一種實時性很是強的在線服務，每個在線用戶都須要維持一個長鏈接，所以對於服務端 IO 和併發能力的要求很是高。此外，每一路用戶推流均可能意味着多路不一樣的轉碼和處理，處理平臺不只是 IO 密集型服務，也是 CPU 密集型服務。

2. 海量終端用戶雖然大都集中在北上廣地區，但在龐大的用戶基數基礎上，長尾用戶的覆蓋面也很是普遍，所以除了須要在網絡上作好規劃以外，轉碼資源的合理利用也須要動態規劃和調整。

實時轉存帶來的挑戰

流的實時轉存是數據處理平臺所需面對的另外一個挑戰，對於一個企業級直播雲服務來講，海量的用戶意味着:

1. 出口網絡帶寬佔用的提高。

2. 海量視頻文件的存儲。

3. 海量的回訪意味着大規模的下載分發。

幸虧七牛是作雲存儲服務開始的，能夠輕鬆應對這些海量視頻文件的存儲和分發需求。

去中心化網絡拓撲

瞭解完實時流轉碼服務面臨的挑戰以後，咱們再來看一下咱們七牛針對這些挑戰打造的實時流網絡 LiveNet 是如何進行實時轉碼的。

圖中的 5 個實心圈表示 5 個 IDC 機房內的收流、轉碼和分發節點，一個節點內包含多個部署不一樣服務的集羣，好比收流、分發和不一樣的轉碼、處理等功能。圖中能夠看出，紅線表示的數據流 1 從 A 節點收流以後轉發到 B 節點，在 B 節點轉碼以後再分發出去。藍線表示的數據流 2 從 E 節點收流以後當即進行轉碼，轉碼後的流通過 C 節點轉發到達 B 節點，再經過 B 節點轉發出去。一樣的，數據流 3 的轉碼和流向也相似。至於爲何有些數據流是在靠近推流端的收流節點進行轉碼，而有些數據流是在靠近播放端的節點進行轉碼，咱們後面會討論。從這張圖能夠看出，只要有須要，任意一個 IDC 機房內均可以部署數據處理服務，同時能夠在流轉發環節的任意一站進行流的處理。這樣的靈活性極大的保證了節點故障下的容錯度，以及節點計算和 IO 能力的動態調配。

收流、轉碼節點服務部署

接下來咱們再看看下每一個收流、轉碼節點裏面服務部署的大體架構怎麼樣。

首先，在流的入口層有一個網關負責收流，同時會在這裏對其是否須要轉碼，以及轉碼參數如何等作業務判斷。而後，網關將收到的流轉發到後端的負載均衡器。對於須要最作處理的流，負載均衡器直接將其分發給後端的業務服務進行處理，如 HLS 切片服務，或者 RTMP 轉碼服務，以及鑑黃等內容識別服務。處理完成後，處理服務輸出相應的 TS 流或者 RTMP 流到下一個路由節點進行後續處理，或者直接由它轉發到目標終端用戶。

爲了最大化資源的利用率，節點上的切片服務或者轉碼服務能夠動態部署，在流量較小的時候不須要部署足夠多的服務在那裏空轉。但爲了不請求過來時候的預熱過程致使延遲的增長，每一個節點上的服務不徹底處於冷卻狀態，負載均衡器背後至少有一個在線服務能夠持續等待請求，請求量增長以後再動態調整服務的副本數。

實時流處理服務的特色

從以上去中心化的網絡結構和流實時處理服務部署結構圖能夠看出，這樣的架構更爲輕量，同時又能處理海量、高併發的流處理請求，同時因爲單個節點成本較低，能夠以極低的成本快速的擴容，可以覆蓋更爲普遍的地域。

其次，因爲實時流分發網絡的主要職責在於流的分發，是典型的網絡 IO 密集型服務，所以節點上的計算能力可能會有浪費。爲了知足實時轉碼的需求，能夠在不影響流分發的狀況下經過充分利用節點計算能力，作到流的就近處理，以保證轉碼性能和低延時。同時，分散式的流數據處理服務可以下降錄製存儲對於上傳帶寬的要求，充分利用七牛對象雲存儲的分佈式就近上傳能力化解單節點帶寬瓶頸。

最後，做爲實時流處理服務的一大特色之一，咱們來解釋一下爲何有些數據流是在靠近推流端的收流節點進行轉碼，而有些數據流是在靠近播放端的節點進行轉碼。

咱們知道，通常來說，流的目標碼率小於原始碼率，這樣的轉碼纔有意義。所以，對於 RTMP 流來講，在靠近推流端的收流節點進行轉碼後，後續轉發環節能夠只轉發低碼率的目標 RTMP 流。

對於 HLS 流來講，理論上也是目標碼率小於原始碼率，但 HTTP 是爲短鏈接設計的，內部轉發環節效率仍是不如 RTMP 流，所以在靠近播放端的節點進行轉碼是比較好的選擇。

新技術下的個性化實時轉碼架構

從前面轉碼節點的部署結構圖能夠看出，咱們使用了基於 Docker 容器虛擬化技術的平臺來調度轉碼服務，它能夠幫助咱們以服務的邏輯單元爲單元，隔離不一樣的處理服務（如切片服務和轉碼服務），同時又可以充分利用容器虛擬化的靈活性，快速擴容縮容，動態調整所需的物理資源。

除了隔離性和動態擴容縮容以外，它帶來了一個很是重要的特性，也即將轉碼服務模塊化以後，便可使用個性化的處理服務替換平臺自帶的處理服務。例如，可使用 H.265 編碼器替換 H.264 編碼器，使用 VP9 替換 VP8，或者同時支持全部這些編碼器。

同時，除了支持水印、截圖和內容識別等數據處理服務以外，還能夠支持其它個性化的數據處理服務。

【Q&A】

Q1：質量監控主要監控哪些內容？

A1：咱們會監控不少東西，好比節點的狀態和節點內服務的狀態，節點狀態包括 CPU、內存、網絡和服務器句柄數等。同時會對健康節點之間的速度進行按期測試（預留足夠的帶寬保證測速的時效性）。另外，除了服務端節點質量的監控以外，還會監控直播客戶端的網絡情況，以及流的質量。

 

Q2：這種類型的直播視頻處理環境，我的想本身搭一個瞭解相關技術能實現嗎？

A2：能夠實現。實際上直播是一個包含不少技術的解決方案，幸運的是大部分技術都有開源的實現，好比轉碼使用 FFmpeg，後端負載均衡使用 Nginx 等，服務資源的隔離和動態調度目前也有比較好的開源容器雲平臺。

 

Q3：FFmpeg 這個轉碼視頻質量怎樣？

A3：這是一個很大的問題，影響最終視頻質量的因素不少，衡量視頻質量的維度也不少，分辨率和碼率，以及 I 幀頻率和 GOP 的大小均可能和視頻質量有關，即使是同一個視頻流在不一樣的解碼器下解碼獲得的效果也可能不太同樣。咱們正在創建一些量化的方法來衡量視頻的質量，好比測量 PSNR 值等方式。

 

Q4：如今的直播平臺能支持相似視頻會議的播放方式嗎 ？

A4：目前的直播通常是爲單向傳輸設計的，所以對互動性比較強的視頻會議不太合適。不過在互動社交直播的需求推進下，咱們也在嘗試使用 WebRTC 技術來提高目前直播的互動性。

 

Q5：有可操做的 Demo 嗎?

A5：咱們直播相關的全部 SDK  都在這裏 https://github.com/pili-engineering

除了 SDK 以外，咱們也作了一些 Demo 可供提早體驗：

1. 安卓：

代碼：

https://github.com/qiniudemo/qiniu-live-android

App 連接：

http://devtools.qiniu.com/QLive-v1.2.2.apk

2. iOS：

代碼：

https://github.com/qiniudemo/qiniu-live-iOS

App 連接：

https://dn-devtools.qbox.me/QNPilePlayDemo-v1.1.0.html

 

Q6：節點去中心化，IDC 節點之間數據是怎麼同步？如 A 節點轉碼好的視頻文件，是怎麼被 B 節點或全網其餘節點知道的？

A6：這是一個頗有價值的問題。咱們的架構和傳統 CDN 不太同樣。A 節點轉碼好以後，會上報狀態到全局調度中心，調度中心將其做爲一個源站存在，這樣別的節點能夠「回源」到它這裏，簡化了同步的邏輯。