简介这是一套基于Java与阿里云数据库的水质检测系统源码工程面向物联网、环境监测方向的Java开发者也适合用于课程设计或项目原型搭建。系统围绕水质监测核心流程展开包含MySQL数据库连接与数据获取、用户注册登录修改注销、温度和水质传感器数据展示以及下位机通过NB开发板连接阿里云数据库上传数据、发送指令控制换水电机等功能代码组织十分完整。压缩包共97个文件大小1.71MB含35个XML配置、27个Java源文件、19个PNG图片、3个Gradle构建文件、3个JAR包及属性文件等工程结构清晰便于分区阅读和二次开发。已有329人学习适合用来理解Java与阿里云数据库、物联网设备协同工作的落地方式可快速启动一个可演示的水质监测系统。1. 水质检测系统的设计源码难的不是传感器是数据链路给一个工业园区排水口做水质监测改造时我拿到过一套“水质检测系统设计源码”技术栈写着 Java 和阿里云数据库。传感器厂商已经把探头、变送器装好了Modbus 寄存器表也给了看起来万事俱备。真正动手才发现采集、解析、入库、告警、展示这条链路里一半以上的工程量在业务代码和数据库设计上。这套基于 Java 和阿里云数据库的水质检测系统本质就是一条从设备侧到业务侧的标准化数据管道Java 服务端负责协议解析和业务规则阿里云数据库负责把时序数据存得住、查得快。它适合两类人一类是拿它做毕业设计、课程设计的学生另一类是中小团队要做标准化水质监测平台、不想从零造轮子的开发者。2. 选型先于编码Java 服务端 阿里云数据库的组合为什么值得复刻2.1 技术栈对照从报表系统到实时监测每一层都有明确理由做水质检测系统技术选型最容易犯的错是一上来就追新用 Python 写采集脚本、用 TimescaleDB 存时序数据、用 WebSocket 推实时曲线。听起来很先进但落地时每一层都要自己扛运维。这套源码的技术栈是 Java 阿里云数据库常见做法是 Spring Boot 做应用框架、MyBatis-Plus 做 ORM、阿里云 RDS MySQL 做存储。这个组合的好处有一条很实在整个链路都是从业者最熟悉的通用件出问题时不缺参考资料招人接手也容易。把 Python 方案和 Java 方案放在一起对比就清楚了对比项Python 采集脚本Java Spring Boot 服务并发采集能力依赖多进程/异步框架代码量上去后心智负担重线程池 Netty 是标配天然适合多设备并发事务与回滚轻量脚本很少做严谨事务Spring 声明式事务一条注解解决与工业网关集成串口、Modbus 库可用但跨平台打包麻烦RXTX、jSerialComm、Modbus4J 生态成熟团队接手成本脚本写的人走了就成黑匣子分层结构清晰controller/service/mapper 约定俗成阿里云数据库在这里承担的不只是一个“能存数据的 MySQL”而是把备份、高可用、监控这些本该自己操心的事外包出去。RDS MySQL 相对于自建 MySQL核心价值有三个主备切换不用自己搭 MHA、Binlog 保留和按时间点恢复是控制台点选操作、慢查询和性能监控开箱即用。对于水质监测这种 7x24 小时采集、数据要保留两三年追溯的场景这些能力正好命中痛点。2.2 数据从传感器到页面的最短路径先明确一条主链路传感器探头 - 变送器/数采仪 - 网关 - Java 采集服务 - RDS MySQL - MyBatis-Plus 查询 - 前端可视化。省略中间任何一层都会出问题。有人为了省事让传感器直接往数据库写数据听起来很短实际上是把协议解析压力全部塞给了数据库而且设备厂商的通讯协议五花八门直接写库意味着每接入一种设备就要改一次表结构。标准做法是 Java 采集服务负责统一接入把不同设备的报文转换成统一的数据模型再落库。这套源码里最值得读的也是这条链路。采集服务通常按设备类型做适配器每个适配器只干两件事解析报文、吐出统一的采集记录对象。下游的告警模块、报表模块完全不感知设备差异。这种设计带来的直接好处是换传感器品牌只改适配器不动业务逻辑。2.3 一套最小可用工程应有的依赖清单拿到源码后第一步不是看业务代码而是先看 pom.xml 里引了什么。依赖清单能直接反映这套系统的技术取向。一个最小可用的水质检测服务端依赖大概是这样的dependencies !-- Web 服务 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 数据库访问层 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency !-- 定时采集调度 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-quartz/artifactId /dependency !-- 设备通讯串口/网络 -- dependency groupIdcom.intelligt.modbus/groupId artifactIdjlibmodbus/artifactId version1.2.9.7/version /dependency !-- 工具类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies这里每个依赖都有明确用途。spring-boot-starter-web 提供 HTTP 接口能力给前端页面取数据和给运维人员查状态都用它。mybatis-plus-boot-starter 负责数据库读写选它而不是原生 MyBatis是因为 BaseMapper 内置了增删改查写采集记录、分页查询这类高频操作不用手写 SQL。quartz 承担定时采集任务水质监测不是实时流式处理绝大多数场景下 5 分钟、15 分钟采一次就足够用定时任务比引入 Kafka 这类重组件划算得多。jlibmodbus 是可选依赖如果现场设备走 Modbus 协议就留着走 HTTP JSON 上报的环保数采仪可以去掉。参数上有一个值得注意的点MyBatis-Plus 的版本号不要随便升到 3.5.3 以上不回头它和 Spring Boot 2.x 的兼容性比较好如果源码里用的是 Spring Boot 3.x那 MyBatis-Plus 必须换用提供mybatis-plus-spring-boot3-starter的新版本。忽略这个边界启动时大概率报ClassNotFoundException。3. 先把源码拆成三层看懂结构再动手改3.1 从目录结构反推系统边界拿到源码包不要先点运行按钮先做一次静态阅读。水质检测系统的源码目录通常能直接看出分层是否合理。src/main/java/com/example/waterquality/ ├── controller/ # HTTP 接口层 │ ├── MonitorPointController.java │ ├── CollectionDataController.java │ └── AlarmRecordController.java ├── service/ # 业务规则层 │ ├── CollectService.java # 采集入库编排 │ ├── AlarmJudgeService.java # 告警判定 │ └── DataStatisticService.java # 统计报表 ├── mapper/ # 数据访问层 │ ├── CollectionRecordMapper.java │ ├── MonitorPointMapper.java │ └── AlarmRecordMapper.java ├── entity/ # 数据库表映射 │ ├── CollectionRecord.java │ ├── MonitorPoint.java │ └── AlarmRecord.java ├── config/ # 配置类 │ ├── MybatisPlusConfig.java │ └── QuartzConfig.java └── common/ # 通用返回体、异常处理 └── Result.java看到这个结构心里就有数了controller 层只做参数接收和结果返回不该有业务判断service 层是核心所有告警逻辑、数据校验都在这mapper 层只做 SQL。判断一套源码写得好不好就看一个地方如果 controller 里出现了超过 10 行的业务代码这套源码的边界就已经模糊了改起来会互相踩。常见做法是拿一个典型的采集入库接口作为切入点比如CollectionDataController里的saveRecord接口。顺着这个接口往下一路点进去就能把整条采集链在脑子里转起来。这套源码如果分层正确你会看到 controller - service - mapper 三层各干各的事每层之间只传递参数和结果对象。3.2 从表结构反推业务模型五个表覆盖一个完整监测场景看表结构比看代码更能理解业务。水质检测系统再复杂核心表也就五张。这套源码的数据库脚本里重点看这几张表-- 监测点表每个测点绑定一个地理位置和设备 CREATE TABLE monitor_point ( id BIGINT PRIMARY KEY AUTO_INCREMENT, point_name VARCHAR(64) NOT NULL COMMENT 监测点名称, river_name VARCHAR(64) COMMENT 所属河流/断面, longitude DECIMAL(10, 6) COMMENT 经度, latitude DECIMAL(10, 6) COMMENT 纬度, status TINYINT DEFAULT 1 COMMENT 1启用 0停用, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 采集记录表核心时序数据表 CREATE TABLE collection_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, point_id BIGINT NOT NULL COMMENT 监测点ID, device_id VARCHAR(32) NOT NULL COMMENT 设备编号, indicator_code VARCHAR(16) NOT NULL COMMENT 指标编码: pH/DO/COD/NH3N, indicator_value DECIMAL(10, 2) NOT NULL COMMENT 指标数值, unit VARCHAR(8) COMMENT 单位, collect_time DATETIME NOT NULL COMMENT 采集时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_point_time (point_id, collect_time), KEY idx_indicator (indicator_code, collect_time) ); -- 告警记录表 CREATE TABLE alarm_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, point_id BIGINT NOT NULL, indicator_code VARCHAR(16) NOT NULL, alarm_type TINYINT COMMENT 1超标 2设备异常 3通讯中断, alarm_value DECIMAL(10, 2), threshold_value DECIMAL(10, 2), alarm_time DATETIME NOT NULL, handle_status TINYINT DEFAULT 0 COMMENT 0未处理 1已处理, handle_remark VARCHAR(255) );这套表设计里有几个关键点。collection_record是典型的时序数据模型indicator_code collect_time联合索引直接决定了按指标查趋势图的性能DECIMAL(10, 2)是水质数值的标准精度pH 值需要两位小数COD 的值域也够用别用 FLOAT二进制浮点存 7.3 这种值会有精度尾巴。device_id单独存而不是关联设备表是有意的冗余。水质监测现场经常出现设备更换但历史数据不迁移的场景把设备编号冗余在采集记录里查历史时不用 JOIN。3.3 冷启动先造仿真数据绕过设备联调的空窗期源码能正常启动但现场设备还没通电这是最常见的空窗期。处理办法是先用 SQL 造一批仿真数据让整条业务链路先转起来。我一般这样造数-- 连续生成 7 天的仿真采集数据每 5 分钟一条 INSERT INTO collection_record (point_id, device_id, indicator_code, indicator_value, unit, collect_time) SELECT 1, SIM-DEV-001, pH, ROUND(6.5 RAND() * 1.5, 2), 无量纲, DATE_SUB(NOW(), INTERVAL (seq * 5) MINUTE) FROM ( SELECT (rownum : rownum 1) AS seq FROM information_schema.COLUMNS, (SELECT rownum : 0) r LIMIT 2016 -- 7天 * 24小时 * 12次/小时 ) t;造数有几个要点。DATE_SUB(NOW(), INTERVAL (seq * 5) MINUTE)生成的是严格等间隔的时间序列方便后面验证趋势图ROUND(6.5 RAND() * 1.5, 2)把 pH 值控制在 6.5 到 8.0 之间这正是地表水 III 类标准的常见区间LIMIT 2016 恰好是 7 天的完整数据量。造完数打开前端页面曲线图、报表、告警列表立刻有数据开发调试不必等硬件到位。造数这件事还有一个隐藏价值可以把告警规则先调一遍。把某条数据的 pH 改成超过阈值看告警是否能在一分钟内触发这个验证动作在设备进场前做一遍省得现场出问题还要两头排查。4. 把业务落进阿里云数据库连接参数与核心设计4.1 连接串里的细节时区、SSL、连接池一个都不能含糊阿里云 RDS MySQL 给的是标准 JDBC 连接串但连接串上手必须调三个参数。时区必须显式指定数据库服务器默认时区和应用服务器不一致会导致collect_time查出来差 8 小时水质监测是小时级数据展示时间差 8 小时等于全部不可用。SSL 要看 RDS 控制台的开启状态没开就写useSSLfalse开了就写useSSLtruerequireSSLtrue写反直接连不上。allowPublicKeyRetrievaltrue只在本地连 RDS 调试时需要生产环境走内网地址时不建议开。spring: datasource: url: jdbc:mysql://rm-xxxxxx.mysql.rds.aliyuncs.com:3306/water_quality?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrue username: water_app password: ${DB_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 20 minimum-idle: 5 connection-timeout: 30000 idle-timeout: 600000 max-lifetime: 1800000这段配置里最容易被忽略的是rewriteBatchedStatementstrue。采集服务是批量写入场景5 分钟一轮采集每个监测点 4 到 6 个指标一轮可能上百条记录。没有这个参数MyBatis-Plus 的批量插入会一条一条发 SQL性能差好几倍。加上之后JDBC 驱动会把多条 INSERT 重写为多值 INSERT插入耗时能降到原来的三分之一以下。连接池参数上maximum-pool-size: 20是中小规模系统的合理起点。水质监测的并发峰值来自定时采集和前端图表查询20 个连接足够应对 50 个监测点每小时 600 次写入的负载。connection-timeout: 30000是连接等待上限数据库抖动时不至于让采集线程无限阻塞max-lifetime: 1800000设置 30 分钟配合 RDS 默认的wait_timeout可以避免连接被服务端断开后客户端还在使用。4.2 阿里云 RDS 的选型边界规格、白名单、备份策略这套源码配套的阿里云数据库选型上有一个原则按采集频率和留存周期倒推而不是按最大并发倒推。一套 20 个监测点、每 5 分钟采集一轮、数据留存两年的系统数据量算下来是20 个点 x 6 个指标 x 12 次/小时 x 24 小时 x 365 天 x 2 年 25,228,800 条500 万到 2500 万行的量级RDS MySQL 基础版单节点的 2 核 4G 规格就够用。但是业务侧有两件事需要多考虑一是告警查询经常按小时、按天聚合SQL 里会带GROUP BY和DATE_FORMAT这类查询吃 CPU二是报表模块月底跑月报时全表扫描的查询会把 CPU 打满。因此基于 Java 的这套服务端建议起步选 2 核 4G指标聚合慢查询出现后再升到 4 核 8G同时开启 RDS 的慢查询日志做定位。白名单配置有一个爽点也有一个坑。爽点是 RDS 控制台可以按 IP 段加白名单ECS 内网 IP 和本地调试 IP 分开配互不影响。坑是很多人在本地调试时忘了改白名单应用启动能过一执行 SQL 就报Communications link failure因为连接建立时就被 MySQL 拒绝了。排查顺序先看 RDS 控制台白名单有没有加当前公网 IP再telnet 连一下 3306 端口最后才看账号权限。备份策略建议用 RDS 自动备份 手动快照双保险。自动备份保留 7 天足够应对误操作但设备档案和监测点配置这类基础数据每次变更前手动打一次快照改坏了能精确回滚到变更前那一刻。这个习惯能在调试阶段省下大量重刷配置的时间。4.3 让 MyBatis-Plus 写出高效的采集 SQL采集记录表的数据量过百万后MyBatis-Plus 的默认查询会出现性能拐点但问题不在 MP 本身而在调用方式。最典型的误用是在循环里单条插入一万条记录产生一万次数据库往返。正确做法是 List 批量插入配合上面已经提到的rewriteBatchedStatementspublic void batchSaveRecords(ListCollectionRecord records) { // 每批 500 条避免单批过大导致 SQL 超过 max_allowed_packet ListListCollectionRecord partition ListUtils.partition(records, 500); for (ListCollectionRecord batch : partition) { // MyBatis-Plus 的批量插入会走 foreach 生成多值 INSERT this.saveBatch(batch); } }批大小的选择要看 RDS 的max_allowed_packet参数默认 4M 时500 条一批已经是安全值。如果现场采集频率提高到每秒 1 次这个方案就压不住了那时候再去考虑原生insert into ... values (...), (...)拼 SQL 或者换时序数据库。分页查询也有讲究。前端展示历史曲线经常需要按监测点和时间范围拉几千条数据。MyBatis-Plus 的Page对象在大数据量下翻页越深越慢本质是LIMIT offset, size的深翻页问题。水质监测前端实际不需要 100 页都是按时间段加载SQL 层面用collect_time范围过滤天然避开深翻页。如果源码里出现pageNum很大的场景查一下是不是前端在按页浏览历史数据那属于需求设计问题不是技术问题。5. 排查与避坑水质监测系统里那些“看着对、跑起来错”的细节5.1 电极漂移导致采集值突变数据库里写入了明显异常的数据现象是曲线图上某一天的 pH 值从 7.2 突然跳到 12.6第二天又恢复正常。原因水质探头在长时间运行后会出现电极漂移或者现场清洗时把探头提出水面变送器会把空气中的读数当成真实值上传。采集服务如果不做校验脏数据直接入库。解决在 service 层加合理范围校验和突变率校验。每个指标都有它在真实水体中不可能出现的上下限比如 pH 的范围是 0 到 14但河流断面的正常范围通常是 6 到 9突变率是指相邻两次采集的差值pH 在 5 分钟内跳变超过 1 就是异常。写进告警规则里同时标记这条数据为无效数据而不是直接丢弃方便事后追溯。5.2 本地跑得好好的换到阿里云数据库就连接失败现象是本地 MySQL 一切正常把application.yml的地址换成 RDS 内网地址后应用启动时报Access denied或连接超时。原因三个地方有一个出了问题RDS 白名单没有包含 ECS 实例的内网 IP账号授权没有勾选应用的访问地址RDS 实例的地域和 ECS 不在同一个 VPC内网根本不通。解决先登录 RDS 控制台检查 IP 白名单里有没有 ECS 的私网 IP进入账号管理确认账号权限授权了water_quality库注意不是只授权了%最后 VPC 和地域必须与 ECS 完全一致。这三个问题按出现频率排白名单第一账号权限第二跨地域第三。还有一种隐蔽情况本地调试时配了公网地址生产配置的内网地址两套配置并存启动时加载了错误的 profile。我的习惯是在application.yml里放公共项把环境差异全部拆进application-dev.yml和application-prod.yml通过启动参数指定。5.3 采集记录的时间乱了最新数据被旧数据顶掉现象是某一台设备的采集时间比真实时间晚了几个小时导致按时间排序查询时新采集的数据没有出现反而一直在展示旧数据。原因数采仪断电重启后时间没有自动同步上传的collect_time是旧时间。如果表结构里collect_time没有唯一索引同样的point_id device_id collect_time会插入两条前端查询结果混乱。解决三处配合。数据库层给(device_id, collect_time)加唯一索引重复采集时间直接覆盖服务层在写入前比较设备上报时间和服务端当前时间超过 5 分钟偏差就告警“设备时间异常”RDS 侧确认实例时区设置正确。时间同步本身要依赖现场设备支持 NTP这在硬件侧做软件侧能做的就是兜底防脏数据。5.4 告警风暴一轮采集触发几十条告警渠道被刷爆现象是氨氮浓度超标的瞬间告警模块给同一组联系人发了几十条短信因为每隔 5 分钟就触发一次。原因告警判定逻辑没有做去抖和恢复窗口只要当前值超过阈值就立刻推消息没有考虑持续性和恢复条件。解决把告警规则改成状态机一个测点同一个指标只维护一个告警状态从正常转为超标时推送一条消息持续超标期间不重复推送只是更新告警记录的最后确认时间只有当值回落到阈值的一定比例比如 90%以下状态才恢复为正常下次超标才会再次推送。比例的设计是核心参数回到阈值立即恢复会导致临界值反复上下跳动告警消息还是一串串地发。6. 从“能跑”到“能交付”用动态规则和回归验证收尾源码跑通只是起点交付一套能实际用的水质检测系统至少要完成两件事。第一件事把固定阈值改成动态告警规则。很多源码里的告警是写死的pH 大于 9 就告警。但同一个指标在不同水域的考核标准不一样饮用水源地和排污口的标准就不同。我一般会在monitor_point表旁边加一张alarm_rule表字段包括测点 ID、指标编码、上限值、下限值、持续次数阈值这些规则通过接口维护不写死在代码里。经验值是持续次数设 2 到 3 次也就是连续两次采集超标才触发告警这能过滤掉大多数电极波动造成的误报。第二件事做一次完整的回归验证。我的固定动作是三步第一步清空采集记录表重新执行第 3 章的仿真造数 SQL确认上报、入库、曲线展示的正常链路没被改动破坏第二步把一条采集值改成超标确认告警能触发、短信通道能收到消息如果接入了第三步用压测工具模拟 1000 个采集请求并发写入观察 RDS 的 CPU 曲线和慢查询日志确认连接池参数没有成为瓶颈。这三步走完才敢说这套源码在自己手里真正跑明白了。说回开头那句话水质检测系统的源码难点从来不是“能不能跑”而是“跑多久不出事”。我自己交付前有个习惯把采集间隔从 5 分钟改成 30 秒连续观察一天慢查询日志同时把告警阈值临时调低到正常值的 90%人为制造几次超标看告警恢复流程是否完整。这套流程下来能让很多隐藏问题提前暴露。这套基于 Java 和阿里云数据库的方案核心技术点不在某个惊艳的算法而在每一层都用了稳定可靠的组件并且把业务规则搭在清晰的表结构上。希望这篇整理能帮你在同样的方向上少走几步弯路。本文还有配套的精品资源点击获取