云视频系统服务高可用技术

徐 艳 谢永强 李忠博 齐 锦 李少南

视频技术的飞速发展满足了人们日益增长的可视化通信需求[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 结论

云视频系统在服务高可用性上获得了长足进步,尤其是在缩短故障响应时间和优化失效恢复策略方面有显著提高,增加了其在指挥控制领域应用的广度和深度.同时,云视频服务高可用也面临占用额外系统资源、产生巨大性能开销等问题挑战.本文从提出云视频系统服务高可用需求出发,梳理了服务高可用相关的软件架构演进、故障检测及失效恢复技术发展,并总结分析各类方法的优缺点.合理指出应权衡监测开销与准确性、恢复开销与完整性之间的矛盾.文中结合云视频系统的服务特点,提出了一种创新、可行的云视频系统服务高可用方案,并展望了服务高可用的云视频系统在指挥控制领域中的应用,阐述分析了其与网络安全之间的问题.以期为读者了解主流服务高可用技术,设计服务高可用的云视频系统,构想服务高可用云视频系统在指挥控制领域中的前景提供帮助.