一种基于微服务的城市地下管廊业务功能系统的制作方法

文档序号:24121170发布日期:2021-03-02 11:32阅读:59来源:国知局
一种基于微服务的城市地下管廊业务功能系统的制作方法

[0001]
本发明涉及一种基于微服务的城市地下管廊业务功能系统,属于城市地下管廊工程技术领域。


背景技术:

[0002]
地下综合管廊工程集成了电力、通讯、燃气、给排水等多种城市生命线工程管线在一体。针对管线集中、容量大、灾害影响因素多、范围广、灾害影响大的特点,研究综合管廊综合灾害防治与管理的问题具有重要的意义。现有综合管廊建设和运营管理,主要是基于国标《城市综合管廊工程技术规范》的规范要求和现有成熟的监控技术实施的,子系统包括环境参数监测系统、附属设备监控系统、视频监控系统、入侵报警系统、通信系统、广播系统和火灾自动报警系统等组成。这些不同功能的系统,由于产品提供来自不同的厂商,系统之间的数据交换没有统一的标准,而且由于接口种类众多、访问性差,就容易形成系统的“信息孤岛”现象,无法满足信息互联、复杂系统联动、环境和人员安全辅助、应急和日常运维管理等诸多需求。
[0003]
从已建的城市综合管理平台发展趋势上看,大多采用了b/s架构,软件开发采用单体系结构风格,各子系统的所有业务功能都被堆到一个单体应用程序中,为管廊的监控管理人员提供业务功能。由于管理平台软件作为一个整体,子系统的组件提供广泛的业务功能,添加或修改组件要不破坏系统的整体性,或者非常昂贵。此外,为了满足总体业务需求,这些组件必须相互通信。这些组件之间的通信通常建立在专有协议和标准之上,它们基于点对点的通信方式。因此,修改或更换给定的组件也相当复杂。
[0004]
近年来,为了提供对单体应用程序体系结构某些局限性的解决方案,面向服务架构(soa)较为流行,soa通过将单体应用程序的功能分离为可重用的、松散耦合的实体(即服务),来应对开发部署大型单体应用程序碰到的问题。使用soa范式,每个业务功能都被构建为一个(粗粒度)服务部署在应用服务器内部,服务会包含多个子功能。当涉及到这些业务功能的使用时,通常需要集成多个服务,或与其他系统创建复合服务。这时,一般使用企业服务总线(esb)用于集成这些服务、数据和系统。服务消费者使用从esb层公开的复合服务,可以将esb看作连接所有这些服务和系统的集中式总线。
[0005]
从国内已建的城市综合管廊运维管理平台来看,软件系统主要内容包含:(1)集管线监控、环境监控、设备监控、安防监控等于一体的综合管廊信息管理系统;(2)根据各个系统之间需要协同共享的数据,构建对这些数据进行统一管理和维护的数据中心,并以服务的方式向各应用系统提供数据共享服务;(3)面向综合管廊运营单位,兼顾政府和各权属单位,集综合管廊日常巡检、资产设备、管线养护、和档案管理等功能的运营管理系统。
[0006]
由于整个项目系统内容繁多,各专业子系统分属不同技术领域,不同系统的数据结构差异大,造成统一数据管理和维护的成本较高,系统开发、调试、部署周期较长,不利于软件系统的更新迭代和纠错。
[0007]
另外,在管廊运营过程中,安全是一个最重要的考虑因素。目前软件系统架构是所
有系统信息汇总到中心平台,系统间信息交互通过中心平台实现,包括紧急情况下的系统联动。在正常运营期间,有利于运营监控人员集中监控、集中处置。一旦发生主干网络通信故障,就会出现系统间联动功能失效,埋下管廊整体运营安全的隐患。


技术实现要素:

[0008]
本发明的目的是为解决由于项目系统内容多,各专业子系统分属不同技术领域,不同系统的数据结构差异大,造成统一数据管理和维护的成本较高,系统开发、调试、部署周期较长,不利于软件系统的更新迭代和纠错;以及运营过程中安全性不足的技术问题。
[0009]
为达到解决上述问题的目的,本发明所采取的技术方案是提供一种基于微服务的城市地下管廊业务功能系统,包括管廊监控管理软件平台的微服务架构,微服务架构从上到下依次包括系统使用方、服务注册、api网关、微服务软件和现场设施设备;微服务软件包括系统微服务和现场设施关联微服务。
[0010]
优选地,所述系统微服务设有平台级的综合服务;系统微服务下层设有现场设施关联微服务,现场设施关联微服务与现场设施设备连接。
[0011]
优选地,所述微服务软件设有自用的用来保存以及实现业务功能的数据库和数据库模式。
[0012]
优选地,所述现场设施关联微服务设有自用的用来保存以及实现业务功能的数据库和数据库模式。
[0013]
优选地,所述微服务软件通过消息传递进行网络上的服务间通信,服务间通信可以建立在各种交互样式和消息格式之上,通过服务约定公开api,用于消费者与微服务软件之间的协作。
[0014]
优选地,所述现场设施设备包括采集信息的设施设备、媒体类设施设备和需要控制的设施设备。
[0015]
优选地,所述现场设施设备通过有线、无线网络或物联网构成信息互联。
[0016]
优选地,所述现场设施设备与所述平台级的综合服务之间设有事件总线;现场设施设备设有的现场设施关联微服务通过事件总线与平台级的综合服务连接构成信息互联。
[0017]
优选地,所述现场设施设备的现场设施关联微服务设有故障降级处理功能。
[0018]
相比现有技术,本发明具有如下有益效果:
[0019]
1.采用微服务体系架构,能较好地解决由于项目系统内容多,各专业子系统分属不同技术领域,不同系统的数据结构差异大,造成统一数据管理和维护的成本较高,系统开发、调试、部署周期较长,不利于软件系统的更新迭代和纠错;以及运营过程中安全性不足的问题。微服务是将单体应用程序开发成一套小型独立的服务,它们在各自的进程中运行、独立开发和部署。微服务架构的主要特征是:服务基于业务功能进行设计,作为独立的实体进行开发、部署和扩展的具有自治能力,灵活、小巧的智能端点和消息传递系统,容错及故障影响最小,去中心化的数据管理等。
[0020]
2.使用微服务体系开发管廊监控管理软件平台的服务端功能,有利于软件开发人员根据各系统采用的不同技术特点,组建不同的软件开发小组,使用适合的软件工具进行微服务的开发。同时,基于不同系统的数据构成特点,不同的微服务可以采用不同类型的数据库(如关系型或非关系型)。如果软件需要更新、迭代,可以仅更新已经测试过的微服务,
而不影响其它系统的正常运行。
[0021]
3.另外,由于微服务实现的功能单一,适合于在单体设备控制器上部署。由于管廊按防火分区单元划分,各分系统在单元中的设备有较多的系统联动功能,采用微服务体系后,即使系统主干网通信发生故障,通过单元内的区域网,通过微服务的自动降级治理,可实现单元内局部的自治联动功能,最大限度保障应急联动的有效实施。
附图说明
[0022]
图1为本发明管廊监控管理软件平台的微服务架构图;
[0023]
图2为本发明各个现场设施设备微服务联络构成图;
[0024]
图3为本发明组合系统的微服务联络构成图;
[0025]
图4为本发明故障降级区域的微服务联络构成图;
具体实施方式
[0026]
为使本发明更明显易懂,兹以优选实施例,并配合附图作详细说明如下:
[0027]
如图1-4所示,本发明提供一种基于微服务的城市地下管廊业务功能系统,包括管廊监控管理软件平台的微服务架构,微服务架构从上到下依次包括系统使用方、服务注册、api网关、微服务软件和现场设施设备;微服务软件包括系统微服务和现场设施关联微服务。系统微服务设有平台级的综合服务;系统微服务下层设有现场设施关联微服务,现场设施关联微服务与现场设施设备连接。微服务软件设有自用的用来保存以及实现业务功能的数据库和数据库模式。现场设施设备包括采集信息的设施设备、媒体类设施设备和需要控制的设施设备。现场设施设备通过有线、无线网络或物联网构成信息互联。现场设施设备设有的现场设施关联微服务通过事件总线与平台级的综合服务连接构成信息互联。现场设施设备通过现场设施关联微服务设有故障降级处理功能。
[0028]
如图1-4所示,在平台软件体系中,相较于soa服务实现粗粒度的服务,微服务体系是基于具体业务功能进行设计,是一种一组更细粒度的、面向业务能力的服务。
[0029]
软件中的微服务分为系统微服务和现场设施关联微服务两大类,现场设施关联微服务按系统、子系统及其不同的业务功能进行划分,并且与系统前端的相关设备进行关联,整合、调理设备生产的数据,控制相关现场设备的状态,并为其它微服务或消费者提供rest服务;系统微服务主要提供平台级的综合服务,如用户管理、巡检管理、应急指挥等。每种微服务有较强的独立性,可以作为独立的实体进行开发、部署和扩展。
[0030]
这些服务通过消息传递进行网络上的服务间通信,是一种松散耦合,服务间通信可以建立在各种交互样式和消息格式之上,通过服务约定公开api,消费者可以使用这些约定与微服务协作。
[0031]
系统生产的数据并非存储在单个集中的逻辑数据库中,每个微服务有自己的数据库和数据库模式,用来保存实现其提供业务功能的数据。给定的微服务只能访问专用的数据库,不能访问其他微服务的数据库。在某些业务场景中,如果需要为单个事务更新多个数据库,这种情况下,其他微服务的数据库只能通过相应的服务api进行更新。分散式数据管理提供了完全解耦的微服务,并可以自由选择不同的数据管理技术,如sql或nosql等,每个服务都可以有不同的数据库管理系统。
[0032]
软件平台的业务层能发现所有注册的微服务,并通过api网关访问这些微服务的功能,组合成各种展示界面,供使用者(如监控管理人员、巡检人员、管线管理人员等)在计算机工作站、移动终端的浏览器客户端、手机app上查看。
[0033]
为保证管廊日常安全运营,配备了各种辅助系统及其设备,按照为实现功能而产生的信息流性质构成进行分类,主要有三种形态:
[0034]
1.仅采集各类信息
[0035]

信息种类:温湿度、有毒有害气体测量,电力监控信息,火灾报警信息,网络状态信息,入侵报警信息,等。
[0036]

微服务主要功能:接收系统配置信息,汇集设备生产的数据,保存数据到专用小型数据库,根据设置阈值生成报警信息,生产数据更新事件。
[0037]
2.媒体类信息
[0038]

信息种类:摄像机视频流媒体,电话音频流媒体。
[0039]

微服务主要功能:接收系统配置信息,流媒体数据本地保存,流媒体转发和检索,生产视频侦测报警事件。
[0040]
3.需要控制的设备
[0041]

信息种类:风机、水泵、照明灯具、灭火系统、防火门、门禁、井盖等的控制及信息。
[0042]

微服务主要功能:接收系统配置信息及控制模式,设备的基本控制逻辑,汇集设备生产的状态和报警数据,保存数据到专用小型数据库,生产数据更新事件。
[0043]
这些部署到设备的微服务为整个系统提供核心数据服务,具备了常规监控系统的数据采集、设备控制等基本功能,是保证系统运行的基础。根据管廊的各业务子系统划分,还具有分系统的组合微服务。如图一所示的通风管理微服务,将收集底层的所有风机设备的信息及状态数据,为客户端提供api服务,并根据管廊运行的需要,向底层风机设备发布控制命令事件。同时,根据订阅其它分系统发布的报警事件,微服务提供相关的联动逻辑控制,相应地发布控制命令。
[0044]
对于平台系统级的微服务,如用户管理、巡检管理、应急指挥、报警管理、入廊管线管理等微服务,主要提供了整个管廊运营组织、授权、紧急协调、日常管理等的综合功能,并与各分系统的数据进行交互。历史数据及报表管理微服务,则提供了整个系统的数据库维护,并为各类运营报表提供检索、组织、分析等功能。
[0045]
根据管廊运营管理的需求,微服务通过使用api、事件和流与外部服务、系统和数据进行连接,其功能以api的形式向消费者公开,并通过调用api来使用外部微服务或应用程序。微服务还可以构建在事件驱动的体系结构上,通过异步事件或消息进行通信。事件可以由给定的服务或系统发出,而其他一些服务可以对其进行操作。微服务还可以对无限事件的流进行连续处理,并基于流处理逻辑发出结果事件。
[0046]
本软件平台的微服务之间关联架构主要有如下几种形态:
[0047]
1.各设备系统微服务:
[0048]
各种不同功能设备的配置单独成系统,一般情况下,运营维护人员也是以专业系统进行分别管理的。系统中的前端设备分布安装在管廊业务舱中,并通过有限、无线网络或物联网构成信息互联。如图2,设备本地微服务是部署在现场设备中的分类微服务实例,微服务含有小型的本地数据库,用于保存短期的设备状态数据,同时,将设备状态向分系统微
服务发布事件流。分系统微服务接收本系统所有本地微服务实例的流事件,根据平台系统配置要求,组织和保存设备系统数据,并通过分系统api对外发布信息。另外,还将系统对设备的配置,通过事件发布方式向本地微服务实例发布。如果系统中是需要控制的设备,则分系统微服务通过系统控制策略,通过事件发布方式向本地微服务实例发布控制命令。
[0049]
2.组合系统微服务:
[0050]
组合系统微服务包括各分系统微服务和平台级系统微服务。组合系统微服务本身不生产原始数据,而是从外部事件源接收事件或从本地设备微服务订阅事件,经过微服务的运算处理后,生成管廊运营业务所需要的各类数据集及组合事件。分系统微服务的主要功能是整合本系统的业务需求,提供系统业务功能,将本系统相关的各类事件信息发布至事件总线。各分系统微服务从事件总线上订阅所需要的事件信息,并根据平台软件的系统联动配置要求,向系统内相关设备发布控制命令事件。平台系统微服务主要提供了整个管廊运营组织功能的服务,通过接收外部源事件(主要是平台客户端发出的配置信息及组合数据检索信息),经过各种业务逻辑算法,向事件总线发布需求事件,并通过事件订阅读取平台需要的各种数据或数据流,通过api向消费者公开。
[0051]
3.故障系统降级微服务:
[0052]
由于管廊中的各类设备分布较远,设备之间信息交换通过网络实现。软件平台管理功能的实现,从本质上看是一个集中监控平台,系统间的设备联动功能通过部署在中心的分系统微服务数据交互而实现。当系统主干网发生故障时,有可能分系统微服务不能及时收到管廊现场的报警信息或不能及时下发控制命令,如果发生火灾之类的报警,各系统的联动处置就无法实现。
[0053]
由于系统间设备的联动主要是同区域内的设备联动,当发生主干网通信故障时,如果区域网路正常工作,则可以通过微服务的故障降级功能,设备本地微服务通过订阅事件总线的本区域事件信息,接收本区域的各种报警信息,并通过本地微服务的联动算法,下发相应的设备控制命令。
[0054]
以上所述,仅为本发明的较佳实施例,并非对本发明任何形式上和实质上的限制,应当指出,对于本技术领域的普通技术人员,在不脱离本发明的前提下,还将可以做出若干改进和补充,这些改进和补充也应视为本发明的保护范围。凡熟悉本专业的技术人员,在不脱离本发明的精神和范围的情况下,当可利用以上所揭示的技术内容而做出的些许更动、修饰与演变的等同变化,均为本发明的等效实施例;同时,凡依据本发明的实质技术对上述实施例所作的任何等同变化的更动、修饰与演变,均仍属于本发明的技术方案的范围内。
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1