雲直播系統架構與實施
雲直播系統架構與實施
直播型別
傳統直播
傳統直播基本都是單向傳輸，很少有做互動。類似於廣電演唱會的直播，做互動都是放在秀場裡做。只是簡單的對外傳輸直播流，並且流數比較少，延遲容忍度高，基本都超過 10 秒，包括電視轉流、演唱會直播等。
遊戲直播
遊戲直播也是單向傳輸，通過直播文字進行互動，利用彈幕或者討論組進行溝通。最大的特點是流數比較多。遊戲直播自身的業務對延遲要求不高，但因為競爭激烈提升要求，目前做秀場直播，要做到2秒。大家想想主播在打遊戲的過程中，不管是在直播自己玩的遊戲內容還是介紹玩遊戲的心得，延遲並不是特別重要，因為更多的時候，在直播的過程當中，彈幕和討論組跟直播流是分開的。
電商直播
電商直播的特點是單向、文字互動，流數少，基本是介紹自己的商品，延遲容忍度高於 5 秒。有跨國性的特殊需求，像海外淘，國外買手在直播自己的內容，這時候需要專業的廠商提供一些海外的內容。
移動輕秀場
移動輕秀場有兩種方式：單向和雙向。通過文字互動或者直接通過流進行聊天，流數比較多。延遲容忍度比較低，2到5秒已是非常大的要求。基本很多都是1到2秒之間。
直播+的概念
直播+使直播進入一個更多垂直的細分領域，包括O2O以及其他內容，比如新聞釋出會、做培訓宣講希望別人看到自己的內容。這是直播架構帶給更多的使用者趨向性的東西，你可以通過直播的方式介紹你的產品、員工。
又拍雲的整個直播服務的架構，首先需要有一個訊號語言，不管是電視訊號源、攝像機訊號源、還是桌面捕捉下來的內容，都可以通過推拉流的方式直接上傳到一個視訊處理的中心，進行編解碼或者做一些水印等視訊處理。比如給它們加一些打點的資料、字幕以及一些特殊說明等，這些都會在視訊處理這塊生成H.264和AAC的直播流，然後通過內容分發的網路，直接分發到全國的邊緣，讓使用者能夠通過各種裝置看到我們的直播流。我們處理完視訊流之後，還可以進行錄製儲存，錄製完了之後還能夠轉成點播，滿足使用者的多樣需求。還有虛擬直播的概念，包括現在一直播，在錄下來的時可以轉成FLV的流推出來，這是虛擬直播的概念，不是真正的現實流錄播。
業務架構
常見業務架構
很多人在設計直播架構的時，通常傳統廠商都會有一個集中的視訊源。視訊源能夠讓使用者把視訊傳到單一視訊源裡面。單一視訊源的優勢是省事，做分支部署比較簡單，但是故障率比較高，傳送故障以後解決的時間較長。而直播，特別是互動類直播，大量的主播分佈在各個運營商網路裡，單一的視訊源並不能夠滿足跨運營商傳播的時效問題和網路的優化問題。通過單一視訊，蒐集到資料之後，再向運營商做一個分發，這是不靠譜的網路結構，那遇到雲直播之後會產生什麼樣的變化呢？
視訊雲業務架構
在視訊雲的業務架構中，會加入更多的組建視訊源的叢集，用於收集視訊主播的邊緣使用者的直播流上傳資料。比如北京電信使用者上傳上來，如果只有一個單一源,在上海電信客戶會需要跨城市去上傳到上海電信區域。但是現在有一個叢集式的雲，他就可以通過合理排程直接上傳到最為適合的上行邊緣節點，比如上傳到北京電信邊緣節點，再通過北京電信上傳到我們的核心源，再通過內部進行互動和分發，如果你的播放使用者在聯通裡面，還可以通過幾個核心源之間進行資料排程中轉，傳輸到聯通邊緣，再提供給終端使用者進行訪問。
在河南、浙江、廣州、北京、江蘇、四川搭建了一個用光纖打通的核心視訊源的叢集，當做主播推流到任何一個邊緣節點的時候。可以通過智慧排程進行跨越傳輸，通過物理光纖直接進行資料互動，縮短資料傳輸的時間。合理的將大量使用者進行智慧排程訪問到不同的運營商，不同區域，提供終端使用者的訪問體驗，也就意味著可以保證一個低延時直播訪問。
核心節點叢集通過的光纖打通之後有什麼好處呢？如果是單一的視訊源，像去年有廠商核心資料中心光纖被挖斷髮生長時間大面積的網路故障，如果使用雲直播平臺服務，在6大核心節點中使用物理光纖打通，當單一核心節點故障時，可以通過智慧排程轉換訪問其他區域，實現自動容災，發生故障時，節點之間可以進行相互切換，自動選路。就不會出現某一個機房斷了，整體的服務就要停止，合理的防止單點故障照成的更大網路故障並提高跨網跨運營商的傳輸速度和效率。
傳統直播服務與直播雲的對比
對直播而言，視訊源站的穩定性非常重要，直播不間斷、不卡頓，跟源站有直接的關係，對直播效果帶來的影響很大。傳統直播服務多采用單一源站，而直播雲將整個平臺去單點化，通過打造源站叢集，形成多個源站的架構。單一源站使整個架構系統非常簡單，在單一機房，維護一套系統，很容易實現分散式；延時方面不用擔心公網網路抖動導致的系統不穩。既然如此，又拍云為何要耗費精力財力打造源站叢集？原因在於單一源站的致命缺點：內容源完全受限於一個源站，當機房頻寬擁堵，整個平臺所有的直播內容都會卡頓；而一旦公網故障，內容就完全推不出去，意味著直播失敗。
為了解決這一問題，又拍雲在全國六個比較重要的地區，如北京、浙江、江蘇、四川、河南、廣東的核心節點部署源站叢集。一個源站的叢集十幾臺伺服器，六個叢集大概六十多臺的規模。通過私有光纖網路將六大資料中心打通，形成類似於內網的狀態，實現高可用性。整個光纖鏈路是個環路，互聯互通，即便北京到江蘇的光纜出現故障，也可以通過浙江轉到北京。因此，使得直播服務的網路質量更有保障，穩定性和安全性也更上一層樓，同時整個平臺具備跨地區的自動容災的能力。舉例來說，直播雲面向的群體是主播端或者播放端，終端使用者群體遍佈在全國各地。在雲南的主播使用者通過 4G 手機推送直播內容到就近的視訊源站，如廣東，這個內容推送上來後將被同步到全國六個其他的源站。全國所有終端使用者播放的時候，就可以到廣東源站獲取資料。這樣不僅可以提高網路傳輸的效率、保障直播的延時效果，同時當視訊源站網路中斷時，系統還可以自動的遷移到其他源站，通過SDK或者是域名解析兩種方式均可進行自動化鏈路選擇。又拍雲選擇SDK的方式進行容錯設計，可實現秒級容災，即廣東出現問題即時切換到浙江的視訊源。而域名解析的延時和生效週期會較長，是分鐘級別的，最快也要將近5分鐘。
傳統的直播架構由於只有一個視訊源站，無二層快取。而直播雲中的產品採用全國分散式叢集架構，除視訊源站裡還會有一層二級快取，在源站與源站間合併回源，從而提升加速的效果，降低使用者流量成本。
雲直播的整體框架
直播雲的雲化，主要是解決了視訊流上傳、處理和分發的一系列問題。使用者只需要實現採集和播放即可。雲直播整體框架包括了運維管理中心、業務管理系統和服務端核心系統、節點叢集模組。
整個運維管理中心對源站、流量、網路進行監控。包括現在全國的使用者到節點之間訪問的網路效果、核心與節點之間的傳輸速率等等資料，參考這些資料，能夠進行一個合理的排程。另外就是裝置的監控，我們可以做到針對單臺裝置的單個硬碟現在的網路情況、頻寬情況和 CPU情況，做一些智慧排程。內部監控主要針對服務端的核心繫統，包括智慧排程、負載均衡、流媒體處理中心、還有音視訊的處理等。還有客戶需要的防盜鏈，我們可以支援後臺自主的進行動態配置防盜鏈，也可以升級配置健全的防盜鏈。還有後端可以自助配置。我們主打的概念是一個帳號、一套API可以實現所有的功能，也就是我們一直提倡讓創業更簡單的概念。
還有一些防攻擊的資料，目前所有的平臺給到使用者的監控資料，使用者都可以在我們的客戶端裡面看到，移動、聯通、電信使用者訪問延時情況還有頻寬速率的情況。當用戶遇到攻擊的時，我們會詳細的幫使用者統計攻擊的型別。我們最新一版升級版的資料，可以按照省份和運營商進行統計，根據每個省份運營商的訪問量級，我們可以調整他的分佈。或者說當你做廣告投放的時候，可以定位看看能不能有比較好的效果。或者某個區域的使用者，可能故障率比較高，某個城市沒有明顯的變動，個別的使用者終端訪問可能存在問題，依靠這些資料可以縮短我們排查故障處理的時間。
核心系統介紹
核心系統中有幾項較為重要的內容，第一是智慧調動中心。它負責整個雲CDN系統的排程，根據網路質量、節點健康狀況進行診斷。我們內部ES把所有的日誌資訊進行蒐集到後臺，可以通過影象化的樣式直接展示出來。每個邊緣節點訪問的狀態碼是多少，佔比有多少，它的訪問數是不是突然有增高的情況，我們可以通過線上篩選的實施，每五分鐘日誌訪問來源的情況。另外是邊緣節點叢集，目前我們除了比較健碩的六個核心資料中心以外，還有 150多個的邊緣節點組成上下行的邊緣節點叢集。
從軟體架構上看，推流與播放器中間，第一個是運用SDK做容錯設計。比如如果不用 SDK，通過域名做訪問可以做一些容錯排程。但它的切換的時間比較長，SDK秒級就可以把資料直接切走。如果是通過域名的話，最快需要5分鐘，更長需要48小時。
另外針對GOP Cache做一些調整的設計。可以把GOP調整成0.05秒，根據使用者具體的要求達到最好的效果。體現功能即第一延時少，第二秒開。不管是GOP的大小，或者播放器的調整，其實都是根據我們的具體業務進行的。因為本質其實就是一個取捨，調整大了或者調整小了，是針對特定的需求的，不是對所有的使用者都通用。
最後一個是邊緣伺服器，有很多使用者對邊緣伺服器是不是能夠直接支援三協議感到疑問。比如說RTMP和HLS都支援，RTMP和RTMP轉HLS和封裝之後，FLV都可以在任何一臺邊緣伺服器中直接播放。
功能
多協議支援
搭建健碩的核心網主要目的是希望在功能上為創業者服務，創業者剛開始做的時候可能會遇到很多問題，我們提供場景化的模板、多協議支援，現在支援 HTTP、RTMP，於月底也會對HTTPS支援進行升級維護，在流媒體裡面，也可以通過使用協議在後臺進行自動化的配置。又拍雲首家釋出基於WEB的SSL自助配置，可以直接提交自有SSL資訊在頁面上進行配置後直接使用，不需要做過多的申請和等待等。
推拉流SDK
推流端可以提供Android和iOS版本。幫助使用者快速建立資料流的採集，避免很多使用者做推流端的時候有一些不規範的地方，比如編碼等。通過SDK可以做一些設定，將其標準化，提供美顏、前後攝像頭切換、閃光燈開啟、位元速率解析度調整等。如果說現有的PC端使用者通過OBS推流上傳的是非標準的協議的版本或者音視訊的版本，雲直播可以幫使用者統一轉成H264、AAC。比如說火貓為了展示更好的效果給終端使用者，讓其播放器播放出來的畫面解析度統一，編碼格式一致，要求廠商提供統一編轉碼設定服務等。
防盜鏈
防盜鏈，是很多使用者比較頭疼的地方，當APP應用做的比較好、有知名主播上線的時候直播、或者有提供的版權內容服務時，會有很多盜鏈服務的風險。又拍可以提供合理的防盜鏈解決方案，可以在又拍後臺進行自主配置。常用的像UA的黑白名單、動態的Taken防盜鏈、回源鑑權等。其他配置功能可以在後臺進行自主操作。
PULL模式支援
如果有一些大型賽事做直播或者做一些比較重點的賽事直播，可以提前通過PULL模式把資料推給我們，我們直接推到邊緣。等開始直播的時候，再讓使用者進行觀看，這樣可以第一達到秒開，第二可以讓保障直播流的流暢穩定。
高效轉碼
轉碼在很多使用者裡面有很大的需求。原因是原始流推上來的時候由於推流端設定的問題原始碼率是大小不一致的，而播放終端的網路又比較差，有可能滿足200K的，有可能500K是比較流暢的，這時就需要進行統一轉碼。但是轉碼裝置如果由使用者自己搭建的話，投入的成本比較高。現在基本上除非是硬體轉碼的裝置，業內做用伺服器搭建的話，一臺普通伺服器可以支援同時轉碼10路或8路，這是屬於比較正常的狀態，還需要看原始碼率的大小。
直播錄製
這是廣電總局最新的要求。所有直播APP必須做直播錄製流程，便於檢視和存檔。很多人希望做直播錄製，錄製完後直接去做點播，不是所有人都把流推到自己伺服器然後轉到CDN廠商去做。因為CDN廠商在邊緣節點有大量的豐富的上行節點，推上來的效率更高一些。這部分使用者他的源是沒有直播流的，就需要CDN廠商提供直播錄製的服務，當然我們也可以轉推路給使用者由使用者進行自主錄製。
非同步音視訊處理
錄製完檔案之後，視訊流的編輯、截圖或者視訊大小的調整等服務需求都可以在音視訊處理功能裡面實現。
直播流截圖
還有一個廣電總局的要求，即鑑別非法、暴力的東西。業界都是用直播流截圖的辦法做，對直播流進行截圖，再針對圖片進行非法鑑別，當然也有做使用者直接做直播流的鑑別，不過這樣消耗比較大。
自定義延播功能
自定義效能比較高，使用者可以選擇，五分鐘之後才播放目前的流或者秒開地播。目前我們提供播放器SDK，iOS和Android版已經發布到GitHub了，大家有興趣的話可以到又拍雲文件中心下載，裡面有詳細的說明。還有一個就是對P2P的支援。
流狀態通知
在直播的整個流程裡面很重要一點是流狀態的通知。比如說使用者的流的是否播放。主播是否推流、斷流了，有 90% 故障都是來源於上行端，我們希望蒐集到主播端的幀率，有關主播推上來的位元速率、節點、速率等。通過測試的方式，直接從流狀態裡面反映出主播現有的情況。還有針對下行訪問資料的收集。一般比較大的廠商會自己去做，可以蒐集流的現在卡頓的情況，因為每個人對卡頓的演算法不一樣。所以說我們在後期也會把流狀態通知的介面到SDK裡面，在第二個版本直接發出來。這是在大資料分析的模組裡面，希望把這塊資料直接通過API和web展示提供出來。
自定義流禁播
當遇到涉黃的時候，如何快速的把流禁播掉。一般情況下的做法是使用者請求流禁播介面，然後把這個流的上行推流停掉。我們上線一個自定義的流禁播的功能模組，使用者可以直接在後臺裡面進行配置。比如禁播使用者多長時間，禁播IP或者是禁播流名，可以設定三個頻率，第一次禁播五分鐘之後自動解禁，第二次禁播三個小時，第三次永遠禁播，不讓使用者推流，通過不同維度的流禁播來提供較好的直播服務。
實時轉碼樣式表的支援
當上行直播流編碼比較複雜和多樣化的時候，使用者可能不再侷限於只針對某個直播流去做轉碼支援。這個時候我們可以提供類似樣式表的服務，使用者可以選擇建立樣式模板、所需要的功能項。比如標準轉碼之後解析度、要求現在要降的位元速率還有其他的格式要求等都可以在轉碼的樣式表裡面建立自己的樣式表。
另外還有自定義訪問限制，可以針對 IP 和來源使用者進行訪問設定；延時追趕，可以做到當有延遲累計的時候進行跳幀的延時追趕行為；以及智慧排程、直播時移等功能；流時長統計服務，主要是使用者需要和主播進行每個月的直播結算場景來源。以及打水印功能，可以在推流端的SDK裡面進行設定定義好後提交上來。我們希望建立一個自定義的水印版本，使用者可以選擇logo，和偏移量以及寬度，還可以針對某路流去打水印。因為使用者可能在同一個掛載點下推了不同的流，某個流可能是有版權需求，賣版權的時候不希望把自己的 LOGO打上去或者是對方要求不能把你的LOGO打上去。我們通過這種比較方便的方式就可以實現自定義水印的功能。
實施效果
以下是最新實際測試的效果圖，北京使用者主播推送出來，左邊框是使用者觀看的視訊，右邊是推流的視訊介面。北京使用者主播在北京觀看，平均延時是1.1秒。此處展示的是RTMP 流。右邊是杭州主播在北京觀看，延時是1.3秒，這在業內來說是比較好的資料。
