视频管理软件技术分析报告(四)–基于SOA的VMS软件架构设计

  VMS系统的开放性和扩展性特性非常适合使用SOA（面向服务的架构）方法来进行设计。
  服务作为物理上独立无关的软件程序而存在，每个服务被赋予其自身独特的功能上下文环境，并由一系列与该环境相关的能力所组成。服务提供的能力通过服务接口（服务合约）来表达。
  根据服务的可复用性，可编排性，可自治，可组合性等特点，在设计服务时宜使用自顶向下的设计思路，在设计模型时可先设计顶层的服务，确定顶层的服务边界后，再逐层设计下层的子服务。
  在服务类型上，宜将服务分为实体服务，任务服务，工具服务三种类型 。
  VMS中涉及到媒体、元数据、系统管理数据（用户，权限）等实体的服务可归类为实体服务；媒体会话，任务调度之类与控制器相关的服务可归类于任务服务；网络传输，安全加密，日志等基础服务可归类于工具服务。
  使用实体服务，任务服务，工具服务三种服务模型可构建逻辑服务抽象层，如图 1所示。
  使用SOA进行VMS的设计应首先聚焦于视频监控系统的业务。以视频数据为核心，一个视频监控系统的基础结构如图 2所示：

  ONVIF作为基于Web service技术标准制定的安防设备开放操作接口，囊括了图 2中包含的所有功能。其服务设计思想可作为VMS设计时的参考。
  分析一下ONVIF定义的服务，可归为如下几类：  VMS中，将视频流，录像，设备参数，设备等视为不同的逻辑实体对象，系统功能即可视为对这些实体对象的操作。借鉴在电信管理网中使用的CMIP (Common Management Information Protocol，通用管理信息协议)所支持的CMIS服务，我们可在VMS中定义六种抽象出来的服务操作原语：  自martin fowler发表了那篇著名的微服务博客文章之后，微服务架构在近几年间在软件界着实火了一把，在国内软件界似乎出现了一种不谈微服务的软件架构设计就不够高大上的现象。其实仔细剖析微服务的模式，我个人更认为微服务是SOA在实现层次的细化和扩充。微服务在分解服务为更细粒度时，同时也为分解的服务间关系带来更多的复杂性。因此在使用面向服务的思路来实施VMS时也要根据实际场景和规模来选择合适的方案。  在前面的软件架构中，设备接入，实时媒体流会话控制服务，录像服务这三个系统中的核心服务在部署上，每个服务建议设计为服务集群（最简单的方式是在一堆服务实例前加一个负载均衡器），可根据项目的实际规模进行配置伸缩。  VMS中，我将数据分为控制面数据与媒体数据，视频流这些媒体数据在规模大时可考虑选型如HDFS这样的开源分布式存储系统，在规模小时可使用单独的磁阵即可。
  对于控制面的数据，如设备信息，媒体配置信息等数据，由于会被多个服务实例访问，可考虑使用ElasticSearch, etcd这样分布式协同系统。  VMS中，我建议服务原语以Rest Api的形式定义，这样在服务实例之间基于HTTP的restful接口就可实现服务原语在服务间的互操作（比如使用spring cloud作为服务实现框架）。  同样，消息服务器根据项目的规模来确定，在系统规模较小的场景下，使用轻量级的消息服务器（如使用redis就可以），系统规模较大的场景下，可以考虑kafka这样的消息集群服务。  VMS中涉及到RTSP,SDP，SIP，RTP/RTCP等多种流媒体相关协议，幸运的是，现在github上各种语言的流媒体中间件都可以找到，如果实在要我推荐，在我用过的产品中，我觉得gstreamer就很好。  传统的VMS中，在浏览器中对视频进行浏览需要借助自己编写的控件，随着WebRTC技术的出现，主流浏览器已经逐步支持WebRTC的规范，因而使用WebRT开发云主机域名C实现免插件的视频浏览成为可能。需要注意，目前浏览器的支持视频编码格式有限，在服务端可能要转码，另外也需要构建WebRTC的服务端作为视频源。

相关推荐: Selenium IDE DOM元素选择定位器

资源推荐：社区资源：自动化测试交流群 DOM（Document ObjectModel）代表整个HTML文档，并且可以通过使用javascript进行访问，通过该定位策略将javascript结果计算为一个页面中的元素。代码示例如下：”loginForm”&g…