基于微服务及大数据的通号智能维护系统的研发及其应用

2020-10-09宋扬

铁路通信信号工程技术 2020年9期

宋扬

(1．北京全路通信信号研究设计院集团有限公司，北京 100070；2．北京市高速铁路运行控制系统工程技术研究中心，北京 100070)

1 概述

本文所介绍的智能维护系统，主要用于对通号各类设备的维护提供帮助，如对设备故障的上报，设备生命周期的追踪，以及设备台账管理等，使售后部门能完全准确掌握通号各产品情况。本文着重对整个智能维护系统的服务设计及服务架构进行阐述：系统各模块采用SpringBoot作为服务基础框架，采用SpringCloud实现微服务架构；工作流使用Activiti,其支持使用Bpmn流程图进行流程的修改与维护，并且各个流程环节采用表单视图和表单数据分离存储的方式（采用非关系数据库Mongodb进行存储），从而实现工作流程的动态可配置；该系统在数据存储及分析方面，应用了一系列大数据工具，采用HDFS分布式存储框架实现文件的上传及存储管理，采用HBase对流程的各个历史状态进行存储，便于后期进行对流程的追溯调查，采用Kafka及Hive进行系统日志的收集及持久化，便于后期对数据进行分析，为实现后期的大数据分析提供了服务支撑。

2 系统各微服务模块设计

2.1 系统微服务架构组成

本系统的微服务架构，主要采用SpringBoot及SpringCloud等框架，分为微服务注册中心(Eureka)，微服务网关模块(Zuul)，通用服务模块，工作流服务模块，设备台账模块。网关模块、工作流模块、通用服务模块及设备台账模块均向注册中心注册，同时它们可以拉取其他微服务模块信息，也可以通过Feign接口调用其他模块服务，实现RPC调用，客户端和网页直接访问网关模块，进而访问各业务模块，系统结构如图1所示。

图1 总系统架构图Fig.1 Overview of system architecture

2.2 微服务注册中心及网关服务

Eureka是Netflix开发的服务发现框架，本身是一个基于REST的服务，用以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目中，以实现SpringCloud的服务发现功能。在本系统中，Eureka部署为两个节点，互相注册并合并各模块注册信息，其他模块也进行双节点高可用部署，作为Consumer注册在Eureka上。运维人员可以通过Eureka相关接口查看各节点的健康情况，并进行节点的启用或移除处理，进而实现节点平滑的下线或是升级处理。

Zuul是Netflix开源的微服务网关，可以和Eureka、Ribbon、Hystrix等组件配合使用。SpringCloud对Zuul进行了整合与增强，主要功能是路由转发和过滤器，在本系统中，客户端直接访问Zuul模块,网关模块与注册中心进行通信，将用户请求路由到各个子模块，方便了客户端的访问。同时，Zuul可以配置多个Filters,进行用户的权限判断及控制，进而实现返回数据的定制，如各个角色用户不同客户端功能页面的展示，方便了不同角色的用户使用。

2.3 各具体业务模块介绍

通用服务模块主要用于用户的注册，注册用户的审核等功能。用户登录验证通过后，获取一定有效时间的令牌，其存储于Redis实现各模块间的共享，并且可以通过令牌从Redis中获取用户的相关权限信息。此外，通用服务也集成了文件上传和下载的功能，获取用户信息的功能，其他模块可以通过Feign接口调用这些服务，实现服务间的RPC调用。

工作流服务模块用于流程的创建及管理，设备故障的上报等具体流程业务的实现。该模块的工作流功能主要通过BPM框架Activiti实现。SpringBoot也提供Activiti对应的支持库，在项目中导入编辑好的工作流程图（Bpmn文件）即可将对应的工作流数据结构导入，其示例如图2所示。流程的每一个环节的表单视图在后期可能根据实际需求有多次修改，本系统在设计时为了缩减开发及后期维护成本，通过表单视图和表单数据分离储存的方式（储存于Mongodb中），实现了各表单视图的动态可配置。业务原理为：工作流服务启动后，Activiti相关类实例化并自动注入，扫描项目路径下的Bpmn文件并将其转换为工作流结构对应的数据结构存储于内存中，Bpmn文件示例如图2所示；客户端可以通过接口获取流程数据结构，包括流程的各环节名称以及环节ID，管理员通过客户端对各环节的表单视图进行定制及上传，视图中的各个输入项具有唯一的ID以及权限配置；用户获取空的表单视图后填入数据并上传，各输入项数据中也包含输入项视图ID；表单数据回显时，数据通过输入项ID和流程实例ID和表单视图进行绑定，并且根据各输入项的权限配置对数据进行读写权限控制，进而实现了数据回显，客户端显示效果如图3所示。

图2 流程图示例Fig.2 An example of flowchart

图3 流程表单示例Fig.3 An example of flowchart form

设备台账模块主要用于通号设备的管理，包括设备的录入，生命周期追溯及管理等。由于每一类设备具有不同的属性，属性名和属性个数以及录入展示形式均有不同，采用传统的关系型数据库（如MySQL）实现该需求难度较高，故而采用非关系型数据库Mongodb将设备属性分为固定属性（固定字段）和扩展属性（可变字段）进行存储。其中固定属性与传统关系型数据库字段类似，扩展属性采用json格式进行序列化后以字符串形式进行存储，进而实现不同设备不同属性的定制。

3 大数据工具在系统中的应用

3.1 HBase在系统中的应用

HBase是一个分布式的、面向列的开源数据库,以HDFS作为底层的存储服务。它与传统的面向行的关系型数据库不同，在水平方向有一个或多个列簇组成，每个列簇可以有任意多个列组成。HBase的每一单元由一个唯一的Row Key确定，但其更新数据时，不会删除原有的数据，而是增加一个新的版本。在本系统中，以流程名称和流程实例ID作为RowKey,一个流程在提交数据到数据库后，也提交相应的数据到HBase,作为该流程的一个新的版本，新版本的数据和上一版本的数据可以进行对比，生成一条对比日志并存储于Mongodb上。流程的处理人员或是处理人员可以查看流程的处理记录，进行流程后期的朔源及调查。

3.2 Kafka以及Hive在系统中的应用

当本系统投入使用后，会产生大量的可用数据，如各地区电务段用户、各工厂用户、各分部用户使用智能维护系统的活跃数据，又比如各类产品设备的故障情况，对于这些数据的分析，可以产生很多具有价值的结论，如哪类产品或是哪个电务段的产品故障较多，又或是出现最多的故障类型等。这就需要将数据收集，供以后分析。

考虑到上述需求，采用Kafka作为数据收集的消息队列，其具有高吞吐量，高可用的特点，本系统所搭建的Kafka具有3个Broker节点，建立Topic时可以将消息备份设置为3，当一台Broker宕机后，还有2个备份可以使用，不会丢失消息。在实际使用时，本系统在需要收集数据的每一个接口上进行切面增强，获取提交的数据信息，将其发送到对应的Kafka消息主题，避免了过多的编程工作及代码耦合。在数据存储方面，采用Hive作为数据仓库，其采用HDFS作为底层存储服务，可以对海量数据进行离线的处理及分析，除了支持MapReduce进行数据计算外，也支持类sql语句对数据进行分析计算。

消息到达Kafka后，需要将消息进行消费并储存。在本系统中，采用Flume消费Kafka的消息数据并下沉到Hive,对后期数据分析进行数据支持。数据收集服务架构如图4所示。