一种基于SpringBoot 架构下的水质监测系统设计∗

2021-11-13羌予践

电子器件 2021年5期

马聪，华亮，羌予践

(南通大学电气工程学院，江苏南通 226019)

水质安全问题关系到国计民生，但水质保护和管理工作中存在的一些问题却依然仍令人担忧。虽然国家已建成了“以水环境监测中心为中心，监测站为节点”的覆盖全国主要江河湖库的水质监测网络体系，但是依然存在同一水域归不同部门管辖，监测内容重复等问题，造成监测工程的重复投资[1]。把监测内容形成一个独立节点，通过授权进行访问，拿到监测数据将是未来水质监控系统的发展趋势[2]。如何结合当前互联网＋技术，设计出一整套的物联网水资源监控系统，也成为当前水质监测系统设计的重点和难点。

传统水质监控系统设计一般采用C/S 架构，采用应用程序设计或者通过组态软件二次开发技术进行实现，仅适合在局域网中运行，为典型的C/S 系统，通信采用TCP/IP 通信技术，在数据库存储方面采用本地数据库存储。而当前的组态软件在解决高并发、大数据存储方面，尚存在技术支撑不足，使得以此为平台的监控系统，很难满足容纳百万级别监控终端的大型监控系统的设计要求。同时C/S 模式下的程序设计，每台监控电脑都要安装客户端，虽然组态软件也与时俱进，引入浏览器发布模式，但是使用时，必须下载专用的动态链接库及OCX 控件，相当于对C/S架构的缝缝补补，没有从根本上解决系统架构问题。也不能从根本上解决大数据监控问题存在的技术难题。随着电商等行业的兴起，B/S 开发模式逐渐成为了当前软件开发的主流模式，互联网＋的开发模式也被国家提到科技升级的战略高度。以B/S 开发模式的系统架构，对传统的水资源监控系统进行重新架构设计，通过前后端分离技术，把数据获取设计为独立的后端数据中心，前端通过网络API 接口获取后端数据，能够把数据与显示分离出来，利用互联网＋的思想，解决传统C/S 模式下水质监控系统设计的不足，实现B/S 模式下新型的水质监控系统[2－3]。

在设计中，结合当前Web 技术的发展，随着网站功能的日趋复杂，前后端分离逐渐成为大型Web 项目开发的主流模式。虽然当前微软、亚马逊、阿里、腾讯、百度等互联网巨头也推出了物联网平台，但是这些物联网平台只能在公网运行，不适于专网设计。本设计借鉴物联网平台的设计风格，采用了前后端分离的微服务技术，可以使得前端设计人员更注重前端设计与用户体验，后端人员更注重服务器管理的开发，前后端分离的设计思想可以使软件开发并行化，加快软件开发的速度。在前后端分离技术中，Spring 技术做为轻量级的容器，在Java 开发中得到广泛赞誉，其SpringBoot 带来了全新的软件设计自动化配置及解决方案，使得SpringBoot 可以快速搭建生产级的独立应用程序，解决传统Java EE 项目中遇到的多种问题。因此本设计采用SpringBoot 对MQTT 物联网协议进行快速整合，后端采用SpringBoot 技术设计监控数据服务器，前端采用Vue 技术设计监控系统，从而完成微型物联网平台的搭建[4－5]。

在服务器与水质监测终端通信方面，可以采用TCP 通信，把服务器设计为TCP Server，采用非阻塞式以太网通信技术，但是考虑到每个水质监测终端为动态IP，当系统掉电后，一段时间不与网络连接，其IP 地址就有可能会发生变化，则又需要把新的IP 地址重新报备给后端服务器，完成用户与设备新动态IP 通讯的再次绑定。此方法可以采用SpringBoot 集成Netty 及数据库更新进行实现，但是相对较复杂。采用HTTP 协议长连接进行通讯，不需要考虑设备掉电后的新动态IP 问题，其采用GET方法提交数据，接口简单，但是HTTP 报文数据量较大，占用带宽资源较高，不利于解决高并发问题。而采用MQTT 通信报文精简、数据先发布到MQTT 消息代理服务器，通过发布/订阅模式进行消息发送及获取，无需考虑设备端联网动态IP 问题，更适合于解决高并发问题。

考虑到未来系统的扩容及集群式部署，本设计采用MQTT 协议。MQTT 协议为物联网重要中间件，是一种轻量级物物互联消息协议，被誉为最适合物联网开发的通信协议。MQTT 协议几乎支持所有编程语言的开发平台，通过移植相关代码，可以把所有的物联网产品与服务器连接起来，同时MQTT 协议相对于HTTP 协议，消息报文简短，双向通信，有利于窄带互联及浏览器端对设备的控制。因此本设计中，引入MQTT 通信协议，对引入物联网的设计思路，对传统的水质监测系统进行重新设计[6－7]。

1 系统架构及平台部署

本水质监测系统包括水质监测终端设备及云服务器。云服务器包括MQTT 消息服务器、后端服务器、前端服务器、Mysql 数据库服务器。结构图如图1 所示。

图1 系统结构图

水质监测终端包括多参数水质检测仪及4G DTU 模块，系统结构如图2 所示。

图2 水质在线监测终端内部结构图

水质监测终端负责完成水质参数及GPS 信息的采集工作，并由STM32F103 单片机进行系统管理，采用串口通信技术，按照GSON 字符串形式，定时通过串口向4G DTU 模块提交水质采集数据，4G DTU 采用MQTT 通讯模式，连接MQTT 消息代理服务器，把该主题消息发布到消息代理服务器上，本消息代理服务器采用ActiveMQ 进行服务器端消息服务器部署[7－8]。

后端服务器:订阅来自ActiveMQ 消息服务器的消息，采用SpringBoot 技术，对订阅主题消息进行解析，然后把消息字符串转换为JSON 数据，纳入Mysql 数据库；在后根据登录人员级别，把相关数据推送给前端服务器。在SpringBoot 数据服务器开发中，集成Swagger2 组件，方便自动生成前端接口文档，提高开发速度；集成Mybatis-plus 组件，方便对数据库进行增删改查操作；集成Logback 组件，有利于生成操作日志。

前端开发工作主要是完成数据显示及用户操作，权限管理、地图标注、系统日志、数据库管理。在前端开发中，Vue 以数据驱动和组件化开发为核心，更适合监控系统的数据绑定，因此在开发工具选择方面，选择Vue 技术为前端开发技术支撑。开发平台采用Node.js＋Webpack＋Vue＋ElementUI＋Axios 搭建。Vue 组件对数据进行视图的绑定，其Model-View-View Model(MVVM)的开发模式也使得前端开发从原来的DOM 操作解放出来，只需关注数据的变化，代码更易维护。ElementUI 方便本系统对视图的渲染，Axios 用于连接前后台数据互换；由于本设计监控主要应用于网页端，如果应用于手机端，可以引入MintUI 进行布局，生成手机端APP，更方便手机浏览。前端开发引入Echart 组件及高德地图组件，通过Vue 引入数据，方便进行曲线显示、地图定位标注，从而增强数据可视化及人机体验。

2 系统关键技术实现

2.1 水质监测数据采集及调试

水质监控终端，考虑要与云服务器进行通信，设计中选择MQTT 协议，其水质监测终端的软件流程参考图3 所示，其通讯数据流采用Gson 字符串格式。

图3 水质监测终端软件流程图

2.2 消息代理服务器

采用ActiveMQ，安装部署在云端服务器上，根据MQTT 协议发布/订阅通信原理，设计相应的主题Topic。

设备主题(Topic)为:water/{deviceID}，一级主题代表水质，二级主题为设备唯一序列号ID；

后端SpringBoot 数据服务器订阅主题:water/，则后端服务器可以订阅所有water 主题下的消息。

2.3 后端数据服务器设计

在水质监测系统设计中，其数据库设计，参考工控组态软件中数据库结构，工控组态软件一般包括实时数据表、历史数据表、报警设定表、报警数据表，管理人员数据表；本数据库设计在吸收工控系统优点的情况下，增加用户与设备绑定表，用于把管理员与其管理区域、权限进行绑定；用户菜单表，根据用户权限推送不同的操作菜单。如下为本系统数据库表结构。

(1)用户数据表

包含字段为用户ID(userid)、用户名(name)、手机号(tel)、管理权限(level)、管理区域(zone)、创建时间(createtime)字段，该表相当于组态软件中用户管理。

(2)设备实时数据表

表结构包含设备唯一序列号ID，所处区域、IP地址、MAC 地址、各种水质参数、GPS 经纬度等数据。当水质监测终端发布主题消息，因后端数据服务器订阅了来自water 主题下的所有消息，所有可以收到来自消息代理服务器ActiveMQ 的所有该主题消息推送；后端服务器在侦听到相应主题消息，把数据刷新到设备实时数据表，该表相当于组态软件实时数据词典。

(3)历史数据表

当设备实时数据表数据刷新时，采用Mysql 触发器把实时数据表该记录根据当前时间增添到历史数据表中。历史数据表设计为当前时间、设备ID、各种水质参数、GPS 经纬度；该表主要用于每台在线设备历史数据存储，供数据前端可视化查询。该表相当于组态软件数据存入历史数据库。

(4)报警设定表

该数据表根据用户所处区域，对该区域水质监测设备的参数上限、下限、上上限、下下限，进行设定。后台服务器侦听消息服务器推送消息，把消息解析后，根据设备ID 查询该表，把数据与参数的报警值进行比较，当触及报警限制时，把报警数据插入报警数据表，该表相当于组态软件中报警设置。

(5)设备用户绑定表

用于记录用户与设备的映射关系，设备唯一序列号devicesID、用户唯一标识userID，当后端服务器侦听到消息服务器推送消息，对消息进行解析，获取设备ID，查设备用户绑定表，可获取用户ID、权限、区域，根据具体要求向前端推送数据，达到精确推送的要求。

(6)报警实时数据表

数据库字段包括报警时间、报警设备、报警参数、报警级别，报警处理字段。该表相当于组态软件中实时报警。

当数据报警时候，纳入报警记录，将报警处理值设置为0，当报警处理结束，报警处理值设为1，表示已经处理该报警。网页端通过Axios 的Get 方法，调用后台数据中心接口，查询报警数据表，获取报警数据，渲染到网页上。

(7)报警历史数据表

该表用于记录系统报警历史数据，通过报警实时数据表刷新触发插入报警历史数据，供前端进行报警历史分析及查询，该表相当于组态软件报警历史数据库。

(8)用户菜单表

根据用户注册信息，当用户登录后，根据权限、区域，获取用户个性化导航栏相关数据、颜色等菜单数据，该表用于个性化前端导航栏，传统组态软件无法实现。

2.4 后端服务器开发

在后端服务器，主要负责消息订阅/发布，根据数据库设定信息，进行相关逻辑业务操作，并把数据推送给前端服务器。后端服务器采用SpringBoot 技术，SpringBoot 采用AOP 开发理念，采用注解编程，采用容器技术，把需要的模块添加到相应的容器中。开发中，采用Maven 技术构建数据仓库，通过pom.xml 引入相关依赖。在本项目中，注入ActiveMQ client、SpringBoot-web-starter、Mybatis-Plus、Mysql-Connector、Swagger2、Lombok 等组件。

(1)新建config 类，利用mybatis-plus 自动代码生成器创建部分通用代码[9]。

对于SpringBoot 软件开发，其对数据库的操作，正常包括增删改查操作、采用步骤基本一样，首先配置数据库:

在application.property 文件中配置数据库基本信息及消息服务器配置及其他信息。

创建实体类:为每个数据表格创建实体类，通过Lombok 插件的＠ Data 注解自动设置Setter，Getter方法。用于存放我们的实体类，与数据库中的属性值基本保持一致。

创建数据库接口DAO 层，通过＠Repository 注解对数据库进行数据持久化操作，完成数据库操作的逻辑映射。通过＠MapperScan 注解，注入主程序管理。

为每个实体类创建Services 接口及Services 执行方法。

为每个实体类创建控制层Controller；通过＠RestController、＠ GetMapping、＠ Postmapping 注解的使用，完成接收前端传过来的参数进行业务操作，再将处理结果返回到前端，实现前后端数据参数传递。

在配置完application.property 后，可以采用Mybatis-Plus 代码生成器[10]，自动生成通用的的数据库操作部分代码，把软件开发人员从重复劳动中解脱出来。通过test 类执行代码，自动生成上述操作代码。配置Swagger2，采用注解的方式自动生成前端接口文档，省去编写前端接文档的麻烦，提高工作效率。

(2)注入消息侦听处理逻辑

当侦听到所订阅的消息主题，解析消息内容:首先把消息字符串由设备端的ASCII 码转UTF－8 码，消息内容统一规定为Gson 字符串形式，把Gson 字符串解析为Gson 数据，调用设备实时数据表Services 接口中插入方法，插入方法调用DAO 层数据库操作映射逻辑，把数据写入设备实时数据表，同时在数据库中，实时数据表数据刷新将触发数据插入到历史数据表的操作，实现历史数据保存；查询设备报警设定表，把Gson 数据与报警设定数据进行比较，当满足报警条件，把报警数据写入报警实时数据库，为报警实时数据库配置插入数据触发写入报警历史数据库方法，实现报警历史数据库保存。

(3)在控制层，编写控制层Controller 接口:

用户登录后，根据权限，采用Get 方法，查询用户菜单表，个性化生成操作界面。

①根据用户权限及分管区域，通过添加设备，通过录入设备SN，设备SN 也就是设备内部MQTT 消息主题号，插入更新到设备用户绑定表，完成设备与用户的绑定。

②为每台设备做报警设置接口，定义监控参数的上限、上上限、下限、下下限，以记录形式插入报警设置表，为其编写接口方法。

③定时查询设备实时数据表，返回当前最新的实时数据，根据用户分管区域实现对其管辖区域内设备精确数据条件查询。

通过上述程序模块的定义，及程序化，配置Swagger2 类，统一生成用户后端API 接口，为进一步前端开发做完准备工作。通过Swagger2 生成的接口文档如图4 所示。

图4 通过Swagger2 生成数据中心接口文档

2.5 Web 前端关键功能整合

前端开发任务为监控数据的可视化。首先利用Visual Studio Code 平台，采用Vue＋ElementUI＋Axios＋Echart＋高德地图等插件，完成前端开发平台搭建。然后统一外部数据接口、跨域设置、状态存储的定义，实现如下功能:

(1)人员登录管理:对管理人员进行增添、删除、权限分配操作；该功能实现通过Axios 传参，调用后台用户SpringBoot 的API 接口获取数据，渲染到网页模块上，通过SpringBoot 实现与数据库的交互。

(2)设备配置:根据设备唯一序列号SN，完成设备添加，设备报警参数设定，设备人员绑定设定，通过API 接口，写入数据库相应的表中。当数据中心侦听到MQTT 消息后，获取消息内容、解析消息后，将根据设备唯一序列号SN 查询报警设定表数据，与之比较，决定数据是否产生报警信息，纳入报警数据库，而后根据权限或地域把设备参数数据及报警数据进行网页精准推送。前端设备配置界面如图5 所示，包括设备添加、报警设置、设备人员绑定配置。

图5 设备配置页面

(3)设备数据前端显示，根据权限，通过调用数据中心设备实时数据表的API 查询接口，完成实时数据获取，渲染到网页上；通过调用数据中心历史数据表的API 查询接口，获取不同设备的历史数据，渲染到网页的Echart 组件上，完成历史曲线等图形化显示；获取设备的GPS 位置信息，通过调用网页中的高德地图组件，标记在高德在线地图上，完成地图上设备的标定。如图6 所示。

图6 设备地图在线标记

3 系统分析与展望

本系统设计的亮点为采用前后端分离的软件设计模式，搭建基于微服务的监测中心，后端数据中心与前端显示分别架构，突破传统C/S 模式下监控中心封闭性、其他系统无法接入的难题，本系统架构为新的开放式架构。其后端数据中心只要通过授权，即可通过API 接口访问该中心数据；其前端视图页面可以接口各种互联网资源，与组态软件二次开发的监控系统比较，参考表1。

表1 与组态软件二次开发的监控系统比较

与架构在公网的物联网平台比较，本设计方法更灵活、可以布局在专用网络中，避免网络攻击，安全性更好；同时也避免了对其他资源平台的技术依赖。

前后端分离的服务器开发模式，在前端采用Vue 技术，ElementUI 组件设计页面，其人机体验远高于传统工控组态软件开发的页面布局。

由于项目处于系统测试阶段，设备较少，在后端SpringBoot 架构中，涉及内存数据库操作没有引入Redis 模块进行服务器内存管理，随着未来设备的扩容，将引入Redis 技术作为补充，以减轻关系数据库的查询压力，提高系统的处理速度及解决高并发问题的能力，在前后端通讯方面，如采用Websocket 技术，实现后台采集数据的前端推送，将优化系统性能。

在测试阶段，没有引入设备自动注册的思路，采用出厂唯一序列号作为标识，在设备大批量生产阶段，将造成出厂前，每次烧写程序都要修改芯片中序列号，不利于大批量生产，在后期将引入设备互联网自动注册方法，由服务器分配序列号，传给设备，自动写入STM32 单片机的NAND 存储器，也就是分配其MQTT 通信的主题，以适应大批量生产的要求。