CN111193610B - 一种基于物联网的智慧监控数据系统和方法 - Google Patents

一种基于物联网的智慧监控数据系统和方法 Download PDF

Info

Publication number
CN111193610B
CN111193610B CN201911207984.XA CN201911207984A CN111193610B CN 111193610 B CN111193610 B CN 111193610B CN 201911207984 A CN201911207984 A CN 201911207984A CN 111193610 B CN111193610 B CN 111193610B
Authority
CN
China
Prior art keywords
management
data
drive
interface
service module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CN201911207984.XA
Other languages
English (en)
Other versions
CN111193610A (zh
Inventor
祝珍珍
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Infinite Free Culture Media Co ltd
Original Assignee
Beijing Infinite Free Culture Media Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Infinite Free Culture Media Co ltd filed Critical Beijing Infinite Free Culture Media Co ltd
Priority to CN201911207984.XA priority Critical patent/CN111193610B/zh
Publication of CN111193610A publication Critical patent/CN111193610A/zh
Application granted granted Critical
Publication of CN111193610B publication Critical patent/CN111193610B/zh
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computer And Data Communications (AREA)

Abstract

本发明实施例公开了一种基于物联网的智慧监控数据系统和方法,所述系统包括:前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦。本发明实施例能够在物联网领域内通过容器+微服务架构的使用,可以实现快速实现,部署,容灾,扩容,节省人力和相关成本。

Description

一种基于物联网的智慧监控数据系统和方法
技术领域
本发明涉及物联网技术领域,尤其涉及一种基于物联网的智慧监控数据系统和方法。
背景技术
在互联网行业的影响下,各个行业的壁垒逐渐降低,竞争更加激烈。由于信息获取的途径更加容易,监控方案能够拥有更快实施特点、更低的成本以及好的质量保证,是现在各个行业的诉求。
物联网的发展依托互联网技术的支持,物联网的发展促进了很多垂直行业的发展,促进了很多新的技术的发展和革新,如农业,物流,交通,运输,消防,公安,百货等等,物联网解决了很多类似“最后一公里”的问题,极大地提高了运行效率。
基于物联网的监控系统都需要和设备相互连接,连接取决于连接的长度,现有技术的基于物联网的监控系统要不就是上云,要不就是部署在现场。很多小方案考虑成本,直接部署在现场,第一调试方便,直接派几个工程师部署一下,第二,直接连接设备,也比较方便。但是直接部署在现场的部署方式,会导致现场出现了其他问题很难去查询和解决。上云的场景主要是在于大的监控系统,监控设备很多,部署在现场的场地原因,或者开发环境不允许,如信息保密,信息保护等,需要上云实现远程的监控。这种方案因为产品体量比较大,如果采用私有云,云设施还需要维护。
现有技术中的物联网数据监控的系统架构中,安装模块比较多,依赖库比较多,体量比较大,在主机环境安装上需要准备的比较多。传统监控系统在部署的时候基本没有使用容器,微服务等技术,或者只使用了容器技术,未使用容器编排,容灾,以及扩容的设计,在部署的时候需要花费大量的实践。在开发功能过程当中,基本使用的是统一的技术栈。
因此,现有技术都具有体量大,基础设施环境不一致时,容易导致部署出现问题,存在软件代码包依赖环境的问题,以及实施部署花费大量时间的缺点。
发明内容
为了解决上述技术问题,本发明实施例提供了一种基于物联网的智慧监控数据系统和方法,能够在物联网领域内通过容器+微服务架构的使用,可以实现快速实现,部署,容灾,扩容,节省人力和相关成本。
为了达到本发明目的,一方面,本发明实施例提供了一种基于物联网的智慧监控数据系统,包括:
前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦。
优选地,所述前端包括服务器Nginx,用于通过服务分类,使用Nginx将不同的服务请求分流到不同的服务中。
优选地,所述后端包括:
子服务模块,用于进行分布式设备的监控、配置和管理;
主服务模块,用于对所有数据进行管理;
设备驱动管理服务模块,用于进行设备驱动的在线更新和传播;
后端第一接口,用于所述设备驱动管理服务模块和所述主服务模块、所述子服务模块之间的连接;
后端第二接口,用于所述主服务模块与所述子服务模块直接的连接。
优选地,所述子服务模块,用于配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
优选地,所述系统用于:
使用容器方式隔离各个服务之间的耦合和依赖;
使用容器编排引擎Kubernetes对容器进行管理。
优选地,所述系统还用于:
通过在服务化架构内再部署额外的子服务,直接监控额外需求的设备,进行系统扩容。
另一方面,本发明实施例还提供了一种基于物联网的智慧监控数据方法,包括:
用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
根据用户请求的数据,后端将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
通过系统接口隔离所述前端和所述后端,进行系统请求接口的解耦。
优选地,所述方法还包括:
通过服务分类,使用服务器Nginx将不同的服务请求分流到不同的服务中。
优选地,所述根据用户请求的数据,后端将所述数据处理好后返回给请求方包括:
通过子服务模块进行分布式设备的监控、配置和管理;
通过主服务模块对所有数据进行管理;
通过设备驱动管理服务模块进行设备驱动的在线更新和传播。
优选地,所述通过子服务模块进行分布式设备的监控、配置和管理包括:
配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
本发明实施例中包括前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦。本发明实施例能够在物联网领域内通过容器+微服务架构的使用,可以实现快速实现,部署,容灾,扩容,节省人力和相关成本。
本发明的其它特征和优点将在随后的说明书中阐述,并且,部分地从说明书中变得显而易见,或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。
附图说明
附图用来提供对本发明技术方案的进一步理解,并且构成说明书的一部分,与本申请的实施例一起用于解释本发明的技术方案,并不构成对本发明技术方案的限制。
图1为本发明实施例基于物联网的智慧监控数据系统的架构图;
图2为本发明实施例基于物联网的智慧监控数据系统的后端基础功能框架示意图;
图3为本发明实施例基于物联网的智慧监控数据系统的最优结构示意图;
图4为本发明实施例基于物联网的智慧监控数据方法的流程示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,下文中将结合附图对本发明的实施例进行详细说明。本申请中的实施例在以本发明技术方案为前提下进行实施,给出了详细的实施方式和具体的操作过程,但本发明的保护范围不限于下述的实施例,基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
图1为本发明实施例基于物联网的智慧监控数据系统的架构图,如图1所示,本发明实施例的系统包括:
前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦。
本发明实施例中,使用容器方式隔离各个服务之间的耦合和依赖,使用容器编排引擎Kubernetes对容器进行管理。
本发明实施例中,通过在服务化架构内再部署额外的子服务,直接监控额外需求的设备,进行系统扩容。
具体地,随着容器技术的发展,软件行业的交付标准得到了革新,容器的封装可以很好地隔离环境不一致的因素,使用容器镜像交付可以极大地方便运维工程师进行现场部署,同时依托云设施的支持,可以极大地提高交付质量和减少部署时间。
DevOps为Development和Operations的组合词,是一组过程、方法与系统的统称,用于促进应用程序/软件工程开发、技术运营和质量保障(QA)部门之间的沟通、协作与整合。随着DevOps技术和理论的发展,DevOps已然成为软件以及相关行业组织转型的目标,DevOps可以极大地提高开发团队提交的速度和质量,基于微服务的软件架构SOA(ServiceOriented Architecture)满足DevOps的实践原则,使用不断迭代的方式极大地缩短了产品系统推向市场的时间。
本发明实施例最主要的是针对物联网监控系统的线程部署问题与驱动在线更新方式的更新,驱动使用的还是行业内成熟的方案,如Zigbee,SNMP/TR069等等,驱动直接支持通用的驱动协议。
本发明实施例的技术方案比较灵活,可以使用上云的方案,因为直接使用容器封装,也可以快速部署在现场,还可以远程直接部署,在网络是连通的前提下,上线运行也可以,因此适应不同的场景。
由于本发明实施例是既可以快速使用在云端,也可以快速实施在现场,从而克服了因为基础设施环境不一致导致的部署出现的问题,同时还解决了软件代码包依赖环境的问题。
实现上,使用容器对交付的软件进行交付,使用容器编排引擎Kubernetes对容器进行管理。基于DevOps思想的实现系统,并应用在物联网行业,摆脱基础环境的干扰。其中,Kubernetes是谷歌最新的开源技术,能够实现容器编排等功能。
同时本发明实施例可以实现在线更新,回滚,自动升级等等创新,这些是现在监控系统都不太能实现的。
本发明实施例针对于DevOps以及微服务架构,对监控系统的实现并不是需要统一的技术栈,这样可以增加系统的扩容性和鲁棒性。
具体地,本发明实施例的监控数据系统基于微服务架构进行实现,使用微服务架构可以很好的隔离各个服务之间的相互依赖关系,同时可以降低因为某些服务失败而出现的系统宕机的情况,通过对微服务的管理可以很好的降低系统的运维成本和协作成本。本发明实施例采用微服务架构实现分为前端和后端实现,下面分别介绍各个模块的作用。
如图1所示,本发明实施例的监控系统的基本架构是采用轻客户端的方式实现,本监控系统采用前后端的方式进行实现,整体使用容器与服务的方式实现。
由于物联网监控系统中,主要的特点在于被监控单元个数比较多,所以本发明实施例的总体架构中采用的是轻前端,重后端的设计发明方式,如图1所示,图1中101属于前端的容器封装,包裹的为使用React实现的前端页面,同时101提供的服务中包含了Nginx实现反向代理和静态路由的功能,图1中103,104,105都属于后端的内容单元,可根据具体的需求进行容器扩容,图1中102是采用前后端分离的Restful API的接口,可以实现OEM二次开发,以及资源访问隔离的功能,同时采用Restful API可以更好的进行接口隔离,方便Nginx进行静态路由的功能。其中,Restful是一种网络应用程序的设计风格和开发方式。
整体系统采用了Kubernetes进行容器调度和统一控制,采用Kubernetes+docker的实现方式区别于传统的方案的区别在于:
本发明实施例使用的Kubernetes+Docker的方案可以动态地实现扩容缩容,增加设备,增加容器,增加容量等等方式可以立刻就实现,这是传统监控系统方案比拟不了的。
本发明实施例的技术方案在容灾方面具有良好的鲁棒性。其特点在于容器的启停以及运行状态是受系统随时监控的,在容器遇到失败停止运行的时候可以快速重建,同时重建容器的过程是无缝衔接的,这个功能是传统方案不可比拟的。
本发明实施例的技术方案是基于DevOps的思想进行实现的,只要是需要DevOps开源的工具都可以集成在本发明实施例的技术方案中,具有良好的可扩展性。
为了实现服务部署方便的考虑,使用“胖容器”的考虑,即服务中不是原子功能,使用组合的方式实现复合式服务策略,这样设计是基于物联网特性考虑,物联网具有分布式的特点,服务架构若太过于分散会造成系统部署以及运维的复杂度增加,同时,基于物联网的系统对后端的复杂度要求比较高,需要对设备进行智能控制和监控,同时需要支持各种设备的驱动,故后端设计上考虑使用多后端服务的策略,实现分布式和物联网复杂繁多设备的支持。
优选地,本发明实施例中,前端包括服务器Nginx,用于通过服务分类,使用Nginx将不同的服务请求分流到不同的服务中。
优选地,本发明实施例中,后端包括:
子服务模块,用于进行分布式设备的监控、配置和管理;
主服务模块,用于对所有数据进行管理;
设备驱动管理服务模块,用于进行设备驱动的在线更新和传播;
后端第一接口,用于所述设备驱动管理服务模块和所述主服务模块、所述子服务模块之间的连接;
后端第二接口,用于所述主服务模块与所述子服务模块直接的连接。
优选地,所述子服务模块,用于配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
具体地,图1中101为系统前端用户界面UI部分,101整体对外提供一个服务Srv_fe,服务Srv_fe里面包含两部分,第一部分是显示WebUI界面,Web界面使用React技术实现,实现界面显示,响应,交互,监控配置,报警控制等,其中React是一个直译式脚本语言js(JavaScrip)框架,可以用它来编写html页面。服务器Nginx的作用是实现负载均衡和反向代理,本发明实施例使用Nginx的作用是后端存在多个服务,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应。
图1中102为系统接口部分,本发明实施例采用统一的Restful API接口,实现接口操作的统一化,同时保持接口的整洁,同时使用Restful API接口实现资源接口的隔离,可以实现系统请求接口的解耦,提高系统的可扩展性。如表1所示,定义了统一的接口模板,方便扩容和维护。
表1接口定义模板
Figure GDA0003225861380000071
Figure GDA0003225861380000081
如表1所示,本发明实施例的系统Restful API接口按资源响应共解耦成4个接口集,分别为配置管理接口,计数器管理接口,报警管理接口和设备驱动管理接口,四个接口集合分别负责监控系统的不同方面。配置管理接口主要负责系统WebUI界面配置,设备配置,用户配置数,以及相关功能配置的数据管理;计数器管理主要负责监控对象的KPI数据的监测,比如温度,湿度,电压值,电量值,吞吐量等等,计数器管理的接口是设备监控的核心;设备报警接口主要是记录设备的报警项,报警列表等,系统可以通过设备报警接口来判断设备的运行状态,乃至整个系统的运行状态;设备驱动管理接口的接口设计目的主要是为了对不同设备驱动进行管理,同时实现系统在线升级的目的。
除了系统监控专用接口之外,还有一些监控系统通用的接口,比如用户列表,用户权限管理接口,设备启动与重启接口,邮件发送接口,导出监控报告等。本系统中最核心的还是表1中所列举的接口。
图1中103为组件服务,也称为子服务(sub-service),其服务的主要目的是为了实现分布式设备的监控、配置和管理的功能,每个子服务接口可视具体项目情况监控一个网段或者一个区域的设备,同时每个子服务中会有基本的驱动库,如果需要更新驱动库,可以使用表1中的驱动设备管理接口进行更新,从而实现在配置过程中出现新设备不兼容的问题,这一个设计极大地简化了设备的驱动管理。子服务的区分可以通过IP地址或者域名进行区别,每一个子服务中有一整套Django的实现逻辑,同时每一个子服务中还有一个数据库Mongo,Mongo数据库中主要会存放本子服务中的设备的实时报警数据,实时的计数器数据以及设备的驱动列表,这个设计是为了隔离实时数据采集信息的时间不同。
图1中104为系统主服务(main service),主服务下不管理和监控任何设备,主服务里有和子服务中类似的Django整体逻辑框架,此外还有一个Redis缓存数据库和MongoDB数据库。主服务主要实现的功能是历史计数器数据的收集与备份,历史报警数据的收集与备份,除了对历史数据的收集,其还需要保存和再现整个配置管理的所有数据,数据存储在Mongo DB数据库中;而Redis数据库主要是为了实现前端对历史数据获取过多的时候进行缓存,提高响应速率,因为历史数据是不变化的。
图1中105是系统设备驱动管理服务(driver service),其服务主要的目的是为了实现设备驱动的在线更新和传播。运行中的系统在设备驱动需要更新的时候可以使用此服务进行设备驱动的更新,此服务中Django也为和主服务Main_Srv一样的整体逻辑框架,Mongo DB数据库中存储的是设备驱动信息列表。此服务更新的原理如下:当前端服务101在配置设备的过程中需要添加新设备驱动,或者更新设备驱动时候,前端服务发送驱动更新的请求由Nginx将消息路由到设备驱动管理服务,前端服务更新上传的新驱动包会首先存放在驱动管理服务中,驱动管理服务会使用Restful API接口106想主服务Main_Srv104获取完整的设备驱动配置列表,进行查找首先通过Restful API接口106更新有配置这个驱动的设备所在子服务103的驱动列表中,同时更新此子服务103的驱动列表,完成此步骤后逐一通过Restful API接口106更新没有配置这个驱动设备所在的子服务,包括主服务的驱动设备列表,逐一更新。
设计驱动管理服务的目的不仅是为了实现负载均衡,通过使用服务分类,使用Nginx将不同的服务请求分流到不同的服务中,从而实现负载均衡的功能。而且也是为了直接降低前端与后端之间的接口的负载,驱动文件的大量分发会一定程度阻塞接口通信,这样实现可以使后端服务可以异步处理驱动包的分发过程。
图1中106接口是设备驱动管理服务和主服务、子服务之间的Restful API接口,接口直接复用表1中的驱动设备管理接口,从而不用再新增新的接口,106接口之间的信息交互是实现了后端服务之间的交互。主要的功能是实现驱动的在线更新和驱动文件的传递。
图1中107接口是主服务与各个子服务直接的Restful API接口,此接口是直接复用设备报警管理接口和计数器管理接口,无需添加新的接口,此接口的作用是定期向各个子服务中获取实时报警列表信息和实时计数器列表信息,更新在主服务中的Redis缓存数据库中,定期写入主服务的MongoDB数据库作为历史数据存放,实现了历史数据的收集。由于此接口通信是在后端服务之间完成的,降低了前端和后端时间的通信负载。
本发明实施例中包括前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦。本发明实施例能够在物联网领域内通过容器+微服务架构的使用,可以实现快速实现,部署,容灾,扩容,节省人力和相关成本。
图2为本发明实施例基于物联网的智慧监控数据系统的后端基础功能框架示意图,图2是对图1中的103的具体细化。
如图2所示,后端核心功能实时报警的基础流程为:在用户配置好相应设备运行系统以后,驱动平台层216会实时检测轮询每一个设备的报警信息,若有报警信息则直接触发报警流程上报给报警管理214模块,实时报警214模块会针对数据库中的实时报警信息和驱动平台层214上报的报警信息进行对应的设备报警信息对比,若有差异则报警管理214把新报上来的信息覆盖自己维护的报警信息中,同时将实时报警信息通过数据清洗与转换215处理后写入到数据库208中,当作历史数据保存;同时报警管理214会将有差异的实时报警信息上报给调度触发器210。在前端进行设备报警信息刷新请求时,通过报警管理接口204进来的请求通过中间件API消息与路由207将请求路由到调度触发器210中,调度触发器会将在用户可配置这段时间内出现的报警变化经行响应,通过204报警管理接口上报给前端进行相应信息的更新,完成了实时报警的实时更新的功能。
如图2所示,后端核心功能驱动管理的基础流程为:用户通过前端界面配置设备驱动使用驱动管理接口204进行请求,请求同样经过中间件API消息与路由207将请求路由到设备驱动管理服务模块209中,设备驱动管理服务模块209将内存中维护的实时驱动列表返回通过驱动管理接口202给用户前端请求;若用户未找到相应的驱动,选择新增驱动并上传驱动时,同样是经过驱动管理接口202,由中间件API消息与路由207将请求路由到设备驱动管理服务模块209中,设备驱动管理服务模块209将新增的驱动新增一个条目写入到数据库中,条目信息包括驱动的版本,驱动的管理路径,驱动日期,支持协议信息等等,同时更新设备驱动管理服务模块209自己的维护的驱动列表,实现驱动在线管理的功能。
如图2所示,后端核心功能计数器统计的基础流程为:计数器管理主要是为了查看整体系统的状态以及各个设备的情况,比如分布式设备的电量,设备的报警数量,设备的状态等等,其功能和实时报警功能比较类似,前端功能定时会请求系统定义的计数器的信息的状态请求,通过计数器管理接口203由中间件API消息与路由207将请求路由到调度触发器209中,调度触发器210会将这段时间更新的状态信息统一将信息打包,将请求通过计数器管理接口203回复给前端相应页面中。考虑到计数器统计的时间间隔比较长,数据量随着设备的增加会变多,在前端请求的时候,采用计数器类目的方式对计数器进行实时更新,比如电量类目计数器等等。在底层,驱动平台层216会定时获取各个设备的配置的计数器信息,将信息上报给计数器管理214模块,计数器管理214模块会将状态信息统一写入数据库作为计数器的历史数据,同时将对比自己模块维护的实时的计数器信息表,将差异的信息维护在内存中,等待前端的计数器更新请求到来,再把更新上报给调度触发器210,完成计数器更新功能,同时能减少数据量。
本发明实施例的部署便利性在于:后端各个服务的代码都是同一套代码,通过使用容器的封装去实现不同的功能。
本发明实施例中实现这些功能是使用Kubernetes实现的容灾,以及扩容的设计。本发明实施例中都有所考虑,且本发明实施例既可以支持云计算平台可以支持一般平台的运行。
本发明实施例技术方案通过在物联网领域内容器+微服务架构的使用,可以实现快速实现,部署,容灾,扩容,节省人力和相关成本。
其中,微服务架构是基于容器技术而起的一个架构,这个架构不是一项技术,而是一种设计理念。容器技术是一项技术,容器技术可以很好地解决微服务架构中部署困难,监控困难,容灾,反馈加速等问题,两者虽然不是同一个范畴,却可以相辅相成。
本发明实施例在扩容上是直接多部署容器的方式进行实现的。
本发明实施例中使用容器以及容器编排是为了实现灵活的部署方案,扩容和容灾的需求。
本发明实施例部署方便,应用场景灵活。同时本发明实施例有驱动管理模块,可是灵活支持不同设备。
在开发的层面,后端只需要维护同一套代码功能,节省的时间。
本发明实施例的各个服务都是使用容器进行交付的,容器的便利性就在于一次发布随处部署,极大地节省的部署的时间和成本。
对于上云和不上云的功能的支持能力,由于使用容器进行封装和部署,而在现有的云端技术都能很好的支持容器化的方案,如OpenStack+Openshift,AWS,Azure等方案,都对容器有密切的支持,上云非常便捷。
本发明实施例对安全性和可靠性的考量:
在交付的容器镜像都是使用安全加密的镜像,保证镜像内部的安全。系统服务之间的通信都采用安全的通信方式,如安全传输层协议TLS。在可靠性方面,使用容器和服务编排的方案,如使用Kubernetes进行容器编排,可以很快的实现服务重启,备份,以及服务的监控。在系统更新方面,由于使用容器镜像进行交付,故使用Kubernetes进行服务编排部署的时候可以便捷的支持滚动更新和服务回滚的机制,可以实现系统的更新不用宕机处理,而是热更新的机制,极大地提高了系统在更新方面的可靠性。
本发明实施例在扩容的支持:微服务化的方案最大的有点在于扩容十分便捷,使用容器化的方案可以很好的隔离各个服务之间的耦合和依赖,通过系统长时间运行中需要进行扩容的需求,既不用断电下线重新部署,也不用系统停止某些服务进行更新,只需要在服务化架构内再部署额外的子服务Sub_Srv即可,这样可以直接监控额外需求的设备,从而很自然的就实现了系统扩容的能力。
如图2所示,本发明实施例系统后端基础功能架构图中,201-206是各个RestfulAPI声明的接口,207是Django内部实现的消息队列和路由,主要功能是将不同种类的Restful API接口请求的消息进行排队缓冲,降低瓶颈效应,同时对不同种类的消息进行路由,路由到不同的逻辑中去。205和206的API消息是直接透传到211与212中,实现公共功能的分离与解耦。
其中,210是核心的逻辑处理部分,其主要的功能是根据用户的配置实现后端所有的信息的调度,流程的触发与定时触发,实时地响应API的请求;如果API层只是需要读取,更新,删除和添加实时数据,可以直接访问数据库获取数据;如果需要访问历史数据库,则需要使用调度器210使用Redis缓存数据库进行数据缓存,然后再进行读取操作。
其中,209为设备驱动管理服务模块,主要是为了实现驱动列表的维护和进行驱动的更新。维护驱动数据列表的主要是更新数据库数据列表;同时驱动的更新是为了如前描述,实现驱动的实时更新,实现一次前后端交互传送,所有服务的驱动可以更新的功能。
其中,计数器管理213与报警管理214是为了实时获取所监控的所有设备的计数器数据和报警数据,计数器数据的实时特性没有报警数据的实时特性高,计数器数据可以每隔15分钟,30分钟,乃至60分钟都可以获取一次,但是报警数据是设备主动触发的,所以实时特性要求高一些。计数器管理213与报警管理214的数据也需要存储到数据库中,在存储之前还需要经过215数据清洗与转换,主要的目的是将上报的实时数据转换成数据库设计的格式,如时间戳的格式修改,设备编号与IP地址的添加等等。
其中,驱动平台层216主要是为了实现驱动的连接,重启,数据获取接口,驱动的加载,升级等等基本的功能,供上层的功能部分进行调用。
图3为本发明实施例基于物联网的智慧监控数据系统的最优结构示意图,如图3所示,其中:
图3的302对应图1的101,303对应于104和105,304,305,306对应于103,图3中前端是在302Pod中,后端是在303-306Pod中,驱动服务在303Pod中,主服务在303Pod中,子服务在304-306中,接口每个服务都有,物理接口是各个Node的eth0,虚拟映射接口就是对应的flannel0和docker0。
优选地,本发明实施例实现了一种便捷的轻量级物联网智能监控系统,本实施案例挑选了灵活的部署方案。如图3所示,本实施案例选取了常规的典型案例,采用了Kubernetes+docker的技术部署方案,软件最后交付和获取采用docker镜像(dockerimage)的方式进行交付与更新。
优选地,如图3所示,301为Kubernetes主节点(Master Node),依赖的基础环境为docker,etcd,flannel和kubernetes,docker主要是为了封装软件设施,kubernetes是为了实现容器编排以及部署监控,etcd是为了实现服务发现,以及保存系统运行中所有服务和Pod的配置信息,flannel是为了实现跨主机Pod之间的通信交互功能。301物理主机相当于Kubernetes的主控制器,而302-306分别是301Kubernetes主机的子节点(Minion);301–306物理主机都处于同一个大的网段中,为192.168.0.100/24,每一个物理主机的Kubernetes服务(Service)使用物理主机IP进行暴露服务。
优选地,302为WebUI+Nginx的服务,主要对外提供了UI界面以及反向代理路由请求的功能,和图1中架构一一对应。WebUI对外使用8080端口和443端口提供服务。
优选地,303为主服务Main_Srv和驱动管理服务Drv_srv,这两个服务一起部署在303中,且303主服务Main_Srv下面会连接一些监控设备,当然主服务下面也可以不连接任何设备,视具体使用情景,若主服务和前端服务都部署在监控室内,则主服务不需要连接任何监控设备;主服务Main_Srv和驱动管理服务Drv_srv使用不同的端口进行区别,主服务Main_Srv使用34500端口,驱动管理服务Drv_srv使用34501端口。
优选地,304,305,306分别是监控子节点,对外暴露各个相同的子服务Sub_Srv,304,305,306子节点的服务是使用34500端口对外进行暴露。304,305,306物理主机的位置可以物理距离非常远,304物理主机下需要监控连接的设备比较多,使用了两个Pod进行监控,对外还是使用一个服务进行服务,305,306主机下面监控的节点数量在一个Django Pod就可以覆盖,故只部署了一个Pod。304节点同事承接历史数据的保存,并且部署的Redis服务进行数据缓存。
优选地,在此系统实施的情况中,典型的数据流处理流程为:
用户操作前端Node1,Node1中的WebUI FE Pod收到前端操作请求,将请求转发给Pod_Nginx进行反向代理,根据用户的请求来将请求路由到对应的Node中;
优选地,假设数据请求从Pod_Nginx指向节点304Node3,Node3收到请求以后,根据用户请求的数据(对应设备的数据等等)将数据处理好后返回给请求方。
对应地,响应数据又回到了Node1节点中,首先是经过Pod_Nginx,Nginx将数据路由给前端Pod WebUI FE,用户收到数据。至此就完成了一个完整的典型流程。
优选地,根据功能响应,用户请求的是设备实时Alarm数据的话,302中的Pod_Nginx会将数据请求路由到303ˉ306中Pod_Sub的链接对应设备的Node上;如果用户请求的是历史数据,302中的Pod_Nginx会将数据请求路由到303中Pod_Main请求对应数据;如果用户请求的是驱动信息数据,302中的Pod_Nginx会将数据请求路由到303中Pod_Drv请求对应数据。
优选地,301节点是Master主节点,Master主节点下面可以连接设备,在本实施案例中,主节点下没有连接设备,只安装了K8s和Docker,主要是方便监控设备放置主机,方便部署。301节点的作用有如下几个:第一,监控子节点303-306,303-306节点中有任何一个节点宕机了,或者服务下线了,主节点K8s都会尝试重启子节点服务,已保证服务质量,同时也达到了一定程度容灾的功能;第二,在线升级服务,在监控子节点中的任何功能进行更新了或者版本升级的时候,可以使用主节点301进行在线热升级功能,直接将监控子节点中的容器升级到指定的容器版本,而不需要下线升级。第三,扩容功能,任何需要规模化应用的时候,只要主机的物理资源允许,主节点Master可以在线部署额外的子节点Pod_Sub服务,从而达到系统功能扩容的功能。
图4为本发明实施例基于物联网的智慧监控数据方法的流程示意图,如图4所示,本发明实施例的方法包括如下步骤:
步骤401:用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
步骤402:根据用户请求的数据,后端将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
步骤403:通过系统接口隔离所述前端和所述后端,进行系统请求接口的解耦。
优选地,所述方法还包括:
通过服务分类,使用服务器Nginx将不同的服务请求分流到不同的服务中。
优选地,所述根据用户请求的数据,后端将所述数据处理好后返回给请求方包括:
通过子服务模块进行分布式设备的监控、配置和管理;
通过主服务模块对所有数据进行管理;
通过设备驱动管理服务模块进行设备驱动的在线更新和传播。
优选地,所述通过子服务模块进行分布式设备的监控、配置和管理包括:
配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
本发明实施例对软件开发的时间缩短,成本降低,更加高效。软件部署更加便捷,提高系统的可靠性。软件容灾能力更强。系统可以实现滚动更新等,以及设备驱动可以更好的在线更新,具有更好的扩容能力。
本发明实施例中,解决了现有技术中因为系统在部署的过程中会有各种因为生产环境和开发环境不一致导致的环境问题,这一问题将直接阻碍系统部署的进度。本发明实施例可以实现系统隔离掉开发环境和部署环境不一致的问题。
本发明实施例中,解决了现有技术中很多监控系统的方案在部署的时候都是配置固定的,当需要进行扩容或者大规模增加监控单元的时候,需要大量的改动,这一点对于一个系统在长时间使用后提出扩容需求的时候会毫无能力。良好的扩容能力对系统是非常重要的。本发明实施例可以实现监控系统具有良好的扩容能力,实现成本的节约。
本发明实施例中,系统容灾恢复能力。由于安防监控系统对系统的可靠性要求比较高,大多数监控系统可靠性具有比较好的保证,但是对于容灾恢复能力,大部分监控方案都是采用冗余两套系统进行灾备切换的,这种方案会在设备上和使用成本上造成浪费,本发明实施例可以实现实时地对系统灾备,回滚,乃至系统升级,而不用部署两套冗余的环境,节约系统成本,提高效率。
本发明实施例中,对于云的支持与便捷扩容的问题。本发明实施例可以具有拥抱云的实施方案,灵活满足用户的需求,既可以安装在私网上,也可以实施在企业云上,同时如果用户允许,也可以实施在公有云上。本发明实施例中实现了服务便捷扩容的能力以及在线驱动热部署的能力,可以解决系统在长时间运行中需要扩容以及设备需要添加支持带来的驱动扩容的问题。
本发明实施例采用了容器化的方案可以开发完成以后直接部署在现场,实现部署时间的缩短和效率的提升。
本发明中通过具体实施例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种基于物联网的智慧监控数据系统,其特征在于,包括:
前端,用于用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
后端,用于根据用户请求的数据,将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
系统接口,用于隔离所述前端和所述后端,进行系统请求接口的解耦;
所述后端包括:
子服务模块,用于进行分布式设备的监控、配置和管理;
主服务模块,用于实现历史计数器数据的收集与备份,历史报警数据的收集与备份,以及整个配置管理的所有数据的保存和再现;
设备驱动管理服务模块,用于进行设备驱动的在线更新和传播;
后端第一接口,用于所述设备驱动管理服务模块和所述主服务模块、所述子服务模块之间的连接;
后端第二接口,用于所述主服务模块与所述子服务模块直接的连接;
后端核心功能驱动管理的基础流程为:用户通过前端界面配置设备驱动使用驱动管理接口进行请求,请求同样经过中间件API消息与路由将请求路由到设备驱动管理服务模块中,设备驱动管理服务模块将内存中维护的实时驱动列表返回通过驱动管理接口给用户前端请求;若用户未找到相应的驱动,选择新增驱动并上传驱动时,同样是经过驱动管理接口,由中间件API消息与路由将请求路由到设备驱动管理服务模块中,设备驱动管理服务模块将新增的驱动新增一个条目写入到数据库中,条目信息包括驱动的版本,驱动的管理路径,驱动日期,支持协议信息,同时更新设备驱动管理服务模块自己的维护的驱动列表,实现驱动在线管理的功能。
2.根据权利要求1所述的基于物联网的智慧监控数据系统,其特征在于,所述前端包括服务器Nginx,用于通过服务分类,使用Nginx将不同的服务请求分流到不同的服务中。
3.根据权利要求1所述的基于物联网的智慧监控数据系统,其特征在于,所述子服务模块,用于配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
4.根据权利要求1-3任一项所述的基于物联网的智慧监控数据系统,其特征在于,所述系统用于:
使用容器方式隔离各个服务之间的耦合和依赖;
使用容器编排引擎Kubernetes对容器进行管理。
5.根据权利要求1-3任一项所述的基于物联网的智慧监控数据系统,其特征在于,所述系统还用于:
通过在服务化架构内再部署额外的子服务,直接监控额外需求的设备,进行系统扩容。
6.一种基于物联网的智慧监控数据方法,其特征在于,包括:
用户操作前端用户界面UI时,通过前端请求将物联网设备监控相关数据发送到指定的服务中进行响应;
根据用户请求的数据,后端将所述数据处理好后返回给请求方,根据具体的需求进行容器扩容;
通过系统接口隔离所述前端和所述后端,进行系统请求接口的解耦;
所述根据用户请求的数据,后端将所述数据处理好后返回给请求方包括:
通过子服务模块进行分布式设备的监控、配置和管理;
通过主服务模块对历史计数器数据进行收集与备份,对历史报警数据进行收集与备份,对整个配置管理的所有数据进行保存和再现;
通过设备驱动管理服务模块进行设备驱动的在线更新和传播;
后端核心功能驱动管理的基础流程为:用户通过前端界面配置设备驱动使用驱动管理接口进行请求,请求同样经过中间件API消息与路由将请求路由到设备驱动管理服务模块中,设备驱动管理服务模块将内存中维护的实时驱动列表返回通过驱动管理接口给用户前端请求;若用户未找到相应的驱动,选择新增驱动并上传驱动时,同样是经过驱动管理接口,由中间件API消息与路由将请求路由到设备驱动管理服务模块中,设备驱动管理服务模块将新增的驱动新增一个条目写入到数据库中,条目信息包括驱动的版本,驱动的管理路径,驱动日期,支持协议信息,同时更新设备驱动管理服务模块自己的维护的驱动列表,实现驱动在线管理的功能。
7.根据权利要求6所述的基于物联网的智慧监控数据方法,其特征在于,还包括:
通过服务分类,使用服务器Nginx将不同的服务请求分流到不同的服务中。
8.根据权利要求6所述的基于物联网的智慧监控数据方法,其特征在于,所述通过子服务模块进行分布式设备的监控、配置和管理包括:
配置管理、驱动管理、计数器管理、报警管理、用户管理、邮件收发。
CN201911207984.XA 2019-11-30 2019-11-30 一种基于物联网的智慧监控数据系统和方法 Expired - Fee Related CN111193610B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911207984.XA CN111193610B (zh) 2019-11-30 2019-11-30 一种基于物联网的智慧监控数据系统和方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911207984.XA CN111193610B (zh) 2019-11-30 2019-11-30 一种基于物联网的智慧监控数据系统和方法

Publications (2)

Publication Number Publication Date
CN111193610A CN111193610A (zh) 2020-05-22
CN111193610B true CN111193610B (zh) 2021-11-26

Family

ID=70709486

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911207984.XA Expired - Fee Related CN111193610B (zh) 2019-11-30 2019-11-30 一种基于物联网的智慧监控数据系统和方法

Country Status (1)

Country Link
CN (1) CN111193610B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111708611B (zh) * 2020-07-02 2022-12-23 浪潮云信息技术股份公司 轻量级Kubernetes监控系统及方法
CN112597133A (zh) * 2020-12-29 2021-04-02 深圳复临科技有限公司 一种百人研发团队项目管理场景的数据应用管理系统
CN113329102B (zh) * 2021-08-04 2021-10-29 苏州浪潮智能科技有限公司 一种Ambari Server系统及网络请求响应方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106533804A (zh) * 2016-12-22 2017-03-22 成都西加云杉科技有限公司 一种网络运营支撑系统
CN107294772B (zh) * 2017-05-23 2020-09-01 中电万维信息技术有限责任公司 一种结合Docker实现动态管理监控服务系统
CN107451246B (zh) * 2017-07-28 2021-02-19 深圳航天智慧城市系统技术研究院有限公司 一种适用于大型城市的信息资源一体化处理系统
CN109980776B (zh) * 2017-12-28 2021-04-13 中国电力科学研究院有限公司 一种智能配变系统和该系统的应用方法
CN109542403A (zh) * 2018-10-12 2019-03-29 浙江托普云农科技股份有限公司 一种基于农业物联网PaaS云平台的项目集成系统及项目集成方法
CN109889416B (zh) * 2019-02-18 2020-06-19 西安交通大学 一种基于微服务架构的智能家居系统及构建方法
CN109993506A (zh) * 2019-04-10 2019-07-09 华夏天信(北京)智能低碳技术研究院有限公司 智慧矿山工业物联网操作系统平台性能测试方法
CN110019635A (zh) * 2019-04-10 2019-07-16 华夏天信(北京)智能低碳技术研究院有限公司 一种基于red-mos的煤矿信息化领域系统模型的构建方法

Also Published As

Publication number Publication date
CN111193610A (zh) 2020-05-22

Similar Documents

Publication Publication Date Title
CN107947961B (zh) 基于SDN的Kubernetes网络管理系统与方法
CN111966305B (zh) 持久卷分配方法、装置、计算机设备和存储介质
CN111522628B (zh) 一种基于OpenStack的Kubernetes集群搭建部署方法、架构及存储介质
Toffetti et al. Self-managing cloud-native applications: Design, implementation, and experience
CN111193610B (zh) 一种基于物联网的智慧监控数据系统和方法
US10855543B2 (en) Policy management method and system, and apparatus
US9880827B2 (en) Managing software version upgrades in a multiple computer system environment
CN110462589A (zh) 本地装置协调器中的按需代码执行
CN107493191B (zh) 一种集群节点及自调度容器集群系统
CN105472042A (zh) Web端控制的消息中间件系统及其数据传送方法
CN114138754B (zh) 基于Kubernetes平台的软件部署方法及装置
CN105187512A (zh) 一种虚拟机集群负载均衡方法及系统
CN109075986A (zh) 一种网络功能实例的管理方法及相关设备
CN114615268B (zh) 基于Kubernetes集群的服务网络、监控节点、容器节点及设备
WO2021043124A1 (zh) 一种kbroker分布式操作系统、存储介质和电子设备
CN112230987A (zh) 一种分布式模块化插件框架实现系统及方法
CN113937894A (zh) 一种基于云边协同的电力智能终端管理系统及方法
CN110011984B (zh) 一种基于rest和rpc的分布式集群系统及方法
CN115357375A (zh) 一种面向MPI的Serverless并行计算方法及其系统
US9106676B1 (en) Grid-based server messaging infrastructure
JPH11312079A (ja) 携帯形情報処理装置の制御方法
CN113342456A (zh) 一种连接方法、装置、设备和存储介质
CN111221620B (zh) 存储方法、装置及存储介质
CN115714747B (zh) 基于Kubernetes的集群内部网络流量优化方法、设备、系统及介质
CN112468349B (zh) 适用于FT2000+平台部署Ceph的主节点

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: Unit B, building 11, Mingshi Jiayuan, Mingxin Middle Road, Wujin District, Changzhou City, Jiangsu Province

Applicant after: Zhu Zhenzhen

Address before: No.44, group 1, ajiawati village, tumantal Township, Maigaiti County, Kashi District, Xinjiang Uygur Autonomous Region, 844000

Applicant before: Zhu Zhenzhen

CB02 Change of applicant information
CB02 Change of applicant information
CB02 Change of applicant information

Address after: No.33, Jitai Road, Wuhou District, Chengdu, Sichuan 610000

Applicant after: Zhu Zhenzhen

Address before: 213100 unit B, building 11, mingshijiayuan, mingxinzhong Road, Wujin District, Changzhou City, Jiangsu Province

Applicant before: Zhu Zhenzhen

TA01 Transfer of patent application right

Effective date of registration: 20211108

Address after: Room 17001, 1701, 17th floor, No. 25, Middle East Third Ring Road, Chaoyang District, Beijing 100020

Applicant after: Beijing infinite free culture media Co.,Ltd.

Address before: No.33, Jitai Road, Wuhou District, Chengdu, Sichuan 610000

Applicant before: Zhu Zhenzhen

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20211126

CF01 Termination of patent right due to non-payment of annual fee