直播類APP開發(fā)目前是非?；鸬?，很多商家都急切的蹭一波熱度,我們今天來聊一聊直播APP開發(fā)的流媒體系統(tǒng)的技術(shù)架構(gòu)及應(yīng)用
?流媒體原理
1.1 流媒體概念
1.2 流式傳輸特點(diǎn)
1.3 流媒體系統(tǒng)構(gòu)成
1.4 流媒體涉及技術(shù)
1.5 流媒體應(yīng)用
1.6 國內(nèi)外大型流媒體系統(tǒng)
1.7 總結(jié)
流媒體相關(guān)術(shù)語
?流媒體系統(tǒng)
2.1 編碼工具
2.2 流媒體服務(wù)器
2.3 CDN分發(fā)網(wǎng)絡(luò)
2.4 網(wǎng)絡(luò)協(xié)議
2.5 播放器
總結(jié)：從一個直播APP看流媒體系統(tǒng)的應(yīng)用
通過第一篇流媒體原理和第二篇對流媒體系統(tǒng)的描述，我們大概能了解流媒體技術(shù)中的基本概念，以及一個大型流媒體系統(tǒng)中大概有哪些部分組成。
本篇文章我們從一個實際應(yīng)用來對照著看前面所講內(nèi)容到底是如何應(yīng)用到一個直播APP中的。今天我們拿歡聚旗下的ME平臺來舉例，這款應(yīng)用于今年2月上線，在直播應(yīng)用中并不強(qiáng)勢，不過它是最早加入連麥功能的平臺之一。
所有直播平臺，不論是PC上的游戲直播、秀場，還是映客類移動直播，功能都大同小異。主線功能就是下面三張圖：
作為觀眾進(jìn)入應(yīng)用看到列表，從眾多主播中選一個進(jìn)入房間觀看直播：
作為主播發(fā)起直播，別人重復(fù)上面的流程：
以上只是直播APP最基本的功能，一個真實的直播平臺背后所涉及的東西要比我們所看到的復(fù)雜得多。下面從直播數(shù)據(jù)流、CDN分發(fā)、消息隊列、業(yè)務(wù)邏輯、交互功能、體驗優(yōu)化、業(yè)務(wù)數(shù)據(jù)/性能數(shù)據(jù)統(tǒng)計監(jiān)控、場景化、平臺架構(gòu)等9大方面簡單列舉一個真實直播應(yīng)用所涉及到的東西。這里面有流媒體技術(shù)相關(guān)的，我們從這里面著重講流媒體原理和流媒體系統(tǒng)中講的點(diǎn)予以對照理解，也有和流媒體技術(shù)本身不相關(guān)的，這些方面只需知道一個直播APP還會用到這些即可。
1、直播數(shù)據(jù)流
一個完整的直播流程即主播發(fā)起直播→觀看進(jìn)入房間觀看→主播結(jié)束直播，我們能看見的就是上面圖中給出那樣，點(diǎn)幾個按鈕即可。然而看不見的背后是下面這張圖給出的直播流在數(shù)秒內(nèi)的歷程。
這個流程是直播APP最核心也是研發(fā)難度最大的部分，包含了我們之前講流媒體系統(tǒng)組成部分中最重要三大環(huán)節(jié)，直播的數(shù)據(jù)流在這里面歷經(jīng)了音視頻采集→視頻前處理（美顏濾鏡、特效等）→音頻前處理（回波消除、降噪等）→音視頻編碼→推流→流媒體服務(wù)器（轉(zhuǎn)碼、轉(zhuǎn)封裝、錄制等諸多云端功能）→拉流→解碼→播放 等一系列流程。
由于技術(shù)門檻高，需投入研發(fā)資源和時間成本極高，通常這部分內(nèi)容直播APP都不自研，而是托管給觀止云、又拍云這樣的直播云服務(wù)平臺。如果是自研一般也在端上發(fā)力，之前文章給出了眾多研發(fā)這些環(huán)節(jié)中經(jīng)常會用到的一些開發(fā)框架：
? 推流端框架：
采集：AVFoundation
濾鏡：GPUImage
編碼：FFmpeg/X264/Speex
推流：Librtmp
? 流媒體服務(wù)器：
nginx-rtmp
SRS
BMS
? 播放端：
解碼：FFmpeg/X264
播放：ijkplayer/video.js/flv.js
2、CDN分發(fā)
上面所述的直播流中，雖然能從推流跑到播流，但如果觀看者數(shù)量眾多，單靠堆砌流媒體服務(wù)器是很難支撐的，所以真實的直播應(yīng)用都有CDN分發(fā)這一環(huán)節(jié)，正因為如此之前講流媒體系統(tǒng)組成中，我們也將CDN納入了大型流媒體系統(tǒng)中必要的組成部分。
除了極少應(yīng)用有能力自建部分CDN節(jié)點(diǎn)，大部分直播APP會采用成熟的第三方商用CDN。直播CDN之前講過，是在標(biāo)準(zhǔn)的CDN架構(gòu)之上，必須依靠獨(dú)立的流媒體服務(wù)器設(shè)備組進(jìn)行流式協(xié)議的分發(fā)，完整的直播CDN系統(tǒng)主要包括流媒體服務(wù)器（Nginx/BMS/SRS等）、負(fù)載均衡、路由重定向（DNS/HTTP DNS等）、防盜鏈、緩存等。
我們用DIG命令去追溯ME平臺分享頁面的地址，可看出ME分享頁面使用的CDN是YY自建CDN。
DIG映客地址，可看出映客分享頁面部分使用的CDN是網(wǎng)宿CDN。
消息隊列
消息隊列指的是直播APP中眾多基于消息隊列的異步通信機(jī)制，主要包括賬號/關(guān)系鏈、消息/提醒/通知/評論/彈幕/點(diǎn)贊/虛擬禮品、紅包、商品/支付等等。消息本身不難做，但要保證一個APP中大規(guī)模、高并發(fā)、多類型的消息隊列的高穩(wěn)定性也是有不小的難度，比如我們經(jīng)常聽說的一場直播中彈幕超超1億條這種。所以消息隊列服務(wù)，部分直播APP也會采用第三方服務(wù)。
下圖為ME平臺中消息系統(tǒng)：
業(yè)務(wù)邏輯
這層主要是直播APP自身的業(yè)務(wù)結(jié)構(gòu)，主要包括房間邏輯、用戶/管理員邏輯、榮譽(yù)體系設(shè)計等。
交互功能
直播過程中，主播與觀眾，觀眾與觀眾，觀眾與直播內(nèi)容之間的交互統(tǒng)稱為交互功能，這里面包括連麥這樣的流媒體技術(shù)互動，大型聊天室這樣的消息互動功能，實時調(diào)查問卷這樣的業(yè)務(wù)互動，也包括商品識別等基于內(nèi)容的互動。
體驗優(yōu)化
我們在看直播的時候都有低延遲、高清流暢、極速秒開等基本的體驗訴求。為了滿足這些觀看體驗要求，就需要流媒體技術(shù)在各個細(xì)節(jié)點(diǎn)上做針對性優(yōu)化。這里面我們需要知道，哪怕是我們視為理應(yīng)的如延遲降低1秒，流暢度提升5個百分點(diǎn)，首屏加載控制到1秒內(nèi)，其背后都是技術(shù)提供商大量的方案論證與研發(fā)投入，這絕不是簡單用開源組件把流程跑起來那么簡單。
之前觀止云，以及各友商的流媒體技術(shù)團(tuán)隊幾乎把其中每一個優(yōu)化點(diǎn)都無私的分享了，此處就不搬磚了。
業(yè)務(wù)運(yùn)營數(shù)據(jù)/性能監(jiān)控
運(yùn)營一個大型直播APP，其中每天都會積累大量的運(yùn)營數(shù)據(jù)，通過采集、分析大量運(yùn)營數(shù)據(jù)，我們能從中抽象出指導(dǎo)產(chǎn)品運(yùn)營的方向。運(yùn)營數(shù)據(jù)一般需要APP在播放器中直接采集原始數(shù)據(jù)，指標(biāo)項如觀看人數(shù)、觀看人次、觀看總時長、人均觀看時長，人均觀看直播流、跳出、觀看路徑等等指標(biāo)，以及他們在多維度、多層面的交叉統(tǒng)計。
直播流程繁復(fù)，是個特別容易出故障的業(yè)務(wù)。要排查、處理直播故障，我們需要從整個直播數(shù)據(jù)流中的各個環(huán)節(jié)去抓取幾十項性能數(shù)據(jù)，并從這海量性能數(shù)據(jù)中不斷優(yōu)化產(chǎn)品的技術(shù)架構(gòu)。性能數(shù)據(jù)可自研，也可采用第三方性能監(jiān)測服務(wù)，指標(biāo)項如建連時長（DNS，TCP，首包等）、首次等待時長、卡頓率、卡頓次數(shù)、連續(xù)卡頓事件、人均卡頓等等。
場景化
場景化指的是對不同垂直直播特點(diǎn)而提供的特有功能組成的針對性解決方案。
另外，還有如大型活動直播需要云端導(dǎo)播，多平臺發(fā)布等。
平臺架構(gòu)
以上8點(diǎn)都是以ME為例對直播APP中獨(dú)立的模塊列舉，雖然說這些模塊基本都有開源方案或者成熟的第三方商用服務(wù)，但要將這些模塊或系統(tǒng)完美的整合起來，就要求有極高的平臺架構(gòu)設(shè)計，做到高承載、高穩(wěn)定、高靈活、易擴(kuò)展。這里面包括就包括我們在第一篇講流媒體涉及技術(shù)中提及的基于云架構(gòu)的計算、數(shù)據(jù)庫、網(wǎng)絡(luò)、存儲、消息隊列等等云計算技術(shù)應(yīng)用。
本文來自網(wǎng)絡(luò) 由藍(lán)暢整理，經(jīng)授權(quán)后發(fā)布，本文觀點(diǎn)不代表Infocode藍(lán)暢信息技術(shù)立場，轉(zhuǎn)載請聯(lián)系原作者。
