云視頻系統服務高可用技術

徐 艷 謝永強 李忠博 齊 錦 李少南

視頻技術的飛速發展滿足了人們日益增長的可視化通信需求[1],深刻改變了溝通交流、目標監控和情報傳遞方式.視頻通信系統已經滲透到遠程會議、在線教育、遠程醫療等多個民用領域[2],在指揮控制領域也構成了信息基礎設施的重要部分.

隨著云計算技術的不斷成熟,視頻通信系統逐漸向云化演進,形成了彈性部署、實時高效、架構靈活的云視頻系統.在民用領域,圍繞音視頻編解碼、資源調度、云視頻架構等關鍵技術已有大量研究.國內外視頻通信和云計算廠商也推出了許多云視頻系統產品,例如國產的阿里釘釘、華為WeLink、騰訊會議等,以及國外的Polycom、Zoom 等,因其低成本、高質量的視頻服務得到了市場高度認可.2019 年12月,新冠疫情爆發,云視頻系統更是在人們居家隔離對抗疫情期間發揮了不可或缺的作用,使經濟、政治、民生得以遠程開展.

在軍用領域,視頻通信系統傳遞音視頻資源為主體的戰場信息,為指揮員提供身臨其境、高效快捷的指揮能力,為可視化信息作戰提供技術平臺支撐.例如美軍的遠程視頻增強（remotely operated video enhanced receiver,ROVER）系統[3],以軍的戰場視頻網系統等,利用共享實時圖像,建立戰場信息共識以及形象直觀、準確翔實的可視化指揮方式.戰術云是云技術在邊緣的擴展,可搭載在車輛、艦艇等前出平臺上,賦能戰術角色的云視頻系統增強態勢感知和決策能力[4].動態、高壓、資源有限的惡劣戰場環境對云視頻系統服務可用性形成嚴峻考驗,而瞬息萬變的戰場敵我對抗則要求云視頻系統服務連續可靠.因此,面向指揮控制領域,云視頻系統服務高可用研究具有必要性和挑戰性.

服務高可用是云視頻系統的非功能性需求之一,指系統穩定運行所需的故障恢復和快速接替能力[5],包括冗余、備份、監測、恢復4 個基礎組件.許多服務高可用技術的研究圍繞上述4 個基礎組件角度分別展開,關于整體高可用架構方案的討論并不多[6-7].另外,云視頻系統依托云平臺基礎資源,服務部署在虛擬機或容器等虛擬環境中,處理數據更多,服務粒度更細、服務交互更復雜,故障監測及失效恢復開銷更大[8].因此,云視頻系統服務高可用解決方案需考慮應用特性.本文從軟件架構、故障監測、失效恢復3 個角度全面梳理了服務高可用技術的研究進展.結合云視頻系統虛擬化運行環境的特點和視頻傳輸協議棧的特性,提出了包括管理控制服務、信令協商服務、媒體處理服務在內的云視頻系統核心服務高可用解決方案,旨在改進故障監測效率和失效恢復速率.展望了服務高可用的云視頻系統在指揮控制領域的若干應用,以期為云視頻系統在指揮控制領域的實現提供參考.最后,探討了相應的網絡安全因素.

1 云視頻系統概述

1.1 起源發展

視頻通信系統是一種利用網絡通信技術、多媒體處理技術和計算機技術實現點對點或多點間的音視頻交互的通信系統[9-10],其發展歷程如圖1 所示.

圖1 視頻通信系統發展歷程Fig.1 Development history of video communication system

20 世紀60 年代,在通信可視化需求的推動下,美國AT&T 公司研制了一套模擬電視會議系統[11],標志著視頻通信系統的發展開端,掀起了模擬視頻通信系統的研究熱潮.20 世紀80 年代,隨著數字信號處理技術的成熟,出現了2 Mbit/s 的彩色數字視頻會議系統,是視頻通信系統數字化的里程碑.同一階段,音視頻編解碼技術的提升和視頻通信標準規范的統一促進了視頻通信系統的商用普及.

20 世紀90 年代,互聯網技術浪潮下,出現了基于分組網絡的H.323 視頻通信系統,并逐漸替代以往基于專線的H.320 視頻通信系統,成為工業界主流.另一方面,國際電信聯盟電信標準分局（International Telecommunication Union-Telecommunication,ITU-T）引領的H.26x 標準和國際標準化組織（International Organization for Standardization,ISO）引領的動態圖像專家組（moving picture experts group,MPEG）標準推動視頻通信系統從標清向高清、超高清發展.

21 世紀初,云計算技術的快速發展,促使了視頻通信系統在基礎平臺上的創新.以云計算平臺為基礎的云視頻系統相較于專用硬件平臺為基礎的傳統視頻通信系統而言,改善了擴展成本高、運維管理難、資源利用低效的問題,具備高彈性、高性能、高并發的優勢[12].云化是視頻通信系統繼數字化、網絡化、高清化后的重要發展趨勢[13].

1.2 云視頻系統組成

云視頻系統可分為云視頻服務、終端和網絡3部分[14],其組成如圖2 所示.

圖2 云視頻系統組成Fig.2 Cloud-based video system composition

云視頻服務側由大規模、分布式的視頻服務器集群構成,實現信令交互、媒體處理、媒體存儲、業務邏輯等[15],是云視頻系統的核心部分.

終端側是用戶獲取視頻服務的基本入口,實現媒體數據的采集、播放、編解碼.云視頻系統支持泛在終端接入[16],例如會議室終端、PC 終端、手機App以及具備音視頻功能的智能穿戴設備等.

網絡是云視頻服務和終端之間傳遞服務的信道.云視頻系統支持泛在網絡接入,包括專線、寬帶和移動互聯網、衛星等通信網絡.

云視頻系統提供服務的模式為：用戶與運營者簽訂服務等級協議（service level agreement,SLA）,就視頻質量、使用時長、數據存儲與訪問等各項服務指標達成一致；用戶選擇終端接入方式,包括終端設備和接入網絡；云視頻服務按用戶需求實現終端互連和媒體處理；最終,用戶通過終端獲得已付費和授權的實時視頻通信服務.

1.3 云視頻系統服務

云視頻系統的特點是功能服務化,基本的視頻通信組件和上層的視頻業務應用均以服務形式封裝,依托虛擬機或容器等運行環境部署[17].云視頻系統的服務包括控制管理、信令協商、媒體處理等核心服務,以及視頻會議、視頻協作、視頻監控等應用服務.

云視頻系統可從服務級、網絡級、平臺級、數據中心級等多個層級設置高可用機制.基于服務化特點,服務高可用是云視頻系統整體高可用中最為關鍵的部分,后續章節對當前主流服務高可用技術進行梳理分析.

2 服務高可用技術研究進展

服務高可用技術是一種依托軟件架構,結合冗余、備份、監測、恢復等高可用組件,實現服務穩定、可靠運行的技術[18].對于云視頻系統而言,虛擬化技術使服務資源更加靈活,從而降低了服務高可用機制中冗余和備份策略的成本.但同時,不斷擴大的服務規模對軟件架構設計形成挑戰,驟增的服務單元及其之間頻繁的交互提升了監測和恢復策略的開銷.分別從軟件架構、故障監測、失效恢復3 個方面梳理國內外已有研究.

2.1 基于軟件架構的服務高可用

軟件架構定義了應用的組件結構及其交互關系,是服務高可用的基礎[19].典型的軟件架構包括單體架構、面向服務的架構（service oriented architecture,SOA）和微服務架構等.

2.1.1 單體架構

傳統軟件應用大多采用單體架構,即業務所需的邏輯模塊、運行數據等作為整體被設計、開發、打包和部署[20],如圖3 所示.

圖3 單體架構Fig.3 Monolithic architechture

單體架構系統的所有軟件功能在同一個進程中執行,多個服務器共同支持其計算任務,但內部各個組成模塊無法獨立運行,單個模塊故障將導致整體功能故障[21].

隨著業務需求變更和系統規模擴增,單體架構越來越龐大、復雜,新業務交付周期延長,對于強實時性、高可用性、高伸縮性要求的系統應用而言,不利于開發部署、運維管理和升級維護[22].例如,2008年,知名流媒體服務商——Netflix 公司的單體架構數據中心發生故障,導致服務中斷3 d[23],影響全球過億付費訂閱用戶體驗.Netflix 公司意識到必須通過垂直擴展架構以避免單點故障后,花費近7 年時間重構其單體系統,于2016 年完成從單體到微服務的架構遷移,進而增強了服務可用性.

2.1.2 面向服務的架構

為了克服單體架構的弊端,應對大規模軟件應用服務高可用要求,產生了SOA.SOA 是一種將整個應用分解為若干個相互獨立、自包含、可重用的服務,具有動態、松耦合和分布式特性的架構設計原則[24].SOA 相對于單體架構降低了組件間的耦合性,便于故障隔離；可啟動多個實例對外提供業務,便于水平擴展；通過服務發布、注冊機制,在線部署服務,無須離線升級維護,提供了服務高可用基礎.

Nuve 是一個典型的SOA 架構用例[25],面向視頻會議即服務.其將音頻、視頻、共享應用、協作等功能封裝成服務,以不同的組合形式為用戶提供靈活、虛擬的云會議室.位于Nuve 架構下層的Marte 服務器可實時創建虛擬會議室資源,為上層服務的高可用性提供資源基礎.Nuve 架構是開源WebRTC 平臺的Licode 組件.

類似的SOA 架構用例還有“Study on Service-Oriented Cloud Conferencing”[26].該研究提出將SOA架構應用于視頻會議系統的平臺層與應用層,并描述了其詳細結構.平臺層是若干原子服務,如會議管理、用戶管理、發言權控制、音頻處理、視頻處理,服務動態發布并在服務注冊中心注冊,應用層可動態訂閱平臺層提供的相關服務,實時構建、擴展不同功能的虛擬會議室.某個服務實例故障時,服務注冊中心即服務代理指派其他實例接替服務,實現服務高可用.

SOA 雖然相較于單體架構,在服務高可用方面有所提升,但仍存在中心式服務和共享數據環境的瓶頸.因此,圍繞服務拆分粒度以及服務交互環境又產生了新的架構設計方法.

2.1.3 微服務架構

為了避免SOA 中心式服務的瓶頸,進一步細化服務拆分粒度,出現了微服務架構[27-29].2014 年Lewis和Flower 提出微服務定義：通過一套小型服務（即微服務）的集合來構造單個應用程序,其中每個微服務都在自己的進程中運行,并采用例如HTTP 等輕量通信機制.首次總結了這一新的架構設計原則.

微服務相對于SOA 有3 個顯著特性：1）去中心化；2）服務管理機制；3）更細的服務拆分粒度[30].以上3 點特性使微服務架構在避免單點故障、橫向擴展和故障隔離方面表現更佳.

2016 年,Alam A F B 在云視頻軟件開發研究中提出了一種基于微服務的軟件架構[31].該架構主要在平臺層對服務編排和管理作出創新,與以往的SOA單一注冊中心而沒有編排和管理形成對比.基礎設施層調用第三方提供的會議基底組件,如呼入信令、呼出信令、音頻混合、視頻混合,提供了比虛擬機更細的服務資源粒度,平臺開發過程無須關注會議通信細節,主要聚焦于服務部署與交互.2018 年,該團隊對此架構進行了擴展[32],如圖4 所示.

圖4 云視頻軟件架構Fig.4 Cloud-based video software architecture

該架構延伸至基礎設施層,其命名為子服務即服務（sub as a service,SubaaS）.該研究包含概念原型驗證,但缺少如服務切換時間、服務恢復開銷等高可用性評價指標.2020 年,TAKASHI 等提出了一種基于容器技術的微服務架構[33].研究目的是利用擴展的伯克利包過濾器作為服務相關容器的測量傳感器,從而獲取高可用相關性能指標.這些指標不僅僅體現服務質量,也體現服務所利用的基礎設施的質量,相較于之前的架構在性能測量方面更加直觀.

2.2 基于故障監測的服務高可用

軟件架構為服務高可用機制提供了良好的運行環境,而機制的實現首先依賴于故障監測策略,其通過探測服務節點狀態,為系統容錯提供信息支持[34].故障監測的實現主要基于心跳機制,即判斷被監測節點發出的消息能否在規定時間內到達,從而判定被監測節點是否發生故障.隨著系統規模和復雜性不斷增加,需要監測的節點數量驟增,同時,系統拓撲的動態變化性、消息延遲的不可預測性等挑戰不斷涌現,監控任務更富有挑戰性.圍繞時效性和擴展性兩項質量目標,故障監測的研究方向劃分為自適應故障監測和共享故障監測兩方面.

2.2.1 自適應故障監測

自適應故障監測是針對監測時效性（速度、準確性）的監測優化方法,通過動態調整心跳消息發送間隔n 和超時閾值Δt 來適應監測環境變化.基于上次心跳是一種復雜度較低的自適應故障監測方法,超時閾值取自上一次接收心跳回復時間.這種方法可以適應網絡突發變化,但仍不能跟蹤網絡緩慢過程中的動態變化.平均心跳方法使用n 次心跳傳輸時間的平均值作為超時閾值Δt,從而作出周期性地動態自適應.索托馬在公共對象請求代理體系結構（common object request broker architecture,CORBA）系統中實現了基于平均心跳方法的失效檢測器[35],通過真實數據驗證了平均心跳方法的自適應性強于基于上次心跳.相比于平均心跳方法,最大心跳方法利用n 次心跳傳輸時間的最大值作為超時閾值Δt 的預測值[36],進一步改善準確性.基于上次心跳和平均心跳方法都是基于人工規則設定的數值,自適應性弱.為此,有研究將差分自回歸移動平均模型引入心跳監測,具有更高的超時閾值預測準確性,但實現復雜度也有所提高[37].綜合對比以上方法,基于上次心跳方法實現簡單、監測較快、準確性較好,平均心跳方法和最大心跳方法性能接近,差分自回歸移動平均方法預測準確性最佳,但實現復雜度最高.

2.2.2 共享故障監測

共享故障監測是提升監測擴展性的優化方法.在一個節點數為n 的系統中,至多有n2個監測關系.隨著系統規模不斷增加,被監測節點數量和監測關系也在不斷增加,進而導致巨大的監測開銷.為了提升監測擴展性,被監測節點之間通過共享結果的方法減少監測關系、降低監測開銷,以改善監測擴展性[38].共享故障監測包括層次式方法和Gossip 方法.

層次式方法利用樹或森林等特殊層次結構組織被監測節點,節約監測關系以降低監測負載,并提高監測擴展性[39].其典型結構如圖5 所示.

圖5 層次式檢測方法Fig.5 Hierarchical detection method

面向Globus 網格計算平臺的故障監測協議中使用到了層次式監測方法[40].本地主機上的每個運行進程為一個被監測節點,每臺主機上配置一個監測模塊,對本地主機所有運行進程實施監測.網格間,不同主機相互交換本地監測結果,進而使所有主機共享全局檢測結果.該協議是一種類兩層的結構,主機之間并沒有嚴格的層次關系,降低開銷的性能有限.BERTIER 等提出了一個雙層結構的監測協議[41].根據IP 地址將被監測節點劃分到不同分組中,每個分組通過選舉產生一個主節點部署監測組件,主節點監測分組內的節點狀態,而所有的主節點通過互相交換監測結果可形成共享.這種監測方法形成了效率較高的層級機構,但并不適合拓撲結構頻繁變化的系統.

Gossip 方法是基于概率多播協議的故障監測方法,采用蠕蟲病毒原理的快速傳播方式,通過多輪監測結果交換以迅速實現全局監測結果共享.主要有基本Gossip 檢測器和多層Gossip 檢測器兩種實現形式[42].基本Gossip 檢測器是在每輪檢測中隨機選取鄰居節點進行檢測并交換檢測結果,通過數輪交換可以獲得其他所有節點狀態.這種檢測器的負載不受系統拓撲結構的影響,但檢測時間受算法隨機性影響.多層Gossip 檢測器是基本Gossip 檢測器與層次式方法的結合,一般在子網內交換檢測結果,少數交換跨子網進行.因檢測負載只與子網數量相關,進一步減少檢測時間和監測開銷.對比分析以上兩類共享故障監測方法,層次式方法復雜度低、擴展性強,適用于拓撲結構相對固定的大規模系統；Gossip方法復雜度高,不受拓撲結構影響、擴展性強且監測迅速快.

2.3 基于失效恢復的服務高可用

失效恢復是故障監控組件提供故障報警信息后為實現服務接替而采取的故障切換（Failover）.失效恢復的相關研究有失效恢復模型與失效恢復實現兩個方面.

2.3.1 失效恢復模型

失效恢復模型是規劃恢復策略的依據,建模參考因素有失效原因、失效規律、恢復性能等.

LAPRIE 等在云服務可靠性的研究中提出了服務失效原因與恢復策略的分類[43],如表1 所示.其中列舉了7 種服務失效原因,給出了與之對應的重啟、重試、重構、遷移4 種恢復策略.但是該模型沒有給出恢復策略相應的實現方案.

表1 服務失效原因與恢復策略Table 1 Causes of service failure and recovery strategies

2013 年,顧軍等提出了一種失效恢復性能建模分析方法[44].其主要思想是采用排隊Petri 網來描述組合服務失效的發生與處理過程,并基于此模型研究各種失效恢復策略的運行情況.通過不同策略對系統整體性能影響的綜合分析,指導不確定網絡環境下失效恢復策略的實施.

2018 年,齊平等提出了一種基于Weibull 分布的失效規律評估模型[45].Weibull 分布是一種常用于描述失效規律的負超指數分布.基于Weibull 分布的失效規律評估模型對于不同時段資源節點和通信鏈路失效規律的局部特征進行描述,根據并行任務之間存在的各類交互關系分析.2019 年,該模型進行了優化,從負載均衡級別充分考略備選恢復資源的可靠程度[46].實驗結果表示,該模型可以提高云服務的可用性,且只增加了少量額外恢復開銷.

2.3.2 失效恢復實現

失效恢復實現有兩項性能指標：

1）故障恢復時間（recovery time objective，RTO）：從速度上衡量恢復策略的優劣.RTO 值為0 時,故障立即得到恢復,沒有任何中斷；RTO 值為無窮大時,服務故障無法恢復.

2）數據恢復程度（recovery point objective，RPO）：從完整度上衡量恢復策略的優劣.RPO 值為0 時,沒有任何數據丟失.RPO 大于0 時,表示恢復后有數據丟失.

恢復策略的理想模型是RTO=RPO=0,但是實現開銷過大,研究與實踐中通常平衡兩者與系統開銷.針對降低RTO,相關方法是集群技術以及負載均衡；針對降低RPO,相關方法是分布式存儲技術.

2001 年,Alexandre Cassen 為解決Linux 虛擬服務器的配置管理,開發了主流高可用軟件之一Keepalived[47].其中在故障切換方面使用的是虛擬路由冗余協議（virtual route redundancy protocol,VRRP）來實現快速的服務恢復.

傳統故障恢復方法依賴于運行時服務狀態的備份,因此,引入了額外的系統開銷.2021 年,張建華等提出了一種針對優化故障恢復性能的基于隱馬爾可夫模型的失效恢復方法[48].該方法面向虛擬機平臺,引入隱馬爾可夫模型對系統運行時的狀態進行預測分析,判斷系統未來運行狀態的概率趨勢,從而減少狀態備份產生的性能開銷.

隨著容器替代虛擬機作為平臺既服務和軟件既服務層服務載體的趨勢,更多的失效恢復面向容器平臺展開.例如,一種面向容器的高可用性（high availability,HA）方案.該方案的創新貢獻在于引入了容器狀態的檢查點備份機制,通過一組與應用無關的高可用代理構成的中間件將高可用功能添加到系統中,不用強制修改應用代碼.這種方式被稱為高可用無關的集成方式.將此方案運用到視頻應用中的測試表明,故障切換時間隨視頻服務器的數量增加而增加,但RTO 性能優于面向虛擬機的HA 方案.

3 云視頻系統服務高可用方案

云視頻系統的服務包括核心服務和應用服務,核心服務是應用服務的基礎.本章面向管理控制、信令協商、媒體處理3 項核心服務,提出云視頻系統服務高可用方案,在實現核心服務高可用的同時為應用服務高可用提供基礎.

3.1 核心服務架構

本方案現采用服務化架構,后期根據業務規模拓展可重構為微服務架構.管理控制服務、信令協商服務、媒體處理服務3 項核心服務部署在不同的虛擬機服務集群上,分別為管理控制集群、信令協商集群、媒體處理集群.方案中引入了數據庫集群,存儲失效恢復所需的服務狀態數據.整個核心服務軟件架構如圖6 所示.

圖6 云視頻系統服務高可用方案Fig.6 High availability solution of cloud-based video system service

管理控制集群包含兩個主備冗余模式的管控節點,管理控制所有服務并以集群IP 方式提供主備節點的統一入口.數據庫集群包含3 個分布式存儲的節點,同步存儲服務狀態數據.數據讀寫由管理控制集群實施,為服務失效恢復提供高可用、強一致的狀態數據.信令協商集群包含多活冗余模式的N 個節點,提供終端呼叫、媒體協商服務等.媒體處理集群包含多活冗余模式的N 個節點,提供媒體轉發、媒體混流服務等.

以視頻會議應用為例,核心服務的工作流程如下：用戶向管理控制集群發起視頻會議請求；控制管理主節點在監聽端口上獲取會議請求指令,通過負載均衡插件從媒體處理集群中選取若干節點以及若干空閑端口作為本地媒體流接收方；管理控制主節點通過負載均衡插件選取若干信令協商節點,并發送參會終端信息（IP 地址、呼叫端口）和媒體流接收端口；被選取的信令協商節點根據管理控制主節點提供的指令及信息,通過H.323 協議棧發起終端呼叫和媒體協商；信令協商服務將協商獲取的媒體收流端口反饋至管理控制主節點；控制管理節點開啟對應媒體處理節點的端口收流.最終,參會終端與媒體處理節點之間可以進行媒體流收發.

分析上述工作流程可知,核心服務之間存在緊密交互,進而提供云視頻系統的各項功能.因此,云視頻系統高可用方案需分別考慮每一項核心服務的高可用機制.

3.2 管理控制服務高可用

管理控制服務是有狀態服務,請求之間存在依賴關系,因此,服務集群采用主備冗余模式,同一時間只有主節點對外提供服務,另一個節點為備用.選取虛擬路由冗余技術（virtual router redundancy protocol,VRRP）對外提供虛擬IP,終端、信令協商服務、媒體處理服務可通過此統一IP 訪問管理控制服務的主節點,故障切換時無須更改服務入口.主備節點之間需要相互監測健康狀態.主節點發生故障時,備節點在超時閾值Δt 后仍未收到心跳回復信息則準備接替主節點.失效恢復時需遷移業務,從數據庫集群讀取當前主節點任務的服務狀態,然后進行IP 漂移,將集群IP 與備用節點綁定.方案選取開源高可用組件Keepalived,其同時包含VRRP技術和上次心跳方法的心跳監測,監測快速準確且簡單易集成.

3.3 信令協商服務高可用

信令協商服務是無狀態服務,因此該服務集群一般采取雙活或多活冗余模式,同一時間由多個活動節點對外提供服務,保證高可用性和高并發性.信令協商服務的健康狀態由管理控制服務監測,采取拉模式的心跳連接.監測實現采用基于超文本傳輸協議（hyper text transfer protocol,HTTP）的平均心跳方法.HTTP 協議中自帶超時監測機制,但是監測頻率固化,方案中引入平均心跳方法可以提升超時檢測的準確性,使超時閾值Δt 動態適應網絡變化.

信令協商服務故障時,管理控制節點根據故障原因,選擇重試策略或遷移策略,兩種策略的狀態恢復數據起點不一樣,將會影響RTO 與RPO.例如,一類故障是發生在信令協商的過程中,終端還未進入收發流,此時大多采用重試策略,仍在原有的信令協商節點上重試呼叫或協商,RPO 較小.還有一類故障發生在終端參與媒體會話過程中,信令協商服務如果采用重試策略其RPO 可能會高于遷移策略.

3.4 媒體處理服務高可用

媒體處理服務也屬于無狀態服務,其任務數量和節點數量更多,冗余模式一般采用多活模式.另外,針對實時視頻通信的特點,故障恢復期間不需要重傳丟失的視頻數據,管理控制服務僅提供給媒體處理服務若干媒體會話相關的服務狀動態適應網絡變化態.

綜合上述3 項核心服務高可用機制所形成的云視頻系統服務高可用方案可以應對節點宕機、離線等服務失效.其參考了主流服務高可用技術和業界用例,具有理論依據.在監測和恢復方面結合了視頻業務特性,并引入數據庫集群存儲狀態數據,具有創新特點.

4 指揮控制領域應用展望

云視頻系統已經邁入高速發展階段,不斷滿足超高業務吞吐量、超高連接數并發、超高可用性等服務需求,同時與工業、交通、軍事等場景深度融合,賦能可視化、信息化指揮控制領域應用.本章展望了云視頻系統服務高可用技術在態勢感知和虛擬戰場中的應用前景,并探討了面對復雜的網絡安全環境時存在的問題與挑戰.

態勢感知.未來,云視頻系統可應用于態勢感知,有效發揮其高可用、動態、快速的態勢數據傳輸、流轉服務能力.戰場態勢感知的處理過程分為覺察、理解和預測3 個層次[49],依賴于陸、海、空、天多維空間中的傳感器設備[50],其部署場景計算能力弱、網絡環境復雜.服務高可用技術將是云視頻系統作用于態勢感知的關鍵.其可監測傳感器網絡的完整性,保證態勢數據傳輸服務穩定連續,避免服務超載和服務失效等故障.除傳統傳感器設備以外,云機器人圖像采集設備將作為態勢感知的新型終端[51].云端需實現高可用的計算服務、媒體分發服務,進而為瞬息萬變的戰場態勢感知提供可靠媒體服務保障.

虛擬戰場.云視頻系統為虛擬現實（virtual reality,VR）設備提供廣泛接入,高效可靠地處理設備所產生的大量視頻數據,再將預測處理后的結果反饋到終端設備.虛擬戰場是VR 技術在軍事斗爭準備中的應用,具有現實符合性和未來預判性[52].VR 設備對時延要求極高,因此,服務高可用性非常關鍵,能夠快速響應故障并從中恢復服務能力,將影響虛擬戰場指戰員的穿戴體驗和戰場模擬的有效性.未來,云視頻系統故障恢復RTO 需降低至毫秒級以適配虛擬戰場的時延要求.依托服務高可用技術,云視頻系統大量豐富多樣的媒體應用服務有了完備的容災備份機制.虛擬戰場得以持續可靠地提供一個多感官模擬的三維世界,提升指戰員使用體驗.

面向異構復雜的指揮控制環境,還必須將服務可用性和服務安全性合并考量.當前,云視頻系統使得海量高清多媒體數據得以實時交互,提高了指揮控制系統的信息共享能力.然而,隨著云平臺、5G 等技術的融入,勢必在提高通信效能的同時引入新的網絡安全風險因素[53-54].與其他系統不同之處在于,云視頻系統為保證服務高可用,必須設置冗余的備份,可能成為敵方網絡安全攻擊的對象.從網絡安全機制對服務高可用性的影響角度來看,信道加密、信源加密、用戶身份認證鑒權等安全手段因其復雜性或將影響服務故障切換速率.總的來說,對于云視頻這類交互信息量廣且意深的系統而言,網絡安全機制和服務高可用機制之間存在著平衡做法而非矛盾關系,在今后的研究中可以協同發展.

5 結論

云視頻系統在服務高可用性上獲得了長足進步,尤其是在縮短故障響應時間和優化失效恢復策略方面有顯著提高,增加了其在指揮控制領域應用的廣度和深度.同時,云視頻服務高可用也面臨占用額外系統資源、產生巨大性能開銷等問題挑戰.本文從提出云視頻系統服務高可用需求出發,梳理了服務高可用相關的軟件架構演進、故障檢測及失效恢復技術發展,并總結分析各類方法的優缺點.合理指出應權衡監測開銷與準確性、恢復開銷與完整性之間的矛盾.文中結合云視頻系統的服務特點,提出了一種創新、可行的云視頻系統服務高可用方案,并展望了服務高可用的云視頻系統在指揮控制領域中的應用,闡述分析了其與網絡安全之間的問題.以期為讀者了解主流服務高可用技術,設計服務高可用的云視頻系統,構想服務高可用云視頻系統在指揮控制領域中的前景提供幫助.