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