以下整理自第十一期技術分享內容，由 時速云 史鑫磊 分享。

首先介紹一下背景，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

有興趣參與周四晚8:30-9:30時速云產品、容器技術相關分享的朋友可以添加微信號：時速云小助手(tenxcloud6)，我們即可拉您進群哦~

您也可以關注我們的官方微信公眾號（ID：ctoutiao），給您更多好看的內容。