基于云原生的視頻管理系統(tǒng)設(shè)計與實現(xiàn)

張 咪，劉 文，郭 慶

（中國航空工業(yè)集團(tuán)公司西安航空計算技術(shù)研究所，西安 710065）

0 引言

由于傳統(tǒng)的面向服務(wù)的架構(gòu)（Service Oriented Architecture，SOA）或單體應(yīng)用無法支撐數(shù)據(jù)爆發(fā)式增長和業(yè)務(wù)的快速迭代，近年來基于云原生的系統(tǒng)構(gòu)建，憑借其高資源利用率、高可擴展、獨立部署、快速迭代的獨特優(yōu)勢，已成為一種新趨勢。

本文基于云原生和微服務(wù)架構(gòu)思想設(shè)計并實現(xiàn)了一套視頻管理系統(tǒng)，該系統(tǒng)能夠?qū)崟r采集與處理持續(xù)產(chǎn)生的監(jiān)控視頻數(shù)據(jù)，并提取視頻關(guān)鍵幀作為視頻摘要，根據(jù)圖片與視頻摘要的相似度比對實現(xiàn)視頻圖像內(nèi)容檢索?；谖⒎?wù)框架、容器化的實現(xiàn)方案，使該系統(tǒng)具有高擴展性。微服務(wù)拆分綜合考慮業(yè)務(wù)、可擴展性、性能、穩(wěn)定性4個要素，使得服務(wù)架構(gòu)清晰，可助力實現(xiàn)服務(wù)的快速更改與部署，從而應(yīng)對動態(tài)多變的業(yè)務(wù)需求，順應(yīng)企業(yè)數(shù)字化變革的大趨勢。

1 相關(guān)研究

1.1 云原生概述

Pivotal 公司提出云原生是一個思想集合，其目的是幫助企業(yè)快速、持續(xù)、可靠、規(guī)?；亟桓稑I(yè)務(wù)軟件。云原生以彈性可擴展、高可用性、高靈活、強兼容和低成本的方式將云的價值最大化，滿足經(jīng)濟社會“智能化”和“云化”轉(zhuǎn)型的新要求［1］。

云原生給企業(yè)帶來了軟件過程應(yīng)用架構(gòu)和基礎(chǔ)設(shè)施的變革［2-3］。其具備容器化封裝、動態(tài)管理及面向微服務(wù)三大特征［4］，同時借助容器化、微服務(wù)、服務(wù)網(wǎng)格、不可變基礎(chǔ)設(shè)施等相關(guān)技術(shù)，能夠構(gòu)建高容錯、易管理和便于觀察的松耦合系統(tǒng)。云原生應(yīng)用設(shè)計之初即考慮到充分利用云資源的優(yōu)勢，故其天然具備云平臺的彈性、分布式、負(fù)載均衡等優(yōu)點，同時借助微服務(wù)、Devops（Development 與Operations 的組合詞）、容器化、可持續(xù)部署等關(guān)鍵技術(shù)手段，可降低開發(fā)復(fù)雜度、簡化研發(fā)流程，實現(xiàn)業(yè)務(wù)的敏捷迭代、可持續(xù)交付及智能運維。

1.2 微服務(wù)架構(gòu)

微服務(wù)最早是由MFlow 和JLewis 于2011 年提出的一種新的軟件架構(gòu)風(fēng)格，也是面向服務(wù)軟件開發(fā)的新趨勢［5］。其旨在從業(yè)務(wù)角度將復(fù)雜的系統(tǒng)劃分成職責(zé)明確的一組服務(wù)，各服務(wù)專注于完成單一的業(yè)務(wù)功能，以更靈活、輕量級的模式進(jìn)行獨立設(shè)計開發(fā)與部署，形成服務(wù)高度內(nèi)聚自治［6］。

相比于傳統(tǒng)應(yīng)用架構(gòu)，微服務(wù)具有以下優(yōu)勢：①技術(shù)棧解耦可采用不同技術(shù)開發(fā)，便于接納與引入新技術(shù)；②單個服務(wù)體量小，可降低上下文理解難度及研發(fā)難度；③容錯性高，問題波及范圍局限在服務(wù)內(nèi)，可減少對系統(tǒng)的影響；④各服務(wù)可獨立部署擴展及定制運維方案。

微服務(wù)架構(gòu)強調(diào)服務(wù)自治及松耦合，將單體應(yīng)用拆分成一組職責(zé)明確的微服務(wù)，服務(wù)間通過輕量級交互機制進(jìn)行通信。微服務(wù)架構(gòu)結(jié)合Devops 研發(fā)工具鏈，能夠輕松實現(xiàn)系統(tǒng)變更、部署和智能運維［7］。

2 視頻管理系統(tǒng)設(shè)計

2.1 系統(tǒng)概述

傳統(tǒng)視頻存儲方式如本地存儲、直連存儲、網(wǎng)絡(luò)附屬存儲（Network Attached Storage，NAS）、磁盤掛載［8-9］等存在由于空間不足導(dǎo)致視頻質(zhì)量差、采集信息匱乏等問題［10］。綜合現(xiàn)狀及云平臺的優(yōu)勢，本文提出基于云原生的視頻管理系統(tǒng)。

基于云原生的視頻管理系統(tǒng)主要用于政企內(nèi)部音視頻等文件管理，可幫助企業(yè)存儲及管理內(nèi)部視頻數(shù)據(jù)。該系統(tǒng)功能模塊如圖1 所示，包括視頻上傳、視頻檢索、視頻處理、視頻瀏覽下載、用戶權(quán)限管理等功能。

視頻管理系統(tǒng)提供上傳接口供企業(yè)通過各渠道將視頻上傳至平臺，同時獲取并存儲視頻相關(guān)屬性。視頻上傳成功后，異步提取視頻關(guān)鍵幀作為封面。視頻檢索相對于其他檢索的特點在于無法直接獲取視頻語義。為此，本系統(tǒng)提供兩個維度進(jìn)行檢索：①根據(jù)視頻屬性檢索：通過視頻采集時間、渠道、類型等屬性進(jìn)行組合檢索，以解決視頻信息不完整導(dǎo)致難以檢索的問題［11］；②根據(jù)圖片檢索：根據(jù)搜索圖片與已提取的視頻關(guān)鍵幀進(jìn)行相似度檢索。同時該系統(tǒng)還包括其他基礎(chǔ)模塊，如用戶權(quán)限管理模塊，可對用戶的登錄、瀏覽、下載等功能權(quán)限進(jìn)行管理；視頻管理模塊，主要包括視頻發(fā)布、下線、刪除、編輯等功能。

Fig.1 System function module圖1 系統(tǒng)功能模塊

2.2 微服務(wù)拆分

服務(wù)拆分是微服務(wù)架構(gòu)設(shè)計的重要環(huán)節(jié)，其合理性將直接影響到服務(wù)開發(fā)、測試、部署的復(fù)雜度。因角度不同，微服務(wù)拆分方法各異，文獻(xiàn)［12］提出基于聚類的服務(wù)拆分，服務(wù)職責(zé)清晰，但不具備普適性，且聚類參數(shù)難以確定。文獻(xiàn)［13］提出數(shù)據(jù)流驅(qū)動的微服務(wù)劃分，其建立在運行數(shù)據(jù)的基礎(chǔ)上，只適用于老系統(tǒng)向微服務(wù)遷移。雖然服務(wù)拆分途徑各異，但歸根結(jié)底仍需從業(yè)務(wù)出發(fā)，在理解業(yè)務(wù)的基礎(chǔ)上，按照職責(zé)單一原則確定微服務(wù)的邊界上下文和功能域［14］。

本文以業(yè)務(wù)功能為主，綜合可靠性、穩(wěn)定性和性能進(jìn)行微服務(wù)設(shè)計，對可靠性與性能要求高的模塊及業(yè)務(wù)變動頻繁的模塊單獨進(jìn)行微服務(wù)。綜合以上因素，本文系統(tǒng)共分為6 個微服務(wù)：①用戶權(quán)限服務(wù)：負(fù)責(zé)用戶身份校驗及訪問權(quán)限設(shè)置。該模塊業(yè)務(wù)獨立，對性能要求較低，但對可靠性和穩(wěn)定性要求較高；②視頻維護(hù)服務(wù)：具體包括視頻發(fā)布、下線、刪除、屬性編輯等，該模塊對于可靠性、穩(wěn)定性與性能的要求都較低；③視頻封面提取服務(wù)：提取視頻關(guān)鍵幀作為視頻封面，對性能要求高，對可靠性與穩(wěn)定性要求低；④視頻上傳服務(wù)：存儲各渠道采集的視頻實體及其屬性，對穩(wěn)定性、可靠性、性能的要求都較高，故單獨為其提供一個微服務(wù)；⑤視頻展示與檢索服務(wù)：展示與檢索業(yè)務(wù)關(guān)聯(lián)密切，對穩(wěn)定性、可靠性及性能要求都較高；⑥視頻下載瀏覽服務(wù)：代碼及業(yè)務(wù)耦合率高，且都對性能要求較高。

2.3 微服務(wù)通信協(xié)作

用戶請求通常需要多個微服務(wù)共同協(xié)作，這就依賴于服務(wù)間的輕量級通信。同步調(diào)用和異步調(diào)用是服務(wù)通信的兩種方式［15］。針對實時響應(yīng)的請求，采用基于超文本傳輸協(xié)議（Hyper Text Transfer Protocol，HTTP）的REST API（Representational State Transfer）進(jìn)行同步通信，針對耗時、易阻塞的請求，采用基于消息隊列的方法進(jìn)行異步調(diào)用，實現(xiàn)輕量級通信。

本系統(tǒng)中多數(shù)請求需要實時響應(yīng)，比如視頻檢索、發(fā)布、上線、編輯等需要用戶保持等待狀態(tài)，直至結(jié)果返回，對于此類請求采取同步通信。對于視頻封面提取和視頻下載，此類請求通常處理時間長，且無需一直保持等待狀態(tài)，因此采用消息隊列實現(xiàn)異步通信?；谙㈥犃械漠惒酵ㄐ啪邆洹跋逍?yīng)”，能夠降低系統(tǒng)高并發(fā)時需要較長時間處理請求給服務(wù)器帶來的壓力。

3 視頻管理系統(tǒng)技術(shù)架構(gòu)

本系統(tǒng)采用Vue+SpringBoot+FastDFS（分布式文件系統(tǒng)）框架，針對數(shù)據(jù)特點分別選用結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)庫存儲視頻屬性及視頻實體。采用基于內(nèi)容的視頻幀提取技術(shù)獲取視頻關(guān)鍵幀作為視頻封面，以支持根據(jù)圖像檢索視頻。該系統(tǒng)架構(gòu)共分為4 層，分別為：應(yīng)用層、服務(wù)層、基礎(chǔ)服務(wù)層、數(shù)據(jù)層，如圖2 所示。

Fig.2 Technical architecture of video management system圖2 視頻管理系統(tǒng)技術(shù)架構(gòu)

應(yīng)用層采用前后端分離的模式，前端采用Vue js 和element-ui 實現(xiàn)，后端使用springboot 的Restful 注解方式對API 請求進(jìn)行接收。前端與后端之間使用Nginx 進(jìn)行負(fù)載均衡，并分發(fā)請求。后端接收前端請求后，根據(jù)業(yè)務(wù)處理需求調(diào)用不同微服務(wù)，完成業(yè)務(wù)的邏輯處理。

服務(wù)層由一組相互獨立的微服務(wù)組成，可處理來自應(yīng)用層的請求，各服務(wù)數(shù)據(jù)庫相互獨立。服務(wù)間通過接口進(jìn)行同步或異步通信。服務(wù)部署并運行在docker 容器上，服務(wù)啟動快，且易橫向擴展，能夠靈活應(yīng)對請求突增。結(jié)合Devops工具鏈，可實現(xiàn)持續(xù)集成和灰度發(fā)布。

基礎(chǔ)服務(wù)層采用Dubbo（開源分布式服務(wù)框架）+zookeeper（分布式應(yīng)用程序協(xié)調(diào)服務(wù)）進(jìn)行服務(wù)治理和負(fù)載均衡，配置管理平臺對各微服務(wù)配置進(jìn)行統(tǒng)一管理。注冊中心管理微服務(wù)的注冊、預(yù)定及服務(wù)調(diào)用，通過ELK 日志管理可實現(xiàn)智能運維。

數(shù)據(jù)層主要選取FastDFS、MySQL 和Redis 3 種數(shù)據(jù)庫。FastDFS 數(shù)據(jù)庫存儲視頻實體本身，其自身具備線性擴展與負(fù)載均衡能力；MySQL 數(shù)據(jù)庫存儲視頻基本屬性、用戶數(shù)據(jù)等其他結(jié)構(gòu)化數(shù)據(jù)，同時關(guān)聯(lián)FastDFS 文件實體；Redis 數(shù)據(jù)庫用于緩存用戶權(quán)限等信息。本文架構(gòu)根據(jù)實體數(shù)據(jù)特點，選取不同數(shù)據(jù)庫進(jìn)行存儲，從而保障存儲、檢索的高效性與可靠性。

4 視頻管理系統(tǒng)實現(xiàn)

4.1 核心模塊實現(xiàn)

視頻上傳模塊為視頻管理系統(tǒng)的核心模塊，對穩(wěn)定性和可靠性要求較高，需要保障文件包不丟失且完整。本文采用分布式存儲數(shù)據(jù)庫FastDFS 實現(xiàn)視頻文件分布式存儲，具體實現(xiàn)步驟如下：

（1）通過Maven 管理包目錄。通過添加pom 依賴包，引入FastDFS jar 包。

（2）配置上傳默認(rèn)屬性。設(shè)置默認(rèn)切片大小，當(dāng)原始文件大于默認(rèn)切片時，按照默認(rèn)文件大小對原始文件進(jìn)行切片上傳。同時還需設(shè)置超時時間、日志存放地點、最大鏈接數(shù)等其他默認(rèn)屬性。

（3）斷點續(xù)傳。針對大文件，本文采取文件切片和斷點續(xù)傳策略。將較大文件切片后再上傳，防止因網(wǎng)絡(luò)原因造成的文件破壞。具體實現(xiàn)代碼如下：

4.2 微服務(wù)通信與集成

本文采用Dubbo 框架實現(xiàn)服務(wù)注冊與發(fā)現(xiàn)，并進(jìn)行服務(wù)管理。Dubbo框架通過生產(chǎn)者、消費者、注冊中心實現(xiàn)服務(wù)的注冊、管理和發(fā)布。其中，服務(wù)注冊中心用于服務(wù)注冊以及服務(wù)事件發(fā)布與訂閱。生產(chǎn)者將服務(wù)接口暴露給注冊中心，供其他微服務(wù)調(diào)用。消費者通過consumer.xml配置文件引入已發(fā)布接口后，即可使用。實現(xiàn)步驟如下：

（1）導(dǎo)入Dubbo Jar 包。對于需要暴露的微服務(wù)接口，在provider.xml 文件中配置聲明，暴露給服務(wù)注冊中心，具體實現(xiàn)代碼如下：

（2）引用接口。對于已在注冊中心發(fā)布的接口，在所需消費的應(yīng)用中通過consumer.xml文件引入接口。具體引用過程相關(guān)代碼如下：

4.3 性能測試

文件上傳模塊也是視頻管理系統(tǒng)的核心模塊，本文對文件上傳模塊進(jìn)行性能測試。設(shè)置并發(fā)線程20 個，選取4個不同大小的文件觸發(fā)文件上傳，測試結(jié)果如表1 所示，文件全部上傳成功。選取表1 中上傳成功的文件，下載后進(jìn)行檢驗，文件可正常打開，且上傳和下載后的文件內(nèi)容均未發(fā)生變化。

Table 1 Upload results of stress test video表1 壓力測試視頻上傳結(jié)果

將本文應(yīng)用分別部署在容器（K8S+docker）和虛擬機（6 核+128G）上，對應(yīng)用的部署及重啟性能進(jìn)行測試。容器與虛擬機部署性能對比如表2 所示，應(yīng)用部署在容器上的重啟時間、占用存儲、可擴展性均優(yōu)于部署在虛擬機上。

Table 2 Performance comparison of container and virtual machine deployment表2 容器與虛擬機部署性能對比

綜上，微服務(wù)架構(gòu)使得系統(tǒng)能夠靈活應(yīng)對企業(yè)業(yè)務(wù)擴充及各種變化，避免了由于存儲空間問題造成的視頻質(zhì)量差、視頻采集數(shù)據(jù)丟失等問題。同時，容器部署占用存儲少、易擴展，服務(wù)重啟速度達(dá)到秒級，可令用戶無感知地進(jìn)行節(jié)點擴充及版本上線。

5 結(jié)語

本文介紹了一套基于云原生的視頻管理系統(tǒng)，通過松耦合的微服務(wù)架構(gòu)、輕量級通信使得系統(tǒng)架構(gòu)清晰、職責(zé)明確，減小了單個服務(wù)故障對系統(tǒng)的影響范圍?；谠圃⑽⒎?wù)與容器部署的系統(tǒng)，支持根據(jù)負(fù)載均衡策略隨時調(diào)整節(jié)點個數(shù)，以應(yīng)對請求陡增，防止服務(wù)崩潰，給企業(yè)數(shù)字化轉(zhuǎn)型工具變革提供了新思路。