摘要：支持等主流流媒體格式。控制中心會(huì)給直播服務(wù)器這些信息，直播服務(wù)器調(diào)用自身的直播流，分發(fā)到各個(gè)切片服務(wù)器。自動(dòng)化運(yùn)維故障恢復(fù)這部分主要是監(jiān)控推流，和切片，以及直播源是否正常。

本文整理自【時(shí)速云微信群線上分享】第十一期

首先介紹一下背景，Radio Dream項(xiàng)目是一個(gè)開源項(xiàng)目，前身為五雷轟頂網(wǎng)絡(luò)電臺(tái)，這個(gè)項(xiàng)目是我個(gè)人逐漸打磨了將近兩年，最開始是因?yàn)樨垞渚W(wǎng)絡(luò)電臺(tái)停播，我個(gè)人是貓撲電臺(tái)的老聽眾，很舍不得這個(gè)平臺(tái)，后來想想，干脆自己做一個(gè)網(wǎng)絡(luò)電臺(tái)，就是因?yàn)檫@些想法催生了這個(gè)項(xiàng)目的成立。

說完背景開始聊聊這個(gè)電臺(tái)的架構(gòu)，我們從流媒體協(xié)議選型到架構(gòu)實(shí)現(xiàn)等多個(gè)方面拆分的講解這個(gè)平臺(tái)實(shí)現(xiàn)方法，另外時(shí)速云鏡像倉庫里Radio Dream的鏡像demo，總體來說這套系統(tǒng)部署起來還是十分復(fù)雜，雖然對(duì)系統(tǒng)要求極其低，單核心CPU，128M內(nèi)存，20GB左右的硬盤就能跑起來，但是從最開始的架構(gòu)設(shè)計(jì)我就打算做成一個(gè)集群化的方案，方便動(dòng)態(tài)擴(kuò)容，服務(wù)更多用戶，由于我個(gè)人比較懶，所以做了很多自動(dòng)化運(yùn)維的工作，這樣我就可以解放雙手和更多的時(shí)間去開發(fā)新的功能。

展現(xiàn)層—–WEB頁面，第三方集成代碼，后臺(tái)管理
邏輯層—–媒體分發(fā)調(diào)度，直播監(jiān)控，故障判斷
執(zhí)行層—–流媒體直播執(zhí)行，ffmpeg推流，拉取
媒體層—–對(duì)媒體直播處理，切片

1.Radio dream控制中心

Radio dream控制中心是整個(gè)電臺(tái)播控集群的核心控制端，負(fù)責(zé)整個(gè)集群調(diào)度，處理故障服務(wù)器，監(jiān)控直播流，錄播調(diào)度，微直播調(diào)度等相關(guān)任務(wù)。

2.直播控制

直播控制組件是負(fù)責(zé)通知錄播推流集群停止推流和繼續(xù)推流，由于直播服務(wù)器只支持單流推送，所以需要一個(gè)控制端來進(jìn)行控制本地推送服務(wù)，當(dāng)點(diǎn)擊頁面開始直播，推流服務(wù)器就會(huì)停止工作，RTMP服務(wù)就會(huì)等待主播編碼器鏈接推送音頻。點(diǎn)擊結(jié)束直播，推流服務(wù)就會(huì)開始工作。

3.媒體管理中心

媒體管理中心負(fù)責(zé)服務(wù)器內(nèi)所有的AAC音頻文件管理，例如上傳，下載，刪除，審核，試聽，分發(fā)URL，CDN分發(fā)部分。

4.錄播控制

錄播控制組件是控制本地音頻文件轉(zhuǎn)換成流的方式進(jìn)行偽直播。

5.轉(zhuǎn)播控制

轉(zhuǎn)播控制是在不替換現(xiàn)有直播架構(gòu)方式進(jìn)行試用新的解決方案的方法，另外可以轉(zhuǎn)播別的電臺(tái)直播節(jié)目。支持RTMP、MMS、RTSP、HLS等主流流媒體格式。

6.錄播分發(fā)

錄播分發(fā)是提供下載和在線收聽等功能。

7.RTMP接收

RTMP接收組件是整個(gè)直播服務(wù)集群最為核心部分，負(fù)責(zé)接收錄播端和主播端的直播音頻部分。

8.切片服務(wù)

切片服務(wù)組件是接收RTMP流過來后轉(zhuǎn)換成HLS的TS切片，并且生成M3U8格式的播放列表，實(shí)現(xiàn)HTTP方式的流媒體。

9.分發(fā)服務(wù)

分發(fā)服務(wù)（邊緣服務(wù)器）是負(fù)責(zé)整個(gè)流媒體切片和錄播的文件進(jìn)行對(duì)外分發(fā)，如果是分布式架構(gòu)，此處根據(jù)自己用戶量大小進(jìn)行帶寬調(diào)整。國際廣播格式48Kbps單用戶收聽1小時(shí)消耗帶寬18MB，可以根據(jù)此公式計(jì)算。

集群工作流程，首先一個(gè)問題

主播不可能24小時(shí)在線，沒有主播時(shí)段會(huì)有很長的空白期，這段時(shí)間用戶如果想收聽，沒有節(jié)目肯定不行

解決辦法：那么我們就做了一個(gè)偽直播的功能，通過把本地文件轉(zhuǎn)成直播流的方式，推送到直播服務(wù)器，這樣用戶收聽就不會(huì)出現(xiàn)空白期

直播錄播切換，如何去做才能實(shí)現(xiàn)無縫切換，讓聽眾“無感切換”

解決方案：直播流是使用ffmpeg進(jìn)行本地文件讀取，推送到rtmp直播服務(wù)器，主播點(diǎn)擊直播按鈕，會(huì)請(qǐng)求一個(gè)API，這個(gè)API會(huì)調(diào)用一個(gè)shell腳本，殺死推流進(jìn)程，主播的直播流就會(huì)推送到服務(wù)器上，直播服務(wù)器會(huì)把這個(gè)流推送到各個(gè)分發(fā)、切片服務(wù)器。

然后我們分享架構(gòu)流程，大家可以看一下上面的圖

首先我們的“偽直播服務(wù)”是全天工作的，有主播連線直播后，會(huì)殺死偽直播的服務(wù)，直播流會(huì)迅速的連上，因?yàn)榉职l(fā)部分使用的是HLS協(xié)議進(jìn)行分發(fā)，所以會(huì)有10秒左右的延遲，而且有直播服務(wù)器和切片服務(wù)器兩個(gè)中間層，用戶根本不會(huì)感覺到有頓卡，直播就已經(jīng)切換成了真正的直播.

直播服務(wù)器會(huì)推送本地的直播流到切片服務(wù)器，切片服務(wù)器一般會(huì)有多臺(tái)，這個(gè)是通過調(diào)度API進(jìn)行獲取推流服務(wù)器的IP地址，端口、application、直播名稱等信息。每個(gè)切片服務(wù)器啟動(dòng)時(shí)候都會(huì)通告控制中心自身的IP地址、服務(wù)狀態(tài)、監(jiān)聽端口、application名稱、直播名稱。控制中心會(huì)給直播服務(wù)器這些信息，直播服務(wù)器調(diào)用自身的直播流，分發(fā)到各個(gè)切片服務(wù)器。

切片服務(wù)器會(huì)對(duì)推送過來的流進(jìn)行切片生成TS文件，并且生成M3U8的索引文件，遵循HLS直播協(xié)議進(jìn)行分發(fā)。

由于切片服務(wù)器有多個(gè)，所以和CDN服務(wù)對(duì)接時(shí)候使用多個(gè)IP地址，CDN會(huì)根據(jù)就近原則，使用到達(dá)速度最快的節(jié)點(diǎn)進(jìn)行拉取源文件。

a) RTMP的并發(fā)性并不好
b) 節(jié)約成本

我測試過，現(xiàn)有實(shí)現(xiàn)rtmp直播最多支持2000個(gè)用戶拉取流，而且CPU占用會(huì)很高，由于網(wǎng)絡(luò)電臺(tái)會(huì)延遲的敏感性并不是特別高，所以選擇HLS，因?yàn)镠LS是走h(yuǎn)ttp協(xié)議，這樣就可以使用nginx實(shí)現(xiàn)大規(guī)模并發(fā)。

節(jié)約成本這塊主要是CDN成本，支持rtmp的CDN廠商一般價(jià)格會(huì)比http請(qǐng)求流量貴35%左右，使用http就會(huì)節(jié)省一部分成本。

自動(dòng)化運(yùn)維&故障恢復(fù)

這部分主要是監(jiān)控rtmp推流，和hls切片，以及直播源是否正常。

工作流程：

檢測分發(fā)m3u8索引文件是否存在,如果是單臺(tái)節(jié)點(diǎn)不存在，證明單點(diǎn)故障，會(huì)檢測rtmp源否推送正常，如果正常，則會(huì)重啟一下服務(wù)，然后進(jìn)行一次檢查，7秒鐘后，還沒有檢查到M3U8文件索引，會(huì)傳輸故障恢復(fù)腳本，進(jìn)行一次常見故障恢復(fù).

例如，檢查文件權(quán)限，檢查內(nèi)部是否可以拉取到源，檢查內(nèi)部是否可以獲取到m3u8文件，然后進(jìn)行恢復(fù)，如果恢復(fù)都不成功，就會(huì)發(fā)送通告到控制中心，當(dāng)前服務(wù)器已經(jīng)不工作，控制中心會(huì)將這臺(tái)機(jī)器剔除服務(wù)集群，通告CDN廠商API，將這臺(tái)機(jī)器剔除，直播服務(wù)器也不會(huì)對(duì)這個(gè)服務(wù)進(jìn)行推送，然后調(diào)用云主機(jī)API，將這臺(tái)系統(tǒng)進(jìn)行重裝系統(tǒng)，分發(fā)當(dāng)前角色的自動(dòng)化部署腳本.

部署完畢后，會(huì)通告控制中心，進(jìn)行一次試推送，檢查如果正常，會(huì)把這個(gè)服務(wù)器加回到服務(wù)集群隊(duì)列。如果檢查不正常，則會(huì)嘗試三次，三次后，還不能夠恢復(fù)，就會(huì)發(fā)短信到手機(jī)通告故障問題。需要人工介入排查。

其他服務(wù)節(jié)點(diǎn)類似，

● 故障難以恢復(fù)

● 浪費(fèi)資源

● 價(jià)格過高

● 高可用過度依賴于自身監(jiān)控

容器的出現(xiàn)恰恰解決的這些問題，尤其對(duì)故障恢復(fù)方面，有著對(duì)傳統(tǒng)虛擬機(jī)無與倫比的優(yōu)勢，首先啟動(dòng)速度快，故障不會(huì)和傳統(tǒng)虛擬機(jī)一樣裝機(jī)時(shí)間很漫長。秒級(jí)啟動(dòng)的容器，非常適合大規(guī)模部署，只要制作好相應(yīng)服務(wù)的鏡像。

故障難以恢復(fù)：

雖然自動(dòng)化運(yùn)維聽著很高大上，但是其中的苦逼只有自己知道，我現(xiàn)在整個(gè)電臺(tái)的自動(dòng)恢復(fù)服務(wù)有47個(gè)腳本，每一個(gè)都一堆的邏輯判斷，我自己改寫起來都得讀很長時(shí)間，容器方式實(shí)現(xiàn)這種微服務(wù)方式就不會(huì)有這些問題，哪個(gè)服務(wù)掛了，直接刪除容器，重啟一個(gè)就完事了。

資源浪費(fèi)：

其實(shí)每個(gè)服務(wù)都可以拆分成很多小服務(wù)，而且資源占用都極低，Docker容器啟動(dòng)，內(nèi)存占用只有一個(gè)shell，和宿主機(jī)共用一個(gè)內(nèi)核，這樣就保證了，只有應(yīng)用在使用內(nèi)存，不會(huì)啟動(dòng)多個(gè)內(nèi)核和系統(tǒng)服務(wù)造成資源的重復(fù)浪費(fèi)。

價(jià)格過高：

傳統(tǒng)的VPS都是按月計(jì)費(fèi)，這樣如果突發(fā)性用戶過多，而且每天只有6點(diǎn)-10點(diǎn)左右用戶量會(huì)增加，平時(shí)如果開著這么多服務(wù)器來處理很少的用戶很不劃算，但是時(shí)速云的容器可以實(shí)現(xiàn)秒級(jí)計(jì)費(fèi)，系統(tǒng)負(fù)載過高了，直接多開幾個(gè)容器就OK了，用戶少了刪除一些容器，只保證最低使用量。

高可用過度依賴于自身監(jiān)控:

傳統(tǒng)VPS掛了那就掛了，不會(huì)發(fā)短信警告和重啟VPS，但是容器掛掉會(huì)自動(dòng)重啟，內(nèi)存占用過高等問題，時(shí)速云會(huì)直接發(fā)郵件&短信通知，這樣本身的監(jiān)控壓力就會(huì)小很多，只需要關(guān)注業(yè)務(wù)層面的問題，而不需要過多的關(guān)注系統(tǒng)底層的問題。

時(shí)速云使用demo：

首先在鏡像市場搜索radiodream鏡像，如果只是選擇做測試可以不掛載存儲(chǔ)卷

成功啟動(dòng)后，查看地址，查看1935映射對(duì)應(yīng)端口是什么

打開vlc播放器或者potpplayer，輸入rtmp://xxxx.xxx.xxx:xxx/radiodream/live,就可以收到偽直播節(jié)目了,更多的設(shè)置選項(xiàng)請(qǐng)觀看時(shí)速云官方視頻教程 https://tenxcloud.com/tutorial

如何參與線上分享？
添加微信號(hào)：時(shí)速云小助手(tenxcloud6)，我們即可拉您進(jìn)群