一种数字化综合安防系统的设计与实现

朱望纯， 张 乐

(桂林电子科技大学 电子工程与自动化学院，广西 桂林 541004)

近几年政府与行业机构颁布若干安防领域的相关政策与规范，表明安防建设已经上升为国家战略发展目标之一，具有十分重要的意义。在《中国安防行业“十三五”发展规划》中提到我国安防行业未来几年发展目标，目标明确指出安防系统建设向高效协同互联与多领域融合方向转变，证明我国的安防体系正从单一、分散的传统模式架构转向数字化、综合化、智能化的方向发展[1]。同时安防系统已经不再是仅局限于军工、民航、政府等特殊领域，已逐步融合至教育、金融、民用安全等多个领域。因此，开发数字化综合安防系统对相关领域部门及社会各界具有积极的影响，其未来具有广阔的发展前景与空间。

在安防领域综合安防系统方面的研究已经积累了一些成果。文献[2]根据国内轨道城市安防需求，设计与实现了一套综合安防系统解决方案，对系统的总体架构、管理模式、关键技术和运营等方面进行了详细阐述与讨论，并对未来轨道城市建设中的综合安防系统发展方向进行了展望；文献[3]介绍了一种应用于军区岛礁等特殊环境的综合安防系统，分析与研究了SOA体系下的安防系统架构设计思路，用于解决军区特殊环境下安全与信息管理等问题；文献[4]通过建立系统可靠性框图模型对安防系统可靠性进行评估；文献[5]提出一种基于物元分析的安防系统可靠性评估方法，对安防系统可靠性进行了量化评估分析。

本研究介绍了一种数字化综合安防系统，并对系统关键设计要点进行研究与讨论，该系统由监控软件、通信网络、系统服务集群、前端监控设备组成，主要功能包含视频监控、周界防护、消防管理、门禁控制、网络对讲、电子巡更6个安防模块，用户可通过以上安防功能对目标进行多角度、多层级的全方位监控。可设置系统警情触发条件、范围、触发优先级等参数，当无人值守时系统各部分安防模块可协同工作，当发生异常情况时模块间可进行协同联动工作，对警情进行实时处理并通知相关技术人员情况。针对系统关键设计要点，对系统总体架构、服务设计、消息传输与组件化机制3个设计要点进行介绍。系统架构总体分为4层，分别为应用服务层、系统业务层、系统数据层、基础支撑层。划分层级的意义在于明确功能与模块业务边界使系统具有良好的扩展性，降低逻辑之间的耦合度，同时便于未来的维护与升级。考虑到模块间的实时高效通信问题，同时为了进一步增强系统的可扩展性，系统实现了消息传输与组件化机制，主要由消息队列、负载均衡、消息路由、模块加载器4部分构成，系统引入消息传输机制提高了服务时效降低系统整体负载，新增资料与模块亦可通过组件化机制实现快速上线扩展，有效提升系统可扩展性和适应能力。针对性能问题对系统服务进行拆分，并引入服务发现、服务注册、服务检测机制对系统服务集群进行统一维护与管理，确保系统在高负载情况下提高容错率保持良好响应。服务拆分将系统关键服务拆分为中心管理服务、监控服务、流媒体服务、数据服务四大服务，每个服务部分可以单独部署、维护与升级，系统可形成服务集群提供高质量稳定服务。服务注册机制采用动态配置对系统各服务进行注册管理，避免了传统静态部署带来的后续可维护性问题，服务发现机制提供了一种服务协调机制，确保安防各子服务能够彼此发现保证系统服务的可靠性，服务检测机制负责服务集群整体状态管理与维护，实现系统平稳高效运行。系统通过以上优化设计实现对目标全方位监控功能，同时较好地提升了整体服务质量与访问性能，具有较高的可靠性与稳定性，可适应日益增长的业务需求。

1 系统总体架构

数字化综合安防系统总体架构是系统业务构成，由宏观至微观的条理化描述，架构层级由上至下分别为系统服务层、系统业务层、系统数据层和基础支撑层。架构设计降低系统整体复杂度与模块之间耦合度，确保系统整体的可扩展性与后期可维护性。

数字化综合安防系统总体架构如图1所示。应用服务层直接面向用户提供系统功能并简化操作逻辑。系统不仅可以提供基本安防功能，还可根据需要定制与配置系统，利用设备部署功能对设备进行添加、删除、分组等操作，实现动态化部署，达到最大化适应现场环境的目的；考虑到现场可能存在原先部署的系统，通过第三方接入功能实现新老系统的对接与融合，以充分利用现有资源；根据部署规模的不同，系统提供tcp、http、rpc、socket等多种通信方式以适应需要；为提升目标区域的安全性，通过系统配置安防模块联动规则，警情触发条件、范围、优先级等属性实现多层次的集中监控。

图1 系统总体架构

系统业务层是整个系统业务规则、逻辑和函数的集合，主要包括监控子系统和系统服务两大部分。监控子系统提供安防相关业务逻辑支撑，同时对模块功能、设备接口进行统一描述，保证层级无差异调用。系统服务包含系统关键部分，消息服务负责组件与应用之间通信，保证消息可靠传输。消息服务是整个系统的消息中心，系统其它服务与组件依赖此机制进行信息的交互；文件存储提供集中统一式文件管理与存储服务；多级缓存和负载均衡消除不同模块设备之间I/O速率差异并消除负载尖峰，防止突发流量对系统的冲击；日志记录服务供开发人员分析系统总体运行情况；设备检测服务通过心跳检测等方式检测前端监控设备状态，对系统各子服务进行实时监控与检测，保证其正常运行与自动化管理，当发生突发情况时，能够自我恢复，实现系统平稳正常运行。当设备发生异常时，进行切换、告警等操作，保证监控功能的持续性。

系统数据层主要提供数据存储、提取、传输等功能，系统数据主要包括监控数据和系统数据2个部分。考虑到对数据实时性访问与安全性等方面需求，具体表现在实际生产环境中，单数据库同时承担所有数据操作未能满足实际生产需求，尤其是针对监控系统这种数据高并发，且存在大量读写请求的场合，因此引入数据读写分离与主从备份方案。当数据请求到达数据层时，首先会经过数据路由分类将请求打散至不同数据库，防止大量请求对同一个数据库的冲击。同时根据数据特征将数据分类至不同数据库，并对不同数据库进行特定优化，例如针对读操作数据库建立全局索引、联合索引等机制强化查询与读取能力，针对写操作数据库进行分库分表、限制并发连接、实行小事务等机制，减少由写等后续操作带来的延迟。为防止不可控因素对数据的破坏，使用主从备份的方式对数据库进行热备份，从部署规模考虑，可采用双机热备或多级热备，考虑到数据量问题，如果数据规模一般，可使用全量备份对数据进行完全拷贝，对于大数据可使用增量备份即记录binlog日志文件，通过日志文件恢复目标数据。

基础支撑层是整个系统运行的基础，包括操作系统、网络链路、监控设备等软硬件基础设施。

2 系统服务设计

系统服务设计针对业务需求及其领域，按照业务边界和拆分原则，对系统服务进行拆分与设计，利用服务注册、服务发现与服务检测机制，对服务集群进行维护与管理。

2.1 服务拆分与设计

为避免集中服务所带来的计算与I/O瓶颈，根据服务拆分原则将系统拆分为中心管理服务、监控服务、流媒体服务、数据库服务四大服务，每项服务可部署在独立的服务器中，最终系统形成集群，提供高质量服务。

为确保系统各子服务能够稳定高效运行，对服务进行合理部署，系统服务部署图如图2所示。

图2 系统服务部署

系统服务部署整体分为3个部分。首先，客户端部署接入系统安防网络实现服务访问；其次，各系统服务进行部署实现安防业务逻辑，考虑到安全性服务部署对外不直接暴露接口，通过安防网络核心交换机或代理服务实现访问与数据交换；最后，安防设备进行部署，设备网络与系统服务进行交互。

图3 系统服务架构

系统服务根据原则拆分为多个系统子服务，系统服务架构图如图3所示。中心管理服务在整个系统体系架构中扮演核心角色。根据服务部署位置考虑，用户的请求首先会经过核心交换机与中心管理服务器，因此承担了认证、鉴权、管理、配置、流量审计等管理工作。在实际部署中，可架设Nginx服务器作为前置堡垒机，对流量进行初步筛选与分发，之后流量到达中心服务器，利用Apache Shiro框架进行认证，并根据配置对其相应操作合法性进行审查与授权。从系统服务治理角度考虑，中心管理服务担任各个节点的管理与监控任务，当节点发生故障时，中心管理服务对相应系统服务节点进行降级或启用备用方案，防止大量请求积压造成I/O高负载引发的响应迟缓或无响应[6]。

监控服务承担系统业务逻辑处理工作，主要包括解析其他服务的指令并操作与控制设备、适配不同种类的安防子系统等工作，提供统一服务接口以供调用，提供高可用的通信机制以实现高效信息交换与信令交换等。监控服务器设计总体从标准化与性能双方面考虑，首先实现标准化，包括规范数据、规范服务接口、配置标准化3个部分。规范数据作用在于屏蔽各厂家之间协议与数据结构之间的差异与不合理的设计，实现异构数据与协议的统一，同时为存储、数据共享、服务接口设计、消息中间件等关键组件的设计打下基础。规范服务接口制定服务接口提供服务规范，统一业务参数、返回类型、异常类型等结构，避免因结构带来的兼容性与测试方面的困难，方便服务扩展、维护与修改。配置标准化目的在于统一配置方式与使用流程，一方面减少开发与维护压力，另一方面减少用户因不同厂家设备带来的学习成本。监控性能方面从系统计算并发和数据并发两个角度考虑。处理计算并发可以利用分治策略解决，将任务分解为若干小任务，分而治之，最后合并得到结果，同时考虑将某些任务绑定至处理器某核心，以减少处理器上下文切换所带来的损耗；解决数据并发针对系统内部逻辑涉及到锁操作时避免全局锁等大事务操作，多次小事务与异步操作可有效减少锁阻塞带来的迟滞处理等问题。

流媒体服务可直接对接网络视频监控设备进行分发推流，同时支持嵌入式和其他非网络与底层设备。利用RTP、RTSP、RTMP等流媒体协议将视频流在网络中传输，实现实时播放、点播回放、录播等多媒体功能，同时可利用服务器后台进行信息统计，发现情况可迅速定位位置，进行问题排除[7]。

数据服务利用SqlServer数据库建立数据库集群，对系统提供监控数据和系统数据的映射、读取、修改等服务。为保证数据安全性，数据库服务在硬件配置上采用独立硬盘冗余阵列等方式提升性能；在非忙时段(例如晚间0点至6点)进行数据备份，在工作时段采用异步备份对关键数据进行及时保存；针对读或写频繁的场合，服务器利用ORM框架作为中间件来保证性能与灵活性，并采用读写分离的方式对特定场景进行优化，将I/O压力分散，提高服务效率。

2.2 服务注册

为保证各个服务能够高效协同工作，在服务初始阶段需要将自身注册至中心管理服务。在实际配置中很多方案采用静态部署的方式，其原因是静态部署实现难度较低，后期运维可迅速定位问题。本系统采用动态配置服务的方式，其原因是考虑到后期架构的扩展性，方便系统进行升级适应未来需求的变化[8]。服务注册流程如图4所示。

图4 服务注册流程

服务注册机制采用动态配置的方式，服务在初期并不知晓中心管理服务的位置，利用广播的方式尝试获取其信息。广播搜索的方式会对网络造成一定负担，当搜索超过预设值时会触发超时策略，超时策略首先利用配置中的静态列表尝试连接，若仍未连接成功，则等待一段时间继续广播搜索，同时记录日志并通知管理用户当前情况。若通过广播搜索方式得到响应，判断响应服务的类型，发现对方为中心管理服务，则会再次确认对方类型，再次确认后向中心管理服务提交注册申请并记录其信息，最后开启定时探测保持与中心管理服务的连接；若响应服务为其他服务，则会继续发送广播信息，此时广播信息会包含自身和响应服务的信息[9]。

2.3 服务发现

当集中服务被拆分为若干服务时，需要一种机制以确保服务之间能够及时准确地获得彼此网络的位置并实现高效通信，这种机制就是服务发现机制。服务发现流程如图5所示。

图5 服务发现流程

服务会从中心管理服务拉取注册服务列表，从列表中搜索并获取待发现服务的必要信息，通过这些必要信息尝试与目标服务进行通信，双方相互确认之后开始协商通信协议等信息，协商成功后刷新自身信息列表，并将协商后的信息上传至中心管理服务，最后开启定时探测保持与其他服务的联系[10]；若未在指定通信次数范围内通信成功，则说明待发现服务位置发生变动或者服务已下线，此时需要刷新拉取服务列表以重新获取待发现服务信息，若仍获取不到信息或通信不成功，则说明待发现服务已下线或出现其他问题，此时记录当前情况并将情况上传至中心管理服务以待排查。

2.4 服务检测

服务在运行过程中可能因为系统故障、网络故障、过负载等原因导致正常或非正常离线，为保证系统平稳高效运行，系统通过服务检测机制发现存在问题服务并及时剔除，防止无效服务带来请求积压、通信超时等不良后果。服务检测流程如图6所示。

图6 服务检测流程

服务检测机制负责维护与管理系统服务整体运行状态。当系统服务发生异常时，通过服务检测机制可迅速确定异常服务离线的原因(主动请求离线或因故障被动离线)，并进行故障排查，确保系统整体服务时效与稳定性。服务检测机制首先通过中心管理服务尝试向目标服务通信以确认当前运行状态，若发生通信超时，则执行超时策略。超时策略会在规定时间内尝试重新连接目标服务，若目标服务仍然出现不可连接的状态，则判定此服务故障，中心管理服务将此服务标记为故障状态，同时向其他服务广播消息通知并建议其他服务暂停与此服务的所有任务，并将任务推送至等待队列中；若中心管理服务成功与目标服务通信并获取响应，则根据响应内容做进一步判断。若目标服务并未主动申请离线，则可能由于目标服务信息发生变更或网络波动原因造成此服务暂时不可见或短时间离线，此时中心管理服务会重新获取目标服务信息并刷新服务列表，并同时告知其他服务目标服务的更新信息，再次确认目标服务状态正常后，将此事件记录日志供运维人员查看分析；若目标服务申请主动离线，则中心管理服务将目标服务标记为离线状态，广播通知其他服务暂停所有与此服务相关的任务，将待执行任务推入等待队列并通知任务发起方当前情况[11]。

3 消息传输与组件化机制

安防系统中各子系统基于软件平台与异构硬件存在大量消息交换，同时为处理消息需要加载不同组件与模块。相较于其他通用计算机系统，在消息传输、组件化处理等方面有一定的不同，具体表现为以下方面：

1)强实时性。安防系统中要求各地防区实时传输数据进行监控并对突发警情进行及时决策与判决。因此必须在规定的时间内完成对数据的接收与处理，进行充分与及时的判断与引导[12]。

2)高可靠性。消息传输功能承担系统绝大部分数据流量的传递与交换，因此决定其高可靠性的要求[13]。尤其是在警情高发等关键时段，必须做到绝对可靠以保证相关安防任务与指挥调度的完成。

3)可扩展性。安防系统为多组件集成应用系统，要求根据任务进行动态变更，实现业务与处理能力的横向扩展，适应未来需求变化。

3.1 消息传输与组件化机制总体流程

针对以上业务需求及其领域，按照实时性、可靠性与可扩展性等原则对消息传输与组件化机制进行设计，其中通过消息队列、流量控制和消息路由等部分构成消息传输机制以保证消息高效、可靠传输，通过组件发现、动态加载、组件容器部分构成组件化机制以实现组件动态扩展与统一管理。以下对机制的总体流程进行讨论。

图7 消息传输与组件化机制总体流程

消息传输与组件化机制总体流程如图7所示，机制总体流程分为如下4个部分：第一部分各模块进行初始化操作，对相关配置信息进行校验，校验通过后加载配置，对关键字段与属性进行赋值。第二部分在初始化完成后加载监听器，用于监听用户操作或设备动作。采用监听器方式的目的在于避免直接引用带来的耦合，可以很好地适配异构硬件与软件接口，因此无需考虑相应接口设计实现与后续变更带来的维护问题[14]。第三部分为消息转换与发送。当监听器监听到用户操作或设备动作时，将其转化为统一格式的消息。第四部分将消息转发至相应处理模块。消息的转发或投递取决于流量控制模块与消息路由模块的决策。流量控制模块对系统流量与负载情况进行监视，防止突发流量对系统的冲击。当队列负载超过阈值时，及时调整上游消息发送速率以实现均衡负载和流量削峰功能。当系统负载和流量在正常阈值范围内，此时允许消息投递，消息进入队列，被消息路由接收并分发至对应处理线程。处理模块的加载依靠组件化机制实现，模块可被动态加载至系统中，无需与系统框架进行耦合，实现系统的可扩展性。

3.2 流量控制

流量控制是消息传输过程中重要组成部分，流量控制的目的在于平滑负载并消除流量尖峰防止瞬时流量冲击对系统造成的不良影响。实现流量控制需要流量策略或机制对流量进行统计与度量。系统采用令牌桶策略实现流量控制，令牌桶策略是目前最常见的流量控制与测量方法，可以用来评估流量速率，判定当前系统负载情况是否需要调整。流量控制过程如图8所示。

图8 流量控制过程

流量控制过程核心部分为令牌桶控制策略。令牌桶策略有多种实现方式，本系统采用双桶实现对流量进行测评。流量控制过程如图8所示。为方便描述，将图中所示2个令牌桶命名为C桶和E桶，C桶和E桶的令牌数为TC与TE。消息首先会尝试获取C桶令牌，若获取成功，则此消息可以直接投放至消息队列，若C桶令牌数小于阈值W，则尝试从E桶获取令牌，获取成功，此消息会投放至等待区域进行排队，获取失败，则会实行失败策略。

使用双桶的策略不仅能够限制数据的平均速率，而且当系统存在尖峰流量时，可以允许一定程度的突发传输。系统可设定令牌桶容量、令牌补充速率、容量阈值等参数控制数据流量，同时用户可根据令牌桶状况对系统整体情况进行判断，例如消息从C桶获取令牌意味着此时数据流量在限定范围内，消息从E桶获取令牌意味着此时数据流量已经超限但仍在控制范围内，因此可引入监控对整体负载情况进行监视，并将数据反馈至流量控制组件以实现对流量的进一步控制。当频繁执行失败策略或消息长时间等待时，系统通知上游消息发送端适当减少消息发送速率，同时检查下游消息处理组件工作情况，将系统状态以日志形式记录，供运维人员进行统计与分析。

3.3 消息路由分发

消息路由分发部分主要承担消息分发至指定的处理模块的功能。主要由优先级队列、初步分发、消息匹配、消息处理等部分组成。

消息路由分发示意图如图9所示。消息经过消息队列后，由消息路由进行转发至对应处理线程。考虑到系统可扩展性与消息分发效率，消息路由未采用集中路由表查询的方式，而采用多级分发的方式进行处理。集中路由表与多级分发区别在于前者将所有待查询的处理线程句柄放置在统一文件中，查询时需要对整个文件进行遍历。多级分发对所有处理线程句柄按照归属模块进行分类形成组，并对分类后的元素进行整合。对数量不多的组元素以链表形式组织，对于数量较多的组元素按照二叉树的形式组织。因此在消息匹配时首先会进行初步分发缩小查询范围，初步分发后在相应组中进行具体的消息搜索与匹配，此时搜索相较于全局搜索而言速度更快，精度更高。当匹配到相应的处理线程后，将消息传递进行处理。考虑到对紧急消息处理的情况，在初步分发前加入优先级队列对消息进行优先级排序，实现对较高优先级的消息进行优先处理；处理线程较多时将线程分组运行在不同线程池中，优势在于当某线程池因故停止工作时不会导致全局处理异常，不同的线程池可以配置不同属性(资源占有率、拒绝策略等)以实现特性化配置。

图9 消息路由分发示意图

3.4 组件化机制

组件化机制实现对系统模块的动态扩展与统一管理。机制主要由组件发现、动态加载、组件启动、组件容器等部分构成。组件化机制UML类图如图10所示。

图10 组件化机制UML类图

组件化机制核心包含3个方面，分别是组件规范接口、容器和扫描。组件规范接口规范组件行为，扫描负责在系统运行时定期查找与注册新模块，容器负责模块加载，ModuleScanScheduler类定时扫描系统，当发现需要加载或更改组件时通知ModuleScanManager进行操作，ModuleScanManager类通过Container容器接口的实现类对发生变动或新模块进行加载，这些继承了ModuleBehavior组件规范接口的模块会在容器中进行统一管理。组件的启动方式分为预热与懒加载2种。预热方式是当组件被容器加载后立即放入线程池中运行，懒加载方式是当有消息需要被组件处理时，此组件才会被放入线程池中运行。通过组件化机制降低了系统耦合度，当系统需求发生变更时新增模块可以迅速上线对系统进行升级，达到了可扩展目的[15]。

4 结束语

本研究对数字化综合安防系统总体设计架构、系统服务设计、消息中间件与组件化机制等关键设计要点进行深入探析。系统服务设计对服务合理拆分以集群形式部署提供高质量不间断服务，内部通过数据传输与组件化机制强化子系统数据传输、共享与扩展能力。系统具有高可用、高可重用、高效率、可扩展的特点，符合当前安防系统发展的趋势。系统在现有基础上，可从2个方面考虑向未来架构过渡。在业务架构领域可建立公有云和专有云混合的云服务架构体系，建设“一体化、自动化、开放化”的综合安防监控体系。在数据管理架构领域向分布式存储方案升级，综合运用高性能并行文件系统、分布式关系型数据库等技术，实现系统安防数据的高效存储与管理。