基于云原生的视频管理系统设计与实现

张 咪，刘 文，郭 庆

（中国航空工业集团公司西安航空计算技术研究所，西安 710065）

0 引言

由于传统的面向服务的架构（Service Oriented Architecture，SOA）或单体应用无法支撑数据爆发式增长和业务的快速迭代，近年来基于云原生的系统构建，凭借其高资源利用率、高可扩展、独立部署、快速迭代的独特优势，已成为一种新趋势。

本文基于云原生和微服务架构思想设计并实现了一套视频管理系统，该系统能够实时采集与处理持续产生的监控视频数据，并提取视频关键帧作为视频摘要，根据图片与视频摘要的相似度比对实现视频图像内容检索。基于微服务框架、容器化的实现方案，使该系统具有高扩展性。微服务拆分综合考虑业务、可扩展性、性能、稳定性4个要素，使得服务架构清晰，可助力实现服务的快速更改与部署，从而应对动态多变的业务需求，顺应企业数字化变革的大趋势。

1 相关研究

1.1 云原生概述

Pivotal 公司提出云原生是一个思想集合，其目的是帮助企业快速、持续、可靠、规模化地交付业务软件。云原生以弹性可扩展、高可用性、高灵活、强兼容和低成本的方式将云的价值最大化，满足经济社会“智能化”和“云化”转型的新要求［1］。

云原生给企业带来了软件过程应用架构和基础设施的变革［2-3］。其具备容器化封装、动态管理及面向微服务三大特征［4］，同时借助容器化、微服务、服务网格、不可变基础设施等相关技术，能够构建高容错、易管理和便于观察的松耦合系统。云原生应用设计之初即考虑到充分利用云资源的优势，故其天然具备云平台的弹性、分布式、负载均衡等优点，同时借助微服务、Devops（Development 与Operations 的组合词）、容器化、可持续部署等关键技术手段，可降低开发复杂度、简化研发流程，实现业务的敏捷迭代、可持续交付及智能运维。

1.2 微服务架构

微服务最早是由MFlow 和JLewis 于2011 年提出的一种新的软件架构风格，也是面向服务软件开发的新趋势［5］。其旨在从业务角度将复杂的系统划分成职责明确的一组服务，各服务专注于完成单一的业务功能，以更灵活、轻量级的模式进行独立设计开发与部署，形成服务高度内聚自治［6］。

相比于传统应用架构，微服务具有以下优势：①技术栈解耦可采用不同技术开发，便于接纳与引入新技术；②单个服务体量小，可降低上下文理解难度及研发难度；③容错性高，问题波及范围局限在服务内，可减少对系统的影响；④各服务可独立部署扩展及定制运维方案。

微服务架构强调服务自治及松耦合，将单体应用拆分成一组职责明确的微服务，服务间通过轻量级交互机制进行通信。微服务架构结合Devops 研发工具链，能够轻松实现系统变更、部署和智能运维［7］。

2 视频管理系统设计

2.1 系统概述

传统视频存储方式如本地存储、直连存储、网络附属存储（Network Attached Storage，NAS）、磁盘挂载［8-9］等存在由于空间不足导致视频质量差、采集信息匮乏等问题［10］。综合现状及云平台的优势，本文提出基于云原生的视频管理系统。

基于云原生的视频管理系统主要用于政企内部音视频等文件管理，可帮助企业存储及管理内部视频数据。该系统功能模块如图1 所示，包括视频上传、视频检索、视频处理、视频浏览下载、用户权限管理等功能。

视频管理系统提供上传接口供企业通过各渠道将视频上传至平台，同时获取并存储视频相关属性。视频上传成功后，异步提取视频关键帧作为封面。视频检索相对于其他检索的特点在于无法直接获取视频语义。为此，本系统提供两个维度进行检索：①根据视频属性检索：通过视频采集时间、渠道、类型等属性进行组合检索，以解决视频信息不完整导致难以检索的问题［11］；②根据图片检索：根据搜索图片与已提取的视频关键帧进行相似度检索。同时该系统还包括其他基础模块，如用户权限管理模块，可对用户的登录、浏览、下载等功能权限进行管理；视频管理模块，主要包括视频发布、下线、删除、编辑等功能。

Fig.1 System function module图1 系统功能模块

2.2 微服务拆分

服务拆分是微服务架构设计的重要环节，其合理性将直接影响到服务开发、测试、部署的复杂度。因角度不同，微服务拆分方法各异，文献［12］提出基于聚类的服务拆分，服务职责清晰，但不具备普适性，且聚类参数难以确定。文献［13］提出数据流驱动的微服务划分，其建立在运行数据的基础上，只适用于老系统向微服务迁移。虽然服务拆分途径各异，但归根结底仍需从业务出发，在理解业务的基础上，按照职责单一原则确定微服务的边界上下文和功能域［14］。

本文以业务功能为主，综合可靠性、稳定性和性能进行微服务设计，对可靠性与性能要求高的模块及业务变动频繁的模块单独进行微服务。综合以上因素，本文系统共分为6 个微服务：①用户权限服务：负责用户身份校验及访问权限设置。该模块业务独立，对性能要求较低，但对可靠性和稳定性要求较高；②视频维护服务：具体包括视频发布、下线、删除、属性编辑等，该模块对于可靠性、稳定性与性能的要求都较低；③视频封面提取服务：提取视频关键帧作为视频封面，对性能要求高，对可靠性与稳定性要求低；④视频上传服务：存储各渠道采集的视频实体及其属性，对稳定性、可靠性、性能的要求都较高，故单独为其提供一个微服务；⑤视频展示与检索服务：展示与检索业务关联密切，对稳定性、可靠性及性能要求都较高；⑥视频下载浏览服务：代码及业务耦合率高，且都对性能要求较高。

2.3 微服务通信协作

用户请求通常需要多个微服务共同协作，这就依赖于服务间的轻量级通信。同步调用和异步调用是服务通信的两种方式［15］。针对实时响应的请求，采用基于超文本传输协议（Hyper Text Transfer Protocol，HTTP）的REST API（Representational State Transfer）进行同步通信，针对耗时、易阻塞的请求，采用基于消息队列的方法进行异步调用，实现轻量级通信。

本系统中多数请求需要实时响应，比如视频检索、发布、上线、编辑等需要用户保持等待状态，直至结果返回，对于此类请求采取同步通信。对于视频封面提取和视频下载，此类请求通常处理时间长，且无需一直保持等待状态，因此采用消息队列实现异步通信。基于消息队列的异步通信具备“消峰效应”，能够降低系统高并发时需要较长时间处理请求给服务器带来的压力。

3 视频管理系统技术架构

本系统采用Vue+SpringBoot+FastDFS（分布式文件系统）框架，针对数据特点分别选用结构化和非结构化数据库存储视频属性及视频实体。采用基于内容的视频帧提取技术获取视频关键帧作为视频封面，以支持根据图像检索视频。该系统架构共分为4 层，分别为：应用层、服务层、基础服务层、数据层，如图2 所示。

Fig.2 Technical architecture of video management system图2 视频管理系统技术架构

应用层采用前后端分离的模式，前端采用Vue js 和element-ui 实现，后端使用springboot 的Restful 注解方式对API 请求进行接收。前端与后端之间使用Nginx 进行负载均衡，并分发请求。后端接收前端请求后，根据业务处理需求调用不同微服务，完成业务的逻辑处理。

服务层由一组相互独立的微服务组成，可处理来自应用层的请求，各服务数据库相互独立。服务间通过接口进行同步或异步通信。服务部署并运行在docker 容器上，服务启动快，且易横向扩展，能够灵活应对请求突增。结合Devops工具链，可实现持续集成和灰度发布。

基础服务层采用Dubbo（开源分布式服务框架）+zookeeper（分布式应用程序协调服务）进行服务治理和负载均衡，配置管理平台对各微服务配置进行统一管理。注册中心管理微服务的注册、预定及服务调用，通过ELK 日志管理可实现智能运维。

数据层主要选取FastDFS、MySQL 和Redis 3 种数据库。FastDFS 数据库存储视频实体本身，其自身具备线性扩展与负载均衡能力；MySQL 数据库存储视频基本属性、用户数据等其他结构化数据，同时关联FastDFS 文件实体；Redis 数据库用于缓存用户权限等信息。本文架构根据实体数据特点，选取不同数据库进行存储，从而保障存储、检索的高效性与可靠性。

4 视频管理系统实现

4.1 核心模块实现

视频上传模块为视频管理系统的核心模块，对稳定性和可靠性要求较高，需要保障文件包不丢失且完整。本文采用分布式存储数据库FastDFS 实现视频文件分布式存储，具体实现步骤如下：

（1）通过Maven 管理包目录。通过添加pom 依赖包，引入FastDFS jar 包。

（2）配置上传默认属性。设置默认切片大小，当原始文件大于默认切片时，按照默认文件大小对原始文件进行切片上传。同时还需设置超时时间、日志存放地点、最大链接数等其他默认属性。

（3）断点续传。针对大文件，本文采取文件切片和断点续传策略。将较大文件切片后再上传，防止因网络原因造成的文件破坏。具体实现代码如下：

4.2 微服务通信与集成

本文采用Dubbo 框架实现服务注册与发现，并进行服务管理。Dubbo框架通过生产者、消费者、注册中心实现服务的注册、管理和发布。其中，服务注册中心用于服务注册以及服务事件发布与订阅。生产者将服务接口暴露给注册中心，供其他微服务调用。消费者通过consumer.xml配置文件引入已发布接口后，即可使用。实现步骤如下：

（1）导入Dubbo Jar 包。对于需要暴露的微服务接口，在provider.xml 文件中配置声明，暴露给服务注册中心，具体实现代码如下：

（2）引用接口。对于已在注册中心发布的接口，在所需消费的应用中通过consumer.xml文件引入接口。具体引用过程相关代码如下：

4.3 性能测试

文件上传模块也是视频管理系统的核心模块，本文对文件上传模块进行性能测试。设置并发线程20 个，选取4个不同大小的文件触发文件上传，测试结果如表1 所示，文件全部上传成功。选取表1 中上传成功的文件，下载后进行检验，文件可正常打开，且上传和下载后的文件内容均未发生变化。

Table 1 Upload results of stress test video表1 压力测试视频上传结果

将本文应用分别部署在容器（K8S+docker）和虚拟机（6 核+128G）上，对应用的部署及重启性能进行测试。容器与虚拟机部署性能对比如表2 所示，应用部署在容器上的重启时间、占用存储、可扩展性均优于部署在虚拟机上。

Table 2 Performance comparison of container and virtual machine deployment表2 容器与虚拟机部署性能对比

综上，微服务架构使得系统能够灵活应对企业业务扩充及各种变化，避免了由于存储空间问题造成的视频质量差、视频采集数据丢失等问题。同时，容器部署占用存储少、易扩展，服务重启速度达到秒级，可令用户无感知地进行节点扩充及版本上线。

5 结语

本文介绍了一套基于云原生的视频管理系统，通过松耦合的微服务架构、轻量级通信使得系统架构清晰、职责明确，减小了单个服务故障对系统的影响范围。基于云原生、微服务与容器部署的系统，支持根据负载均衡策略随时调整节点个数，以应对请求陡增，防止服务崩溃，给企业数字化转型工具变革提供了新思路。