CN113157796A - 一种基于微服务的数采展示系统 - Google Patents

Abstract

本发明涉及一种基于微服务的数采展示系统，包括：浏览器前端框架，采用B/S架构进行前端数据的展示，通过WebSocket方式与微服务连接；微服务，包括实时数据微服务、离线数据微服务、配置微服务，连接现场设备和数据库，用于采集设备的离线数据、实时数据以及配置采集参数；SpringCloud及其组件，包括网关Zuul、注册中心Eureka、配置中心Config、服务调用Feign、熔断器Hystrix，用于对微服务进行管理。本发明通过微服务架构管理数据采集与展示，能够将各个终端的实时数据传输、离线数据展示、功能配置等各个功能解耦。在实现功能的同时，提升了系统的可靠性和可扩展性。

Description

一种基于微服务的数采展示系统

技术领域

本发明属于软件架构领域，具体的说是一种基于微服务的数采展示系统。

背景技术

微服务架构是一种将功能分散、对应各个服务要求进行解决并最终组合在一起的服务方式。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。通常情况下，一个微服务架构会根据系统需求采取一组解决方案来构建一个应用，使每个分系统、分功能能够在相对独立的情况下运转；保持单独分系统实现独立运转的同时又能够进行轻量级的交互通信，进而使多个分系统组成一个完整的系统。微服务架构如此的服务方式可以有效保持分系统的独立运转和扩展与延伸，为每个分系统之间实现了划分、使每个分系统都可以单独地进行维护和替换，又在交互通信的推动下协同作业，使整个系统分而不散，有机结合。微服务架构主要拥有以下优点：

(1)通过服务实现应用的组件化：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。

(2)智能端点与管道扁平化：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTFULHTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。

(3)去中心化治理：微服务架构鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。

(4)去中心化数据管理：微服务架构倡导采用多样性持久化的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。

发明内容

针对现有框架在数据采集及展示方面的上述不足，本发明提出一种基于微服务的数据采集展示系统。

一种基于微服务的数采展示系统，包括：

浏览器前端框架，采用B/S架构进行前端数据的展示，通过WebSocket方式与微服务连接；

微服务，包括实时数据微服务、离线数据微服务、配置微服务，连接现场设备和数据库，用于采集设备的离线数据、实时数据以及配置采集参数；

SpringCloud及其组件，包括网关Zuul、注册中心Eureka、配置中心Config、服务调用Feign、熔断器Hystrix，用于对微服务进行管理。

所述实时数据微服务根据不同试验台，到配置微服务的服务调用Feign中拉取数据采集的方式以及数据采集的变量配置。

所述离线数据微服务通过连接数据库中的离线数据获取历史数据信息，返回给前台进行展示，其在后台处于休眠状态、当实时数据微服务出现故障或者手动切换时启动。

所述配置微服务用于设置离线数据与实时数据的切换、实时数据采集的协议配置、前台变量展示的配置以及离线工况的配置；

离线数据与实时数据的切换，为在前端页面中供用户手动设置，并作为离线数据微服务事件监听的输入源；

离线工况配置，获取离线工况信息提供给离线数据微服务；

前台变量展示配置，用于设置前台展示数据的结构、组成和样式；展示结构包括折线图、柱状图、饼状图。

所述网关Zuul作为接口，用于转发多客户端、多窗口、多图形的并发访问请求，将外部的请求访问转换为内部的请求访问，并负责WebSocket的全双工通道的保持。

所述注册中心Eureka用于对各个微服务进行监控、注册、管理，供外部或内部调用。

所述配置中心Config包括客户端Client和服务端Server两个部分，服务端提供配置文件的存储、及其调用接口，客户端通过调用接口获取数据、并依据该数据初始化应用。

所述服务调用Feign包括如下调用接口：1)离线微服务对配置微服务的离线状态监控调用、工况切换调用；2)实时数据微服务对配置微服务的数据采集配置调用；3)前台访问对配置微服务变量展示配置的调用。

所述熔断器Hystrix用于在前台访问激增时能够判断微服务的响应状态，当连续多次调用服务不响应时，通知调用端调用失败。

本发明的有益效果是：

在一种基于微服务的数据采集展示架构中，将微服务架构引入到传统的数据采集与展示系统中，将设备的离线数据采集、实时数据采集、采集配置封装成微服务，通过Eureka注册中心、Config配置中心、Feign服务调用、Hystix熔断器、Zuul网关等进行管理。在满足实时、离线数据切换展示及配置需求的基础上，提升了系统的稳定性和可维护性。

附图说明

图1是一种基于微服务的数采展示系统的架构图。

图2是OPC数据采集流程。

图3是离线微服务切换流程。

图4是前台数据展示配置流程。

图5是OPC数据采集配置流程。

具体实施方式

下面结合附图对本发明做进一步的详细说明。

在工业现场需要部署大量的运行终端，对现场设备、仪器、产线的运行逻辑进行控制，运行终端包括可编程逻辑控制器、机械手、专机设备等。

在终端的运行过程中往往需要获取终端的运行状态，如空闲、运行、停止、故障等；或者获取终端的运行参数，如电流、电压、温度等；或者获取终端的生产参数，如生产数量、品质等。由于这些信息存在于终端内部，无法直接被用户所读取，就必须通过数据采集手段，将终端的运行状体、运行参数、生产参数采集到服务器，进行汇总与分类存储。

在数据采集的同时将数据推送给前端进行不同形式的图形化展示，其中包括折线图、柱状图、饼图、条形图等，根据采集到的数据变化而驱动图形的展示变化。对于一些特殊的数据展示需求，如果由于网络或设备故障原因，导致实时数据无法采集，那么就需要切换到离线数据的展示，利用在数据库中存储的离线信息绘制展示图表。在切换的过程中不能够产生页面的卡顿或刷新的情况，且需要能够重新切换回实时数据。

在传统架构下，如果在多种设备同时并发采集和展示的过程中，由于某个设备发生异常，或者需要进行升级，导致数据无法采集，必须停机维护和调试时，就会影响到其它正常设备的数据采集与展示。无法应对设备变更的突发情况。

如图1所示，微服务云SpringCloud包括三个核心微服务及其组件。框架采用B/S架构进行前端数据的展示，浏览器端通过WebSocket方式与服务器连接。WebSocket为全双工通道，以往架构下一般采用轮询方式访问后台数据，即设置一个访问周期，每间隔访问周期即向后台请求一次数据，后台给出应答后再展示数据。这样的缺点在于需要频繁访问服务器资源，当多终端并行访问时，会给网络资源和服务器资源造成不必要的访问压力。建立WebSocket的全双工访问通道，可以只建立一次终端与服务器的访问连接，即可以不受限制的发送数据，实现服务器到终端的数据推送。

数据呈现的核心在微服务上，为了满足数采展示系统的需求，在后台提供了三种微服务，包括实时数据微服务、离线数据微服务、配置微服务。每个试验台都具备以上三种微服务，实现了试验台数据采集、展示的解耦，下面分别详细说明三种微服务的实现方式。

实时数据微服务运行数据采集程序，通过现场总线与设备连接，按照配置的数据采集协议连接设备进行数据采集。如图2所示，以OPC数据采集协议为例，实时数据采集流程如下：

步骤1：启动一次数据OPC数据读取程序，遍历所有的OPC Server，若没有Server信息，则返回采集错误；

步骤2：选定目标Server并建立连接；

步骤3：选择是否建立缺省组，如果需要自定义组，可以为自定义组命名；

步骤4：添加变量组；

步骤5：判断读操作或者是写操作，如果为读操作则进入步骤6，如果为写操作则进入步骤8；

步骤6：执行读操作，判断是否读取结束，如果结束则进入步骤7，如果没结束则返回步骤5；

步骤7：将读取到的数据存储于内存或者外存，结束；

步骤8：执行写操作，选择需要写入的变量；

步骤9：写入数据，结束。

实时数据微服务需要与配置微服务之间打通数据接口，通过Feign进行服务调用，后续会进行详细说明。其中实时数据微服务需要根据不同试验台的配置情况，到配置微服务中拉取数据采集的方式以及数据采集的变量配置。

离线数据微服务通过连接数据库中的离线数据，获取历史数据信息，在Redis缓存中形成离线数据记录，返回给前台进行展示。离线微服务作为备用微服务在后台处于休眠状态，当实时数据微服务出现故障或者手动切换到离线数据微服务时，离线数据微服务启动。如图3所示，具体切换流程如下：

步骤1：持续监听事件，直到获取到事件为止，事件包括实时数据微服务故障或者手动切换为离线数据微服务；

步骤2：根据事件信号获取试验台编号；

步骤3：连接Redis缓存，根据试验台编号，获取对应的离线数据；

步骤4：判断试验是否为进行中，如果为进行中，则进入步骤5，否则进入步骤6；

步骤5：调用配置微服务获取当前的离线工况信息，拿到工况相关离线数据；

步骤6：将试验离线数据和工况信息返回给前台；

步骤7：判断试验是否为结束状态，如果为结束状态，则流程结束，如果为进行中则返回步骤4。

配置微服务主要用于设置离线数据与实时数据的切换、实时数据采集的协议配置、前台变量展示的配置以及离线工况的配置。

其中离线数据与实时数据切换的功能在页面中供用户手动设置，设置的结果在离线数据的微服务中作为事件监听的输入源，当用户设置了数据为离线数据，则离线数据微服务启动，向前台返回离线数据。

其中离线工况配置也是供离线微服务使用，在离线微服务的步骤5中，获取到离线工况信息，加入到试验数据中，返回给前台。

实时数据采集的协议可以采用OPC数据采集协议、Modbus串行通信协议、MQTT协议、Web Server协议、西门子S7COM协议。

其中前台变量展示配置是设置前台展示数据的结构、组成和样式等，如图4所示，目前能够支持的展示结构包括折线图、柱状图、饼状图。如果为柱状图，配置包括：选择试验台变量、设置横坐标单位及刻度、设置纵坐标单位及刻度、设置方向、设置标题及样式。如果为折线图，配置包括：选择试验台变量、设置横坐标单位及刻度、设置纵坐标单位及刻度、设置标题及样式。如果为饼状图，设置包括：选择试验台变量、设置对比维度、设置标题及样式。

其中实时数据采集的协议配置是对数据采集的各个数据变量以及采集方式进行设置。如图5所示，以OPC数据采集配置为例，流程如下：

步骤1：选择数据采集协议，为OPC；

步骤2：设置OPC Server信息，包括IP地址和Server Name；

步骤3：新增OPC Tag；

步骤4：设置变量数据类型；

步骤5：设置变量采集频率；

步骤6：设置变量单位；

步骤7：判断是否为最后一个变量，如果不需要录入则结束，需要继续录入则返回到步骤3。

三种核心微服务设计完成之后，需要通过SpringCloud的组件对微服务进行管理，其中的管理组件包括网关Zuul、注册中心Eureka、配置中心Config、服务调用Feign、熔断器Hystrix等。

Zuul是微服务访问的入口网关。在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。在基于微服务的项目中，网关简化了前端的调用逻辑，同时网关中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。网关提供动态路由、监控、弹性、安全等的边缘服务，具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。

Eureka提供服务注册和发现的功能，它提供了完整的服务注册Service Registry和服务发现Service Discovery实现，将所有的可以提供的服务都注册到这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。服务中心这样重要的组件一但故障将会影响全部服务，因此需要搭建Eureka集群来保持高可用性。随着系统的流量不断增加，需要根据情况来扩展某个服务，Eureka内部提供了均衡负载的功能，只需要增加相应的服务端实例既可，并且通过心跳检测机制，如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉，避免了某个实例故障而影响服务。

Feign是一个声明式的Web Service客户端，它的目的就是让Web Service调用更加简单。它提供了HTTP请求的模板，通过编写简单的接口和插入注解，我们就可以定义好HTTP请求的参数、格式、地址等信息。Feign会完全代理HTTP的请求，我们只需要像调用方法一样调用它就可以完成服务请求。

Config是一个解决分布式系统的配置管理方案。随着微服务不断的增多，每个微服务都有自己对应的配置文件，每个微服务又对应至少三个不同环境的配置文件。大量的配置文件，在修改某个公共服务的配置信息时，如：缓存、数据库等，会产生混乱。Config包含了客户端Client和服务端Server两个部分，服务端提供配置文件的存储、以接口的形式将配置文件的内容提供出去，客户端通过接口获取数据、并依据此数据初始化自己的应用，服务端将所有的配置文件服务化，需要配置文件的服务实例去服务端获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。

Hystrix提供了一种熔断机制，在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，导致了服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。Hystrix会在某个服务连续调用多次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。

在本发明中，Zuul网关用于转发多客户端、多窗口、多图形的并发访问请求，将外部的请求访问转换为内部的请求访问，同时负责WebSocket的全双工通道的保持，保证与各个客户端的双向数据通信。

Eureka注册中心用于发现和注册各个终端的多个微服务，包括实时数据微服务、离线数据微服务、配置微服务，将各个微服务进行发现、注册、管理，从而能够供外部或内部调用，另一方面，通过Eureka能够监控实时数据微服务的状态，在实时数据微服务不可用时能够启动离线数据微服务并切换数据流到离线数据微服务。

Feign服务调用提供了便捷的调用接口，能够方便微服务之间的接口调用：1)离线微服务对配置微服务的离线状态监控调用、工况切换调用；2)实时数据微服务对配置微服务的数据采集配置调用；3)前台访问对配置微服务变量展示配置的调用。

Hystrix提供了一种熔断机制，在前台访问激增时能够判断微服务的响应状态，无论是实时数据微服务还是离线数据微服务，在被调用或者调用配置微服务时都有可能出现故障，通过熔断机制能够保证其他的服务访问不受影响，提供了一种安全机制。

本发明通过微服务架构管理数据采集与展示，能够将各个终端的实时数据传输、离线数据展示、功能配置等各个功能解耦。在实现功能的同时，提升了系统的可靠性和可扩展性。

Claims (9)

1.一种基于微服务的数采展示系统，其特征在于，包括：

浏览器前端框架，采用B/S架构进行前端数据的展示，通过WebSocket方式与微服务连接；

微服务，包括实时数据微服务、离线数据微服务、配置微服务，连接现场设备和数据库，用于采集设备的离线数据、实时数据以及配置采集参数；

SpringCloud及其组件，包括网关Zuul、注册中心Eureka、配置中心Config、服务调用Feign、熔断器Hystrix，用于对微服务进行管理。

2.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述实时数据微服务根据不同试验台，到配置微服务的服务调用Feign中拉取数据采集的方式以及数据采集的变量配置。

3.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述离线数据微服务通过连接数据库中的离线数据获取历史数据信息，返回给前台进行展示，其在后台处于休眠状态、当实时数据微服务出现故障或者手动切换时启动。

4.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述配置微服务用于设置离线数据与实时数据的切换、实时数据采集的协议配置、前台变量展示的配置以及离线工况的配置；

离线数据与实时数据的切换，为在前端页面中供用户手动设置，并作为离线数据微服务事件监听的输入源；

离线工况配置，获取离线工况信息提供给离线数据微服务；

前台变量展示配置，用于设置前台展示数据的结构、组成和样式；展示结构包括折线图、柱状图、饼状图。

5.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述网关Zuul作为接口，用于转发多客户端、多窗口、多图形的并发访问请求，将外部的请求访问转换为内部的请求访问，并负责WebSocket的全双工通道的保持。

6.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述注册中心Eureka用于对各个微服务进行监控、注册、管理，供外部或内部调用。

7.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述配置中心Config包括客户端Client和服务端Server两个部分，服务端提供配置文件的存储、及其调用接口，客户端通过调用接口获取数据、并依据该数据初始化应用。

8.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述服务调用Feign包括如下调用接口：1)离线微服务对配置微服务的离线状态监控调用、工况切换调用；2)实时数据微服务对配置微服务的数据采集配置调用；3)前台访问对配置微服务变量展示配置的调用。

9.根据权利要求1所述的一种基于微服务的数采展示系统，其特征在于，包括：所述熔断器Hystrix用于在前台访问激增时能够判断微服务的响应状态，当连续多次调用服务不响应时，通知调用端调用失败。

Images