企业官网建设流程全解析

这里name必须是 Nacos 里注册的服务名，大小写要完全一致；fallback指定降级类，对方服务不可用时返回兜底数据，避免网关直接报 500；configuration指定自定义超时配置，因为预测服务要做模型推理，默认超时往往不够。

@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 Result<Void> report(@RequestBody List<PollutantReportDTO> 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(method="linear", limit=4)

resample("h")会把 10:23 这类时间归到 10:00 一档，同档内取均值，这就完成了时间对齐。interpolate(method="linear", limit=4)只在连续缺失不超过 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。d=1 表示对原序列做一阶差分来消除趋势，这是处理污染物浓度这种带季节波动数据最常见的选择。实际项目里我的做法是先跑一遍，看 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_back=24): 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_back=24) 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(optimizer="adam", loss="mse") model.fit(x_train, y_train, epochs=50, batch_size=32, validation_split=0.2)

代码里activation我没有显式写，这是有意的——LSTM 的默认激活是 tanh，比 relu 更适合循环结构。有些教程用 relu，训练时梯度很容易异常，导致预测结果退化成一条直线。look_back=24用过去 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 更符合微服务风格，但调试时多一跳；直接用配置指定地址更省事，毕设推荐后者，问题定位更快。下表是两条预测路线的选型对比，可以直接抄进项目说明：

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:8848，Docker 内部网络会解析。演示现场一句话“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(f"MAE={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 就自动变小，它只跟数据质量和工程细节有关。希望这篇能帮你把链路打通，希望帮到你。

本文还有配套的精品资源，点击获取