數(shù)字化視頻會議系統(tǒng)的設(shè)計和實現(xiàn)

浙江省臺州市機關(guān)服務(wù)中心 段汝立

隨著5G網(wǎng)絡(luò)的不斷普及，數(shù)字化技術(shù)需要不斷優(yōu)化視頻和音頻，以更高的音頻質(zhì)量呈現(xiàn)給人們使用。人們對視頻的信息獲取需求越來越高，機關(guān)、企事業(yè)單位和高校對于線上視頻會議有很大的需求。除了機關(guān)單位常用的幾個視頻會議系統(tǒng)之外，在一些特定場景下，需要通過其他數(shù)字化視頻會議形式來提高工作效率。本文以WebRTC（Web實時交流）技術(shù)為框架，進行視頻會議的系統(tǒng)設(shè)計，實現(xiàn)一種可以進行資源動態(tài)伸縮的視頻會議系統(tǒng)。

4G移動網(wǎng)絡(luò)的普及以及5G移動網(wǎng)絡(luò)的開始普及，讓人們獲取信息的方式變得更加多樣化，用戶之間的交互方式也越來越多樣化，短視頻、直播等新的信息交互方式成為當(dāng)前社會主流。在5G網(wǎng)絡(luò)開始普及后，視頻會議也需要相應(yīng)地提高自身的音視頻質(zhì)量，以便為用戶提供更加流暢的視頻會議體驗。當(dāng)前市場中視頻會議軟件眾多，但是基本沒有基于WebRTC技術(shù)進行設(shè)計的視頻會議系統(tǒng)。WebRTC技術(shù)擁有更加多樣化的音視頻處理工具與網(wǎng)絡(luò)框架，可以更加方便地進行音視頻媒體服務(wù)，該系統(tǒng)可以為用戶提供多方視頻會議，降低了額外加載匹配的使用率，大大提高了使用便捷性。

1 數(shù)字化視頻會議系統(tǒng)功能性需求分析

1.1 會議管理系統(tǒng)功能性需求

在會議管理系統(tǒng)的功能模型中，主要分為4大功能，用戶管理、通訊錄、會議管理以及通知，如圖1所示。通過對整個管理模塊進行功能分析后，可以更好地利用會議管理系統(tǒng)的功能。通過圖1，直觀地展示出了系統(tǒng)模塊與各個用戶之間的交互關(guān)系[1]。

會議管理系統(tǒng)的用例表如表1[2]所示。

表1 會議管理系統(tǒng)用例表Tab.1 Use case table of conference management system

1.2 媒體服務(wù)器架構(gòu)功能性需求

媒體服務(wù)器主要為視頻會議提供音視頻服務(wù)，需要與WebRTC框架兼容，為用戶提供音視頻服務(wù)，保證視頻會議的音視頻效果。媒體服務(wù)與WebRTC框架相連接，可以提供多人音視頻功能，并與音視頻流建立聯(lián)系。前端控制著音視頻流，給出房間號，讓媒體服務(wù)后臺使用。在音視頻流交互過程中，前端可以自行關(guān)閉音視頻流，并為用戶提供完整的音視頻方案。

2 數(shù)字化視頻會議系統(tǒng)總體設(shè)計

2.1 整體架構(gòu)設(shè)計

視頻會議系統(tǒng)有兩大子系統(tǒng)，會議管理系統(tǒng)與媒體服務(wù)后臺系統(tǒng)，都是通過WebRTC框架進行互聯(lián)，兩者之間沒有交互功能，但是都具備一定的容錯性，為用戶提供不同的服務(wù)。會議管理系統(tǒng)主要對用戶進行管理，將唯一會議號反饋到前端，前端通過唯一會議號，將其返回到媒體服務(wù)集群中，完成媒體流的通訊功能[3]。

用戶首先進入到會議管理后臺進行訪問，后臺會對用戶的信息進行檢查和鑒別，檢查完畢后建立音視頻信息，通過會議號進行媒體服務(wù)后臺訪問，媒體服務(wù)后臺需要對會議號進行檢驗，查看其真實性，然后建立音視頻流，進行視頻會議。會議結(jié)束后，WebRTC會與媒體服務(wù)后臺斷開，媒體服務(wù)后臺會將會議進行存儲。WebRTC通過發(fā)送會議結(jié)束的消息通知會議結(jié)束。

2.2 會議管理系統(tǒng)模塊設(shè)計

（1）會議管理系統(tǒng)微服務(wù)模塊：在整個模塊中，均采用容器部署的形式，各個模塊之間通過Redis與RabbitMQ進行交互。存儲對象采用騰訊云的線上存儲服務(wù)，可以方便用戶隨時查看，大大的保證了文件的安全性。

（2）用戶管理模塊：為用戶提供服務(wù)，方便用戶進行注冊注銷、查詢、更新，還可以出現(xiàn)多端登錄情況的發(fā)生。用戶管理模塊主要對系統(tǒng)的用戶信息進行管理，當(dāng)其他模塊需要進行用戶信息檢索時，需要提供相關(guān)驗證權(quán)限。

（3）通訊錄模塊：通過添加刪除、新建、修改、移動等操作，完成對用戶的管理。通過好友管理功能，為會議的管理提供便捷。主持人的功能就是方便對人員進行管理，通過添加和刪除好友操作，更好地進行人員管理[4]。

（4）會議管理模塊：會議管理模塊是在通訊錄模塊的基礎(chǔ)上，對通訊錄模塊中的好友進行人員篩選，讓參會人員可以在最短的時間加入到會議中。新建會議通過記錄會議信息，進行時間、會議人員的記錄。同時，通過會議識別碼的形式生成人數(shù)，方便后續(xù)的匿名用戶使用。

（5）通知模塊：為通訊錄模塊和會議管理模塊提供通知信息推送服務(wù)，保證用戶可以及時接收到會議消息并進行及時的操作。通知模塊主要通過Redis和RabbitMQ進行交互。

2.3 數(shù)據(jù)庫設(shè)計

通過對會議管理后臺的各個模塊進行分析后，需要有合理的數(shù)據(jù)庫設(shè)計，數(shù)據(jù)庫設(shè)計可以起到降低開發(fā)成本的效果，還可以保證上層數(shù)據(jù)可以得到更加準(zhǔn)確的讀寫數(shù)據(jù)，從而提高存儲效果。數(shù)據(jù)庫設(shè)計需要對數(shù)據(jù)進行寫入、讀取、查詢以及修改，以保證數(shù)據(jù)的合理性，避免數(shù)據(jù)出現(xiàn)冗余。

會議管理系統(tǒng)需要的數(shù)據(jù)庫表很多，所有的數(shù)據(jù)表中都需要包含下列兩個字段，如表2[5]所示。

表2中的這兩個字段，是對表中的創(chuàng)建時間進行記錄，方便隨時對數(shù)據(jù)庫中的數(shù)據(jù)進行修改，保證效率。數(shù)據(jù)庫中大多數(shù)都是采用主鍵的方式進行字段添加，表與表之間主要通過業(yè)務(wù)代碼層進行聯(lián)系，以便更好地維護數(shù)據(jù)庫表并及時更新。

表2 所有數(shù)據(jù)表包含字段信息Tab.2 All data tables contain field information

2.4 媒體服務(wù)系統(tǒng)模塊設(shè)計

2.4.1 SFU（選擇性轉(zhuǎn)發(fā)單元）架構(gòu)

SFU架構(gòu)通過媒體服務(wù)器的形式進行對流，適用于小型視頻會議。主要讓所有的上行音頻流和視頻流都可以集中到媒體服務(wù)器中，完成對音視頻流的轉(zhuǎn)發(fā)，從而實現(xiàn)媒體流互通效果。SFU架構(gòu)也可以作為一個WebRTC的Peer的客戶端，讓每一個客戶端的上行音視頻流都可以準(zhǔn)確的發(fā)送到另一個客戶端或者媒體服務(wù)器中。

2.4.2 MCU（多點控制單元）架構(gòu)

MCU架構(gòu)適用于大型會議，起到混流、音視頻流隨意切換效果，與SFU不同，在MCU架構(gòu)中，可以有多個用戶參與，上行音視頻流和下行音視頻流各有一條。擁有神的信令服務(wù)器和資源分配服務(wù)器，用于適配分布式架構(gòu)操作。相較于SFU架構(gòu)，增設(shè)了資源分配器可以更加便捷的對媒體服務(wù)器進行資源分配，減少服務(wù)器的壓力[6]。

2.4.3 動態(tài)負(fù)載均衡

動態(tài)負(fù)載均衡設(shè)計的目的是適配分布式架構(gòu)的動態(tài)變化，當(dāng)請求量增加時，分布式集群的節(jié)點數(shù)量也在增加，傳統(tǒng)的負(fù)載均衡器無法滿足需求，需要使用動態(tài)負(fù)載均衡器。動態(tài)負(fù)載均衡器分為SFU和MCU兩大部分，以MCU架構(gòu)為例。在MCU架構(gòu)中，同一會議中的所有用戶都需要在同一個媒體服務(wù)器下工作，這樣才可以讓資源分配器與動態(tài)負(fù)載均衡器更好的聯(lián)系在一起，當(dāng)運行動態(tài)負(fù)載均衡時可以更好地分配用戶所需功能。

3 數(shù)字化視頻會議系統(tǒng)實現(xiàn)

3.1 會議管理系統(tǒng)實現(xiàn)

（1）用戶管理模塊主要對用戶的一系列操作進行管理，用戶可以通過用戶名或者手機進行登錄，禁止多賬戶同時登錄，極大地提高了用戶信息的安全性。刷新token，會自動記錄用戶瀏覽的內(nèi)容，用于后續(xù)模塊驗證用戶的真實身份，以保證用戶在所登錄的時間內(nèi)所有的行為合法。Controller層中，AuthController用于記錄用戶的登錄方式；UserController用于記錄用戶的登錄密碼；FileController用于用戶的頭像上傳。Service層根據(jù)業(yè)務(wù)完成對數(shù)據(jù)的記錄，并通過Controller進行使用。其中，authService用于驗證用戶密碼；UserService方便用戶查找所需功能；tokenService主要對token進行處理。

（2）通訊錄模塊主要對用戶進行管理、分組和群組管理，可以對用戶進行增加、刪除操作，通過通知模塊，還可以添加、拒絕好友。通過分組管理，對所有的分組信息進行整理，根據(jù)分組ID獲取好友。群組管理的功能不僅可以創(chuàng)建群組，還可以對群組中的信息進行修改，還可以獲取群組中全部成員的信息。

（3）會議管理模塊中，有兩大接口，ConferenceAction Controller和Conference UserController。其中，Conference ActionController對會議的狀態(tài)進行管理，通過Start、Cancel、Finish等函數(shù)進行管理。當(dāng)管理會議狀態(tài)時，需要先獲取實體類，再進行會議狀態(tài)的修改。

ConferenceUserController對會議成員進行管理，當(dāng)會議狀態(tài)未開始時，需要通過添加參會成員通知會議，通過invitedJoin函數(shù)，邀請成員加入會議，并記錄會議人數(shù)，該函數(shù)會對用戶的ID進行查找，并查詢會議狀態(tài)，根據(jù)會議狀態(tài)進行會議記錄并反饋信息；joinMeeting函數(shù)通過會議ID進入會議中，通過調(diào)用ConferenceAction Controller中的Get函數(shù)完成會議內(nèi)容的獲取[7]。

（4）通知模塊主要為其他三個模塊進行服務(wù)，通過通知模塊，將所有的信息集合在一個模塊中改進型管理，并通過openAPI的方式將其提供給其他三個模塊。通知模塊的核心功能就是通知站內(nèi)信息，通過WebSocket實現(xiàn)，通過Redis和RabbitMQ對信息進行緩存，通過MySQL數(shù)據(jù)庫對信息進行存儲。以WebSocket服務(wù)器作為主要服務(wù)器，對各類的信息進行處理，并更加快捷的增加通知事件。

3.2 媒體服務(wù)系統(tǒng)實現(xiàn)

SFU架構(gòu)采用Coturn服務(wù)器進行音視頻流的轉(zhuǎn)發(fā)操作，MCU架構(gòu)采用FreeSwitch進行音視頻服務(wù)，兩種架構(gòu)本身就具備不同的性能測試，后臺架構(gòu)在進行指標(biāo)采集時，通過Prometheus監(jiān)控該平臺獲取CPU、內(nèi)存和帶寬的使用情況，通過Chrome瀏覽器中的WebRTC測試工具完成幀速率的指標(biāo)采集。對于SUF而言，采用分布式架構(gòu)，在進行CPU的使用時，每一個容器的CPU的使用情況都需要根據(jù)數(shù)量得到平均數(shù)。集群模式與單機模式相比，CPU的使用率并沒有受到很大影響。由于Coturn服務(wù)器需要通過網(wǎng)絡(luò)對UDP包進行轉(zhuǎn)發(fā)，當(dāng)人數(shù)有所增加時，內(nèi)存占用比降低，內(nèi)存是隨著人數(shù)的變化而發(fā)生變化的。

MCU架構(gòu)采用混流方式，因此CPU的使用率較高，相同并發(fā)人數(shù)使用的網(wǎng)絡(luò)帶寬降低。不管是哪一種架構(gòu)模式，對于客戶端而言，都是為其提供相同的媒體服務(wù)，當(dāng)人數(shù)較多的情況下，都可以有更好的速率為其使用，能夠處理更多的突發(fā)情況。

4 結(jié)語

總而言之，通過會議管理系統(tǒng)和媒體服務(wù)系統(tǒng)兩大部分，對視頻會議系統(tǒng)進行設(shè)計與實現(xiàn)，對會議管理系統(tǒng)的四大管理模塊進行詳細(xì)分析，并對其功能進行了闡述。隨后簡單介紹了媒體服務(wù)架構(gòu)所用到的兩種實現(xiàn)方式，在保證功能完整的情況下，提高系統(tǒng)的使用率，實現(xiàn)媒體資源的動態(tài)伸縮功能。