1、七牛云：大規(guī)模實時流處理平臺架構隨著不同網絡質量下接入終端設備種類的增多，服務端轉碼已經成為視頻點播和直播產品中必備的能力之一。直播產品講究時效性，希望在一定的時間內讓所有終端看到不同尺寸甚至是不同質量的視頻，因此對轉碼的實時性要求也較高。上次卜赫分享了我們實時流網絡LiveNet的架構，它在整個流分發(fā)的環(huán)節(jié)中起著流傳輸通道和網絡骨干的作用。理論上它和傳輸內容的類型是無關的，可以傳輸音頻和視頻數(shù)據(jù)，也可以傳輸其它數(shù)據(jù)包，因此涉及到編碼和轉碼相關的內容比較多。今天我的分享主要集中于七牛直播云實時流處理平臺的架構。通用直播模型通用直播模型主播端RTMP直播服務耦KTN1P/HL5ALV這是一個通用

2、的直播模型，大家可能對直播產品的架構已經非常熟悉了。無論是自己去建設，還是使用第三方云服務，它的通用架構都差不多是這樣的。一個生產環(huán)境可用的直播產品應該包含一個主播方，它是產生視頻流的源頭。主播播出去的視頻，最直接的訴求就是希望被觀眾觀看到，我們稱之為播放端。我們知道，一般來講，內容產生方和消費方一般都不是一一對應的。對于一個直播產品來講，最直觀的體現(xiàn)就是一個主播可能會有很多粉絲。因此，我們不能直接讓主播端和所有播放端進行點對點通信，這在技術上是做不到或者很有難度的。主播方播出的視頻在到達播放端之前，需要經過一系列的中間環(huán)節(jié)，也就是圖中的直播服務器端，它能夠把主播方的能力放大，提供更加強大的通

3、信通道供主播方和所有播放端進行對話。這是一個看起來非常簡單的模型，實際上無論是主播端還是播放端，他們的訴求都不會僅僅是拍攝視頻和播放視頻這么簡單。在這個核心訴求被滿足之后，還有很多關鍵訴求需要被滿足。接下來我們再看看，實現(xiàn)一個基于這個簡單模型的消費級直播產品還需要做哪些事情。七牛直播云方案首先，在主播端，他需要通過一定的設備來拍攝視頻，我們稱之為采集。然后,將采集的這些視頻進行一系列的處理，比如水印、美顏和特效濾鏡等處理。最后將處理后的結果視頻進行編碼壓縮成可觀看可傳輸?shù)囊曨l流，再通過網絡通道傳輸出去。對于一個社交直播產品來說，在觀眾端，他希望能夠實時的看到主播端推過來的視頻流，并且和主播以及

4、其他觀眾產生一定的互動，比如點贊、聊天、彈幕甚至是一些高級道具。這就是播放端所需做的事情。我們前面說過，主播端不太可能直接和播放端進行連接，在這個過程中還有一個中間環(huán)節(jié)，幫助主播把能力放大，以滿足更多的觀眾，這就是直播服務器端。通常來講，直播服務器端提供的最核心功能是收集主播端的視頻推流，并將其放大后推送給所有觀眾端。直播服務端由一系列的網絡節(jié)點構成，它們都能夠進行收流和分發(fā)視頻流，這個流式傳輸?shù)木W絡結構我們在上一次分享中卜赫重點介紹過了。除了這個核心功能之外，還有很多運營級別的訴求需要在這個服務端滿足，比如鑒權認證，視頻連線和實時轉碼，自動鑒黃，多屏合一，以及云端錄制存儲等功能。另外，對于一

5、個主播端推出的視頻流，中間需要經過一些環(huán)節(jié)才能到達播放端，因此對中間環(huán)節(jié)的質量進行監(jiān)控，以及根據(jù)這些監(jiān)控來進行智能調度，也是非常重要的訴求。七牛直播云平臺框架接下來我們分享這個流分發(fā)網絡中涉及到的實時流處理平臺的架構。這里我們先簡單的來看下這個實時流處理平臺包含哪些內容。這是我們直播云平臺的框架圖，我們今天分享的內容主要集中于存儲與回訪、轉碼和內容處理以及內容識別平臺的架構，同時它還包含實時轉存儲的能力，也就是圖中間的綠色部分所表示的模塊。為什么需要實時轉碼？在分享實時轉碼平臺架構之前，我們先來回答一個問題，為什么需要對視頻流進行實時轉碼？從字面上看，實時性的要求是直播場景決定的，它需要保證比

6、較低的延時。那么，為什么需要轉碼？編碼器的多樣性：我們知道，經過30年的長時間發(fā)展，市場上出現(xiàn)了無數(shù)多的音視頻編碼器和編碼格式。同時，現(xiàn)在主流的終端設備和操作系統(tǒng)有好幾個，它們對于不同編碼解碼器的支持都不一樣。這就導致了在不同設備不同平臺之間播放相同的視頻可能存在差異。帶寬限制：現(xiàn)在移動3G和4G網絡已經非常普及了，他們的速度也相對較快，但還是存在很多弱網環(huán)境，比如偏遠地區(qū)戶外，或者大型活動現(xiàn)場。要保證在不同網絡條件下都能流暢的在線觀看視頻，網絡自適應的傳輸不同碼率的視頻是目前最好的選擇。終端設備的多樣性還體現(xiàn)在另外一方面，也即它們尺寸的多樣性。設備屏幕尺寸的大小決定了在它們上面呈現(xiàn)視頻的最佳

7、分辨率，因此為了在不同設備下都能獲得最佳用戶體驗，需要在服務端準備多種不同尺寸的視頻流。大規(guī)模實時轉碼面臨的挑戰(zhàn)回答了為什么需要實時轉碼之后，我們再來看一下它面臨哪些挑戰(zhàn)。網絡方面的架構之前卜赫已經分享過，我們假設轉碼所需數(shù)據(jù)能夠通過LiveNet實時流網絡獲取到，同時轉碼結果也能夠通過實時流網絡LiveNet實時傳輸出去。因此，這里講的第一個挑戰(zhàn)低延時只涉及到編解碼效率和內部路由環(huán)節(jié)。其次，直播云服務需要向很多企業(yè)級公司提供服務，面臨非常大的終端用戶量，這是另外一個挑戰(zhàn)。最后，應國家有關部門和業(yè)務的需求，直播過程中產生的數(shù)據(jù)需要存檔。在某些業(yè)務場景教育直播，直播過程產生的數(shù)據(jù)具有非常大的存檔

8、價值。面對海量的直播流，如何將其實時存儲起來是另一個較大的挑戰(zhàn)。低延時帶來的挑戰(zhàn)我們先來看一下低延時帶來的挑戰(zhàn)。要做到較低的延時，首先意味著轉碼性能需提升，也即，要么使用性能更好的硬件（比如GPU，要么優(yōu)化編碼解碼器的能力，降低編碼延遲。或者，減少關鍵幀間隔，增加關鍵幀出現(xiàn)的頻率，這樣能夠讓播放器以較高頻率獲取到關鍵幀，直接解碼播放，降低等待關鍵幀的延時。當然，這樣做也有它的風險，關鍵幀的增加會增大視頻流的編碼碼率，或者在碼率恒定的情況下會降低關鍵幀的編碼質量，影響關鍵幀進而影響整個視頻流的質量。低延時帶來的第二個挑戰(zhàn)在于，需盡量縮短流在服務端內的傳輸路徑，動態(tài)調整流在服務端內的轉發(fā)路由。這在

9、傳統(tǒng)的樹狀網絡結構下是難以做到的，之前卜赫分享過實時流網絡LiveNet中流的最優(yōu)傳輸路徑的選擇，這里面不再介紹。海量終端用戶帶來的挑戰(zhàn)接下來我們再看看，海量終端用戶對于對于實時流處理服務來說意味著什么。高并發(fā)、高在線：大量用戶同時直播和訪問，意味著同時有大量并發(fā)請求需要處理。直播是一種實時性非常強的在線服務，每一個在線用戶都需要維持一個長連接，因此對于服務端IO和并發(fā)能力的要求非常高。此外，每一路用戶推流都可能意味著多路不同的轉碼和處理，處理平臺不僅是IO密集型服務，也是CPU密集型服務。海量終端用戶雖然大都集中在北上廣地區(qū)，但在龐大的用戶基數(shù)基礎上，長尾用戶的覆蓋面也非常廣泛，因此除了需要

10、在網絡上做好規(guī)劃之外，轉碼資源的合理利用也需要動態(tài)規(guī)劃和調整。實時轉存帶來的挑戰(zhàn)流的實時轉存是數(shù)據(jù)處理平臺所需面對的另一個挑戰(zhàn)，對于一個企業(yè)級直播云服務來說，海量的用戶意味著:1.出口網絡帶寬占用的提升。2.海量視頻文件的存儲。海量的回訪意味著大規(guī)模的下載分發(fā)。幸好七牛是做云存儲服務開始的，可以輕松應對這些海量視頻文件的存儲和分發(fā)需求。去中心化網絡拓撲了解完實時流轉碼服務面臨的挑戰(zhàn)之后，我們再來看一下我們七牛針對這些挑戰(zhàn)打造的實時流網絡LiveNet是如何進行實時轉碼的圖中的5個實心圈表示5個IDC機房內的收流、轉碼和分發(fā)節(jié)點，一個節(jié)點內包含多個部署不同服務的集群，比如收流、分發(fā)和不同的轉碼、

11、處理等功能。圖中可以看出，紅線表示的數(shù)據(jù)流1從A節(jié)點收流之后轉發(fā)到B節(jié)點，在B節(jié)點轉碼之后再分發(fā)出去。藍線表示的數(shù)據(jù)流2從E節(jié)點收流之后立即進行轉碼，轉碼后的流經過C節(jié)點轉發(fā)到達B節(jié)點，再通過B節(jié)點轉發(fā)出去。同樣的，數(shù)據(jù)流3的轉碼和流向也類似。至于為什么有些數(shù)據(jù)流是在靠近推流端的收流節(jié)點進行轉碼，而有些數(shù)據(jù)流是在靠近播放端的節(jié)點進行轉碼，我們后面會討論。從這張圖可以看出，只要有需要，任意一個IDC機房內都可以部署數(shù)據(jù)處理服務，同時可以在流轉發(fā)環(huán)節(jié)的任意一站進行流的處理。這樣的靈活性極大的保證了節(jié)點故障下的容錯度，以及節(jié)點計算和IO能力的動態(tài)調配。收流、轉碼節(jié)點服務部署接下來我們再看看下每個收流

12、、轉碼節(jié)點里面服務部署的大致架構怎么樣。首先，在流的入口層有一個網關負責收流，同時會在這里對其是否需要轉碼，以及轉碼參數(shù)如何等做業(yè)務判斷。然后，網關將收到的流轉發(fā)到后端的負載均衡器。對于需要最做處理的流，負載均衡器直接將其分發(fā)給后端的業(yè)務服務進行處理，如HLS切片服務，或者RTMP轉碼服務，以及鑒黃等內容識別服務。處理完成后，處理服務輸出相應的TS流或者RTMP流到下一個路由節(jié)點進行后續(xù)處理，或者直接由它轉發(fā)到目標終端用戶。為了最大化資源的利用率，節(jié)點上的切片服務或者轉碼服務可以動態(tài)部署，在流量較小的時候不需要部署足夠多的服務在那里空轉。但為了避免請求過來時候的預熱過程導致延遲的增加，每個節(jié)點

13、上的服務不完全處于冷卻狀態(tài)，負載均衡器背后至少有一個在線服務可以持續(xù)等待請求，請求量增加之后再動態(tài)調整服務的副本數(shù)。收流、轉碼節(jié)點服務部署rtrnp!ts流網關rtmo流-w.-rtmp流實時流處理服務的特點從以上去中心化的網絡結構和流實時處理服務部署結構圖可以看出，這樣的架構更為輕量，同時又能處理海量、高并發(fā)的流處理請求，同時由于單個節(jié)點成本較低，可以以極低的成本快速的擴容，能夠覆蓋更為廣泛的地域。其次，由于實時流分發(fā)網絡的主要職責在于流的分發(fā)，是典型的網絡io密集型服務，因此節(jié)點上的計算能力可能會有浪費。為了滿足實時轉碼的需求，可以在不影響流分發(fā)的情況下通過充分利用節(jié)點計算能力，做到流的就

14、近處理，以保證轉碼性能和低延時。同時，分散式的流數(shù)據(jù)處理服務能夠降低錄制存儲對于上傳帶寬的要求，充分利用七牛對象云存儲的分布式就近上傳能力化解單節(jié)點帶寬瓶頸。最后，作為實時流處理服務的一大特點之一，我們來解釋一下為什么有些數(shù)據(jù)流是在靠近推流端的收流節(jié)點進行轉碼，而有些數(shù)據(jù)流是在靠近播放端的節(jié)點進行轉碼。我們知道，一般來講，流的目標碼率小于原始碼率，這樣的轉碼才有意義。因此，對于RTMP流來說，在靠近推流端的收流節(jié)點進行轉碼后，后續(xù)轉發(fā)環(huán)節(jié)可以只轉發(fā)低碼率的目標RTMP流。對于HLS流來說，理論上也是目標碼率小于原始碼率，但HTTP是為短連接設計的，內部轉發(fā)環(huán)節(jié)效率還是不如RTMP流，因此在靠近

15、播放端的節(jié)點進行轉碼是比較好的選擇。新技術下的個性化實時轉碼架構從前面轉碼節(jié)點的部署結構圖可以看出，我們使用了基于Docker容器虛擬化技術的平臺來調度轉碼服務，它可以幫助我們以服務的邏輯單元為單元，隔離不同的處理服務（如切片服務和轉碼服務），同時又能夠充分利用容器虛擬化的靈活性，快速擴容縮容，動態(tài)調整所需的物理資源。除了隔離性和動態(tài)擴容縮容之外，它帶來了一個非常重要的特性，也即將轉碼服務模塊化之后，即可使用個性化的處理服務替換平臺自帶的處理服務。例如，可以使用H.265編碼器替換H.264編碼器，使用VP9替換VP8，或者同時支持所有這些編碼器。同時，除了支持水印、截圖和內容識別等數(shù)據(jù)處理服

16、務之外，還可以支持其它個性化的數(shù)據(jù)處理服務?！綫&AQ1：質量監(jiān)控主要監(jiān)控哪些內容?A1:我們會監(jiān)控很多東西，比如節(jié)點的狀態(tài)和節(jié)點內服務的狀態(tài)，節(jié)點狀態(tài)包括CPU內存、網絡和服務器句柄數(shù)等。同時會對健康節(jié)點之間的速度進行定期測試（預留足夠的帶寬保證測速的時效性）。另外，除了服務端節(jié)點質量的監(jiān)控之外，還會監(jiān)控直播客戶端的網絡狀況，以及流的質量。Q2這種類型的直播視頻處理環(huán)境，個人想自己搭一個了解相關技術能實現(xiàn)嗎？A2:可以實現(xiàn)。實際上直播是一個包含很多技術的解決方案，幸運的是大部分技術都有開源的實現(xiàn)，比如轉碼使用FFmpeg,后端負載均衡使用Nginx等,服務資源的隔離和動態(tài)調度目前也有比較好的開源容器云平臺。Q3:FFmpeg這個轉碼視