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

林 旻

(南京審計(jì)大學(xué) 實(shí)驗(yàn)中心，南京 211815)

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

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

1 技術(shù)介紹

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

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

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

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

靜態(tài)回源：假設(shè)兩臺(tái)流媒體服務(wù)器A和B，A上存在視頻流S，當(dāng)用戶向B請(qǐng)求S，由于B上不存在S，所以B需要向A拉取S，這種情況被稱作回源，因?yàn)榛卦吹刂肥枪潭ㄔ诹髅襟w服務(wù)器的配置文件中，不能動(dòng)態(tài)調(diào)整，所以稱作靜態(tài)回源。靜態(tài)回源的工作流程如圖2所示。

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

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

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

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

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

配置RTMP和HLS視頻流

rtmp {

server {

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

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

application lablive { #rtmp推流請(qǐng)求路徑

live on; #開啟直播

hls on; #開啟HLS視頻流

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

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

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

}

}

}

在http標(biāo)簽下增加一個(gè)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è)置緩存機(jī)制

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

}

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

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

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

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

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

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

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

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

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

rtmp {

server {

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

chunk_size 4096;

application lablive { #rtmp推流請(qǐng)求路徑

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分段長(zhǎng)度

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

}

}

}

靜態(tài)回源操作的實(shí)現(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分段長(zhǎng)度

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

}

}

}

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

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

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

4 性能測(cè)試與分析

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

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

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

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

假設(shè)靜態(tài)集群中的服務(wù)器總數(shù)量(源服務(wù)器+邊緣服務(wù)器)為M，因?yàn)榧褐凶钌賾?yīng)當(dāng)存在一臺(tái)源服務(wù)器和兩臺(tái)邊緣服務(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í)，假設(shè)調(diào)整數(shù)量為N，當(dāng)調(diào)整為增加服務(wù)器數(shù)量時(shí)N>1，那么靜態(tài)集群的總并發(fā)數(shù)為：

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

當(dāng)邊緣服務(wù)器的調(diào)整為減少服務(wù)器數(shù)量時(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é)論

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

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