3. 整体架构设计：分层架构
好，咱们进入正题。设备监控系统，说白了就是一套「看住设备」的体系。你想想看，工厂里几百上千台设备，每台都在跑数据——温度、转速、振动、电流……这些数据怎么收？收了怎么传？传了怎么用？
我个人习惯，第一件事就是画分层图。把系统拆成五层：采集层、传输层、处理层、存储层、展示层。每一层各管各的事，互不干扰。这就像盖楼——地基、框架、水电、装修，各工种同时干，最后拼起来就行。
核心原则：分层不是目的，解耦才是。每一层只关心自己的输入和输出，不关心隔壁怎么实现的。
3.1 五层架构总览
先看一张整体图，我手绘的 SVG，帮你建立全局感。
这张图我画了好几个版本，最后选了这种「瀑布式」布局。为什么？因为数据从下往上流，逻辑清晰，新人一看就懂。你在做架构设计时，也建议先画这种图——画出来，思路就顺了。
3.2 各层职责与交互
3.2.1 采集层
这是最「接地气」的一层。传感器、PLC、边缘网关，都在这层干活。它们负责把物理世界的信号，变成数字世界的结构化数据。
我在项目中遇到过一个问题：某工厂的振动传感器，采集频率是 10kHz，但网关只支持 1kHz 的采样。结果高频振动全丢了，设备坏了都没发现。后来我们加了一层「自适应采样」——网关根据信号变化率动态调整频率。
避坑指南：采集层最容易踩的坑是「协议地狱」。Modbus、OPC UA、Profibus、CAN……每个设备都有自己的方言。我曾经在一个项目里对接了 17 种协议，最后写了个统一的协议适配器，才把问题解决。
采集层的核心输出：原始数据 + 时间戳 + 设备ID。就这三样，别整花里胡哨的。
3.2.2 传输层
数据从采集层出来，怎么送到后端？这就是传输层的活。说白了，就是「管道」。
我建议用 MQTT 做设备端到服务器的传输。为什么？因为 MQTT 是发布/订阅模式，设备只管发，服务器只管收，两者解耦。而且 MQTT 支持 QoS 级别，可以保证数据不丢。
但要注意：MQTT 不适合大数据量的批量传输。如果你要传视频流或高频波形，建议用 gRPC 或 WebSocket。
| 协议 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| MQTT | 低频传感器数据 | 轻量、支持 QoS | 不适合大包 |
| Kafka | 高吞吐日志/事件 | 持久化、可回溯 | 延迟稍高 |
| gRPC | 实时控制指令 | 双向流、低延迟 | 客户端较重 |
3.2.3 处理层
数据到了服务器，不能直接存——得先「洗一洗」。处理层干的就是这个活。
处理层要做三件事：
- 数据清洗：去重、补全、过滤异常值。比如温度传感器突然跳了 200 度，明显是故障，要剔除。
- 规则判定：温度超过 85 度就告警？转速低于阈值就停机？这些逻辑都在处理层。
- 流计算：实时统计、滑动窗口聚合。比如过去 5 分钟的平均温度。
嗯，这里要注意：处理层最容易犯的错误是「逻辑耦合」。我曾经见过一个项目，告警规则直接写在采集脚本里——每次改规则都要重启设备，太痛苦了。后来我们抽了一个独立的规则引擎，用配置文件驱动，才算解脱。
3.2.4 存储层
处理完的数据，得找个地方存起来。存储层的设计，直接决定了系统的查询性能和扩展能力。
我个人的经验是：不要只用一种数据库。时序数据用 InfluxDB 或 TimescaleDB，元数据用 MySQL 或 PostgreSQL，缓存用 Redis，文件用对象存储。
关键点：存储层要支持「冷热分离」。最近 7 天的数据放热存储（SSD + 内存），历史数据放冷存储（HDD 或云存储）。这样既保证查询速度，又控制成本。
3.2.5 展示层
最后一层，是给用户看的。Web 仪表盘、移动端、大屏、告警通知……都归展示层管。
展示层的设计原则就一条：别让用户思考。数据要直观，图表要清晰，告警要醒目。我见过一些监控系统，满屏都是数字，用户根本不知道哪里出了问题。
我个人习惯用 Grafana 做仪表盘，配合自定义的告警通知。但如果你需要深度定制，还是得自己写前端。
3.3 架构设计原则
分层架构不是万能的，但遵循三个原则，能让你少走很多弯路。
3.3.1 解耦
每一层只通过接口通信，不直接依赖内部实现。比如采集层只管发数据，不管数据怎么存。传输层只管传数据，不管数据怎么处理。
解耦的好处是：改一层，不影响其他层。你想想看，如果采集层和存储层耦合在一起，换数据库就得改采集代码——太可怕了。
3.3.2 冗余
设备监控系统，最怕的就是「单点故障」。采集网关挂了怎么办？消息队列挂了怎么办？数据库挂了怎么办？
冗余不是浪费，是保险。我建议：
- 采集层：双网关热备
- 传输层：Kafka 集群 + 副本机制
- 处理层：多实例部署 + 负载均衡
- 存储层：主从复制 + 自动故障转移
注意：冗余不是越多越好。每增加一个副本，就多一份维护成本。我见过一个项目，Kafka 副本设了 5 个，结果磁盘空间直接爆了。一般 2~3 个副本就够了。
3.3.3 水平扩展
系统上线后，设备数量会增长。今天 100 台，明天 1000 台，后天 10000 台。架构必须支持水平扩展——加机器就能扛住。
水平扩展的关键在于：无状态。处理层的实例不能保存状态，所有状态都丢到存储层或缓存里。这样加实例时，新实例直接干活，不用迁移数据。
举个例子：告警判定服务，如果每个实例都维护一个「设备状态表」，那加实例时就得同步状态——麻烦。正确的做法是：状态存 Redis，实例只管读 Redis 做判定。
3.4 小结
这一章的内容，说白了就是一句话：分层、解耦、冗余、扩展。这八个字，是我做架构设计时的「心法口诀」。你把这个框架搭好了，后面的细节填充就水到渠成了。
对了，最后提一句：架构设计没有标准答案。我给你的这套分层，适合大多数设备监控场景。但如果你遇到特殊场景——比如超低功耗设备、卫星通信链路——该调整就调整。灵活一点，别死板。
公众号:蓝海资料掘金营，微信deep3321