直播云平臺架構(gòu)如何構(gòu)建？【 附PPT】

本文根據(jù)4月26日 UCloud流媒體研發(fā)總監(jiān)曾凱源于〖KVM社區(qū)&UCloud技術(shù)微信群〗線上分享內(nèi)容整理而成。歡迎關(guān)注〖KVM社區(qū) & UCloud〗線上系列分享

注：每一種架構(gòu)在一定程度上都有參考的意義。UCloud 將邀請到了在直播、抱抱直播、Shou.tv和一起玩?？萍嫉募夹g(shù)專家，分享他們在海量服務(wù)架構(gòu)探索過程中的技術(shù)實踐。

如感興趣，您可以點擊文末“閱讀原文”，或?qū)⑷缦骆溄訌椭频綖g覽器打開了解并報名參加活動。

http://form.mikecrm.com/0Whn1K#rd

講師介紹

曾凱源

UCloud流媒體研發(fā)總監(jiān)

主要負責UCloud視頻云和 CDN 產(chǎn)品的研發(fā)工作。擁有近十年的互聯(lián)網(wǎng)研發(fā)經(jīng)驗，在云計算領(lǐng)域具有豐富的經(jīng)驗。此前，曾任職于騰訊，分別負責海量云存儲系統(tǒng)、海量CDN系統(tǒng)以及微信支付、彩票系統(tǒng)的性能優(yōu)化等工作。

演講提綱

本次主要為大家解析UCloud自有直播云平臺架構(gòu)，分析平臺架構(gòu)短板以及在用戶規(guī)?？焖僭鲩L下的架構(gòu)演進過程。

直播場景簡介

直播云架構(gòu)

核心架構(gòu)演進

容災(zāi)及故障處理

直播場景&直播服務(wù)架構(gòu)

直播場景

首先，介紹當下很火的直播場景。目前對直播場景的基本分類主要有媒體&活動直播、游戲直播、秀場直播和社交直播。

媒體&活動直播

特點：單向，無交互，流數(shù)少，延遲容忍度高 >10s；包含電視轉(zhuǎn)流、演唱會直播等。

這類目前對于直播的技術(shù)要求較低，低上行，高下行。

游戲直播

特點：單向，無交互，流數(shù)多，延遲容忍度高 >5s；目前國內(nèi)CDN產(chǎn)商搶得最激烈的一塊。

本身的業(yè)務(wù)場景其實并不需要那么低的延遲。延遲是2秒、5秒還是10秒其實對體驗的影響不是十分大。不過由于競爭激烈，拉高了延遲門檻。

秀場直播

特點：單向，文字交互，流數(shù)量多，延遲容忍度低 2~5s；這個是目前大家都能看得到盈利模式的一種。除了主播在播外，觀眾可以點贊，文字，送禮物，有一定的交互性。所以對直播的延遲要求苛刻，越低越好。推流主要是專業(yè)主播PC端，流數(shù)量多。

此類直播也稱為美女秀場，市場上存在大大小小公司，基本帶寬在1~5G。 秀場平臺非常多。

社交直播

特點：單向，文字交互，流數(shù)量非常多，延遲容忍度低 2~5s；社交直播和秀場直播，在交互上類似，區(qū)別比較大有兩點：1. 秀場一般都是有限的主播把內(nèi)容運營起來，推流的數(shù)量較少，一般是<100路；2. 社交直播是路人即可產(chǎn)生內(nèi)容，所以直播的流數(shù)會上升到1000，甚至10000。

目前最火的一塊，有映客，在直播，花椒等。整體直播云的設(shè)計是以滿足技術(shù)及并發(fā)要求最高的社交直播需求為主要目標。

直播服務(wù)架構(gòu)解析

要完成這類直播產(chǎn)品，需要有哪些模塊支撐？通常包括直播內(nèi)容采集、直播后臺系統(tǒng)和直播內(nèi)容播放三個模塊。

內(nèi)容采集：采集的方式有很多，從一般幾十塊PC攝像頭到幾十萬的專業(yè)錄制編碼設(shè)備，還有移動端的手機前后置攝像頭；分布式推流：這里是比較成熟的架構(gòu)，用戶在推流之前會通過名字服務(wù)，一般是DNS智能解析或是自有按IP調(diào)度系統(tǒng)獲取最靠譜的推流節(jié)點，然后把流上傳到服務(wù)器。

直播后臺系統(tǒng)：在分布式推流節(jié)點“接入”了用戶流之后，后續(xù)一系列的分發(fā)、轉(zhuǎn)碼、截圖、錄制、存儲等構(gòu)成了直播后臺系統(tǒng)；這里根據(jù)不同的業(yè)務(wù)需求，需要有不同的后臺服務(wù)來支撐。

直播內(nèi)容播放：這個就比較好理解了，一般輸出是PC屏幕、手機、現(xiàn)在還有VR頭盔。

直播云的云化，主要是解決了視頻流 上傳、處理和分發(fā) 的一系列問題。用戶只需要實現(xiàn)采集和播放即可。

直播云架構(gòu)

直播云最核心、難度最大的部分是直播的流分發(fā)網(wǎng)絡(luò)的架構(gòu)和分發(fā)算法設(shè)計，直接決定了整套服務(wù)可支撐的并發(fā)數(shù)和質(zhì)量以及服務(wù)成本。

以下重點分析UCloud核心分發(fā)網(wǎng)絡(luò)這塊的設(shè)計和演進。直播云架構(gòu)主要有核心的流分發(fā)網(wǎng)絡(luò)、運營子系統(tǒng)和業(yè)務(wù)邏輯子系統(tǒng)三大部分構(gòu)成。

運營子系統(tǒng)包括了調(diào)度系統(tǒng)、監(jiān)控系統(tǒng)和故障處理系統(tǒng)。

調(diào)度系統(tǒng)：實現(xiàn)直播索引及調(diào)度的能力，主要解決三個問題：用戶去哪個IP推流？流如何分發(fā)？用戶去哪個IP觀看？

監(jiān)控系統(tǒng)：實時監(jiān)控整套分發(fā)體系的上行壓力、下行壓力、中間網(wǎng)絡(luò)質(zhì)量及服務(wù)狀態(tài)等。

故障處理系統(tǒng)：負責IP、機房、片區(qū)網(wǎng)絡(luò)不可用時的處理。

業(yè)務(wù)子系統(tǒng)包含了非常多的系統(tǒng)，這里列舉幾個常見的。

實時轉(zhuǎn)碼：是一個集群，作用是在用戶推流碼率較高（比如720P）、但是會有移動端觀看的用戶時，需要實時轉(zhuǎn)成360P低清晰度的流；這個子系統(tǒng)實際服務(wù)能力非常有限，一臺8核設(shè)備只能實時轉(zhuǎn)10 路流，如果來1000路，就需要100臺。這里給一個重要經(jīng)驗：如果做不到按流的按需實時轉(zhuǎn)碼，建議不要搭建實時轉(zhuǎn)碼集群。因為成本極高！

實時截圖：架構(gòu)和實時轉(zhuǎn)碼類似，一般單機可處理100 流。

實時錄制：即將直播內(nèi)容實時保存下來存儲成點播文件。

核心架構(gòu)演進

那么，龐大復雜的直播云背后，核心架構(gòu)的挑戰(zhàn)到底有哪些呢？以下介紹一下UCloud直播云最核心直播流的分發(fā)網(wǎng)絡(luò)架構(gòu)的演進。

直播流的分發(fā)網(wǎng)絡(luò)主要挑戰(zhàn)：

高并發(fā)，高上行，高在線。

5億中國人已經(jīng)離不開在線娛樂，2006年-2015年，月度覆蓋人數(shù)增長5倍 ，每人每天花近一個小時用于在線娛樂，2007年到2014年，有效使用時長更是增長15倍 ；不同于傳統(tǒng)的CDN分發(fā)模型，直播是流式的數(shù)據(jù)，主播產(chǎn)生內(nèi)容、云服務(wù)進行實時的處理和分發(fā)，對上行的帶寬和質(zhì)量要求也非常高。以最近融資的映客為例，同時在線主播10000 ，觀眾50000 。

對比于傳統(tǒng)的CDN，這里有個重要的架構(gòu)考慮是需要支撐高上行的帶寬。

熱點時間集中直播流的分發(fā)網(wǎng)絡(luò)。

透過我們對大量直播客戶的帶寬觀察發(fā)現(xiàn)，直播的高峰期集中在晚上22點~0點，產(chǎn)品以“你丑你先睡，我美我直播”為宣言，在此期間的帶寬是平時的5~10倍。

帶寬成本高。

上行帶寬，下行帶寬，中間轉(zhuǎn)發(fā)的帶寬，總體帶寬成本非常高。

分發(fā)質(zhì)量要求高。

傳統(tǒng)的視頻點播，有一個源站，一份文件可以在發(fā)布的前一天把文件分發(fā)到離觀眾最近的節(jié)點，上行哪怕再慢些也無所謂，在直播的場景，越來越多的交互形式，需要實時把直播內(nèi)容盡可能快且穩(wěn)定的傳輸?shù)接^眾端。

總結(jié)：這可能是迄今為止最難設(shè)計的分發(fā)網(wǎng)絡(luò)。

核心架構(gòu)演進

直播云最核心的架構(gòu)－直播流的分發(fā)網(wǎng)絡(luò)經(jīng)歷了三次大演進。

V1.0 版本——一級DC

使用多線BGP進行全國覆蓋，憑借BGP技術(shù)解決解決了多運營商間轉(zhuǎn)播的問題，電信主播、移動觀看也流暢，同時也能兼顧到一些小運營商。

全國延遲區(qū)間在40ms~100ms；部分地區(qū)用戶網(wǎng)離BGP距離長，路由極易不穩(wěn)定，高峰期容易卡頓。

由于成本較高，在最初期僅支持4000路上下行，能滿足較小規(guī)模的直播客戶，并且需要設(shè)置較大的播放緩存來對抗網(wǎng)絡(luò)丟包和延遲，直播內(nèi)容延遲高。

容災(zāi)方面，單機房無異地容災(zāi)，遇到光纖挖斷，機房變更等會是致命打擊。

V1.5版本——高突發(fā)架構(gòu)

高突發(fā)架構(gòu)：引入了CDN供應(yīng)商到架構(gòu)中，快速優(yōu)化下行瓶頸的問題，下行容量增大N倍，基本不成為瓶頸；

流轉(zhuǎn)推：將熱門主播推流到合作CDN進行分發(fā)，從架構(gòu)層面看，是同一分出流量進行了多份的復制；

DNS智能解析：使用智能解析DNS按運營商、省份、用戶比例將播放帶寬切到CDN供應(yīng)商。

對于中小型的UGC 產(chǎn)品來說，帶寬上已夠用了。但是BGP的瓶頸仍然存在，并且合作CDN的質(zhì)量不可控。下行的延遲起到了一定的優(yōu)化，但和行業(yè)最優(yōu)還有不小的距離。于是又誕生了V2.0。

V2.0 版本——兩級DC＋OC架構(gòu)

架構(gòu)優(yōu)化：引入離用戶最近的OC小機房，推流端也通過DNS智能解析的方式，將上行分散到各個OC點。

質(zhì)量上，OC到BGP機房的路由是可控的，進行針對優(yōu)化，拉城域或區(qū)域?qū)＞€，流分發(fā)穩(wěn)定性非常高，已可支持1秒播放buffer，整體的直播延遲最低可以做到1秒。

瓶頸：由于仍要通過BGP對跨運營商的流做中轉(zhuǎn)，所以上行瓶頸問題沒有得到解決。

缺點：BGP的分發(fā)帶寬上升，對于不活躍的主播，從BGP 1 to N 的形式， 演變成 1 to M to N，在調(diào)度上需要算法來決策是否要下行放到OC上。

容災(zāi)能力：BGP機房仍然是鏈路單點。

架構(gòu)V2.0 對于架構(gòu)V1.5 來說， 單路流的成本其實是有上漲，但是質(zhì)量上起到不小的優(yōu)化。在V2.0 中我們也對BGP進行了帶寬擴容以應(yīng)對業(yè)務(wù)增長。

V3.0 版本

目前最新的架構(gòu)V3.0，引入了區(qū)域三通點，為BGP機房做容災(zāi)，對于同一區(qū)域如都在華東的推流和分發(fā)，直接走區(qū)域三通機房，BGP機房和三通機房部署多個，故障是只要調(diào)整路由即可。

三級多通架構(gòu)

架構(gòu)優(yōu)化：引入?yún)^(qū)域三通點，為BGP機房做容災(zāi)，對于同一區(qū)域如都在華東的推流和分發(fā)，直接走區(qū)域三通機房，BGP機房和三通機房部署多個，故障是只要調(diào)整路由即可。

分發(fā)策略：對同區(qū)域的同運營商的OC先進行分發(fā)，如廣東電信有10個OC機房，如果推流和播放是發(fā)生在這10份機房內(nèi)，就可以完全不經(jīng)過BGP和三通點，降低了BGP和三通架構(gòu)上的帶寬瓶頸。

整套架構(gòu)由BGP、三通機房、OC機房和合作CDN構(gòu)成，中間的轉(zhuǎn)發(fā)策略和鏈路非常多，需要通過主播所在地域、觀眾所在地域，熱度、質(zhì)量、成本的折中來實時調(diào)整分發(fā)的路由。

兩級多路由回源容災(zāi)

除了引入三通點外，還做了一些容災(zāi)設(shè)計，這里介紹一個典型的多路由容災(zāi)。

客戶端到接入OC：使用DNS做負載均衡，同時配置多個OC節(jié)點的IP，降低單點故障影響，同時監(jiān)控單線路如廣東電信配置是否存在單點。

OC回源：使用自有索引體系管理路由，為每個OC節(jié)點至少分配兩個以上的回源路由，并實時監(jiān)控上報各個oc回源質(zhì)量與各中轉(zhuǎn)節(jié)點負載信息。

前期靜態(tài)純?nèi)斯ぢ酚删S護，運維壓力非常大，多路由容災(zāi)后起碼節(jié)省了30%的故障處理人力。

故障自動處理

對于龐大數(shù)量的機房，故障的處理也不容易，比如一個機房IP down了，人工判斷如何遷移 IP的帶寬 是可以的，如果是一個OC機房或三通機房，純靠人工計算帶寬和配置，就很容易出錯。

所以有了直播云非常重要的一個故障處理模塊： 帶寬、負載動態(tài)路由規(guī)劃系統(tǒng)。

分級：單IP、單OC、三通點、BGP、合作CDN 的故障處理算法略有區(qū)別，通過對負載數(shù)據(jù)的線性規(guī)劃算法，可以求出成本和負載最優(yōu)，風險最低的負載均攤調(diào)度算法。

故障負載均攤優(yōu)先級：

均攤負載到 同一OC機房，這樣負載均攤就控制在機房內(nèi)；

將負載均攤到相鄰同省份機房，負載問題控制在省內(nèi)消化；

將負載均攤到區(qū)域機房，區(qū)域內(nèi)消化；

將負載均攤到合作CDN；

將負載均攤到三通、BGP中轉(zhuǎn)點.

這里優(yōu)先級也不是必然，需要根據(jù)實際情況來動態(tài)調(diào)整。

Q&A

Q1:UCloud的多路推送怎么做的負載均衡，轉(zhuǎn)碼過后怎么推送出去的，另外集群調(diào)度是怎么實現(xiàn)的？

答：多路推送靠DNS配置多IP輪轉(zhuǎn)來做負載均衡，轉(zhuǎn)碼過后不需要推出去，當有觀眾的時候再主動回來拉取。集群以DNS就近接入的方式調(diào)度。

Q2:負載均衡跨機房分攤有沒有什么具體指標呢？動態(tài)變化多嗎？如果發(fā)生動態(tài)變化，一般需要多少時間去處理？

答：1. 帶寬，基于直播場景，其實CPU,內(nèi)存不是瓶頸。2. 第二是根據(jù)實際用戶直播的延遲上報數(shù)據(jù)。

動態(tài)變化不算特別多。IP 級別的容災(zāi)是自動化，5分鐘左右。 OC機房的自動處理要看規(guī)模， 2G左右的機房一般能在10分鐘內(nèi)容完成帶寬遷移。20G帶寬的機房就需要人工介入，可以優(yōu)先切到合作CDN 再二次決策更優(yōu)的方案。

Q3:不同網(wǎng)絡(luò)環(huán)境網(wǎng)絡(luò)不一樣的時候碼率，和幀數(shù)怎樣控制？

答：目前直播很少做動態(tài)碼率幀率調(diào)整，一般是固定的碼率和幀率。 網(wǎng)絡(luò)質(zhì)量差的情況下做動態(tài)碼率，幀率的調(diào)整效果不佳，難以使直播流暢，最終用戶還是會放棄。

Q4:云CDN和傳統(tǒng)CDN方式什么區(qū)別？

答：云CDN，最大的特點是 和其他云產(chǎn)品如主機、存儲、計算等能有機的結(jié)合起來。傳統(tǒng)的CDN，僅負責對內(nèi)容進行分發(fā)。

Q5:CDN方面目前有沒有API接口，支持腳本調(diào)用不？

答：有API接口的，詳細的刻可以瀏覽：https://docs.ucloud.cn/api-docs/ucdn-api/index.html

Q6:OC回源鏈路是什么？什么情況/場景下需要回源？怎么回源？

答：回源鏈路就是決定OC去什么地方拉直播流。OC機房當前沒有用戶要看的直播流時，需要往上拉流。

Q7:直播后臺系統(tǒng)內(nèi)部，底層使用什么協(xié)議？

答：上行RTMP，內(nèi)部轉(zhuǎn)發(fā)有RTMP協(xié)議，也有自研UDP協(xié)議，播放走RTMP/HTTP協(xié)議。

Q8:實時轉(zhuǎn)碼：一臺8核設(shè)備只能實時轉(zhuǎn)10 路流，這里是用的cpu核？實時轉(zhuǎn)碼需求大嗎？

答：用的CPU核。要看具體場景，如果是PC推流，有手機觀察的用戶，轉(zhuǎn)碼就有需求，大屏錄制轉(zhuǎn)小屏觀看的情況。

Q9: 目前我知道的CDN延遲都在5s左右，厲害的到2s。既然這是使用了CDN，如何做到40-100ms的延遲的？

答：這里說的40-100ms的延遲是指純網(wǎng)絡(luò)時間，CDN延時在5s是指的直播內(nèi)容級別的延遲，是由于在不同設(shè)備上的轉(zhuǎn)發(fā)，各層級加上了不同大小的緩存造成，另外還有客戶端錄制和播放的消耗。

Q10:關(guān)于推流。如果客戶端源從攝像頭到如ppt類的切換，那么推流方式有在技術(shù)上何不同？如何完成從攝像頭到個人PC桌面內(nèi)容的切換推流。

答：攝像頭和PPT只是采集方式不一樣，出來的兩路流在播放的時候進行切換即可。 個人PC桌面內(nèi)容的推流及合并可以用OBS，可以做串流處理，同時展示攝像頭和屏幕內(nèi)容。

Q11: 關(guān)于播放。如果不是m3u8（不知道有沒有記錯），安卓客戶端要如何播放？

答：使用內(nèi)嵌瀏覽器的方式即可，一般安卓都會使用librtmp之類的播放RTMP，不會播m3u8.

Q12:如果通過微信公眾號接入直播服務(wù)，是否需要特定的頁面與cdn推流及播放對接？這是否需要寫一個播放頁出來？

答：需要寫一個簡單的播放也面，只要直播服務(wù)支持HLS格式就行，公眾號里面可以直接播放。

Q13: 客戶端接入那個服務(wù)端是怎么做的？需要測速么？

答：從DNS或其他方式獲取到具體的IP后，進行基本的PING測速選定服務(wù)器IP。

Q14: 推上來的流只有一路，怎么做到雙路由回到bgp 或者三通？

答：雙路由僅指在播放的時候。

下期預告

參與方式詳見：

30天四場技術(shù)分享，我賭上程序員的尊嚴解析UCloud產(chǎn)品技術(shù)實踐

歡迎報名：云計算存儲技術(shù)峰會.成都站

更多詳情請掃描活動下方二維碼參與報名！

加速會：加速你對世界的理解，內(nèi)幕全在這里！請關(guān)注加速會微信公號：jiasuhuihao

加速會主編微信：leaderweb

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。