简介这是一份面向计算机相关专业在校生与教师的毕设级项目源码基于Spring Cloud(Finchley.SR2)微服务架构打造环境污染物数据分析与预测平台。平台整合Consul注册中心、Zuul网关、Config配置中心等组件实现数据可视化、空气质量排行、PM2.5预测、污染物预警、历史数据导出及API服务等功能。代码完整稳定既可用于课程设计、大作业也适合毕业设计演示与二次开发。资源包共2000个文件约57.49MB涵盖173个Java微服务源码、1078个前端JavaScript及309个CSS样式、138个HTML页面以及JSON/XML配置、Markdown项目说明等。目录按airnet-config-service、airnet-data-service等模块清晰分离便于对照学习微服务拆分与业务实现。项目亮点在于结合Kafka实现异步训练、Redis缓存热点数据并基于Seq2seq模型进行PM2.5浓度预测具有较高技术参考价值。目前已有225人学习下载适合希望进阶Spring Cloud与数据预测实战的开发者。1. 这个毕设值不值得做先把架构看懂再谈跑通毕设题目里只要同时出现 Spring Cloud 和环境污染物数据分析与预测基本就是在说同一件事把分散的监测站数据收进来算成能看的指标再预测未来几小时的污染浓度。这类系统最容易翻车的地方从来不是算法而是微服务之间的数据衔接——CSV 导进去了没校验、AQI 算出来单位不对、预测模型跑通了却不知道参数怎么存。准备拿它当毕业设计的人还有想攒一份微服务落地经验、又不是只写 CRUD 的初级开发都可以从这套方案里找到自己能复用的部分。它解决的是三类真实诉求一是数据从零散文件变成结构化存储二是污染物浓度从原始数值变成有业务含义的 AQI 指标三是基于历史趋势做短时浓度预测。先说清一点这套系统的开发难点在数据接入和联调不在模型。模型用传统时间序列方法就够答辩架构上能讲清楚服务边界比堆一个谁也调不通的 LSTM 有用得多。2. 拆开这套微服务体系五服务划分与 Nacos、存储选型拿到手第一件事不是启动项目而是看整体架构。环境污染物数据分析与预测平台的典型拆法是按数据生命周期分服务而不是按页面分。常见做法是网关、认证、采集、分析、预测五个服务外加 MySQL 和时序库做存储。2.1 按数据流向拆服务别按页面拆拆服务的原则看数据怎么流动数据从 CSV 文件进入系统经过校验入库再做指标聚合最后喂给预测模块。每一道处理都是一个独立服务这样任何一个环节升级或出问题都不影响其他模块。五服务划分如下服务职责关键依赖gateway-service统一入口、路由转发、跨域处理Spring Cloud Gatewayauth-service用户登录、token 签发与校验Spring Security JWTcollector-serviceCSV 上传、脏数据校验、原始数据入库Commons CSV、MyBatis-Plusanalyze-serviceAQI 计算、小时聚合、统计查询接口InfluxDB Java Client、Caffeineforecast-service读取历史序列、加载模型参数、输出预测值模型推理模块、Feign这个划分里分析服务和采集服务是数据量的主要承担者预测服务因为计算密度高且失败不影响主链路单独拆出来最合适。网关和认证是横切关注点放在最外层。服务不是越多越好五个对毕设来说已经到上限再多一个就要多维护一份接口文档和排查一个潜在问题答辩时也更容易被追问。数据流的完整路径是前端上传 CSV 到网关网关转发到采集服务校验后写入 MySQL分析服务定时或按需从 MySQL 读取原始记录计算 AQI 后写入小时聚合表前端查询时走分析服务的聚合接口预测服务通过 Feign 拉取历史序列加载模型参数后返回预测结果。这条链路每个节点都清晰答辩画图时也方便讲。2.2 Nacos 做注册与配置中心一条命令启动一个 yml 说清依赖服务间调用需要知道彼此地址配置也要集中管理。常见选型是 Nacos一个组件同时覆盖注册中心和配置中心比 Eureka 加 Spring Cloud Config 的组合少维护一个服务。启动 Nacos 在 Linux 下一条命令即可Windows 下用 startup.cmd默认端口 8848。服务接入 Nacos 需要引入依赖注意版本统一交给 BOM 管理。核心依赖如下dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-bootstrap/artifactId /dependency第三个依赖是很多人漏掉的。Spring Cloud 2021 之后默认关闭 bootstrap 上下文不加这个依赖Nacos 配置中心的数据不会加载。每个服务里的 application.yml 只需要写应用名和 Nacos 地址。spring: application: name: analyze-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 config: server-addr: 127.0.0.1:8848 file-extension: yaml这里有个实用细节配置中心的 dataId 默认是服务名加扩展名比如 analyze-service.yaml。数据库口令、模型参数路径这些容易变的东西放进配置中心代码里不要硬编码。我曾经见过把数据库密码写在 application.yml 里提交到仓库的这种毕设答辩时会被直接打回。Nacos 还支持配置热更新改完配置发布后服务不需要重启演示的时候可以当加分项。2.3 存储选型MySQL 存业务InfluxDB 存时序环境污染物浓度数据是典型的时间序列数据每条记录是站点加时间加一堆浓度字段。这类数据用关系库也能存但量级上来后聚合查询会很吃力。常见做法是 MySQL 负责用户、站点、批次记录等业务数据InfluxDB 负责原始浓度数据。不同方案的适用场景可以看对比表方案适用量级优点风险MySQL 单表加复合索引百万行以下简单答辩好解释数据量大后聚合变慢MySQL 分区表千万行级别不用引入新组件分区维护麻烦InfluxDB 时序库任意量级聚合查询快、保留策略自动清理需要解释为什么引入多组件原始表设计上核心字段包括站点编号、记录时间、SO2、NO2、PM10、PM2.5、O3、CO附带温度和湿度。复合索引建在站点编号加记录时间上这是查询最常用的条件。CO 浓度单位和其他污染物不同是 mg/m³其他是 µg/m³入库时做好单位标注后面算 AQI 才不会出错。小时聚合表单独一张存每个站点每小时的平均浓度和最大浓度页面查询直接走这张表不扫原始数据。3. 环境污染物数据入库从 CSV 到 AQI 指标的完整链路数据接入是这套系统的第一个拦路虎。环境监测数据最常见的载体是 Excel 导出的 CSV一行一条记录包含时间、站点和各污染物浓度。把 CSV 变成数据库里可用的记录需要解决三个问题文件解析、脏数据清洗、批量写入效率。3.1 CSV 批量导入接口先解决 BOM、脏数据和批量提交CSV 导入接口的核心不是解析而是不知道数据会脏成什么样。Excel 导出的 CSV 自带 UTF-8 BOM第一列列名会带一个不可见字符直接按列名取值会全部落空。还有负浓度、空值、时间格式混乱等问题都需要在解析时处理。PostMapping(/import) public Result importCsv(RequestParam(file) MultipartFile file) { int total 0, skipped 0; try (BufferedReader reader new BufferedReader( new InputStreamReader(file.getInputStream(), StandardCharsets.UTF_8))) { String line reader.readLine(); if (line ! null line.startsWith(\uFEFF)) { line line.substring(1); // 去掉 BOM 头 } String[] headers line.split(,); MapString, Integer colIndex buildColIndex(headers); if (!colIndex.containsKey(record_time) || !colIndex.containsKey(pm25)) { return Result.fail(列头不符合约定缺少 record_time 或 pm25); } ListPollutantDO batch new ArrayList(BATCH_SIZE); String dataLine; while ((dataLine reader.readLine()) ! null) { try { PollutantDO row parseLine(dataLine, colIndex); if (row null) { skipped; continue; } batch.add(row); if (batch.size() BATCH_SIZE) { pollutantMapper.batchInsert(batch); total batch.size(); batch.clear(); } } catch (Exception e) { skipped; } } if (!batch.isEmpty()) { pollutantMapper.batchInsert(batch); total batch.size(); } } catch (IOException e) { return Result.fail(文件读取失败); } return Result.ok(导入完成成功 total 条跳过 skipped 条); }这段代码里有三个关键点。第一BOM 头必须在读取第一行时处理否则列名匹配不上。第二单行解析失败不能中断整个导入计数跳过但要返回给前端让用户知道哪些数据有问题。第三批量写入用 batchSize 控制每 500 条提交一次避免一次性攒几万条在内存里导致 OOM。parseLine 方法里做的校验包括时间字段能解析成 LocalDateTime、浓度值不能为负、PM2.5 浓度不能超过物理上限 1000。超出上限的记录直接丢弃。这里解释一下为什么用 BufferedReader 而不是 EasyExcel毕设项目的导入数据量通常在几万行以内BufferedReader 按行读够用依赖也更少答辩时逻辑讲得清楚。3.2 AQI 分指数计算单位换算与分段插值的实现AQI 不是简单的浓度平均而是先对每种污染物算分指数 IAQI取最大值。每个污染物的浓度区间对应一个 IAQI 区间落在线性插值上。公式是分段线性插值国标上给了一张完整的浓度限值表代码里保存这张表即可。最容易错的是 CO 单位国标表里的 CO 浓度是 mg/m³但很多原始数据给的是 µg/m³不改单位算出来的 IAQI 直接翻车。public int calcIAQI(double conc, int[] cLow, int[] cHigh, int[] iLow, int[] iHigh) { if (conc cHigh[cHigh.length - 1]) { return iHigh[iHigh.length - 1]; } for (int i 0; i cHigh.length; i) { if (conc cHigh[i]) { if (conc cLow[i]) { return iLow[i]; } double result (double) (iHigh[i] - iLow[i]) * (conc - cLow[i]) / (cHigh[i] - cLow[i]) iLow[i]; return (int) Math.round(result); } } return iLow[0]; }代码逻辑本身不复杂但有两个细节决定结果对不对。第一乘法和除法要注意运算顺序先乘后除避免整数除法直接截断。第二浓度恰好落在边界值时返回对应区间的 IAQI 下限这是国标约定。每种污染物的分段表用数组传入表本身可以放在配置中心比如 nacos 配置里维护一份 yaml这样国标更新时不需要重新部署代码。算完每种污染物的 IAQI 后整条记录的 AQI 就是其中的最大值首要污染物是 IAQI 最大的那个。这里可以额外做一个校验接口用一张包含站点、时间、各污染物浓度和 AQI 的 CSV 反向校验计算结果防止分段表配置错位。我一般会在导入完成后自动触发一次抽样校验拿 10 条记录和平台计算值对比误差超过 1 就告警。3.3 小时聚合查询给可视化接口提速的缓存与索引思路页面上的趋势图不会看原始分钟数据而是看小时聚合。聚合操作如果每次请求都实时扫原始表几万行数据加 group by 会明显变慢。常见做法是写入时同步维护小时聚合表查询时只读聚合表。聚合 SQL 里有个隐藏问题要注意。SELECT DATE_FORMAT(record_time, %Y-%m-%d %H:00) AS hour_start, AVG(pm25) AS avg_pm25, MAX(pm25) AS max_pm25 FROM pollutant_record WHERE station_id #{stationId} AND record_time #{startTime} AND record_time #{endTime} GROUP BY DATE_FORMAT(record_time, %Y-%m-%d %H:00)这条 SQL 看着没问题但如果对 record_time 字段套了 DATE_FORMAT 再做条件过滤复合索引会失效。正确做法是 where 条件里直接用原始时间字段比较group by 里再格式化输出。索引设计上pollutant_record 表建(station_id, record_time)复合索引查询条件先按站点过滤再按时间范围过滤命中索引后性能能提升一个数量级。聚合结果还被频繁查询需要做缓存。毕设级别用 Caffeine 就够了不需要上 Redis。缓存在 analyze-service 里加一层key 是站点加时间范围过期时间 10 分钟聚合数据本身变化频率低10 分钟内的延迟对可视化页面完全无感。CacheString, ListHourlyAggVO cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(10)) .build(); public ListHourlyAggVO queryHourly(String stationId, LocalDateTime start, LocalDateTime end) { String key stationId : start : end; return cache.get(key, k - loadFromDb(stationId, start, end)); }缓存加载失败时要能回源数据库Caffeine 的 get 方法自带这个能力。注意 key 里要带上站点和时间范围只按站点做 key 会导致不同时间段的请求互相覆盖缓存。4. 污染物浓度预测把 Python 训练模型融进 Spring Cloud 微服务体系预测模块是整套系统的最大亮点也是最容易翻车的环节。很多毕设一上来就选 LSTM但环境监测数据量通常只有几千到几万条LSTM 训练不稳定周期还长。传统时序方法在数据量小、周期性强的场景下更可靠而且参数可以导出Java 侧能直接实现推理。先跑通轻量路线再谈升级才是务实的做法。4.1 预测引擎的两种落法远程 Python 服务还是 Java 本地推理Python 在数据分析与数据挖掘上优势明显但怎么融进 Spring Cloud 微服务体系有两条路可走。一条是用 FastAPI 写独立预测服务注册到 Nacos和其他微服务一样走注册发现另一条是 Python 只做离线训练把模型参数导出成 JSONJava 侧加载参数完成推理。两条路的取舍很清楚方案部署依赖实时性答辩风险Python FastAPI 独立服务需要运行 Python 环境安装依赖每次预测走 HTTP 调用现场环境缺包会导致演示失败Java 本地推理只要一个 jar 包无网络开销需要解释清楚模型能力边界毕设推荐第二种。训练阶段在 Python 里把模型调好参数导出成 JSON提交到代码仓库Java 侧启动时加载参数预测时直接计算。这样不依赖 Python 运行环境演示时只要服务还活着就能出结果。如果项目说明里强调要体现 Python 能力可以在数据处理链路里加一个 Python 脚本做数据清洗和缺失值填充而不是把推理服务独立部署。4.2 Python 离线训练脚本滞后特征、时序切分与参数导出预测目标设定为某个站点未来一小时的 PM2.5 浓度。特征不用太多滞后特征加时间特征就够。滞后的含义是取过去某个时刻的浓度值作为输入比如前 1 小时、前 3 小时和前 24 小时的 PM2.5加上当前小时和月份。模型用岭回归能处理特征间的相关性参数也容易导出。关键是切分数据集时不能随机打乱时间序列必须按时间顺序切分否则会用到未来数据看起来精度很高真实预测就露馅。import pandas as pd from sklearn.linear_model import Ridge from sklearn.metrics import mean_absolute_error import json df pd.read_csv(pm25_hourly.csv, parse_dates[time]) df df.sort_values(time) # 滞后特征 df[lag_1h] df[pm25].shift(1) df[lag_3h] df[pm25].shift(3) df[lag_24h] df[pm25].shift(24) df[hour] df[time].dt.hour df[month] df[time].dt.month df df.dropna().reset_index(dropTrue) features [lag_1h, lag_3h, lag_24h, hour, month] X df[features] y df[pm25] # 按时间切分前 80% 训练后 20% 验证 cut int(len(df) * 0.8) X_train, X_test X.iloc[:cut], X.iloc[cut:] y_train, y_test y.iloc[:cut], y.iloc[cut:] model Ridge(alpha1.0) model.fit(X_train, y_train) pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, pred)) params { features: features, coef: model.coef_.tolist(), intercept: model.intercept_ } with open(ridge_params.json, w, encodingutf-8) as f: json.dump(params, f, ensure_asciiFalse, indent2)脚本里三个细节值得说。第一shift 产生的缺失值必须 dropna否则会把空值喂给模型。第二时序切分用 iloc 按行号切不要用 train_test_split 的默认随机模式。第三coef 转成 list 再写 JSONnumpy 的 ndarray 不能直接序列化。输出结果里看 MAE对 PM2.5 来说误差在 15 以内就算能接受。数据量只有几千条时这种带滞后特征的线性回归往往比复杂模型更稳。导出 JSON 而不是 pickle是刻意为之。pickle 文件隐含执行代码的风险而且 pandas 或 sklearn 版本一升级可能就加载不了。JSON 参数文件可读、可审查、可版本控制Java 侧解析也方便毕设答辩时往这个方向解释反而加分。4.3 Java 侧推理实现特征顺序对齐与滚动预测Java 侧拿到 ridge_params.json 后要做的事是加载参数、构建特征、套用线性公式。这里最大的坑是特征顺序必须和 Python 训练时完全一致。Python 侧训练时特征列表是 lag_1h、lag_3h、lag_24h、hour、monthJava 侧构建数组时也得按这个顺序不能看心情调整。预测服务里的核心实现也不复杂Service public class RidgeForecastEngine implements ForecastEngine { private final ModelParams modelParams; public RidgeForecastEngine(ModelParams modelParams) { this.modelParams modelParams; } public double predictNext(ListDouble historyPm25, LocalDateTime now) { double[] features buildFeatures(historyPm25, now); double result modelParams.getIntercept(); double[] coef modelParams.getCoef(); for (int i 0; i coef.length; i) { result coef[i] * features[i]; } // 浓度不允许为负 return Math.max(0, result); } private double[] buildFeatures(ListDouble history, LocalDateTime now) { double[] features new double[5]; features[0] getLag(history, 1); // 前 1 小时 features[1] getLag(history, 3); // 前 3 小时 features[2] getLag(history, 24); // 前 24 小时 features[3] now.getHour(); features[4] now.getMonthValue(); return features; } private double getLag(ListDouble history, int hours) { int idx history.size() - hours; if (idx 0) { return history.get(idx); } return history.get(0); } }滚动预测的意思是要预测未来 3 个小时需要把上一小时的预测值补回历史序列尾部再算下一个。所以 predictNext 每次只推一步外层循环控制步数。这个设计要提前想好否则遇到连续预测需求就要重新设计接口。ForecastEngine 设计成接口当前实现是 RidgeForecastEngine后续想换模型不影响调用方。模型参数加载可以放到配置中心也可以用资源文件。我倾向于把 JSON 放在 classpath 下启动时读取不存在远程依赖。如果参数文件缺失或特征维度对不上启动时直接抛异常不要等到调用预测接口时报错这样更早暴露问题。5. 联调避坑指南5 个让答辩现场翻车的细节微服务联调阶段的坑比想象中多而且很多坑在自己的机器上根本不会暴露一到现场演示就出问题。下面五条都是血泪经验每条按现象、原因、解决来拆。5.1 网关 503、Feign 时间错乱、CSV 乱码联调期高频三连网关转发报 503 Service Unavailable直接请求后端的分析服务 8080 端口却能通。这个现象很典型原因大概率是 Spring Cloud 2021 版本移除了 RibbonOpenFeign 发起调用时没有负载均衡实现拿不到可用的实例列表。解决方法是引入spring-cloud-starter-loadbalancer依赖在网关和分析服务的调用方都加上。检查时先看 Nacos 服务列表里服务是否在线再看调用方有没有 loadbalancer 依赖两步能定位大多数问题。Feign 调用返回的时间字段错乱前端拿到的时间变成了数组或者少了 8 小时。原因是两个服务配置了不同的 Jackson 序列化规则一个把 LocalDateTime 序列化成 ISO 字符串一个序列化成时间戳数组。解决方法是统一注册 Jackson 定制器日期格式固定为yyyy-MM-dd HH:mm:ss时区统一 GMT8所有服务共用同一份配置类。CSV 导入时第一列列名乱码中文列名变成类似锘库record_time的开头。原因是 Excel 导出的 CSV 带 UTF-8 BOMInputStreamReader 按 UTF-8 读取时本身能显示正常但 Java 字符串里开头多了一个\uFEFF字符。解决方式是读取第一行后判断是否以\uFEFF开头是就去掉。这个字符肉眼看不见但 map 里按列名取值时永远匹配不上非常隐蔽。5.2 预测虚高、模型文件损坏、接口超时数据链路隐蔽雷区预测模块的验证集误差很好但上线后预测值明显偏离真实值。原因通常是数据泄漏训练时用了随机切分而不是时序切分随机切分会让模型偷看到未来信息验证集是开卷考试真实预测就露馅。解决方式是回到训练脚本按时间顺序前 80% 训练、后 20% 验证重新评估 MAE。这个坑不只在毕设里常见很多论文的实验数据也是这样虚高的答辩时会被直接问穿。项目打包或克隆到别的机器后预测接口报模型参数文件不存在。原因是模型参数文件用相对路径加载路径依赖运行目录。解决方式是把 JSON 放到 resources 目录下用ClassPathResource读取不要用File路径。另外如果模型文件是 pickle 格式提交到 git 后可能因为换行符或版本问题损坏这也是前面坚持用 JSON 的原因。预测接口偶发超时前端等十几秒才有响应。常见原因是推理逻辑里做了同步 HTTP 调用远程 Python 服务模型加载又慢叠加起来就超时。解决方式分三层模型参数启动时预热加载不放在首次调用时初始化相同请求用 Caffeine 缓存短期结果外部调用超时时间从 3 秒调到 10 秒并加熔断降级。毕设里做到前两层基本就够演示了。6. 答辩前验收用一条手算数据钉死整条链路最后的验收阶段不要只开着系统点页面。准备一条手算数据把整条链路从导入到预测全量核对一遍这个方法比自动化测试更能在答辩现场讲出说服力。手算样本的做法是挑一个站点某一天的数据手动用 Excel 算出该小时 6 种污染物的 IAQI取最大值得出 AQI记下结果。然后调导入接口把这份 CSV 导入平台查页面上同一时刻的 AQI两个值必须一致。预测部分同理取某个时刻前 24 小时的序列手动代入回归公式算一个预测值和平台接口返回结果对比误差应该在 0.01 以内。这里公式系数是定点数不用浮点数计算误差只在小数位。每个服务启动后先做健康检查一条命令串起来for svc in gateway-service auth-service collector-service analyze-service forecast-service; do echo $svc curl -s http://localhost:9000/$svc/actuator/health echo done如果某个服务返回 DOWN不要直接重启先看 Nacos 控制台里服务是否注册成功再看日志里数据库连接是否正常。这套检查流程可以在答辩前半小时完整跑一遍比临时翻日志靠谱得多。进阶用法上ForecastEngine 接口留了一个扩展位。如果后续想换 LSTM只需要新增一个实现类用 Spring 的Qualifier做切换调用方完全不用改。这个设计本身就是一个可讲的答辩亮点比模型本身更能体现工程思维。另外一个习惯是我做这类系统养成的模型参数文件导出后立刻在代码里写一个加载校验测试专门检查特征维度和系数个数是否匹配。环境污染物预测本身有大量不确定性模型参数过拟合很正常关键是给自己留一条快速验证的路。手算数据、健康检查脚本、接口抽象这三样东西就是这条路的护栏。希望帮到你毕设顺利。本文还有配套的精品资源点击获取 
长河君 · 2026/10/2 13:24:17 · 阅读 1.2k Spring Cloud微服务环境污染物数据分析与预测平台架构实践
简介这是一份面向计算机相关专业在校生与教师的毕设级项目源码基于Spring Cloud(Finchley.SR2)微服务架构打造环境污染物数据分析与预测平台。平台整合Consul注册中心、Zuul网关、Config配置中心等组件实现数据可视化、空气质量排行、PM2.5预测、污染物预警、历史数据导出及API服务等功能。代码完整稳定既可用于课程设计、大作业也适合毕业设计演示与二次开发。资源包共2000个文件约57.49MB涵盖173个Java微服务源码、1078个前端JavaScript及309个CSS样式、138个HTML页面以及JSON/XML配置、Markdown项目说明等。目录按airnet-config-service、airnet-data-service等模块清晰分离便于对照学习微服务拆分与业务实现。项目亮点在于结合Kafka实现异步训练、Redis缓存热点数据并基于Seq2seq模型进行PM2.5浓度预测具有较高技术参考价值。目前已有225人学习下载适合希望进阶Spring Cloud与数据预测实战的开发者。1. 这个毕设值不值得做先把架构看懂再谈跑通毕设题目里只要同时出现 Spring Cloud 和环境污染物数据分析与预测基本就是在说同一件事把分散的监测站数据收进来算成能看的指标再预测未来几小时的污染浓度。这类系统最容易翻车的地方从来不是算法而是微服务之间的数据衔接——CSV 导进去了没校验、AQI 算出来单位不对、预测模型跑通了却不知道参数怎么存。准备拿它当毕业设计的人还有想攒一份微服务落地经验、又不是只写 CRUD 的初级开发都可以从这套方案里找到自己能复用的部分。它解决的是三类真实诉求一是数据从零散文件变成结构化存储二是污染物浓度从原始数值变成有业务含义的 AQI 指标三是基于历史趋势做短时浓度预测。先说清一点这套系统的开发难点在数据接入和联调不在模型。模型用传统时间序列方法就够答辩架构上能讲清楚服务边界比堆一个谁也调不通的 LSTM 有用得多。2. 拆开这套微服务体系五服务划分与 Nacos、存储选型拿到手第一件事不是启动项目而是看整体架构。环境污染物数据分析与预测平台的典型拆法是按数据生命周期分服务而不是按页面分。常见做法是网关、认证、采集、分析、预测五个服务外加 MySQL 和时序库做存储。2.1 按数据流向拆服务别按页面拆拆服务的原则看数据怎么流动数据从 CSV 文件进入系统经过校验入库再做指标聚合最后喂给预测模块。每一道处理都是一个独立服务这样任何一个环节升级或出问题都不影响其他模块。五服务划分如下服务职责关键依赖gateway-service统一入口、路由转发、跨域处理Spring Cloud Gatewayauth-service用户登录、token 签发与校验Spring Security JWTcollector-serviceCSV 上传、脏数据校验、原始数据入库Commons CSV、MyBatis-Plusanalyze-serviceAQI 计算、小时聚合、统计查询接口InfluxDB Java Client、Caffeineforecast-service读取历史序列、加载模型参数、输出预测值模型推理模块、Feign这个划分里分析服务和采集服务是数据量的主要承担者预测服务因为计算密度高且失败不影响主链路单独拆出来最合适。网关和认证是横切关注点放在最外层。服务不是越多越好五个对毕设来说已经到上限再多一个就要多维护一份接口文档和排查一个潜在问题答辩时也更容易被追问。数据流的完整路径是前端上传 CSV 到网关网关转发到采集服务校验后写入 MySQL分析服务定时或按需从 MySQL 读取原始记录计算 AQI 后写入小时聚合表前端查询时走分析服务的聚合接口预测服务通过 Feign 拉取历史序列加载模型参数后返回预测结果。这条链路每个节点都清晰答辩画图时也方便讲。2.2 Nacos 做注册与配置中心一条命令启动一个 yml 说清依赖服务间调用需要知道彼此地址配置也要集中管理。常见选型是 Nacos一个组件同时覆盖注册中心和配置中心比 Eureka 加 Spring Cloud Config 的组合少维护一个服务。启动 Nacos 在 Linux 下一条命令即可Windows 下用 startup.cmd默认端口 8848。服务接入 Nacos 需要引入依赖注意版本统一交给 BOM 管理。核心依赖如下dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-discovery/artifactId /dependency dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-nacos-config/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-bootstrap/artifactId /dependency第三个依赖是很多人漏掉的。Spring Cloud 2021 之后默认关闭 bootstrap 上下文不加这个依赖Nacos 配置中心的数据不会加载。每个服务里的 application.yml 只需要写应用名和 Nacos 地址。spring: application: name: analyze-service cloud: nacos: discovery: server-addr: 127.0.0.1:8848 config: server-addr: 127.0.0.1:8848 file-extension: yaml这里有个实用细节配置中心的 dataId 默认是服务名加扩展名比如 analyze-service.yaml。数据库口令、模型参数路径这些容易变的东西放进配置中心代码里不要硬编码。我曾经见过把数据库密码写在 application.yml 里提交到仓库的这种毕设答辩时会被直接打回。Nacos 还支持配置热更新改完配置发布后服务不需要重启演示的时候可以当加分项。2.3 存储选型MySQL 存业务InfluxDB 存时序环境污染物浓度数据是典型的时间序列数据每条记录是站点加时间加一堆浓度字段。这类数据用关系库也能存但量级上来后聚合查询会很吃力。常见做法是 MySQL 负责用户、站点、批次记录等业务数据InfluxDB 负责原始浓度数据。不同方案的适用场景可以看对比表方案适用量级优点风险MySQL 单表加复合索引百万行以下简单答辩好解释数据量大后聚合变慢MySQL 分区表千万行级别不用引入新组件分区维护麻烦InfluxDB 时序库任意量级聚合查询快、保留策略自动清理需要解释为什么引入多组件原始表设计上核心字段包括站点编号、记录时间、SO2、NO2、PM10、PM2.5、O3、CO附带温度和湿度。复合索引建在站点编号加记录时间上这是查询最常用的条件。CO 浓度单位和其他污染物不同是 mg/m³其他是 µg/m³入库时做好单位标注后面算 AQI 才不会出错。小时聚合表单独一张存每个站点每小时的平均浓度和最大浓度页面查询直接走这张表不扫原始数据。3. 环境污染物数据入库从 CSV 到 AQI 指标的完整链路数据接入是这套系统的第一个拦路虎。环境监测数据最常见的载体是 Excel 导出的 CSV一行一条记录包含时间、站点和各污染物浓度。把 CSV 变成数据库里可用的记录需要解决三个问题文件解析、脏数据清洗、批量写入效率。3.1 CSV 批量导入接口先解决 BOM、脏数据和批量提交CSV 导入接口的核心不是解析而是不知道数据会脏成什么样。Excel 导出的 CSV 自带 UTF-8 BOM第一列列名会带一个不可见字符直接按列名取值会全部落空。还有负浓度、空值、时间格式混乱等问题都需要在解析时处理。PostMapping(/import) public Result importCsv(RequestParam(file) MultipartFile file) { int total 0, skipped 0; try (BufferedReader reader new BufferedReader( new InputStreamReader(file.getInputStream(), StandardCharsets.UTF_8))) { String line reader.readLine(); if (line ! null line.startsWith(\uFEFF)) { line line.substring(1); // 去掉 BOM 头 } String[] headers line.split(,); MapString, Integer colIndex buildColIndex(headers); if (!colIndex.containsKey(record_time) || !colIndex.containsKey(pm25)) { return Result.fail(列头不符合约定缺少 record_time 或 pm25); } ListPollutantDO batch new ArrayList(BATCH_SIZE); String dataLine; while ((dataLine reader.readLine()) ! null) { try { PollutantDO row parseLine(dataLine, colIndex); if (row null) { skipped; continue; } batch.add(row); if (batch.size() BATCH_SIZE) { pollutantMapper.batchInsert(batch); total batch.size(); batch.clear(); } } catch (Exception e) { skipped; } } if (!batch.isEmpty()) { pollutantMapper.batchInsert(batch); total batch.size(); } } catch (IOException e) { return Result.fail(文件读取失败); } return Result.ok(导入完成成功 total 条跳过 skipped 条); }这段代码里有三个关键点。第一BOM 头必须在读取第一行时处理否则列名匹配不上。第二单行解析失败不能中断整个导入计数跳过但要返回给前端让用户知道哪些数据有问题。第三批量写入用 batchSize 控制每 500 条提交一次避免一次性攒几万条在内存里导致 OOM。parseLine 方法里做的校验包括时间字段能解析成 LocalDateTime、浓度值不能为负、PM2.5 浓度不能超过物理上限 1000。超出上限的记录直接丢弃。这里解释一下为什么用 BufferedReader 而不是 EasyExcel毕设项目的导入数据量通常在几万行以内BufferedReader 按行读够用依赖也更少答辩时逻辑讲得清楚。3.2 AQI 分指数计算单位换算与分段插值的实现AQI 不是简单的浓度平均而是先对每种污染物算分指数 IAQI取最大值。每个污染物的浓度区间对应一个 IAQI 区间落在线性插值上。公式是分段线性插值国标上给了一张完整的浓度限值表代码里保存这张表即可。最容易错的是 CO 单位国标表里的 CO 浓度是 mg/m³但很多原始数据给的是 µg/m³不改单位算出来的 IAQI 直接翻车。public int calcIAQI(double conc, int[] cLow, int[] cHigh, int[] iLow, int[] iHigh) { if (conc cHigh[cHigh.length - 1]) { return iHigh[iHigh.length - 1]; } for (int i 0; i cHigh.length; i) { if (conc cHigh[i]) { if (conc cLow[i]) { return iLow[i]; } double result (double) (iHigh[i] - iLow[i]) * (conc - cLow[i]) / (cHigh[i] - cLow[i]) iLow[i]; return (int) Math.round(result); } } return iLow[0]; }代码逻辑本身不复杂但有两个细节决定结果对不对。第一乘法和除法要注意运算顺序先乘后除避免整数除法直接截断。第二浓度恰好落在边界值时返回对应区间的 IAQI 下限这是国标约定。每种污染物的分段表用数组传入表本身可以放在配置中心比如 nacos 配置里维护一份 yaml这样国标更新时不需要重新部署代码。算完每种污染物的 IAQI 后整条记录的 AQI 就是其中的最大值首要污染物是 IAQI 最大的那个。这里可以额外做一个校验接口用一张包含站点、时间、各污染物浓度和 AQI 的 CSV 反向校验计算结果防止分段表配置错位。我一般会在导入完成后自动触发一次抽样校验拿 10 条记录和平台计算值对比误差超过 1 就告警。3.3 小时聚合查询给可视化接口提速的缓存与索引思路页面上的趋势图不会看原始分钟数据而是看小时聚合。聚合操作如果每次请求都实时扫原始表几万行数据加 group by 会明显变慢。常见做法是写入时同步维护小时聚合表查询时只读聚合表。聚合 SQL 里有个隐藏问题要注意。SELECT DATE_FORMAT(record_time, %Y-%m-%d %H:00) AS hour_start, AVG(pm25) AS avg_pm25, MAX(pm25) AS max_pm25 FROM pollutant_record WHERE station_id #{stationId} AND record_time #{startTime} AND record_time #{endTime} GROUP BY DATE_FORMAT(record_time, %Y-%m-%d %H:00)这条 SQL 看着没问题但如果对 record_time 字段套了 DATE_FORMAT 再做条件过滤复合索引会失效。正确做法是 where 条件里直接用原始时间字段比较group by 里再格式化输出。索引设计上pollutant_record 表建(station_id, record_time)复合索引查询条件先按站点过滤再按时间范围过滤命中索引后性能能提升一个数量级。聚合结果还被频繁查询需要做缓存。毕设级别用 Caffeine 就够了不需要上 Redis。缓存在 analyze-service 里加一层key 是站点加时间范围过期时间 10 分钟聚合数据本身变化频率低10 分钟内的延迟对可视化页面完全无感。CacheString, ListHourlyAggVO cache Caffeine.newBuilder() .maximumSize(10_000) .expireAfterWrite(Duration.ofMinutes(10)) .build(); public ListHourlyAggVO queryHourly(String stationId, LocalDateTime start, LocalDateTime end) { String key stationId : start : end; return cache.get(key, k - loadFromDb(stationId, start, end)); }缓存加载失败时要能回源数据库Caffeine 的 get 方法自带这个能力。注意 key 里要带上站点和时间范围只按站点做 key 会导致不同时间段的请求互相覆盖缓存。4. 污染物浓度预测把 Python 训练模型融进 Spring Cloud 微服务体系预测模块是整套系统的最大亮点也是最容易翻车的环节。很多毕设一上来就选 LSTM但环境监测数据量通常只有几千到几万条LSTM 训练不稳定周期还长。传统时序方法在数据量小、周期性强的场景下更可靠而且参数可以导出Java 侧能直接实现推理。先跑通轻量路线再谈升级才是务实的做法。4.1 预测引擎的两种落法远程 Python 服务还是 Java 本地推理Python 在数据分析与数据挖掘上优势明显但怎么融进 Spring Cloud 微服务体系有两条路可走。一条是用 FastAPI 写独立预测服务注册到 Nacos和其他微服务一样走注册发现另一条是 Python 只做离线训练把模型参数导出成 JSONJava 侧加载参数完成推理。两条路的取舍很清楚方案部署依赖实时性答辩风险Python FastAPI 独立服务需要运行 Python 环境安装依赖每次预测走 HTTP 调用现场环境缺包会导致演示失败Java 本地推理只要一个 jar 包无网络开销需要解释清楚模型能力边界毕设推荐第二种。训练阶段在 Python 里把模型调好参数导出成 JSON提交到代码仓库Java 侧启动时加载参数预测时直接计算。这样不依赖 Python 运行环境演示时只要服务还活着就能出结果。如果项目说明里强调要体现 Python 能力可以在数据处理链路里加一个 Python 脚本做数据清洗和缺失值填充而不是把推理服务独立部署。4.2 Python 离线训练脚本滞后特征、时序切分与参数导出预测目标设定为某个站点未来一小时的 PM2.5 浓度。特征不用太多滞后特征加时间特征就够。滞后的含义是取过去某个时刻的浓度值作为输入比如前 1 小时、前 3 小时和前 24 小时的 PM2.5加上当前小时和月份。模型用岭回归能处理特征间的相关性参数也容易导出。关键是切分数据集时不能随机打乱时间序列必须按时间顺序切分否则会用到未来数据看起来精度很高真实预测就露馅。import pandas as pd from sklearn.linear_model import Ridge from sklearn.metrics import mean_absolute_error import json df pd.read_csv(pm25_hourly.csv, parse_dates[time]) df df.sort_values(time) # 滞后特征 df[lag_1h] df[pm25].shift(1) df[lag_3h] df[pm25].shift(3) df[lag_24h] df[pm25].shift(24) df[hour] df[time].dt.hour df[month] df[time].dt.month df df.dropna().reset_index(dropTrue) features [lag_1h, lag_3h, lag_24h, hour, month] X df[features] y df[pm25] # 按时间切分前 80% 训练后 20% 验证 cut int(len(df) * 0.8) X_train, X_test X.iloc[:cut], X.iloc[cut:] y_train, y_test y.iloc[:cut], y.iloc[cut:] model Ridge(alpha1.0) model.fit(X_train, y_train) pred model.predict(X_test) print(MAE:, mean_absolute_error(y_test, pred)) params { features: features, coef: model.coef_.tolist(), intercept: model.intercept_ } with open(ridge_params.json, w, encodingutf-8) as f: json.dump(params, f, ensure_asciiFalse, indent2)脚本里三个细节值得说。第一shift 产生的缺失值必须 dropna否则会把空值喂给模型。第二时序切分用 iloc 按行号切不要用 train_test_split 的默认随机模式。第三coef 转成 list 再写 JSONnumpy 的 ndarray 不能直接序列化。输出结果里看 MAE对 PM2.5 来说误差在 15 以内就算能接受。数据量只有几千条时这种带滞后特征的线性回归往往比复杂模型更稳。导出 JSON 而不是 pickle是刻意为之。pickle 文件隐含执行代码的风险而且 pandas 或 sklearn 版本一升级可能就加载不了。JSON 参数文件可读、可审查、可版本控制Java 侧解析也方便毕设答辩时往这个方向解释反而加分。4.3 Java 侧推理实现特征顺序对齐与滚动预测Java 侧拿到 ridge_params.json 后要做的事是加载参数、构建特征、套用线性公式。这里最大的坑是特征顺序必须和 Python 训练时完全一致。Python 侧训练时特征列表是 lag_1h、lag_3h、lag_24h、hour、monthJava 侧构建数组时也得按这个顺序不能看心情调整。预测服务里的核心实现也不复杂Service public class RidgeForecastEngine implements ForecastEngine { private final ModelParams modelParams; public RidgeForecastEngine(ModelParams modelParams) { this.modelParams modelParams; } public double predictNext(ListDouble historyPm25, LocalDateTime now) { double[] features buildFeatures(historyPm25, now); double result modelParams.getIntercept(); double[] coef modelParams.getCoef(); for (int i 0; i coef.length; i) { result coef[i] * features[i]; } // 浓度不允许为负 return Math.max(0, result); } private double[] buildFeatures(ListDouble history, LocalDateTime now) { double[] features new double[5]; features[0] getLag(history, 1); // 前 1 小时 features[1] getLag(history, 3); // 前 3 小时 features[2] getLag(history, 24); // 前 24 小时 features[3] now.getHour(); features[4] now.getMonthValue(); return features; } private double getLag(ListDouble history, int hours) { int idx history.size() - hours; if (idx 0) { return history.get(idx); } return history.get(0); } }滚动预测的意思是要预测未来 3 个小时需要把上一小时的预测值补回历史序列尾部再算下一个。所以 predictNext 每次只推一步外层循环控制步数。这个设计要提前想好否则遇到连续预测需求就要重新设计接口。ForecastEngine 设计成接口当前实现是 RidgeForecastEngine后续想换模型不影响调用方。模型参数加载可以放到配置中心也可以用资源文件。我倾向于把 JSON 放在 classpath 下启动时读取不存在远程依赖。如果参数文件缺失或特征维度对不上启动时直接抛异常不要等到调用预测接口时报错这样更早暴露问题。5. 联调避坑指南5 个让答辩现场翻车的细节微服务联调阶段的坑比想象中多而且很多坑在自己的机器上根本不会暴露一到现场演示就出问题。下面五条都是血泪经验每条按现象、原因、解决来拆。5.1 网关 503、Feign 时间错乱、CSV 乱码联调期高频三连网关转发报 503 Service Unavailable直接请求后端的分析服务 8080 端口却能通。这个现象很典型原因大概率是 Spring Cloud 2021 版本移除了 RibbonOpenFeign 发起调用时没有负载均衡实现拿不到可用的实例列表。解决方法是引入spring-cloud-starter-loadbalancer依赖在网关和分析服务的调用方都加上。检查时先看 Nacos 服务列表里服务是否在线再看调用方有没有 loadbalancer 依赖两步能定位大多数问题。Feign 调用返回的时间字段错乱前端拿到的时间变成了数组或者少了 8 小时。原因是两个服务配置了不同的 Jackson 序列化规则一个把 LocalDateTime 序列化成 ISO 字符串一个序列化成时间戳数组。解决方法是统一注册 Jackson 定制器日期格式固定为yyyy-MM-dd HH:mm:ss时区统一 GMT8所有服务共用同一份配置类。CSV 导入时第一列列名乱码中文列名变成类似锘库record_time的开头。原因是 Excel 导出的 CSV 带 UTF-8 BOMInputStreamReader 按 UTF-8 读取时本身能显示正常但 Java 字符串里开头多了一个\uFEFF字符。解决方式是读取第一行后判断是否以\uFEFF开头是就去掉。这个字符肉眼看不见但 map 里按列名取值时永远匹配不上非常隐蔽。5.2 预测虚高、模型文件损坏、接口超时数据链路隐蔽雷区预测模块的验证集误差很好但上线后预测值明显偏离真实值。原因通常是数据泄漏训练时用了随机切分而不是时序切分随机切分会让模型偷看到未来信息验证集是开卷考试真实预测就露馅。解决方式是回到训练脚本按时间顺序前 80% 训练、后 20% 验证重新评估 MAE。这个坑不只在毕设里常见很多论文的实验数据也是这样虚高的答辩时会被直接问穿。项目打包或克隆到别的机器后预测接口报模型参数文件不存在。原因是模型参数文件用相对路径加载路径依赖运行目录。解决方式是把 JSON 放到 resources 目录下用ClassPathResource读取不要用File路径。另外如果模型文件是 pickle 格式提交到 git 后可能因为换行符或版本问题损坏这也是前面坚持用 JSON 的原因。预测接口偶发超时前端等十几秒才有响应。常见原因是推理逻辑里做了同步 HTTP 调用远程 Python 服务模型加载又慢叠加起来就超时。解决方式分三层模型参数启动时预热加载不放在首次调用时初始化相同请求用 Caffeine 缓存短期结果外部调用超时时间从 3 秒调到 10 秒并加熔断降级。毕设里做到前两层基本就够演示了。6. 答辩前验收用一条手算数据钉死整条链路最后的验收阶段不要只开着系统点页面。准备一条手算数据把整条链路从导入到预测全量核对一遍这个方法比自动化测试更能在答辩现场讲出说服力。手算样本的做法是挑一个站点某一天的数据手动用 Excel 算出该小时 6 种污染物的 IAQI取最大值得出 AQI记下结果。然后调导入接口把这份 CSV 导入平台查页面上同一时刻的 AQI两个值必须一致。预测部分同理取某个时刻前 24 小时的序列手动代入回归公式算一个预测值和平台接口返回结果对比误差应该在 0.01 以内。这里公式系数是定点数不用浮点数计算误差只在小数位。每个服务启动后先做健康检查一条命令串起来for svc in gateway-service auth-service collector-service analyze-service forecast-service; do echo $svc curl -s http://localhost:9000/$svc/actuator/health echo done如果某个服务返回 DOWN不要直接重启先看 Nacos 控制台里服务是否注册成功再看日志里数据库连接是否正常。这套检查流程可以在答辩前半小时完整跑一遍比临时翻日志靠谱得多。进阶用法上ForecastEngine 接口留了一个扩展位。如果后续想换 LSTM只需要新增一个实现类用 Spring 的Qualifier做切换调用方完全不用改。这个设计本身就是一个可讲的答辩亮点比模型本身更能体现工程思维。另外一个习惯是我做这类系统养成的模型参数文件导出后立刻在代码里写一个加载校验测试专门检查特征维度和系数个数是否匹配。环境污染物预测本身有大量不确定性模型参数过拟合很正常关键是给自己留一条快速验证的路。手算数据、健康检查脚本、接口抽象这三样东西就是这条路的护栏。希望帮到你毕设顺利。本文还有配套的精品资源点击获取