视频分析服务器系统架构,视频管理软件技术分析报告(四)--基于SOA的VMS软件架构设计...

设备管理服务(包含设备IO服务)：是ONVIF中定义的核心服务，对设备进行设备参数，设备状态等信息的管理和配置。通过设备管理服务能够获取其它服务的地址。

媒体服务：提供对媒体设备相关元数据(视频源、视频参数等)的配置查询功能。使用媒体服务能够获取视频流的相关参数。

设备操控服务：ONVIF中主要提供了PTZ服务，用于完成对采集摄像设备的操控。

录像服务：主要包括录像控制和录像查询服务。

录像回放服务：主要定义了录像回放的相关参数的查询与配置。

门禁服务：定义了门禁控制的相关操作。

视频分析服务：定义了视频分析的基础模型与相关服务接口。

流服务：定义视音频媒体、元数据流的控制协议，传输协议和交换方式。

参考图 2与ONVIF的服务模型，遵循第1节介绍的设计原则和思路，以视频流的流动路径为方向，相关的服务边界与互操作关系可如图 3所示。

图 3中，任务服务层与实体服务层定义的主要服务描述如下：

设备接入(发现与注册)：实现物理设备的发现与注册，使用与物理设备兼容的协议(方式)实现与物理设备的直接互联，是物理设备的实际操作者。

设备管理：实现设备参数及其它系统数据的配置和查询，与设备接入服务是双向互操作的关系。

媒体配置：用于实现对于媒体设备(如摄像机与DVR)的媒体相关参数的配置与查询，与设备管理服务是双向互操作关系。

实时媒体流会话控制：实现与媒体设备的媒体会话控制，获取媒体设备的实时媒体流数据并实现分发。媒体流会话控制服务在使用时会调用媒体配置和设备管理服务以获取相关参数。

录像：实现根据媒体流进行录像的功能。录像服务可根据录像计划进行录像，也可根据用户操作进行随机录像，同时录像服务也提供录像查询功能。录像服务需要调用媒体配置和设备管理服务获取相关参数，调用媒体流会话控制服务获取媒体流。

实时流浏览：提供实时监控功能，需要调用媒体流会话控制服务获取实时媒体流。

录像回放：录像回放服务可调用录像服务查询录像信息，并直接访问录像存储介质获取待回放的录像数据。

PTZ控制：PTZ控制服务调用设备管理服务(通过设备接入服务)向监控设备发送PTZ指令实现用户的PTZ控制。

门禁控制：门禁控制调用设备管理服务(通过设备接入服务)向门径设备发送门禁控制指令实现用户对门禁的控制。

视频分析：视频分析服务实现对实时媒体流会话控制服务和录像服务的调用，采集实时流或录像数据进行视频分析。

图 4显示了服务架构中视频流的流向以及服务与物理设备的关联关系，其中带红色箭头的粗线表示视频流，蓝色虚线表示与物理设备的关联关系。

图 4中，设备接入服务与接入的物理设备直接打交道，使用物理设备所提供的传输交换协议。鉴于物理设备接入协议的多样化(如SNMP，SIP,SOAP等)，建议对于不同的接入协议定义不同的子接入服务，设备接入服务可根据设备可接入的类型确定所调用的子接入服务实例。

同设备接入服务一样，实时媒体流会话控制服务与请求媒体流的物理设备通过物理设备支持的媒体会话协议进行交互。不同的设备支持的媒体会话协议可能不同(如SIP,RTSP等)，建议对于不同的媒体会话协议定义不同的子会话控制服务， 实时媒体流会话控制服务根据请求设备支持的媒体会话协议选择该调用的子会话控制服务。

VMS服务架构中服务之间的互操作可使用服务操作原语来定义，如第3节所描述。

3. 服务操作原语

VMS中，将视频流，录像，设备参数，设备等视为不同的逻辑实体对象，系统功能即可视为对这些实体对象的操作。借鉴在电信管理网中使用的CMIP (Common Management Information Protocol，通用管理信息协议)所支持的CMIS服务，我们可在VMS中定义六种抽象出来的服务操作原语：

VM-CREATE：创建相关的逻辑实体对象，如视频流，媒体配置实体，安全逻辑实体(如keystore)，网络接口，录像文件等对象。

VM-CREATE：删除已经创建的逻辑实体对象，如视频流，媒体配置实体，安全逻辑实体(如keystore)等对象。

VM-GET：获取逻辑实体对象的相关参数与属性。

VM-SET：设置逻辑实体对象的相关参数与属性。

VM-ACTION：执行逻辑实体对象可执行的一个动作，如进行媒体会话，进行解码动作等。

VM-EVENT-REPORT:服务实例在运行过程中发送被触发的事件消息。

4. 实施策略

自martin fowler发表了那篇著名的微服务博客文章之后，微服务架构在近几年间在软件界着实火了一把，在国内软件界似乎出现了一种不谈微服务的软件架构设计就不够高大上的现象。其实仔细剖析微服务的模式，我个人更认为微服务是SOA在实现层次的细化和扩充。微服务在分解服务为更细粒度时，同时也为分解的服务间关系带来更多的复杂性。因此在使用面向服务的思路来实施VMS时也要根据实际场景和规模来选择合适的方案。

4.1 服务要多大

在前面的软件架构中，设备接入，实时媒体流会话控制服务，录像服务这三个系统中的核心服务在部署上，每个服务建议设计为服务集群(最简单的方式是在一堆服务实例前加一个负载均衡器)，可根据项目的实际规模进行配置伸缩。

4.2 数据如何存储

VMS中，我将数据分为控制面数据与媒体数据，视频流这些媒体数据在规模大时可考虑选型如HDFS这样的开源分布式存储系统，在规模小时可使用单独的磁阵即可。

对于控制面的数据，如设备信息，媒体配置信息等数据，由于会被多个服务实例访问，可考虑使用ElasticSearch, etcd这样分布式协同系统。

4.3 服务原语的实现形式

VMS中，我建议服务原语以Rest Api的形式定义，这样在服务实例之间基于HTTP的restful接口就可实现服务原语在服务间的互操作(比如使用spring cloud作为服务实现框架)。

4.4 如何选择消息服务器

同样，消息服务器根据项目的规模来确定，在系统规模较小的场景下，使用轻量级的消息服务器(如使用redis就可以)，系统规模较大的场景下，可以考虑kafka这样的消息集群服务。

4.5 如何选择流媒体中间件

VMS中涉及到RTSP,SDP，SIP，RTP/RTCP等多种流媒体相关协议，幸运的是，现在github上各种语言的流媒体中间件都可以找到，如果实在要我推荐，在我用过的产品中，我觉得gstreamer就很好。

4.6 基于Web的视频浏览

传统的VMS中，在浏览器中对视频进行浏览需要借助自己编写的控件，随着WebRTC技术的出现，主流浏览器已经逐步支持WebRTC的规范，因而使用WebRTC实现免插件的视频浏览成为可能。需要注意，目前浏览器的支持视频编码格式有限，在服务端可能要转码，另外也需要构建WebRTC的服务端作为视频源。