直播類APP開發(fā)目前是非常火的，很多商家都急切的蹭一波熱度,我們今天來聊一聊直播APP開發(fā)的流媒體系統(tǒng)的技術(shù)架構(gòu)及應(yīng)用
?流媒體原理
1.1 流媒體概念
1.2 流式傳輸特點
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)用中并不強勢，不過它是最早加入連麥功能的平臺之一。
所有直播平臺，不論是PC上的游戲直播、秀場，還是映客類移動直播，功能都大同小異。主線功能就是下面三張圖：
作為觀眾進入應(yīng)用看到列表，從眾多主播中選一個進入房間觀看直播：
作為主播發(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)中講的點予以對照理解，也有和流媒體技術(shù)本身不相關(guān)的，這些方面只需知道一個直播APP還會用到這些即可。
1、直播數(shù)據(jù)流
一個完整的直播流程即主播發(fā)起直播→觀看進入房間觀看→主播結(jié)束直播，我們能看見的就是上面圖中給出那樣，點幾個按鈕即可。然而看不見的背后是下面這張圖給出的直播流在數(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é)點，大部分直播APP會采用成熟的第三方商用CDN。直播CDN之前講過，是在標準的CDN架構(gòu)之上，必須依靠獨立的流媒體服務(wù)器設(shè)備組進行流式協(xié)議的分發(fā)，完整的直播CDN系統(tǒng)主要包括流媒體服務(wù)器（Nginx/BMS/SRS等）、負載均衡、路由重定向（DNS/HTTP DNS等）、防盜鏈、緩存等。
我們用DIG命令去追溯ME平臺分享頁面的地址，可看出ME分享頁面使用的CDN是YY自建CDN。
DIG映客地址，可看出映客分享頁面部分使用的CDN是網(wǎng)宿CDN。
消息隊列
消息隊列指的是直播APP中眾多基于消息隊列的異步通信機制，主要包括賬號/關(guān)系鏈、消息/提醒/通知/評論/彈幕/點贊/虛擬禮品、紅包、商品/支付等等。消息本身不難做，但要保證一個APP中大規(guī)模、高并發(fā)、多類型的消息隊列的高穩(wěn)定性也是有不小的難度，比如我們經(jīng)常聽說的一場直播中彈幕超超1億條這種。所以消息隊列服務(wù)，部分直播APP也會采用第三方服務(wù)。
下圖為ME平臺中消息系統(tǒng)：
業(yè)務(wù)邏輯
這層主要是直播APP自身的業(yè)務(wù)結(jié)構(gòu)，主要包括房間邏輯、用戶/管理員邏輯、榮譽體系設(shè)計等。
交互功能
直播過程中，主播與觀眾，觀眾與觀眾，觀眾與直播內(nèi)容之間的交互統(tǒng)稱為交互功能，這里面包括連麥這樣的流媒體技術(shù)互動，大型聊天室這樣的消息互動功能，實時調(diào)查問卷這樣的業(yè)務(wù)互動，也包括商品識別等基于內(nèi)容的互動。
體驗優(yōu)化
我們在看直播的時候都有低延遲、高清流暢、極速秒開等基本的體驗訴求。為了滿足這些觀看體驗要求，就需要流媒體技術(shù)在各個細節(jié)點上做針對性優(yōu)化。這里面我們需要知道，哪怕是我們視為理應(yīng)的如延遲降低1秒，流暢度提升5個百分點，首屏加載控制到1秒內(nèi)，其背后都是技術(shù)提供商大量的方案論證與研發(fā)投入，這絕不是簡單用開源組件把流程跑起來那么簡單。
之前觀止云，以及各友商的流媒體技術(shù)團隊幾乎把其中每一個優(yōu)化點都無私的分享了，此處就不搬磚了。
業(yè)務(wù)運營數(shù)據(jù)/性能監(jiān)控
運營一個大型直播APP，其中每天都會積累大量的運營數(shù)據(jù)，通過采集、分析大量運營數(shù)據(jù)，我們能從中抽象出指導(dǎo)產(chǎn)品運營的方向。運營數(shù)據(jù)一般需要APP在播放器中直接采集原始數(shù)據(jù)，指標項如觀看人數(shù)、觀看人次、觀看總時長、人均觀看時長，人均觀看直播流、跳出、觀看路徑等等指標，以及他們在多維度、多層面的交叉統(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ù)，指標項如建連時長（DNS，TCP，首包等）、首次等待時長、卡頓率、卡頓次數(shù)、連續(xù)卡頓事件、人均卡頓等等。
場景化
場景化指的是對不同垂直直播特點而提供的特有功能組成的針對性解決方案。
另外，還有如大型活動直播需要云端導(dǎo)播，多平臺發(fā)布等。
平臺架構(gòu)
以上8點都是以ME為例對直播APP中獨立的模塊列舉，雖然說這些模塊基本都有開源方案或者成熟的第三方商用服務(wù)，但要將這些模塊或系統(tǒng)完美的整合起來，就要求有極高的平臺架構(gòu)設(shè)計，做到高承載、高穩(wěn)定、高靈活、易擴展。這里面包括就包括我們在第一篇講流媒體涉及技術(shù)中提及的基于云架構(gòu)的計算、數(shù)據(jù)庫、網(wǎng)絡(luò)、存儲、消息隊列等等云計算技術(shù)應(yīng)用。
本文來自網(wǎng)絡(luò) 由藍暢整理，經(jīng)授權(quán)后發(fā)布，本文觀點不代表Infocode藍暢信息技術(shù)立場，轉(zhuǎn)載請聯(lián)系原作者。
