高并發(fā)需求下VR 遠程教育平臺的設計與優(yōu)化

摘要：在遠程教學中引入VR技術(shù)對系統(tǒng)的存儲容量、帶寬以及并發(fā)能力提出了更高的要求。采用微服務架構(gòu)搭建遠程教育平臺，可以實現(xiàn)各業(yè)務子模塊的無狀態(tài)彈性運行，并通過容器平臺作為底層支撐，滿足高并發(fā)和高可用需求。集群化部署對象存儲技術(shù)可為VR遠程教育平臺提供海量的存儲空間，同時分攤用戶訪問流量，實現(xiàn)負載均衡。Galera和Elasticsearch數(shù)據(jù)庫集群的多主特性，使底層數(shù)據(jù)庫在分布式部署情況下保持強一致性。壓力測試結(jié)果表明，該設計方案能夠有效提高平臺的并發(fā)性能。

關鍵詞：VR；遠程教育平臺；高并發(fā)；高可用；集群化部署

中圖分類號：TP315 文獻標識碼：A

文章編號：1009-3044（2024）17-0114-03 開放科學（資源服務）標識碼（OSID） ：

隨著國家對新型基礎設施建設的大力投入，5G 通信網(wǎng)絡的覆蓋范圍不斷擴大，預計到2025年底，全國將實現(xiàn)5G網(wǎng)絡的基本覆蓋[1]。5G網(wǎng)絡所具備的高速率和低延時特性，消除了制約VR（虛擬現(xiàn)實）技術(shù)應用發(fā)展的障礙，使VR技術(shù)用于遠程教育教學成為可能。本研究針對VR遠程教育平臺對海量存儲、高帶寬和高并發(fā)需求進行分析，設計了一套適合高并發(fā)需求的VR遠程教育平臺。

1 需求分析

1.1 提供沉浸式學習體驗

給用戶帶來沉浸式體驗是VR技術(shù)的優(yōu)勢與特色。目前主流的VR媒體攝錄與編碼包括半球面畸變法、正方體擬合、腰鼓畸變法等多種模式[2]。其中，半球畸變法使用多個簡單的魚眼鏡頭拍攝廣角影像，將拍攝到的球狀影像展開成二維，再按照傳統(tǒng)視頻的方式進行編碼和傳輸，最終通過播放終端還原成球狀的全景影像，是各類VR錄像機最常使用的技術(shù)。

各類VR媒體編碼與傳輸對遠程教育平臺沒有額外的功能需求，但隨著頭戴設備技術(shù)的發(fā)展，實現(xiàn)良好的沉浸式體驗需要較高的視頻分辨率。根據(jù)實測，4K像素的VR視頻在頭戴設備上才能勉強達到高分屏播放普通720p視頻的效果，但依然存在顆粒感。因此，VR遠程教育平臺必須支持8K以上視頻的流暢播放，這對帶寬需求、存儲需求、服務器端的編碼性能和終端的解碼性能都提出了更高要求。

1.2 提供交互功能

VR 遠程教育平臺的交互功能主要包含兩個方面：一是VR視頻本身所提供的全景互動體驗，用戶可以通過終端設備控制觀看視角，點擊視頻中的標記點實現(xiàn)互動；二是提供在線實驗測試環(huán)境，例如為常規(guī)專業(yè)提供的客觀題在線測試，以及為工程類學科提供的虛擬仿真平臺[3]。

1.3 具備高級別的安全性與可靠性

在安全性方面，VR遠程教育平臺根據(jù)其行業(yè)用途的不同，需執(zhí)行的信息安全等級保護也有所差異。教育屬于社會公共服務，涉及民生，根據(jù)《信息安全等級保護管理辦法》，或?qū)ι鐣?zhí)行構(gòu)成損失的信息系統(tǒng)至少需要執(zhí)行安全保護等級二級標準，系統(tǒng)架構(gòu)及所需的模塊組件必須足夠成熟且安全可控。

在可靠性方面，遠程教育平臺一般要求7×24小時不間斷運行，并設計至少能覆蓋5萬用戶。實際上，在遇到冰災、疫情等需要大范圍支持遠程教學的情況下，用于單一高校的并發(fā)訪問量可達2～8萬人。而根據(jù)湖南省教育統(tǒng)計快報的數(shù)據(jù)，用于省、市等不同級別、不同階段教育的平臺并發(fā)數(shù)需求如表1所示。

基于對大量VR教學視頻進行編碼測試，錄制8K/ 30fps視頻的原始碼率約為50Mbps，這意味著在默認情況下，單臺常規(guī)服務器最多只能支持約2 000人的并發(fā)用戶。為了滿足較大的區(qū)域覆蓋需求，需要采用集群化部署的方式進行優(yōu)化。

2 技術(shù)選型

基于上述需求，我們對流媒體傳輸協(xié)議、內(nèi)容存儲、數(shù)據(jù)庫及全文索引、運維與部署等方面的關鍵技術(shù)進行了分析和選型。

2.1 流媒體傳輸協(xié)議

當前主流的流媒體傳輸協(xié)議包括RTP（RTCP、RTSP、RTMP） 、MMS、HLS等。其中，RTP協(xié)議與MMS 協(xié)議相似，都將音視頻數(shù)據(jù)進行編碼封裝，輔以傳輸控制數(shù)據(jù)和傳輸質(zhì)量監(jiān)控機制，提供穩(wěn)定可靠的音視頻在線體驗。由于帶寬優(yōu)化和防私接保護等優(yōu)勢，這些協(xié)議在早期被廣泛應用。

HLS（HTTP Live Streaming） 協(xié)議是蘋果公司提出的一種基于HTTP的流媒體傳輸協(xié)議[4]。它的重要特征是將媒體文件切片存儲，并通過HTTP協(xié)議進行分發(fā)和重組，不依賴特定的服務端和客戶端軟件，具有良好的兼容性和可擴展性，適合大型網(wǎng)絡視頻服務平臺，也同樣適合VR遠程教育平臺。當前，YouTube、優(yōu)酷、bilibili等知名平臺均使用HLS協(xié)議提供服務。

2.2 內(nèi)容存儲

本平臺采用分布式部署的MinIO作為內(nèi)容存儲。MinIO支持S3協(xié)議，沒有存儲對象數(shù)量限制，單個文件最大支持5TB[5]，即使不對VR視頻進行切片，也能滿足所有課程需求。MinIO可支持32個節(jié)點組成集群，每個節(jié)點同時接入集群內(nèi)網(wǎng)和外網(wǎng)，通過內(nèi)網(wǎng)實現(xiàn)互聯(lián)，外網(wǎng)提供服務，訪問任意節(jié)點都能讀取集群中的任意內(nèi)容。

通過糾刪碼技術(shù)，MinIO可保護數(shù)據(jù)免受硬件故障和數(shù)據(jù)損壞，即使丟失一半節(jié)點的硬盤，也可以讀取和恢復數(shù)據(jù)，具有優(yōu)秀的可靠性。MinIO支持旁路服務，即直接通過接口面向用戶提供讀寫網(wǎng)址，用戶可以直接將文件寫入MinIO或從MinIO下載數(shù)據(jù)，減輕業(yè)務服務端訪問壓力。

2.3 數(shù)據(jù)庫與全文索引

在高并發(fā)場景下，遠程教學互動帶來的高頻次數(shù)據(jù)庫讀寫可能形成性能瓶頸。根據(jù)湖南師范大學智慧校園平臺的實踐經(jīng)驗，當并發(fā)數(shù)超過5 000時，用戶認證業(yè)務可能導致單節(jié)點數(shù)據(jù)庫運行滿負荷，訪問開始出現(xiàn)卡頓及無響應。

為滿足成本和安全需求，本項目采用開源的MariaDB+Galera集群作為數(shù)據(jù)庫。其優(yōu)勢包括：一是不增加額外開發(fā)成本，所有數(shù)據(jù)庫訪問與SQL語句編寫與單節(jié)點部署無異，僅在嚴格控制數(shù)據(jù)讀寫次序的業(yè)務中需注意采用事務封裝，避免數(shù)據(jù)不一致和死鎖問題；二是Galera集群不區(qū)分主從節(jié)點，不需讀寫分離操作，任何節(jié)點的寫入都通過同步機制分發(fā)到所有節(jié)點，保障數(shù)據(jù)一致性[6]。

針對MariaDB不提供原生中文全文索引的問題，測試結(jié)果表明像Mroonga這樣的插件在高并發(fā)場景下表現(xiàn)不佳，容易導致數(shù)據(jù)庫鎖死和宕機。因此，本平臺采用 Elasticsearch 提供全文索引支持。Elastic? search支持分布式部署，具備良好的中文分詞效果，對包含過億文檔的索引依然能保持良好的檢索效率，并提供完善的分類匯總統(tǒng)計功能[7]。

2.4 運維與部署

在設計之初，我們考慮到平臺的通用性，即該平臺既可以小規(guī)模部署，滿足較小覆蓋范圍的需求，在硬件資源有限的情況下也能正常運行；也可以支持大覆蓋、高并發(fā)的業(yè)務需求。平臺部署的組件和模塊盡可能支持彈性部署和動態(tài)擴容，即在出現(xiàn)訪問瓶頸時，能夠通過簡單配置增加運行實例和集群節(jié)點，避免出現(xiàn)大規(guī)模的數(shù)據(jù)遷移和系統(tǒng)重建操作。

基于上述要求，平臺采用容器化方式進行部署。對于用戶覆蓋較小、負載較輕的平臺可在單節(jié)點Docker環(huán)境中部署運行；對于覆蓋區(qū)域較廣、并發(fā)需求較高的平臺，采用Rancher作為Kubernetes管理平臺。其優(yōu)勢如下：管理與業(yè)務分離，業(yè)務的高負載不會影響管理平臺的運行；業(yè)務節(jié)點可動態(tài)擴容，當硬件資源不足時，可以非常快捷地增加節(jié)點，并將現(xiàn)有的業(yè)務實例遷移至新節(jié)點；也可通過簡單操作增加或減少實例數(shù)量，快速響應可能發(fā)生的訪問量驟增；邏輯簡單、操作便捷，容易形成固定模式的運維手冊，在發(fā)生非程序BUG引起的宕機故障時，按照檢查點清單逐一排查即可解決問題[8]。

3 功能模塊設計

在業(yè)務服務端，平臺采用微服務架構(gòu)設計，將用戶認證、課程管理、視頻切片預處理、內(nèi)容檢索與呈現(xiàn)等功能模塊單獨封裝，并盡可能支持無狀態(tài)、多實例運行。所有功能模塊采用RESTful風格的Web API提供訪問接口，模塊間通訊則由MQTT協(xié)議通過消息中間件提供實時的信號通知。

3.1 身份認證

平臺采用獨立封裝的OAuth2授權(quán)協(xié)議模塊來提供身份認證功能。當用戶訪問平臺業(yè)務時，業(yè)務后端接口會讀取請求頭中的Token令牌，如果令牌無效則將用戶重定向到身份認證模塊。身份認證模塊支持密碼驗證、短信驗證、微信掃碼驗證等多種方式，并為驗證成功的用戶頒發(fā)新的Token令牌。令牌遵循JWT 標準，其優(yōu)勢在于令牌驗證是基于簽名算法的，服務端通過計算驗證簽名有效即可確認用戶的合法性，無須到數(shù)據(jù)庫中查詢用戶信息，也不產(chǎn)生I/O開銷，相比傳統(tǒng)的基于Session會話的身份驗證模式性能更優(yōu)[9]。

3.2 課程管理

課程管理由三部分組成：

一是課程元數(shù)據(jù)的增刪改查操作，主要包括課程名稱、層次、內(nèi)容摘要、授課教師，課時與章節(jié)的描述等內(nèi)容，其業(yè)務邏輯類似于CMS系統(tǒng)。

二是非結(jié)構(gòu)化的課件管理，滿足在線備課、課件及文檔資料的上傳和編輯等需求。我們采用WOPI+ Office Online來支撐，業(yè)務端通過WOPI協(xié)議創(chuàng)建一個在線文檔的句柄，編輯和在線瀏覽都由受托管的Of? fice Online來完成，文檔的內(nèi)容也全部保存在MinIO 對象存儲中。

三是課程視頻的管理，這一部分由MinIO提供的PresignedPutObject接口實現(xiàn)，即業(yè)務端通過接口獲取一個預上傳的地址，教師則通過UI直接將視頻文件傳輸至MinIO中保存，存儲完成后將結(jié)果寫回業(yè)務數(shù)據(jù)庫。這樣可以實現(xiàn)無狀態(tài)、多實例運行，數(shù)據(jù)庫及I/O 壓力降至最低。

3.3 視頻切片預處理

由于HLS協(xié)議需要對視頻進行切片預處理[10]，故設計了這一獨立模塊來實現(xiàn)。具體業(yè)務邏輯如下：

在Kubernetes集群中運行一組Agent，這些Agent 接入消息中間件以偵聽通知，等待預處理任務。教師上傳課程視頻后，會創(chuàng)建一個預處理任務，并將其推送至任務隊列中。同時通過MQTT協(xié)議推送一個廣播通知，告知全體Agent有新任務待處理。當前空閑的Agent收到通知后，會向課程管理模塊請求執(zhí)行任務，課程管理模塊則從任務隊列中取出一個任務進行派發(fā)。Agent獲得任務后，從MinIO讀取完整的視頻文件，后端調(diào)用ffmpeg工具執(zhí)行視頻切片操作，生成ts 格式的視頻序列以及m3u8索引。然后將ts序列和索引回寫至MinIO，向課程管理端報告預處理任務已完成。如果任務執(zhí)行過程中出現(xiàn)異?；虺瑫r，課程管理模塊會標記任務的異常狀態(tài)，并重新分配給其他Agent重試。顯然，在這種機制下，各Agent均獨立運行，支持動態(tài)擴容，方便檢查與維護。

3.4 前端呈現(xiàn)

在Web瀏覽器端，平臺采用Hls.js腳本來支持課程視頻的播放。在手機端或VR終端中，采用支持HLS 協(xié)議的VR播放器來支持全景視頻的播放。由于前述的ts視頻序列和m3u8索引均存放在MinIO中，因此前端呈現(xiàn)之前需要通過PresignedGetObject接口獲取對象的下載地址，并采用HTTP重定向的方式將對索引及內(nèi)容的請求導向MinIO。這樣業(yè)務端只負責解析地址并重定向，所有的IO和流量負載均由MinIO集群承擔，會自動分攤到所有的節(jié)點上。因此，當VR遠程教育平臺需要支持更高的并發(fā)訪問時，只需對MinIO集群進行擴容即可。另外，當實際情況超出預估時，也可以通過增加一個集群的方式來實現(xiàn)擴容，這需要在業(yè)務端啟用MinIO多集群的隨機分配功能，即在創(chuàng)建課程時，明確此課程對應的MinIO集群。而當單一課程負載超標時，則需要將課件資源在多個MinIO 集群上進行同步。

4 平臺架構(gòu)

根據(jù)前述的需求及功能模塊設計，在高并發(fā)需求下整個平臺架構(gòu)分為業(yè)務后端、對象存儲、數(shù)據(jù)湖三個板塊。如圖1所示，圖中右部區(qū)域為業(yè)務后端板塊，oss區(qū)域為對象存儲板塊，左下區(qū)域為數(shù)據(jù)湖板塊，各板塊的組織結(jié)構(gòu)概述如下：

業(yè)務后端是平臺的核心板塊，其底層支撐為可動態(tài)擴容的k3s（一種輕量化的Kubernetes業(yè)務集群），另有一個Kubernetes集群作為業(yè)務集群的管理端，提供Rancher工具供運維人員使用。中層是按需編排的各類微服務模塊，包括身份認證（OAuth2） 、課程管理（CMS） 、視頻處理Agent池（VPS） 等。用于支撐各微服務模塊調(diào)度及通訊的各類協(xié)議與組件也可以放在業(yè)務集群中運行，包括MQ消息中間件（我們選用的是RabbitMQ，其他支持MQTT協(xié)議的中間件亦可）、支持WOPI協(xié)議的文檔管理組件等。

對象存儲板塊是存放VR遠程教育平臺海量音視頻數(shù)據(jù)和課件資料的區(qū)域，由一個或多個MinIO集群組成。對象存儲板塊的具體規(guī)劃需要對平臺的并發(fā)訪問量和容量需求進行評估，配置足夠的節(jié)點服務器和硬盤空間。每個節(jié)點服務器均需配置雙網(wǎng)卡，分別接入互聯(lián)網(wǎng)和業(yè)務內(nèi)網(wǎng)，并保障充裕的帶寬，避免因在線人數(shù)過多導致的網(wǎng)速瓶頸。如平臺需要覆蓋全國且用戶量特別巨大（達到國家智慧教育大平臺這種量級），還可以考慮引入第三方CDN來進行內(nèi)容分發(fā)。

數(shù)據(jù)湖板塊主要包含一組MariaDB Galera集群和一組Elasticsearch集群?？紤]到一些第三方組件在設計時并未考慮支持數(shù)據(jù)庫集群，我們有三種解決方案：

1） 直接指定連接集群中的一臺服務器，將集群當作單節(jié)點使用。由于Galera集群和Elasticsearch集群都沒有主從之分，因此數(shù)據(jù)將自動在集群中同步，不會影響業(yè)務正常運行。這么做的缺點是將會導致各集群節(jié)點的負載無法平衡，增加服務停止響應的風險。

2） 在業(yè)務內(nèi)網(wǎng)增加一個用于內(nèi)部名稱解析的DNS服務器，設置一個內(nèi)部域名指向全部集群節(jié)點的IP地址，依靠TCP/IP協(xié)議底層的邏輯來實現(xiàn)負載均衡。這種做法通常有效，但在某些組件上依然會指向一個固定的節(jié)點，無法完全起到負載均衡的作用。

3） 部署一個Nginx作為負載均衡。這種做法的缺點是犧牲了集群的高可用特性，因為一旦Nginx崩潰，業(yè)務也將隨之宕機。

5 總結(jié)

本文提出了一種VR遠程教育平臺設計方案。該方案在設計之初充分考慮了高并發(fā)與高可用的實際需求，采用了最新的理念和前沿技術(shù)進行規(guī)劃，理論上具備極高的性能與穩(wěn)定性。部分模塊在湖南師范大學進行了生產(chǎn)環(huán)境測試。在數(shù)據(jù)庫集群和多實例運行的情況下，響應速度和穩(wěn)定性相比同類系統(tǒng)有顯著提升。在5萬并發(fā)的壓力測試中，訪問成功率由18%提升至95%，顯示出顯著的效果。

【通聯(lián)編輯：唐一東】

基金項目： 2021 年湖南省普通高等學校教學改革研究項目，基于5G+VR 技術(shù)的中小學教師繼續(xù)教育研學場景構(gòu)建及其應用研究（項目編號： HNJG-2021-0404）