Mini MES · 架构演进
| 字段 | 内容 |
|---|---|
| 状态 | 🔵 设计中 |
| 类型 | [决策] |
| 项目 | Mini MES |
原则
不画一张「终态全家桶」当目标。只记录：当前跑到哪一版、下一版解决什么问题、为什么不跳级。
V0（当前目标）
text
Simulator / Modbus
↓
Gateway
↓
HTTP
↓
Spring Boot
↓
MySQL + Redis
↓
Vue 监控页要解决：业务与协议解耦；一条链可演示「采 → 存 → 看」。
已知代价：单消费者、无发布订阅；多网关 / 多下游时会吃力。
→ 决策：V0 为何 Gateway → HTTP
V1（计划）
text
Gateway → MQTT → EMQX → Spring Boot → …要解决：多设备 / 多消费者、弱网与解耦。
触发条件：Lab 001 跑通后，且出现「第二个订阅方」或明确的可靠性实验需求。
→ 决策：为何暂不用 MQTT
V2（更远）
text
IoT 服务（实时 / 测点）
↕
MES 服务（工单 / 质量，仍可先单体模块）
↕
按需 TSDB要解决：测点洪流与业务事务分离；历史查询压力。
触发条件：日写入量、查询延迟有实测数字，再评估 TDengine 等。
为什么不直接上 V2
跳级会同时引入协议、消息中间件、存储与领域模型，失败时说不清是哪一层的问题。实验室价值在于每升一级有对照实验（如 HTTP vs MQTT）。