基于開源架構(gòu)的流媒體靜態(tài)集群應(yīng)用研究

林 旻

(南京審計大學(xué) 實驗中心，南京 211815)

在5G移動網(wǎng)絡(luò)技術(shù)高速發(fā)展以及教育部大力推動在線課程的大背景下，慕課、微課、直播課等一系列線上教學(xué)途徑成為高等教育教學(xué)模式的一部分。南京審計大學(xué)教育技術(shù)中心緊跟現(xiàn)代教育技術(shù)的發(fā)展步伐，設(shè)計并建設(shè)了一套基于開源架構(gòu)的課程直播平臺，積累了豐富的直播教學(xué)資源和實施經(jīng)驗，為師生的教學(xué)活動提供了新的途徑，拓寬了教學(xué)活動的空間屬性。

隨著校內(nèi)直播教學(xué)的不斷發(fā)展，越來越多的教學(xué)活動通過線上直播的方式開展，原本單個服務(wù)器直播平臺的性能已經(jīng)無法滿足教學(xué)需求，出現(xiàn)了播放卡頓、延遲高等問題。為了滿足伴隨教學(xué)活動日益增長的并發(fā)性能需求，基于開源架構(gòu)的流媒體靜態(tài)集群方案，通過多組服務(wù)器之間的互相協(xié)同來提高直播平臺的并發(fā)性能，有效降低系統(tǒng)延遲，解決視頻觀看時的卡頓問題[1]。

1 技術(shù)介紹

NRM(Nginx-Rtmp-Module)是基于Nginx的開源流媒體模塊。Nginx是基于BSD開源協(xié)議的高性能Web服務(wù)器平臺，具有占用資源少、穩(wěn)定性高、數(shù)據(jù)處理量大等特點。而Rtmp-module是Github開源軟件平臺的著名流媒體平臺，支持RTMP和HLS流媒體協(xié)議，能夠?qū)崿F(xiàn)視頻流的點播、直播、存儲和轉(zhuǎn)發(fā)等功能[2]。

流媒體服務(wù)器(Streaming Media Server)負(fù)責(zé)直播視頻流的接收、存儲和轉(zhuǎn)發(fā)。流媒體服務(wù)器對CPU和內(nèi)存資源的消耗較小，但對IO和網(wǎng)絡(luò)資源的消耗較高。

靜態(tài)轉(zhuǎn)推：假設(shè)兩臺流媒體服務(wù)器A和B，A收到視頻流S后，將S推送到B，這種情況被稱為轉(zhuǎn)推，因為轉(zhuǎn)推地址是固定在流媒體服務(wù)器的配置文件中，不能動態(tài)調(diào)整，所以稱作靜態(tài)轉(zhuǎn)推。靜態(tài)轉(zhuǎn)推的工作流程如圖1所示。

圖1 靜態(tài)轉(zhuǎn)推示意圖

靜態(tài)回源：假設(shè)兩臺流媒體服務(wù)器A和B，A上存在視頻流S，當(dāng)用戶向B請求S，由于B上不存在S，所以B需要向A拉取S，這種情況被稱作回源，因為回源地址是固定在流媒體服務(wù)器的配置文件中，不能動態(tài)調(diào)整，所以稱作靜態(tài)回源。靜態(tài)回源的工作流程如圖2所示。

圖2 靜態(tài)回源示意圖

源服務(wù)器：負(fù)責(zé)接收OBS或其他直播推流軟件的流媒體服務(wù)器，源服務(wù)器在接收到視頻流后，會根據(jù)服務(wù)器中的固定配置將視頻流推送給邊緣服務(wù)器。

邊緣服務(wù)器：為直播呈現(xiàn)平臺(Web端、移動端)提供視頻分發(fā)功能的流媒體服務(wù)器，在靜態(tài)集群中，任意一臺邊緣服務(wù)器中都存著系統(tǒng)中所有的視頻流。

2 基于NRM的流媒體服務(wù)器設(shè)計與實現(xiàn)

流媒體靜態(tài)集群由一組相互獨立又互相協(xié)作的流媒體服務(wù)器節(jié)點組成，我們的研究是在學(xué)校原有的開源直播平臺上做升級改進。學(xué)校原有的流媒體服務(wù)器由Nginx-Rtmp-Module搭建，為了滿足全平臺播放(PC端+移動端)的要求，需要支持RTMP和HLS兩種視頻流協(xié)議，核心代碼配置如下：

配置RTMP和HLS視頻流

rtmp {

server {

listen 1935; #監(jiān)聽的端口

chunk_size 4096; #設(shè)置流整合大小

application lablive { #rtmp推流請求路徑

live on; #開啟直播

hls on; #開啟HLS視頻流

hls_path /usr/local/lablive/hlsFile; #設(shè)置HLS切片文件保存路徑

hls_fragment 5s; #設(shè)置HLS分段長度

hls_playlist_length 10s; #設(shè)置HLS播放列表長度

}

}

}

在http標(biāo)簽下增加一個location，具體代碼如下：

location /labhls {

types {

application/vnd.apple.mpegurl m3u8;

video/mp2t ts; #設(shè)置封閉格式

}

alias /usr/local/lablive/hlsFile; #設(shè)置文件位置

add_header Cache-Control no-cache; #設(shè)置緩存機制

add_header Access-Control-Allow-Origin *; #解決跨域

}

實際使用中，教師通過OBS或其他直播推流軟件向NRM流媒體服務(wù)器推送視頻流，直播呈現(xiàn)平臺也從同一個NRM流媒體拉取視頻流并播放給學(xué)生進行直播教學(xué)。NRM單流媒體服務(wù)器的具體的推流和拉流地址如表1所示。

表1 單個流媒體服務(wù)器的推拉流地址

根據(jù)流媒體服務(wù)器的數(shù)據(jù)處理特點，單個流媒體服務(wù)器在實際工作過程中的并發(fā)性能不僅受到服務(wù)器本身硬件(CPU的個/核數(shù)、內(nèi)存資源等)的影響，還受到I/O硬能和網(wǎng)絡(luò)資源的影響，特別是當(dāng)流媒體服務(wù)器宕機或者網(wǎng)絡(luò)出現(xiàn)故障的時候，整體的直播服務(wù)都將被迫停止[3]。所以需要通過多個流媒體服務(wù)器組成直播服務(wù)集群來提高系統(tǒng)整體的并發(fā)性、安全性和可靠性。

3 靜態(tài)流媒體集群的設(shè)計與實現(xiàn)

靜態(tài)流媒體集群是一種較為簡單的流媒體集群方案，能夠?qū)蝹€流媒體服務(wù)器的出口壓力分?jǐn)偟蕉鄠€流媒體服務(wù)器上[4]。集群中設(shè)有一臺源服務(wù)器和多臺邊緣服務(wù)器，源服務(wù)器負(fù)責(zé)專門接收視頻流并轉(zhuǎn)推到其他邊緣服務(wù)器上，集群中每一臺邊緣流媒體服務(wù)器上存在著相同的視頻流，用戶可以從任意一臺邊緣流媒體服務(wù)器上拉取視頻流，集群中所有的轉(zhuǎn)推和回源操作都固定設(shè)置在每個流媒體服務(wù)器的配置文件中，所以稱作靜態(tài)流媒體集群。靜態(tài)流媒體集群具體結(jié)構(gòu)如圖3所示。

圖3 靜態(tài)集群示意圖

在實際設(shè)計時，采用了一臺源服務(wù)器來接收視頻流，兩臺邊緣服務(wù)器向用戶提供視頻流，具體配置如表2所示。

表2 靜態(tài)集群服務(wù)器配置表

靜態(tài)轉(zhuǎn)推操作的實現(xiàn)主要采用Nginx-Rtmp-Module提供的push_module，讓源服務(wù)器將接收到的視頻流推送給邊緣服務(wù)器，源服務(wù)器具體配置如下：

rtmp {

server {

listen 1935; #監(jiān)聽的端口

chunk_size 4096;

application lablive { #rtmp推流請求路徑

live on;

push rtmp://172.24.200.47:1935/lablive; #轉(zhuǎn)推到邊緣服務(wù)器1

push rtmp://172.24.200.48:1935/lablive; #轉(zhuǎn)推到邊緣服務(wù)器2

hls on;

hls_path /usr/local/lablive/hlsFile; #設(shè)置HLS切片文件保存路徑

hls_fragment 5s; #設(shè)置HLS分段長度

hls_playlist_length 10s; #設(shè)置HLS播放列表長度

}

}

}

靜態(tài)回源操作的實現(xiàn)主要采用Nginx-Rtmp-Module提供的pull_module，讓邊緣服務(wù)器向源服務(wù)器拉取視頻流，邊緣服務(wù)器具體配置如下：

rtmp {

server {

listen 1935;#監(jiān)聽的端口

chunk_size 4096;

application lablive {

live on;

pull rtmp://172.24.200.46:1935/lablive;

hls on;

hls_path /usr/local/lablive/hlsFile; #設(shè)置HLS切片文件保存路徑

hls_fragment 5s; #設(shè)置HLS分段長度

hls_playlist_length 10s; #設(shè)置HLS播放列表長度

}

}

}

實際使用中，教師通過OBS或其他直播推流軟件向源服務(wù)器推送視頻流，直播呈現(xiàn)平臺從邊緣服務(wù)器拉取視頻流并播放給學(xué)生學(xué)習(xí)。具體的推流和拉流地址如表3所示。

表3 靜態(tài)集群推拉流地址

相較于單個流媒體服務(wù)器，靜態(tài)集群中每個邊緣流媒體服務(wù)器中都存在相同的視頻流，用戶可以從任意一臺邊緣服務(wù)器上拉取視頻流，同時邊緣服務(wù)器還可以根據(jù)直播服務(wù)的帶寬需求進行數(shù)量調(diào)整，可伸縮性強、可靠性高。

4 性能測試與分析

使用OBS作為推流軟件分別對單個流媒體服務(wù)器和靜態(tài)集群中源服務(wù)器進行推流，使用ST-Load作為負(fù)載測試工具分別對單個流媒體服務(wù)器和靜態(tài)集群中的每個邊緣服務(wù)器進行并發(fā)負(fù)載測試，考慮到NRM架構(gòu)的特點和校內(nèi)直播課程的實際使用人數(shù)需求，為了避免服務(wù)器負(fù)載過高，設(shè)置為單個進程模擬1 000個客戶端進行并發(fā)測試，RTMP和HLS負(fù)載測試參數(shù)如表4、表5所示：

表4 RTMP負(fù)載測試參數(shù)

表5 HLS負(fù)載測試參數(shù)

通過測試發(fā)現(xiàn)，在相同硬件配置和相同拉流連接數(shù)的情況下，單個流媒體服務(wù)器和靜態(tài)集群中單個邊緣服務(wù)器負(fù)載能力相當(dāng)，所以單個流媒體服務(wù)器的并發(fā)性能數(shù)是Publisher(Single)，那么靜態(tài)集群單個連接服務(wù)器的并發(fā)數(shù)即是Publisher(Eedg)。

假設(shè)靜態(tài)集群中的服務(wù)器總數(shù)量(源服務(wù)器+邊緣服務(wù)器)為M，因為集群中最少應(yīng)當(dāng)存在一臺源服務(wù)器和兩臺邊緣服務(wù)器，所以M≥=3，靜態(tài)集群的總并發(fā)數(shù)為：

Publisher(Cluster)=Publisher(E)*(M-1)> Publisher(E)*(2)>Plublisher(S)

當(dāng)靜態(tài)集群根據(jù)直播業(yè)務(wù)的并發(fā)需求調(diào)整邊緣服務(wù)器數(shù)量時，假設(shè)調(diào)整數(shù)量為N，當(dāng)調(diào)整為增加服務(wù)器數(shù)量時N>1，那么靜態(tài)集群的總并發(fā)數(shù)為：

Publisher(Cluster)=Publisher(E)*(M+N-1)>>Plubisher(S)

當(dāng)邊緣服務(wù)器的調(diào)整為減少服務(wù)器數(shù)量時，減少的數(shù)量受到集群最小服務(wù)器數(shù)量的限制，所以M-N>=3，那么靜態(tài)集群的總并發(fā)數(shù)為：

Publisher(Cluster)=Publisher(E)*(M-N-1)> Publisher(E)*(2)Plubisher(S)

5 結(jié)論

相較于單個流媒體服務(wù)器，靜態(tài)集群可以根據(jù)直播服務(wù)的需求靈活調(diào)整邊緣服務(wù)器的數(shù)量，不僅有效提高了直播平臺的整體并發(fā)性，還能降低服務(wù)器硬件資源的浪費。同時，集群中任意一臺邊緣服務(wù)器的宕機或故障不會影響系統(tǒng)整體服務(wù)的有序進行，提高了直播平臺的可靠性。

但是，正因為靜態(tài)集群中每一個邊緣服務(wù)器都存在著相同的視頻流，所以在實際生產(chǎn)業(yè)務(wù)中，邊緣服務(wù)器會存在用戶不需要的視頻流，造成隱形的資源浪費；同時，根據(jù)靜態(tài)集群的邏輯特點，當(dāng)源服務(wù)器出現(xiàn)故障時整個直播系統(tǒng)都將被迫癱瘓，存在一定的安全隱患，所以如何解決邊緣服務(wù)器的隱形資源浪費和源服務(wù)器的安全隱患是本項目進一步研究的目標(biāo)。