Radio Dream流媒體直播平臺基於Docker的應用

本文整理自【時速雲微信羣線上分享】第十一期

首先介紹一下背景，Radio Dream項目是一個開源項目，前身爲五雷轟頂網絡電臺，這個項目是我我的逐漸打磨了將近兩年，最開始是由於貓撲網絡電臺停播，我我的是貓撲電臺的老聽衆，很捨不得這個平臺，後來想一想，乾脆本身作一個網絡電臺，就是由於這些想法催生了這個項目的成立。

說完背景開始聊聊這個電臺的架構，咱們從流媒體協議選型到架構實現等多個方面拆分的講解這個平臺實現方法，另外時速雲鏡像倉庫裏Radio Dream的鏡像demo，整體來講這套系統部署起來仍是十分複雜，雖然對系統要求極其低，單核心CPU，128M內存，20GB左右的硬盤就能跑起來，可是從最開始的架構設計我就打算作成一個集羣化的方案，方便動態擴容，服務更多用戶，因爲我我的比較懶，因此作了不少自動化運維的工做，這樣我就能夠解放雙手和更多的時間去開發新的功能。

傳統架構下的Radio Dream

技術層面的分層：

展示層—–WEB頁面，第三方集成代碼，後臺管理
邏輯層—–媒體分發調度，直播監控，故障判斷
執行層—–流媒體直播執行，ffmpeg推流，拉取
媒體層—–對媒體直播處理，切片

業務邏輯分層

1.Radio dream控制中心

Radio dream控制中心是整個電臺播控集羣的核心控制端，負責整個集羣調度，處理故障服務器，監控直播流，錄播調度，微直播調度等相關任務。

2.直播控制

直播控制組件是負責通知錄播推流集羣中止推流和繼續推流，因爲直播服務器只支持單流推送，因此須要一個控制端來進行控制本地推送服務，當點擊頁面開始直播，推流服務器就會中止工做，RTMP服務就會等待主播編碼器連接推送音頻。點擊結束直播，推流服務就會開始工做。

3.媒體管理中心

媒體管理中心負責服務器內全部的AAC音頻文件管理，例如上傳，下載，刪除，審覈，試聽，分發URL，CDN分發部分。

4.錄播控制

錄播控制組件是控制本地音頻文件轉換成流的方式進行僞直播。

5.轉播控制

轉播控制是在不替換現有直播架構方式進行試用新的解決方案的方法，另外能夠轉播別的電臺直播節目。支持RTMP、MMS、RTSP、HLS等主流流媒體格式。

6.錄播分發

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

7.RTMP接收

RTMP接收組件是整個直播服務集羣最爲核心部分，負責接收錄播端和主播端的直播音頻部分。

8.切片服務

切片服務組件是接收RTMP流過來後轉換成HLS的TS切片，而且生成M3U8格式的播放列表，實現HTTP方式的流媒體。

9.分發服務

分發服務（邊緣服務器）是負責整個流媒體切片和錄播的文件進行對外分發，若是是分佈式架構，此處根據本身用戶量大小進行帶寬調整。國際廣播格式48Kbps單用戶收聽1小時消耗帶寬18MB，能夠根據此公式計算。

集羣工做流程，首先一個問題

主播不可能24小時在線，沒有主播時段會有很長的空白期，這段時間用戶若是想收聽，沒有節目確定不行

解決辦法：那麼咱們就作了一個僞直播的功能，經過把本地文件轉成直播流的方式，推送到直播服務器，這樣用戶收聽就不會出現空白期

直播錄播切換，如何去作才能實現無縫切換，讓聽衆「無感切換」

解決方案：直播流是使用ffmpeg進行本地文件讀取，推送到rtmp直播服務器，主播點擊直播按鈕，會請求一個API，這個API會調用一個shell腳本，殺死推流進程，主播的直播流就會推送到服務器上，直播服務器會把這個流推送到各個分發、切片服務器。

而後咱們分享架構流程，你們能夠看一下上面的圖

首先咱們的「僞直播服務」是全天工做的，有主播連線直播後，會殺死僞直播的服務，直播流會迅速的連上，由於分發部分使用的是HLS協議進行分發，因此會有10秒左右的延遲，並且有直播服務器和切片服務器兩個中間層，用戶根本不會感受到有頓卡，直播就已經切換成了真正的直播.

直播服務器會推送本地的直播流到切片服務器，切片服務器通常會有多臺，這個是經過調度API進行獲取推流服務器的IP地址，端口、application、直播名稱等信息。每一個切片服務器啓動時候都會通告控制中心自身的IP地址、服務狀態、監聽端口、application名稱、直播名稱。控制中心會給直播服務器這些信息，直播服務器調用自身的直播流，分發到各個切片服務器。

切片服務器會對推送過來的流進行切片生成TS文件，而且生成M3U8的索引文件，遵循HLS直播協議進行分發。

因爲切片服務器有多個，因此和CDN服務對接時候使用多個IP地址，CDN會根據就近原則，使用到達速度最快的節點進行拉取源文件。

選擇HLS也是有兩方面考慮

a) RTMP的併發性並很差
b) 節約成本

我測試過，現有實現rtmp直播最多支持2000個用戶拉取流，並且CPU佔用會很高，因爲網絡電臺會延遲的敏感性並非特別高，因此選擇HLS，由於HLS是走http協議，這樣就可使用nginx實現大規模併發。

節約成本這塊主要是CDN成本，支持rtmp的CDN廠商通常價格會比http請求流量貴35%左右，使用http就會節省一部分紅本。

自動化運維&故障恢復

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

工做流程：

檢測分發m3u8索引文件是否存在,若是是單臺節點不存在，證實單點故障，會檢測rtmp源否推送正常，若是正常，則會重啓一下服務，而後進行一次檢查，7秒鐘後，尚未檢查到M3U8文件索引，會傳輸故障恢復腳本，進行一次常見故障恢復.

例如，檢查文件權限，檢查內部是否能夠拉取到源，檢查內部是否能夠獲取到m3u8文件，而後進行恢復，若是恢復都不成功，就會發送通告到控制中心，當前服務器已經不工做，控制中心會將這臺機器剔除服務集羣，通告CDN廠商API，將這臺機器剔除，直播服務器也不會對這個服務進行推送，而後調用雲主機API，將這臺系統進行重裝系統，分發當前角色的自動化部署腳本.

部署完畢後，會通告控制中心，進行一次試推送，檢查若是正常，會把這個服務器加回到服務集羣隊列。若是檢查不正常，則會嘗試三次，三次後，還不可以恢復，就會發短信到手機通告故障問題。須要人工介入排查。

其餘服務節點相似，

傳統的雲主機或者物理服務器會有幾個很嚴重的問題：

● 故障難以恢復

● 浪費資源

● 價格太高

● 高可用過分依賴於自身監控

容器的出現偏偏解決的這些問題，尤爲對故障恢復方面，有着對傳統虛擬機無與倫比的優點，首先啓動速度快，故障不會和傳統虛擬機同樣裝機時間很漫長。秒級啓動的容器，很是適合大規模部署，只要製做好相應服務的鏡像。

故障難以恢復：

雖然自動化運維聽着很高大上，可是其中的苦逼只有本身知道，我如今整個電臺的自動恢復服務有47個腳本，每個都一堆的邏輯判斷，我本身改寫起來都得讀很長時間，容器方式實現這種微服務方式就不會有這些問題，哪一個服務掛了，直接刪除容器，重啓一個就完事了。

資源浪費：

其實每一個服務均可以拆分紅不少小服務，並且資源佔用都極低，Docker容器啓動，內存佔用只有一個shell，和宿主機共用一個內核，這樣就保證了，只有應用在使用內存，不會啓動多個內核和系統服務形成資源的重複浪費。

價格太高：

傳統的VPS都是按月計費，這樣若是突發性用戶過多，並且天天只有6點-10點左右用戶量會增長，平時若是開着這麼多服務器來處理不多的用戶很不划算，可是時速雲的容器能夠實現秒級計費，系統負載太高了，直接多開幾個容器就OK了，用戶少了刪除一些容器，只保證最低使用量。

高可用過分依賴於自身監控:

傳統VPS掛了那就掛了，不會發短信警告和重啓VPS，可是容器掛掉會自動重啓，內存佔用太高等問題，時速雲會直接發郵件&短信通知，這樣自己的監控壓力就會小不少，只須要關注業務層面的問題，而不須要過多的關注系統底層的問題。

時速雲使用demo：

首先在鏡像市場搜索radiodream鏡像，若是隻是選擇作測試能夠不掛載存儲卷

成功啓動後，查看地址，查看1935映射對應端口是什麼

打開vlc播放器或者potpplayer，輸入rtmp://xxxx.xxx.xxx:xxx/radiodream/live,就能夠收到僞直播節目了,更多的設置選項請觀看時速雲官方視頻教程 https://tenxcloud.com/tutorial

如何參與線上分享？添加微信號：時速雲小助手(tenxcloud6)，咱們便可拉您進羣