简介这是一套面向计算机相关专业计科、大数据、人工智能、物联网等的毕业设计/课程设计源码包主题为基于Spring Cloud的环境污染物数据分析与预测平台项目以微服务架构组织包含服务注册中心、配置中心、Zuul网关、数据服务、邮件服务、导出服务、PM2.5预测服务等模块覆盖空气质量可视化、排行榜、污染物预警、历史数据导出与后台管理等功能前端页面基于Bootstrap和Echarts实现搭配第三方天气API适合作为毕设项目或大作业也支持二次扩展。资源共2000个文件以Java源码、JS/CSS前端文件、JSON配置、HTML页面和Markdown说明为主压缩包约57.49MB代码完整且运行验证通过并附有详细项目说明可帮助读者快速理解服务拆分、接口调用和异步训练PM2.5预测模型的设计思路。目前已有226人浏览学习适合不同起点的学生和教师使用对于希望快速搭建微服务数据分析平台的人而言其中的Consul注册、Kafka异步处理、Redis缓存、阈值预警与数据导出等实现均可作为直接参考或复用的范例。1. 基于Spring Cloud的环境污染物数据分析与预测平台它在毕设里到底承担什么不少计算机专业的毕设题目会把“Spring Cloud”写进标题但真正答辩时很多人只能演示几个服务启动成功业务闭环却讲不清楚。环境污染物数据分析与预测平台之所以是个好选题是因为它把三条硬要求串在了一起污染物监测数据要能入库要能按站点和污染物维度做统计分析还要用历史时序数据预测未来浓度。这三条链路一旦跑通微服务、数据分析、预测建模三个方向的得分点就都拿到了。这个标题指的是一套以 Spring Cloud 为微服务骨架的毕设工程通常会附带源码和详细项目说明。它适合两类人一是想同时展示微服务应用能力和数据建模能力的应届生二是想快速跑通一套真实业务链路的初中级开发。这篇文章按我自己的落地路径来拆——服务边界怎么切、数据链路怎么建、预测模型怎么接、哪些坑会让你熬夜排查最后给出可交付的验证方法。目标只有一个你照着做能复现答辩时能讲圆。2. 服务拆分与微服务骨架从Nacos注册到Sentinel保护的4个关键选型2.1 先按数据域切服务别按页面切我见过很多毕设项目把服务拆成“登录服务、首页服务、图表服务”结果十几个微服务互相调用依赖乱成一团。拿到这个题目正确的切法是按数据流动方向来采集—存储—分析—预测—网关。每个服务只对一种数据行为负责调用关系就是一条单向链路答辩时画架构图也清晰。服务名职责关键依赖collection-service接收监测站上报数据清洗落库MySQL>spring: application: name:>FeignClient( name predict-service, fallback PredictFeignFallback.class, configuration FeignTimeoutConfig.class ) public interface PredictFeignClient { PostMapping(/api/predict/forecast) PredictResult forecast(RequestBody ForecastRequest request); }这里name必须是 Nacos 里注册的服务名大小写要完全一致fallback指定降级类对方服务不可用时返回兜底数据避免网关直接报 500configuration指定自定义超时配置因为预测服务要做模型推理默认超时往往不够。Configuration public class FeignTimeoutConfig { Bean public Request.Options feignOptions() { return new Request.Options( 3000, // 连接超时毫秒 8000 // 读取超时毫秒 ); } }连接超时设 3 秒、读取超时设 8 秒是比较合理的起点连接阶段通常很快3 秒足够读取阶段要等模型加载和推理8 秒能覆盖大多数情况。不要两个都设成 1 秒否则预测接口一定会超时重试反而把服务拖垮。2.4 Sentinel限流与规则持久化控制台规则重启就丢网关和预测接口一定要接 Sentinel否则某个站点数据刷新的请求一多可能导致整条链路雪崩。但这里有个坑在 Sentinel 控制台手动配置的限流规则默认只存在内存里服务一重启全部丢失。生产环境的常用做法是把规则持久化到数据源比如推给 Nacos 或 Redis 集群服务启动时会自动加载规则。spring: cloud: sentinel: datasource: flow: nacos: server-addr: ${NACOS_ADDR:192.168.1.10:8848} >CREATE TABLE pollutant_hourly ( id BIGINT AUTO_INCREMENT PRIMARY KEY, station_code VARCHAR(32) NOT NULL COMMENT 监测站点编码, monitor_time DATETIME NOT NULL COMMENT 监测时间按小时对齐, pm25 DECIMAL(8,2) COMMENT PM2.5浓度 ug/m3, pm10 DECIMAL(8,2) COMMENT PM10浓度 ug/m3, so2 DECIMAL(8,2) COMMENT 二氧化硫浓度, no2 DECIMAL(8,2) COMMENT 二氧化氮浓度, co DECIMAL(8,2) COMMENT 一氧化碳浓度, o3 DECIMAL(8,2) COMMENT 臭氧浓度, aqi INT COMMENT 空气质量指数, UNIQUE KEY uk_station_time (station_code, monitor_time), KEY idx_monitor_time (monitor_time) ) COMMENT 污染物小时级监测数据;主键用自增id但业务上的唯一键必须是station_code monitor_time。这个唯一键能挡住同一站点同一小时的重复上报是数据清洗的第一道防线。实际项目中接口幂等不是你写了判断逻辑而是数据库层面直接拒绝重复这才是最可靠的。idx_monitor_time是为了给按时间范围取数的查询加索引后面跑预测要取一年的数据没有这个索引全表扫描会非常慢。3.2 采集接口接收上报与去重落库采集接口是整条链路的第一站。实际项目里监测设备上报的数据往往是批量 POST一次可能带几十条记录间隔一分钟重发一次。接口的职责不是做复杂校验而是接收、去重、落库。RestController RequestMapping(/api/collect) public class CollectController { PostMapping(/report) public ResultVoid report(RequestBody ListPollutantReportDTO batch) { // 批量上报同站点同小时只保留最后一条 collectService.saveBatchWithDeduplicate(batch); return Result.success(); } }saveBatchWithDeduplicate的内部逻辑是先把 batch 按station_code monitor_time分组同一组只保留时间戳最新的一条然后批量插入撞到唯一键的自动跳过。这里建议用 MyBatis-Plus 的saveBatch配合数据库唯一键去重不要用“先查询再插入”的方式——一查一插在高频上报场景下性能差也没有天然防竞争的能力。采集接口不要暴露到公网只允许网关和内部网络访问这一点写在项目说明的安全章节里会很加分。3.3 清洗时间对齐先过滤异常值再对齐小时再插缺失采集接口只能处理结构上的重复数值层面的清洗得单独做。污染物数据的脏数据无非几类浓度值为负设备零漂、数值突变到离谱范围、时间戳没有对齐到整点。我的清洗顺序是固定的先过滤负值再对齐时间最后插缺失值。顺序错了插值会把负值也“插”得自然反而更难排查。import pandas as pd df pd.read_csv(raw_pollutant.csv, parse_dates[monitor_time]) # 1. 浓度负值属于设备异常直接过滤 df df[df[pm25] 0] # 2. 对齐为整小时把 10:15 对齐到 10:00 这一档 df df.set_index(monitor_time).resample(h).mean() # 3. 连续缺失不超过 4 小时才线性插值超过则保留 NaN df df.interpolate(methodlinear, limit4)resample(h)会把 10:23 这类时间归到 10:00 一档同档内取均值这就完成了时间对齐。interpolate(methodlinear, limit4)只在连续缺失不超过 4 个小时时插值超过 4 小时说明仪器长时间掉线这时候插出来的数据不具备可信度宁可保留 NaN后面分析时直接跳过。这一步是整条数据链路里最有“工程感”的地方项目说明里能把这 3 步的逻辑都写清楚已经能和其他只用官方数据集的学生拉开差距。3.4 存储选型MySQL够用但要区分分析查询与预测取数毕设阶段数据量通常也就几十万行MySQL 完全够用不需要引入时序数据库。但有两条经验建议你照做第一分析报表的查询和预测服务的取数都走只读库或同一份索引良好的表不要在生产库上跑重型统计 SQL第二如果数据量大到几千万行再把 analysis-service 里的统计 SQL 切到 Spark 或 Hive 上跑离线分析这是在“Spring Cloud 数据平台”方向上加分的关键一笔。存储层永远不要变成瓶颈这是微服务架构里最容易被忽视的一环。4. 分析加预测的落地SQL统计、ARIMA与LSTM两条预测路线怎么选4.1 统计报表用SQL算AQI变化趋势和站点对比分析模块不需要单独写算法绝大多数指标直接用 SQL 聚合就能完成。污染物平台最常见的两个分析需求是某城市近一年 PM2.5 均值走势不同站点同一时段的污染物浓度对比。前者按月份分组即可SELECT station_code, DATE_FORMAT(monitor_time, %Y-%m) AS mon, AVG(pm25) AS avg_pm25, MAX(aqi) AS max_aqi FROM pollutant_hourly WHERE monitor_time DATE_SUB(NOW(), INTERVAL 12 MONTH) GROUP BY station_code, DATE_FORMAT(monitor_time, %Y-%m) ORDER BY station_code, mon;命中了idx_monitor_time索引时间过滤不会全表扫描。注意WHERE里一定要先按时间缩小范围再分组聚合否则数据量起来后这条 SQL 会是整个平台最慢的查询。analysis-service 里把这些 SQL 封装成接口即可前端用 ECharts 把结果渲染成趋势图这个模块就闭环了。4.2 ARIMA路线样本少、趋势平稳时的省心选择预测模块是整个平台的核心得分点但不要一上来就堆 LSTM。先评估数据形态如果只有几个月的日度数据样本量几百条优先用 ARIMA。ARIMA 参数少、训练快、可解释性强答辩时讲“为什么用 ARIMA”比讲“为什么用 LSTM”容易得多。from statsmodels.tsa.arima.model import ARIMA # series 为按小时对齐后的 PM2.5 均值序列先做差分平稳性检查 model ARIMA(series, order(2, 1, 2)) model_fit model.fit() print(model_fit.summary())order(2, 1, 2)里的三个数分别是自回归阶数 p、差分阶数 d、移动平均阶数 q。d1 表示对原序列做一阶差分来消除趋势这是处理污染物浓度这种带季节波动数据最常见的选择。实际项目里我的做法是先跑一遍看 summary 里的 AIC 值再尝试把 p、q 改成 (1,1,1) 或 (3,1,2) 对比哪个 AIC 低用哪个。“ARIMA 的阶数不需要你懂透推导会对比 AIC已经比大多数硬调参学生强了。”4.3 LSTM路线时序数据量足够时的进阶之选如果你的数据集有至少一年的小时级数据LSTM 的拟合上限更高答辩也更有话题性。LSTM 的本质是把时间序列预测改造成监督学习用过去 N 个小时的浓度预测下一个小时。这里的关键参数是滑窗长度 look_back 和归一化。import numpy as np from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dense def make_windows(data, look_back24): x, y [], [] for i in range(look_back, len(data)): x.append(data[i - look_back:i]) y.append(data[i]) return np.array(x), np.array(y) # 先用 MinMaxScaler 把序列归一化到 [0,1]避免浓度量纲影响训练 x_train, y_train make_windows(scaled, look_back24) x_train x_train.reshape((x_train.shape[0], x_train.shape[1], 1)) model Sequential([ LSTM(64, input_shape(24, 1)), Dense(1) ]) model.compile(optimizeradam, lossmse) model.fit(x_train, y_train, epochs50, batch_size32, validation_split0.2)代码里activation我没有显式写这是有意的——LSTM 的默认激活是 tanh比 relu 更适合循环结构。有些教程用 relu训练时梯度很容易异常导致预测结果退化成一条直线。look_back24用过去 24 小时预测下 1 小时污染物浓度有日内周期24 比较自然地覆盖了一个完整周期。训练完成后预测出的结果必须用训练时的 scaler 做 inverse_transform 还原成真实浓度值否则输出永远在 [0,1] 区间答辩时一眼穿帮。4.4 模型封装成独立服务Java和Python各干各的预测模型跑在 Python 里Spring Cloud 服务是 Java两者怎么协作是很多人的盲区。最稳妥的方案Python 侧用 FastAPI 包一层 HTTP 接口predict-service 用 Feign 去调用模型权重文件、Python 环境都独立部署互不影响。千万不要把模型塞进 JVM 里。# predict_service.py from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ForecastRequest(BaseModel): station_code: str hours: int 24 app.post(/api/predict/forecast) def forecast(req: ForecastRequest): # 读取该站点最近look_back小时真实数据加载模型推理 result run_lstm_forecast(req.station_code, req.hours) return {data: result}Java 侧不需要知道 Python 怎么实现的只把它当成一个普通的 HTTP 服务。Feign 接口已经在 2.3 节定义好了此时只需要把url指向 Python 服务的地址或者也注册到 Nacos 里按服务名调用。两条路线我都试过注册到 Nacos 更符合微服务风格但调试时多一跳直接用配置指定地址更省事毕设推荐后者问题定位更快。下表是两条预测路线的选型对比可以直接抄进项目说明维度ARIMALSTM数据量要求几百条即可建议一年以上小时级数据训练成本秒级分钟级可解释性强参数有统计含义弱黑盒部署依赖statsmodels 单文件TensorFlow/Keras 模型文件答辩友好度好讲原理好讲工程但不易讲透5. 避坑与常见问题5条让毕设项目翻车的隐蔽记录5.1 Nacos版本和Spring Boot版本打架控制台静默失败现象服务启动日志显示连接 Nacos 成功但注册中心列表里就是没有这个服务。原因Spring Cloud Alibaba 的每个版本都对应特定版本的 Nacos client 和 Spring Boot版本矩阵对不上时注册过程不会报致命错误只在后台静默失败。这是我在多个项目里亲眼见过的“玄学问题”查了一下午最后发现是版本号组合不对。解决拿到源码后第一件事就是看 pom.xml 里的版本变量按 Spring Cloud Alibaba 官方 release 页面的版本对应表核对。确认 Spring Boot 版本、Spring Cloud 版本、Spring Cloud Alibaba 版本三者一致再谈其他配置。不要用最新版本强行组合“最新不等于兼容”在 Spring 生态里是血泪经验。5.2 Feign默认超时1秒预测接口必挂现象前端调用预测接口10 次里有 7 次返回 500 或 504但 Python 服务手动访问是通的。原因OpenFeign 的默认连接超时和读取超时都是 1 秒预测模型首次要加载权重、推理要算几十步1 秒根本不够。解决按 2.3 节那样配置 Feign 超时连接 3 秒、读取 8 秒起步。再加一层保险在 predict-service 里做一个预热接口服务启动时先加载模型到内存避免第一个请求触发冷启动。我记得一次现场演示就是吃了冷启动的亏提前预热之后50 次连续调用一次都没超时。5.3 一台4G内存的电脑服务启动到一半被系统kill现象Nacos、MySQL、四个微服务依次启动启动到第三个时进程直接消失日志里能看到“Killed”。原因每个 Java 服务默认堆内存按物理内存的 1/4 分配Nacos 本身就要 1G 左右MySQL 再占几百兆4G 内存根本不够分。解决每个微服务启动脚本里显式指定 -Xmx按 128M 起步。Nacos 用单机模式启动不要开集群。MySQL 的 performance_schema 可以关掉能省出一两百兆内存。这是环境配置问题却能让项目看起来“跑不起来”排查优先级排最高。java -Xmx128m -Xms64m -jar># 按时间顺序切分不打乱 split_idx int(len(scaled) * 0.8) train scaled[:split_idx] test scaled[split_idx:] # 只对训练集 fit再 transform 全部 scaler.fit(train.reshape(-1, 1)) train_scaled scaler.transform(train.reshape(-1, 1)) test_scaled scaler.transform(test.reshape(-1, 1))这样模型看到的未来信息只有测试集本身报告的误差才是真实可信的。很多学生习惯把数据一 load 就全量归一化这一个小习惯就是“演示很好”和“真正能预测”的分水岭。6. Docker编排与预测误差验收交付前的最后一关6.1 Docker Compose编排一行命令拉起整套平台毕设答辩时最怕的就是现场环境配置失败用 Docker Compose 把依赖一次性编排好可以省掉一半事故。一个最小编排包含 MySQL、Nacos 和业务服务services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: pollutant volumes: - ./scripts/init.sql:/docker-entrypoint-initdb.d/init.sql nacos: image: nacos/nacos-server:v2.2.3 environment: MODE: standalone ports: - 8848:8848 predict-service: build: ./predict-service depends_on: - mysql - nacos environment: NACOS_ADDR: nacos:8848要点Nacos 必须用MODE: standalone这是单机模式内存占用最小服务间的地址不要写 IP直接写 compose 里的服务名例如nacos:8848Docker 内部网络会解析。演示现场一句话“docker compose up”全部拉起比“双击 start.bat”专业得多。6.2 预测效果验收MAE跟RMSE都要算别只报一个答辩时如果你只贴一张预测对比图评委大概率会追问“误差到底多少”。在验证脚本里同时计算 MAE 和 RMSE并判断是否存在滞后性。MAE 衡量平均偏差RMSE 对大误差更敏感两者结合能看出模型的稳定性。我自己的习惯是再单独算最近 7 天的误差不要只看全量测试集的均值——模型可能在 3 个月前预测得很好最近一周却明显漂移。import numpy as np from sklearn.metrics import mean_absolute_error, mean_squared_error mae mean_absolute_error(y_true, y_pred) rmse np.sqrt(mean_squared_error(y_true, y_pred)) print(fMAE{mae:.2f} ug/m3, RMSE{rmse:.2f} ug/m3)报告里写清楚模型预测的是 PM2.5 浓度单位是 ug/m³MAE 在 10 到 20 之间是合理水平低于 5 就要怀疑数据泄漏高于 30 说明模型基本没用。这套阈值可以帮助你判断项目是不是在“自嗨”。6.3 进阶方向可视化大屏和Spark离线分析按需选平台跑通之后还有两个经常被问到的扩展方向。一个是可视化大屏把 analysis-service 的统计接口接到 ECharts渲染站点热力分布、24 小时浓度走势、超标天数日历图这些图对答辩观感的提升非常直接。另一个是离线分析当数据量确实大到 MySQL 查询吃力时把统计任务换成 Spark 作业跑在 Hive 表上。但我个人的建议是不要为了炫技而上先解决“数据从哪来—在哪分析—如何预测—怎么验证”这条主链路扩展项写进项目说明的“后续优化”一节就够了。这些年我带过的毕设里最常见的遗憾不是模型不够深而是整套平台跑通了数据链路却讲不清楚。我自己的习惯是先拿真实数据在 Excel 里手算三天的 MAE再回去看代码这个简单习惯帮我过滤掉至少一半的“假优秀结果”。真正的预测误差不会因为你用了 LSTM 就自动变小它只跟数据质量和工程细节有关。希望这篇能帮你把链路打通希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 7:08:14 · 阅读 1.2k Spring Cloud环境污染物数据分析与预测平台：微服务架构与时序预测实战
简介这是一套面向计算机相关专业计科、大数据、人工智能、物联网等的毕业设计/课程设计源码包主题为基于Spring Cloud的环境污染物数据分析与预测平台项目以微服务架构组织包含服务注册中心、配置中心、Zuul网关、数据服务、邮件服务、导出服务、PM2.5预测服务等模块覆盖空气质量可视化、排行榜、污染物预警、历史数据导出与后台管理等功能前端页面基于Bootstrap和Echarts实现搭配第三方天气API适合作为毕设项目或大作业也支持二次扩展。资源共2000个文件以Java源码、JS/CSS前端文件、JSON配置、HTML页面和Markdown说明为主压缩包约57.49MB代码完整且运行验证通过并附有详细项目说明可帮助读者快速理解服务拆分、接口调用和异步训练PM2.5预测模型的设计思路。目前已有226人浏览学习适合不同起点的学生和教师使用对于希望快速搭建微服务数据分析平台的人而言其中的Consul注册、Kafka异步处理、Redis缓存、阈值预警与数据导出等实现均可作为直接参考或复用的范例。1. 基于Spring Cloud的环境污染物数据分析与预测平台它在毕设里到底承担什么不少计算机专业的毕设题目会把“Spring Cloud”写进标题但真正答辩时很多人只能演示几个服务启动成功业务闭环却讲不清楚。环境污染物数据分析与预测平台之所以是个好选题是因为它把三条硬要求串在了一起污染物监测数据要能入库要能按站点和污染物维度做统计分析还要用历史时序数据预测未来浓度。这三条链路一旦跑通微服务、数据分析、预测建模三个方向的得分点就都拿到了。这个标题指的是一套以 Spring Cloud 为微服务骨架的毕设工程通常会附带源码和详细项目说明。它适合两类人一是想同时展示微服务应用能力和数据建模能力的应届生二是想快速跑通一套真实业务链路的初中级开发。这篇文章按我自己的落地路径来拆——服务边界怎么切、数据链路怎么建、预测模型怎么接、哪些坑会让你熬夜排查最后给出可交付的验证方法。目标只有一个你照着做能复现答辩时能讲圆。2. 服务拆分与微服务骨架从Nacos注册到Sentinel保护的4个关键选型2.1 先按数据域切服务别按页面切我见过很多毕设项目把服务拆成“登录服务、首页服务、图表服务”结果十几个微服务互相调用依赖乱成一团。拿到这个题目正确的切法是按数据流动方向来采集—存储—分析—预测—网关。每个服务只对一种数据行为负责调用关系就是一条单向链路答辩时画架构图也清晰。服务名职责关键依赖collection-service接收监测站上报数据清洗落库MySQL>spring: application: name:>FeignClient( name predict-service, fallback PredictFeignFallback.class, configuration FeignTimeoutConfig.class ) public interface PredictFeignClient { PostMapping(/api/predict/forecast) PredictResult forecast(RequestBody ForecastRequest request); }这里name必须是 Nacos 里注册的服务名大小写要完全一致fallback指定降级类对方服务不可用时返回兜底数据避免网关直接报 500configuration指定自定义超时配置因为预测服务要做模型推理默认超时往往不够。Configuration public class FeignTimeoutConfig { Bean public Request.Options feignOptions() { return new Request.Options( 3000, // 连接超时毫秒 8000 // 读取超时毫秒 ); } }连接超时设 3 秒、读取超时设 8 秒是比较合理的起点连接阶段通常很快3 秒足够读取阶段要等模型加载和推理8 秒能覆盖大多数情况。不要两个都设成 1 秒否则预测接口一定会超时重试反而把服务拖垮。2.4 Sentinel限流与规则持久化控制台规则重启就丢网关和预测接口一定要接 Sentinel否则某个站点数据刷新的请求一多可能导致整条链路雪崩。但这里有个坑在 Sentinel 控制台手动配置的限流规则默认只存在内存里服务一重启全部丢失。生产环境的常用做法是把规则持久化到数据源比如推给 Nacos 或 Redis 集群服务启动时会自动加载规则。spring: cloud: sentinel: datasource: flow: nacos: server-addr: ${NACOS_ADDR:192.168.1.10:8848} >CREATE TABLE pollutant_hourly ( id BIGINT AUTO_INCREMENT PRIMARY KEY, station_code VARCHAR(32) NOT NULL COMMENT 监测站点编码, monitor_time DATETIME NOT NULL COMMENT 监测时间按小时对齐, pm25 DECIMAL(8,2) COMMENT PM2.5浓度 ug/m3, pm10 DECIMAL(8,2) COMMENT PM10浓度 ug/m3, so2 DECIMAL(8,2) COMMENT 二氧化硫浓度, no2 DECIMAL(8,2) COMMENT 二氧化氮浓度, co DECIMAL(8,2) COMMENT 一氧化碳浓度, o3 DECIMAL(8,2) COMMENT 臭氧浓度, aqi INT COMMENT 空气质量指数, UNIQUE KEY uk_station_time (station_code, monitor_time), KEY idx_monitor_time (monitor_time) ) COMMENT 污染物小时级监测数据;主键用自增id但业务上的唯一键必须是station_code monitor_time。这个唯一键能挡住同一站点同一小时的重复上报是数据清洗的第一道防线。实际项目中接口幂等不是你写了判断逻辑而是数据库层面直接拒绝重复这才是最可靠的。idx_monitor_time是为了给按时间范围取数的查询加索引后面跑预测要取一年的数据没有这个索引全表扫描会非常慢。3.2 采集接口接收上报与去重落库采集接口是整条链路的第一站。实际项目里监测设备上报的数据往往是批量 POST一次可能带几十条记录间隔一分钟重发一次。接口的职责不是做复杂校验而是接收、去重、落库。RestController RequestMapping(/api/collect) public class CollectController { PostMapping(/report) public ResultVoid report(RequestBody ListPollutantReportDTO batch) { // 批量上报同站点同小时只保留最后一条 collectService.saveBatchWithDeduplicate(batch); return Result.success(); } }saveBatchWithDeduplicate的内部逻辑是先把 batch 按station_code monitor_time分组同一组只保留时间戳最新的一条然后批量插入撞到唯一键的自动跳过。这里建议用 MyBatis-Plus 的saveBatch配合数据库唯一键去重不要用“先查询再插入”的方式——一查一插在高频上报场景下性能差也没有天然防竞争的能力。采集接口不要暴露到公网只允许网关和内部网络访问这一点写在项目说明的安全章节里会很加分。3.3 清洗时间对齐先过滤异常值再对齐小时再插缺失采集接口只能处理结构上的重复数值层面的清洗得单独做。污染物数据的脏数据无非几类浓度值为负设备零漂、数值突变到离谱范围、时间戳没有对齐到整点。我的清洗顺序是固定的先过滤负值再对齐时间最后插缺失值。顺序错了插值会把负值也“插”得自然反而更难排查。import pandas as pd df pd.read_csv(raw_pollutant.csv, parse_dates[monitor_time]) # 1. 浓度负值属于设备异常直接过滤 df df[df[pm25] 0] # 2. 对齐为整小时把 10:15 对齐到 10:00 这一档 df df.set_index(monitor_time).resample(h).mean() # 3. 连续缺失不超过 4 小时才线性插值超过则保留 NaN df df.interpolate(methodlinear, limit4)resample(h)会把 10:23 这类时间归到 10:00 一档同档内取均值这就完成了时间对齐。interpolate(methodlinear, limit4)只在连续缺失不超过 4 个小时时插值超过 4 小时说明仪器长时间掉线这时候插出来的数据不具备可信度宁可保留 NaN后面分析时直接跳过。这一步是整条数据链路里最有“工程感”的地方项目说明里能把这 3 步的逻辑都写清楚已经能和其他只用官方数据集的学生拉开差距。3.4 存储选型MySQL够用但要区分分析查询与预测取数毕设阶段数据量通常也就几十万行MySQL 完全够用不需要引入时序数据库。但有两条经验建议你照做第一分析报表的查询和预测服务的取数都走只读库或同一份索引良好的表不要在生产库上跑重型统计 SQL第二如果数据量大到几千万行再把 analysis-service 里的统计 SQL 切到 Spark 或 Hive 上跑离线分析这是在“Spring Cloud 数据平台”方向上加分的关键一笔。存储层永远不要变成瓶颈这是微服务架构里最容易被忽视的一环。4. 分析加预测的落地SQL统计、ARIMA与LSTM两条预测路线怎么选4.1 统计报表用SQL算AQI变化趋势和站点对比分析模块不需要单独写算法绝大多数指标直接用 SQL 聚合就能完成。污染物平台最常见的两个分析需求是某城市近一年 PM2.5 均值走势不同站点同一时段的污染物浓度对比。前者按月份分组即可SELECT station_code, DATE_FORMAT(monitor_time, %Y-%m) AS mon, AVG(pm25) AS avg_pm25, MAX(aqi) AS max_aqi FROM pollutant_hourly WHERE monitor_time DATE_SUB(NOW(), INTERVAL 12 MONTH) GROUP BY station_code, DATE_FORMAT(monitor_time, %Y-%m) ORDER BY station_code, mon;命中了idx_monitor_time索引时间过滤不会全表扫描。注意WHERE里一定要先按时间缩小范围再分组聚合否则数据量起来后这条 SQL 会是整个平台最慢的查询。analysis-service 里把这些 SQL 封装成接口即可前端用 ECharts 把结果渲染成趋势图这个模块就闭环了。4.2 ARIMA路线样本少、趋势平稳时的省心选择预测模块是整个平台的核心得分点但不要一上来就堆 LSTM。先评估数据形态如果只有几个月的日度数据样本量几百条优先用 ARIMA。ARIMA 参数少、训练快、可解释性强答辩时讲“为什么用 ARIMA”比讲“为什么用 LSTM”容易得多。from statsmodels.tsa.arima.model import ARIMA # series 为按小时对齐后的 PM2.5 均值序列先做差分平稳性检查 model ARIMA(series, order(2, 1, 2)) model_fit model.fit() print(model_fit.summary())order(2, 1, 2)里的三个数分别是自回归阶数 p、差分阶数 d、移动平均阶数 q。d1 表示对原序列做一阶差分来消除趋势这是处理污染物浓度这种带季节波动数据最常见的选择。实际项目里我的做法是先跑一遍看 summary 里的 AIC 值再尝试把 p、q 改成 (1,1,1) 或 (3,1,2) 对比哪个 AIC 低用哪个。“ARIMA 的阶数不需要你懂透推导会对比 AIC已经比大多数硬调参学生强了。”4.3 LSTM路线时序数据量足够时的进阶之选如果你的数据集有至少一年的小时级数据LSTM 的拟合上限更高答辩也更有话题性。LSTM 的本质是把时间序列预测改造成监督学习用过去 N 个小时的浓度预测下一个小时。这里的关键参数是滑窗长度 look_back 和归一化。import numpy as np from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dense def make_windows(data, look_back24): x, y [], [] for i in range(look_back, len(data)): x.append(data[i - look_back:i]) y.append(data[i]) return np.array(x), np.array(y) # 先用 MinMaxScaler 把序列归一化到 [0,1]避免浓度量纲影响训练 x_train, y_train make_windows(scaled, look_back24) x_train x_train.reshape((x_train.shape[0], x_train.shape[1], 1)) model Sequential([ LSTM(64, input_shape(24, 1)), Dense(1) ]) model.compile(optimizeradam, lossmse) model.fit(x_train, y_train, epochs50, batch_size32, validation_split0.2)代码里activation我没有显式写这是有意的——LSTM 的默认激活是 tanh比 relu 更适合循环结构。有些教程用 relu训练时梯度很容易异常导致预测结果退化成一条直线。look_back24用过去 24 小时预测下 1 小时污染物浓度有日内周期24 比较自然地覆盖了一个完整周期。训练完成后预测出的结果必须用训练时的 scaler 做 inverse_transform 还原成真实浓度值否则输出永远在 [0,1] 区间答辩时一眼穿帮。4.4 模型封装成独立服务Java和Python各干各的预测模型跑在 Python 里Spring Cloud 服务是 Java两者怎么协作是很多人的盲区。最稳妥的方案Python 侧用 FastAPI 包一层 HTTP 接口predict-service 用 Feign 去调用模型权重文件、Python 环境都独立部署互不影响。千万不要把模型塞进 JVM 里。# predict_service.py from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ForecastRequest(BaseModel): station_code: str hours: int 24 app.post(/api/predict/forecast) def forecast(req: ForecastRequest): # 读取该站点最近look_back小时真实数据加载模型推理 result run_lstm_forecast(req.station_code, req.hours) return {data: result}Java 侧不需要知道 Python 怎么实现的只把它当成一个普通的 HTTP 服务。Feign 接口已经在 2.3 节定义好了此时只需要把url指向 Python 服务的地址或者也注册到 Nacos 里按服务名调用。两条路线我都试过注册到 Nacos 更符合微服务风格但调试时多一跳直接用配置指定地址更省事毕设推荐后者问题定位更快。下表是两条预测路线的选型对比可以直接抄进项目说明维度ARIMALSTM数据量要求几百条即可建议一年以上小时级数据训练成本秒级分钟级可解释性强参数有统计含义弱黑盒部署依赖statsmodels 单文件TensorFlow/Keras 模型文件答辩友好度好讲原理好讲工程但不易讲透5. 避坑与常见问题5条让毕设项目翻车的隐蔽记录5.1 Nacos版本和Spring Boot版本打架控制台静默失败现象服务启动日志显示连接 Nacos 成功但注册中心列表里就是没有这个服务。原因Spring Cloud Alibaba 的每个版本都对应特定版本的 Nacos client 和 Spring Boot版本矩阵对不上时注册过程不会报致命错误只在后台静默失败。这是我在多个项目里亲眼见过的“玄学问题”查了一下午最后发现是版本号组合不对。解决拿到源码后第一件事就是看 pom.xml 里的版本变量按 Spring Cloud Alibaba 官方 release 页面的版本对应表核对。确认 Spring Boot 版本、Spring Cloud 版本、Spring Cloud Alibaba 版本三者一致再谈其他配置。不要用最新版本强行组合“最新不等于兼容”在 Spring 生态里是血泪经验。5.2 Feign默认超时1秒预测接口必挂现象前端调用预测接口10 次里有 7 次返回 500 或 504但 Python 服务手动访问是通的。原因OpenFeign 的默认连接超时和读取超时都是 1 秒预测模型首次要加载权重、推理要算几十步1 秒根本不够。解决按 2.3 节那样配置 Feign 超时连接 3 秒、读取 8 秒起步。再加一层保险在 predict-service 里做一个预热接口服务启动时先加载模型到内存避免第一个请求触发冷启动。我记得一次现场演示就是吃了冷启动的亏提前预热之后50 次连续调用一次都没超时。5.3 一台4G内存的电脑服务启动到一半被系统kill现象Nacos、MySQL、四个微服务依次启动启动到第三个时进程直接消失日志里能看到“Killed”。原因每个 Java 服务默认堆内存按物理内存的 1/4 分配Nacos 本身就要 1G 左右MySQL 再占几百兆4G 内存根本不够分。解决每个微服务启动脚本里显式指定 -Xmx按 128M 起步。Nacos 用单机模式启动不要开集群。MySQL 的 performance_schema 可以关掉能省出一两百兆内存。这是环境配置问题却能让项目看起来“跑不起来”排查优先级排最高。java -Xmx128m -Xms64m -jar># 按时间顺序切分不打乱 split_idx int(len(scaled) * 0.8) train scaled[:split_idx] test scaled[split_idx:] # 只对训练集 fit再 transform 全部 scaler.fit(train.reshape(-1, 1)) train_scaled scaler.transform(train.reshape(-1, 1)) test_scaled scaler.transform(test.reshape(-1, 1))这样模型看到的未来信息只有测试集本身报告的误差才是真实可信的。很多学生习惯把数据一 load 就全量归一化这一个小习惯就是“演示很好”和“真正能预测”的分水岭。6. Docker编排与预测误差验收交付前的最后一关6.1 Docker Compose编排一行命令拉起整套平台毕设答辩时最怕的就是现场环境配置失败用 Docker Compose 把依赖一次性编排好可以省掉一半事故。一个最小编排包含 MySQL、Nacos 和业务服务services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: pollutant volumes: - ./scripts/init.sql:/docker-entrypoint-initdb.d/init.sql nacos: image: nacos/nacos-server:v2.2.3 environment: MODE: standalone ports: - 8848:8848 predict-service: build: ./predict-service depends_on: - mysql - nacos environment: NACOS_ADDR: nacos:8848要点Nacos 必须用MODE: standalone这是单机模式内存占用最小服务间的地址不要写 IP直接写 compose 里的服务名例如nacos:8848Docker 内部网络会解析。演示现场一句话“docker compose up”全部拉起比“双击 start.bat”专业得多。6.2 预测效果验收MAE跟RMSE都要算别只报一个答辩时如果你只贴一张预测对比图评委大概率会追问“误差到底多少”。在验证脚本里同时计算 MAE 和 RMSE并判断是否存在滞后性。MAE 衡量平均偏差RMSE 对大误差更敏感两者结合能看出模型的稳定性。我自己的习惯是再单独算最近 7 天的误差不要只看全量测试集的均值——模型可能在 3 个月前预测得很好最近一周却明显漂移。import numpy as np from sklearn.metrics import mean_absolute_error, mean_squared_error mae mean_absolute_error(y_true, y_pred) rmse np.sqrt(mean_squared_error(y_true, y_pred)) print(fMAE{mae:.2f} ug/m3, RMSE{rmse:.2f} ug/m3)报告里写清楚模型预测的是 PM2.5 浓度单位是 ug/m³MAE 在 10 到 20 之间是合理水平低于 5 就要怀疑数据泄漏高于 30 说明模型基本没用。这套阈值可以帮助你判断项目是不是在“自嗨”。6.3 进阶方向可视化大屏和Spark离线分析按需选平台跑通之后还有两个经常被问到的扩展方向。一个是可视化大屏把 analysis-service 的统计接口接到 ECharts渲染站点热力分布、24 小时浓度走势、超标天数日历图这些图对答辩观感的提升非常直接。另一个是离线分析当数据量确实大到 MySQL 查询吃力时把统计任务换成 Spark 作业跑在 Hive 表上。但我个人的建议是不要为了炫技而上先解决“数据从哪来—在哪分析—如何预测—怎么验证”这条主链路扩展项写进项目说明的“后续优化”一节就够了。这些年我带过的毕设里最常见的遗憾不是模型不够深而是整套平台跑通了数据链路却讲不清楚。我自己的习惯是先拿真实数据在 Excel 里手算三天的 MAE再回去看代码这个简单习惯帮我过滤掉至少一半的“假优秀结果”。真正的预测误差不会因为你用了 LSTM 就自动变小它只跟数据质量和工程细节有关。希望这篇能帮你把链路打通希望帮到你。本文还有配套的精品资源点击获取