CN112379640B - 分布式智能感知控制器 - Google Patents

Abstract

本发明涉及一种智能感知控制器，属于大数据处理技术领域，具体是涉及一种分布式智能感知控制器。包括：若干组独立带存储的计算单元，至少2块以太网数据交换模块，其中，物理上各计算单元相互独立，交换模块分为外网数据交换和内网数据交换。因此，本发明具备以下优点：(1)同时提高多计算单元对数据的预处理能力；(2)支持可扩展功能，单计算单元可以兼容系统性能和容量升级。随着系统计算能力和数据量的提升，硬件可以根据需求更换高性能计算模块和交换模块以满足系统的能力；(3)维修售后更便捷，当单个计算单元损坏，可以快速更换而不需要整机更换，缩短运维维护时间和成本。

Description

分布式智能感知控制器

本发明涉及一种智能感知控制器，属于大数据处理技术领域，具体是涉及一种分布式智能感知控制器。

背景技术

地铁行业的设备与服务状态监控，关系到整个地铁运行的安全与稳定，对数据的高可靠、高可用以及安全性都有很高的要求标准。

目前设备与服务状态监控存在以下问题：

(1)单一服务器部署监控服务，容易出现设备单点故障问题。

(2)多节点多台服务器部署监控服务，成本大幅增加，资源浪费。

(3)监控服务部署在业务集群内，服务器资源容易被主要业务占用，从而导致监控系统性能降低，出现卡顿甚至崩溃等问题。

(4)设备与服务的故障类型需要人为判断，并且没有与运维策略智能结合，运维难度大,成本高。

分布式智能感知控制器，未来可结合嵌入式技术，将单一计算节点拆分为瘦终端设备，结合温湿度等环境感应设备，5G通信技术，特征识别及处理，具体包括但不限于图像识别与处理、声音识别与处理等技术，提供边缘计算能力。可将瘦终端设备安置于地铁运行的各个环境与设备当中，对地铁各个专业设备、设备周围环境实时监测。感知系统全面对接地铁中各个子业务系统接口与设备接口，通过终端设备对不同环境下的瘦终端设备，下发不同的计算模型，智能诊断分析设备状态，对设备出现的故障进行智能化运维，并将运维结果同步至上层终端设备。充分结合大数据技术，利用大数据集群的分析、计算能力，对故障数据、运维数据进行大数据分析，实现设备故障预测预警，运维方案智能推荐，使地铁运维更加信息化、智能化。

此外，针对当前常见的两地双数据中心的架构设计而言，两地两个数据中心需要安装、部署并运行相同的大数据的服务，同时向上层应用提供稳定安全可靠的数据服务。数据中心作为新时代轨道交通项目的关键核心，中心的安全稳定运行，将直接影响整个轨道交通项目的安全稳定运行。对数据中心的健康状态，具体包括但不限于数据中心各个设备的健康状态、各个服务的健康状态以及数据的健康状态的监测，就显得尤为重要。当任一数据中心出现故障导致数据丢失时，还需要对双中心的数据进行同步。

并且，现有大数据平台监控系统常见Web应用，都是基于传统B/S的MVC三层架构。通常包含，最前端的视图展示层，中间的调度控制层，以及后台的应用模型层。而且软件的安装部署，一般都是在数据中心的集群内进行部署并运行。当集群出现故障导致数据丢失时，需要人工线下去确定需要数据同步的内容，并手动进行数据同步。

现有大数据平台监控系统从功能上，无法对当集群出现故障后，集群的数据是否完整进行检测告警。数据同步只能人工线下确认并执行。由于数据中心数据可能出现的不健康、不完整的状况，可能使用户在一定程度上无法正常使用系统。从系统架构上，传统的三层垂直架构，一旦任意一层出现故障，将会导致整个系统宕机。部署没有从监测的集群中独立出来，很容易受到集群系统资源分配不均，导致系统卡顿，延时。当集群宕机时，监控系统也会随之宕机。这样的架构，无法满足轨交行业高可靠高可用的特殊性。

发明内容

以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。

本发明主要的目的是解决现有技术中所存在的上述的技术问题，提供了一种分布式智能感知控制器。本发明的方案是：

一种分布式智能感知控制器，包括：若干组独立带存储的计算单元，至少2块以太网数据交换模块，其中，物理上各计算单元相互独立，交换模块分为外网数据交换和内网数据交换。

优选的，上述的一种分布式智能感知控制器，包括6组独立计算单元，该6组独立计算单元被划分为每3组一种独立供电，共2路供电线路。

优选的，上述的一种分布式智能感知控制器，每个计算单元和外部的数据交换通道有2路，每个交换模块均可对外进行数据交换，外界可以通过2个交换模块对计算单元进行访问。

优选的，上述的一种分布式智能感知控制器，在系统软件上采用基于B/S三层结构体系架构，具体包括：

持久层，用于实现业务数据的存储，用于响应数据请求并调取MySQL服务器以返回相应的数据请求结果；

中间层，包括表示层逻辑以及业务层逻辑，所述业务层逻辑用于实现对数据业务逻辑处理并向持久层发送数据请求；所述表示层逻辑用于显示数据和接收用户的请求，并调用所述业务层逻辑实现数据的处理；

应用层，用于实现对中间层的调用以完成具体的业务应用。

因此，本发明具备以下优点：

(1)同时提高多计算单元对数据的预处理能力。

(2)支持可扩展功能，单计算单元可以兼容系统性能和容量升级。随着系统计算能力和数据量的提升，硬件可以根据需求更换高性能计算模块和交换模块以满足系统的能力。

(3)维修售后更便捷，当单个计算单元损坏，可以快速更换而不需要整机更换，缩短运维维护时间和成本。

附图说明

并入本文并形成说明书的一部分的附图例示了本发明的实施例，并且附图与说明书一起进一步用于解释本发明的原理以及使得所属领域技术人员能够制作和使用本公开。

图1例示了本发明实施例中的分布式智能感知控制系统体系结构图；

图2例示了本发明实施例中的分布式智能感知控制系统网络图；

图3-10例示了本发明实施例中的分布式智能感知控制系统业务流程图。

图11例示了本实施例分布式智能感知控制系统硬件结构布局图；

图12例示了本实施例分布式智能感知控制系统内部数据交互图。

将参照附图描述本发明的实施例。

具体实施方式

实施例

下面对本实施例提供的分布式微服务架构数据中心智能感知控制系统及方法进行详细介绍。

1.分布式智能感知控制系统体系结构

本实施例系统采用B/S三层结构的体系结构，如图1所示。系统包括持久层，中间层，上层应用这三个层次。

其中，持久层包括业务层以驻数据库。中间层通过业务持久层操作数据库。业务持久层包括用户权限模块，数据同步模块，服务状态模块等。

中间层包括业务逻辑层和表示逻辑层。其中，业务逻辑层用于和业务持久层通信，其包括用户权限模块，数据同步模块，服务状态模块。表示逻辑层与业务逻辑层和上层应用通信。其中，表示逻辑层包括用户登录模块，同步审核列表模块，服务状态曲线模块，服务状态列表模块等。

上层应用包括感知平台终端，上层网管平台终端，上层系统平台终端，第三方平台终端等。

2.分布式智能感知控制系统网络

分布式智能感知控制系统网络如图2所示。整体架构采用双中心相互监测的方式进行，这样可以有效防止一端智能感知服务器宕机后，无法对集群进行监控预警，从而保证集群的安全和高可用。各中心系统的控制系统监测和控制集群内的业务结点，并且与其它中心的分布式控制系统通信。

3.分布式智能感知控制系统架构

分布式智能感知控制系统采用SpringCloud微服务架构开发，将多节点的业务逻辑层服务模块software和业务持久层服务模块dao注册到以Eureka集群作为服务注册中心中。从而达到系统服务之间的“高效率”、“负载均衡”、“高可用”等优点。系统对外开放路径，则由nginx作为网关，进行反向代理和负载均衡处理。优势在于避免将服务真实路径在外网状态下暴露出来，降低风险。

分布式智能感知控制系统从请求到入库的总体流程:

外部终端登陆平台并发起HTTP请求，nginx接收到请求，通过反向代理，代里到目前负载最低的业务逻辑层服务模块software(N)中，业务逻辑层服务模块software(N)处理完毕自身逻辑之后，通过eureka服务注册中心集群，找到目前负载最低的业务持久层服务模块dao(M)的网络路径，并将剩余任务通过网络路径发送给业务持久层服务模块dao(M)，业务持久层服务模块dao(M)调取MySQL服务器，并与之进行交互。交互完毕，向外部终端返回相应的信息结果。

4.分布式智能感知控制系统模块

分布式智能感知控制系统包括：状态检测模块、数据同步模块、故障告警模块、Web服务模块。

状态检测模块包括：

(1)服务健康状态监测：分布式智能感知控制系统定时监测双中心的大数据平台各项服务状态，更新系统平台实时的服务状态；如果服务状态不是“健康”则将此状态按照服务类型分类，记录下来。此外，每隔半个小时，系统会将所有服务目前的状态进行一次记录。服务状态监测模块流程如图4所示。

(2)硬件健康状态监测

分布式智能感知控制系统定时监测部署系统主机的各项硬件指标状态(包括处理器CPU、内存MEM、存储DISK的使用情况，网卡信息NIC、主要服务进程THREAD的状态等)，更新系统平台实时的硬件指标状态；如果硬件指标状态不是“健康”则将此状态按照硬件指标类型分类，记录下来。此外，每隔半个小时，系统会将所有硬件指标目前的状态进行一次记录。其中，监测硬件指标状态由python语言开发，状态筛选以及记录逻辑算法由java语言开发。硬件指标状态监测模块流程如图5所示。

(3)流任务健康状态监测：分布式智能感知控制系统定时监测双中心的大数据平台各项指定流任务的运行状态，更新系统平台实时的流任务运行状态。流任务运行状态监测模块流程如图6所示。

本实施例中，数据同步模块的应该满足数据同步操作的可靠性，安全性，高性能和可管理的原则。

(1)数据同步的可靠性

依托于分布式智能感知控制器提供的服务实时监测，平台根据中心监控到的故障时间，产生数据同步任务。分布式智能感知控制器，软件系统采用分布式架构，微服务多节点部署，硬件同样以分布式架构为基础，运用超融合理念，以此来保证服务的高可靠和高可用。

(2)数据同步的安全性

分布式智能感知控制系统采用安全协议，并针对不同用户设置权限，对各个敏感操作有完整的日志记录。大数据平台也拥有独立的，级别更高的安全验证，为数据的敏感操作提供了安全保证。

(3)数据同步的高性能

针对不同场景下的数据同步，采用不同的同步方式，将任务根据计算能力拆分为多个小任务，批量执行，保证数据同步的高性能。

(4)数据同步的可管理性

数据同步的申请、审核、同步以及停止当前同步等操作，依托于分布式智能感知控制系统，它提供了一个可视化的WEB界面，运维人员可以通过登录分布式智能感知控制系统，就可以对数据同步进行各项操作。不同用户在系统中拥有不同的权限，以此保证数据同步的可管理。

数据同步方案设计有以下五大要点：

下面介绍数据同步的判定规则。

通过对大数据主要服务进行分析：

1.消息队列(kafka)服务宕机时，底层数据源会重新上传缺失数据，不需要进行数据同步。

2.当分布式数据库(Hbase)服务宕机时，会导致数据无法正常写入，从而造成数据丢失。但与此同时，流式计算服务(Slipstream)也会出现服务宕机。

3.当流式计算服务(Slipstream)出现服务宕机，没有数据写入分布式数据库(Hbase)，也会造成数据丢失。

根据以上情况分析可知：数据同步的产生一般只有一种情况，那就是当流式计算服务(Slipstream)中的任意一个流任务(Job)出现异常时，就会造成集群故障，数据缺失，需从另一端健康中心同步缺失数据。

下面介绍数据同步的策略。

目前中心间数据同步有如下几种方式：Hbase层有如下两种方式：CopyTable，Snapshot。

数据同步大致可分为两种，一种是当月数据同步，一种是跨月数据同步。当月数据同步需要满足，同步时间灵活，同步尽可能不影响写入业务。跨月数据同步则尽量保证同步效率。

当同步任务在当月时，选择CopyTable方式进行数据同步，当任务跨越时，选择Snapshot方式进行数据同步。

下面介绍数据同步的任务切分。

数据同步任务的大小，跟故障中心的故障时间有关，当故障中心的服务宕机时间越长时，数据同步的任务量就会越大，由于数据同步的执行方式为Copytable或Snapshot方式，底层实现机制决定了，数据同步过程中无法支持断点续传，当我们一次同步任务执行过程中，受到主观人为干预或者客观条件影响时，任务就会执行失败，同步数据回滚。这种同步方式，执行周期长，影响因素多，同步失败率高。

本实施例中，根据现有计算能力，以及平均预估闲事时长的大致范围，将超过一定天数的数据同步任务进行任务切分。将一个大任务，切分为多个小任务，批量执行。以此提高了数据同步的成功率，缩短每个任务的执行周期，降低了影响因素对数据同步的影响。

下面介绍数据同步的执行方式转换。当前大数据中心表设计是基于每个车站，按月建表。那么，故障时间如果设计跨月，我们不但要同步不同的数据表，而且要将同步方式，按照我们之前提出的方案。进行方式转换，将上月的未同步的大于一条的CopyTable任务，全部转换为SnapShot的方式进行数据同步。这个过程，我们也将在分布式智能感知控制系统的后台中完成。对用户来说，是完全无感的，用户只需要对未同步以及同步失败的任务进行数据同步即可。

下面介绍数据同步的同步审核。当故障中心需要执行数据同步操作时，我们必须确保对端健康中心的所有服务是健康的，并且资源是足够提供数据同步服务的。由于两地双中心相隔距离比较远，如果无法及时获取对端中心现在的运行状态以及中心的负载状态，就不能保证数据同步的可靠性，所以，像对端中心审核数据同步任务，是必要的。本实施例中，需要向对端健康中心审核数据同步任务，在对端中心确认可以执行时，才可以执行同步。由于人工操作，在某种程度上有一定的不可靠性，而集群的状态每个时刻都是不同的，则设定我们审核成功的状态，有一定的过期时间，审核过期后需要运维人员重新审核，才可以继续执行数据同步任务。

本实施例的数据同步整体流程图如图7所示。数据同步整体流程包括健康状态检测、数据同步任务审核以及数据同步执行等。根据流程可将流程分为三个模块，即数据同步健康检测模块、数据同步审核模块以及数据同步执行模块。

数据同步健康检测模块流程图如下图8所示。健康检测模块主要对流服务以及流服务中的各个流任务进行状态监控，当检测到任务状态异常时，需要记录异常服务出现的最后一次健康检测时间。等待故障恢复后，将再次更新服务健康时间，当判定两次健康时长大于我们的检测周期，同时也大于预设定的检测阈值时，判定中心需要数据同步，并同时产生数据同步任务，系统针对现有计算能力，对任务进行任务切分，并将所有任务存入分布式智能感知控制系统的数据库中，前端运维人员可在分布式智能感知控制系统的前端可视化页面中查询当前需要数据同步的任务信息。数据同步审核模块流程图如图9所示。

数据同步审核模块主要功能有，当运维人员操作提交数据同步任务审核，对端中心运维人员根据现有条件，判断是否可以进行数据同步，如果不可以，则拒绝同步申请，如果可以，则通过同步申请，故障端运维人员就可以在分布式智能感知控制系统的页面上操作数据同步。如果审核通过，但故障端人员未操作同步，则超过我们预设的阈值时，数据同步任务的状态改为审核过期，需重新审核才可再进行同步。

数据同步执行模块流程图如图10所示。数据同步执行模块主要功能有，执行数据同步任务，与停止数据同步任务等。当运维人员可在分布式智能感知控制系统页面，批量操作审核通过的数据同步任务，后台会上传数据同步任务文件到大数据平台，上传成功后，调用数据同步脚本，执行数据同步任务。同步结束时，会将同步结果返回给感知前端页面，方便运维人员掌握同步进度。

同步过程会占用大量系统资源，在一定程度上会造成查询缓慢等情况，所以建议同步尽可能选在业务闲事进行操作，当有应急任务或突发情况时，运维人员可手动停止所有同步作业，以此来保证正常业务不被同步影响。

通过以上描述可知，本发明具备以下优点：

(1)将线下数据同步功能转变为线上可视化功能，降低运维难度，降低运维成本。根据分析算法，智能切分、整合数据同步任务，并提供审核机制，运维人员可以灵活配置，根据项目情况和需求，选择相应的数据同步任务执行，并可以及时有效的控制数据同步流程。

(2)将监控从集群中独立出来，利用分布式结合微服务的技术，避免了从软件到硬件的单点故障问题，提升了设备以及系统的可靠性以及可用性级别。

(3)通过智能分析诊断算法，分析诊断数据中心的各个服务健康状态，并对集群状态，数据状态做出准确的评估。在健康数据积累到一定程度，还可以对服务状态及故障等数据进行数据挖掘，根据算法，提供故障预测，以及智能化运维功能。

5.分布式智能感知控制系统硬件结构

分布式智能感知控制系统硬件集成多计算处理CPU和多数据交换模块，解决传统控制系统中多计算单元和外界交换数据交换单一的问题。同时提高多计算单元对数据的预处理能力。结构布局如图11所示。

系统硬件配置为6组独立带存储的计算单元，2块以太网数据交换模块，物理上各计算单元相互独立，交换模块分为外网数据和内网数据交换；6组独立计算单元又被划分为每3组一路独立供电，共2路供电；

支持可扩展功能，单计算单元可以兼容系统性能和容量升级。随着系统计算能力和数据量的提升，硬件可以根据需求更换高性能计算模块和交换模块以满足系统的能力。

维修售后更便捷，当单个计算单元损坏，可以快速更换而不需要整机更换，缩短运维维护时间和成本。

本实施例的分布式智能感知控制系统内部数据交互如图12所示。单个计算单元可分别通过2个交换模块进行数据交互，即每个计算单元和外部的数据交换通道有2路。2个交换模块均可对外进行数据交换，外界可以通过2个交换模块对计算单元进行访问。

注意到，说明书中对“一个实施例”、“实施例”、“示例实施例”、“一些实施例”等的引用指示所描述的实施例可以包括特定特征、结构或特性，但是每个实施例可以不必包括所述特定特征、结构或特性。而且，这样的短语不必指代同一实施例。此外，当结合实施例描述特定特征、结构或特性时，无论是否明确描述，结合其他实施例来实现这样的特征、结构或特性将在所属领域的技术人员的知识范围内。

提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。

Claims (5)

1.一种分布式智能感知控制器，其特征在于，包括：若干组独立带存储的计算单元，至少2块以太网数据交换模块，其中，物理上各计算单元相互独立，交换模块分为外网数据交换和内网数据交换；

其中，状态检测模块的服务健康状态监测包括：分布式智能感知控制系统定时监测双中心的大数据平台各项服务状态，更新系统平台实时的服务状态；如果服务状态不是“健康”则将此状态按照服务类型分类，记录下来；此外，每隔半个小时，系统会将所有服务目前的状态进行一次记录；

状态检测模块的硬件健康状态监测包括：分布式智能感知控制系统定时监测部署系统主机的各项硬件指标状态，更新系统平台实时的硬件指标状态；如果硬件指标状态不是“健康”则将此状态按照硬件指标类型分类，记录下来；此外，每隔半个小时，系统会将所有硬件指标目前的状态进行一次记录；

状态检测模块的流任务健康状态监测包括：分布式智能感知控制系统定时监测双中心的大数据平台各项指定流任务的运行状态，更新系统平台实时的流任务运行状态；

其中，数据同步的可靠性依托于分布式智能感知控制器提供的服务实时监测，平台根据中心监控到的故障时间，产生数据同步任务；分布式智能感知控制器，软件系统采用分布式架构，微服务多节点部署，硬件同样以分布式架构为基础，运用超融合理念，以此来保证服务的高可靠和高可用；其中，分布式智能感知控制系统包括：状态检测模块、数据同步模块、故障告警模块、Web服务模块；

所述数据同步模块进一步包括：

数据同步健康检测模块、数据同步审核模块以及数据同步执行模块；

健康检测模块对流服务以及流服务中的各个流任务进行状态监控，当检测到任务状态异常时，记录异常服务出现的最后一次健康检测时间；等待故障恢复后，将再次更新服务健康时间，当判定两次健康时长大于我们的检测周期，同时也大于预设定的检测阈值时，判定中心需要数据同步，并同时产生数据同步任务，系统针对现有计算能力，对任务进行任务切分，并将所有任务存入分布式智能感知控制系统的数据库中，前端运维人员可在分布式智能感知控制系统的前端可视化页面中查询当前需要数据同步的任务信息；

数据同步审核模块的流程包括：当运维人员操作提交的数据同步任务审核，对端中心运维人员根据现有条件，判断是否可以进行数据同步，如果不可以，则拒绝同步申请，如果可以，则通过同步申请，故障端运维人员就可以在分布式智能感知控制系统的页面上操作数据同步；如果审核通过，但故障端人员未操作同步，则超过预设的阈值时，数据同步任务的状态改为审核过期，需重新审核才可再进行同步；

数据同步执行模块用于执行数据同步任务与停止数据同步任务；当运维人员可在分布式智能感知控制系统页面，批量操作审核通过的数据同步任务，后台会上传数据同步任务文件到大数据平台，上传成功后，调用数据同步脚本，执行数据同步任务；同步结束时，会将同步结果返回给感知前端页面。

2.根据权利要求1所述的一种分布式智能感知控制器，其特征在于，包括6组独立计算单元，该6组独立计算单元被划分为每3组一种独立供电，共2路供电线路。

3.根据权利要求1所述的一种分布式智能感知控制器，其特征在于，每个计算单元和外部的数据交换通道有2路，每个交换模块均可对外进行数据交换，外界可以通过2个交换模块对计算单元进行访问。

4.根据权利要求1所述的一种分布式智能感知控制器，其特征在于，在系统软件上采用基于B/S三层结构体系架构，具体包括：

持久层，用于实现业务数据的存储，用于响应数据请求并调取MySQL服务器以返回相应的数据请求结果；

中间层，包括表示层逻辑以及业务层逻辑，所述业务层逻辑用于实现对数据业务逻辑处理并向持久层发送数据请求；所述表示层逻辑用于显示数据和接收用户的请求，并调用所述业务层逻辑实现数据的处理；

应用层，用于实现对中间层的调用以完成具体的业务应用。

5.根据权利要求1所述的一种分布式智能感知控制器，其特征在于，采用SpringCloud微服务架构开发，将多节点的业务层逻辑服务模块software和持久层的业务技久服务模块dao注册到Eureka服务框架中，并对外开放路径，由nginx作为网关进行反向代理和负载均衡处理。

Images