第二章：总体架构设计——分层架构与技术选型
好，咱们直接进入正题。一个智能监控系统能不能跑得稳、扛得住、好扩展，架构设计占了七成功力。我这些年见过太多项目，前期图省事搞了个大泥球架构，后期改一个功能要动全身，那叫一个痛苦。
所以这一章，我带你从顶层往下捋一遍。说白了，就是先画好蓝图，再挑趁手的工具。
2.1 分层架构：四层模型
我习惯把AALC系统分成四层：感知层、网络层、平台层、应用层。每一层各司其职，层与层之间通过标准接口通信。这样做的好处是——哪一层出了问题，就换哪一层，不影响其他。
核心原则：上层依赖下层，下层不依赖上层。数据从下往上流，指令从上往下传。
2.1.1 感知层
这是系统的「五官」。负责采集现场数据，比如温度、振动、电流、压力等。我在项目中遇到过一个问题：传感器选型时只看了精度，没看防护等级，结果在粉尘车间用了三个月就全挂了。嗯，这里要注意——工业现场的环境远比实验室恶劣。
- 设备类型：PLC、RTU、智能传感器、边缘网关
- 通信协议：Modbus RTU/TCP、OPC UA、MQTT、Profinet
- 数据粒度：毫秒级采样，秒级上传
2.1.2 网络层
这一层负责把感知层的数据安全、可靠地送到平台层。你想想看，工厂里几百台设备同时发数据，网络一堵，数据就丢了。我曾经在一个钢铁厂项目里，就因为网络抖动导致报警延迟了30秒，差点出事故。
- 有线方案：工业以太网、光纤环网
- 无线方案：4G/5G、LoRa、Wi-Fi 6
- 安全措施：VPN隧道、TLS加密、设备证书认证
2.1.3 平台层
这是系统的「大脑」。所有数据在这里汇聚、存储、计算、分析。我个人的习惯是，平台层一定要做「数据缓冲」，不能直接让数据库扛写入压力。否则并发一上来，数据库就挂了。
- 核心组件：消息队列、时序数据库、流计算引擎、规则引擎
- 关键能力：高可用、水平扩展、数据持久化
2.1.4 应用层
这是用户直接打交道的部分。包括监控大屏、报警推送、报表分析、设备管理等。我建议应用层尽量「薄」，只做展示和交互，复杂的业务逻辑下沉到平台层。
- 前端形态：Web端、移动端、工业HMI
- 核心功能：实时看板、历史趋势、报警管理、设备拓扑
2.2 技术选型：我踩过的坑和推荐
技术选型这事儿，没有银弹。但我可以给你一些经过实战检验的组合。说白了，选技术就是选「生态」和「团队熟悉度」。再好的技术，没人会用也是白搭。
2.2.1 数据库选型
工业数据有两个特点：写入量大、时间属性强。关系型数据库在这场景下很吃力。我推荐混合存储策略。
| 数据类型 | 推荐方案 | 原因 |
|---|---|---|
| 时序数据（温度、振动等） | InfluxDB / TimescaleDB | 高写入吞吐、自动降采样、保留策略 |
| 设备元数据（型号、位置等） | PostgreSQL | 强一致性、支持JSON、成熟稳定 |
| 报警记录 | Elasticsearch | 全文检索、聚合分析、可视化 |
| 缓存 | Redis | 毫秒级响应、支持发布订阅 |
避坑指南：我曾经在一个项目中把所有数据都塞进MySQL，结果单表到了2亿行后，查询一条历史数据要30秒。后来拆成时序库+关系库，查询时间降到了200毫秒。记住——不要用一把钥匙开所有的锁。
2.2.2 消息队列选型
消息队列是平台层的「血管」。它负责削峰填谷、解耦生产者和消费者。我个人的习惯是，优先选Kafka，除非你的场景特别轻量。
- Kafka：适合高吞吐、持久化、多消费者场景。我一般在数据采集和流计算之间用Kafka。
- EMQX：原生支持MQTT协议，适合设备直接上报。边缘网关到平台这一跳，用EMQX很顺手。
- RabbitMQ：适合低延迟、复杂路由。报警消息的即时推送，我用它。
注意：不要用消息队列做数据库！消息队列的数据有生命周期，过期会删除。如果你需要长期保存，一定要把数据写到时序库里。
2.2.3 前端框架选型
工业监控的前端，核心要求是「实时性」和「稳定性」。花里胡哨的动画少来，数据不丢才是王道。
- Vue 3 + Element Plus：上手快，生态好，适合中后台系统。我团队的主力框架。
- React + Ant Design：组件丰富，适合复杂交互。如果你团队React熟练，选它没问题。
- ECharts / Highcharts：图表库，必选。实时曲线、仪表盘、拓扑图都靠它。
- WebSocket：实时数据推送的标准方案。别用轮询，那是十年前的做法。
2.3 模块划分与交互流程
系统拆模块，我遵循一个原则：高内聚、低耦合。每个模块只做一件事，并且做好。
2.3.1 核心模块清单
- 设备接入模块：负责解析不同协议（Modbus、OPC UA、MQTT），统一成内部标准格式。
- 数据存储模块：负责将数据写入时序库和关系库，处理数据压缩和降采样。
- 实时计算模块：负责流式处理，比如阈值判断、趋势预测、异常检测。
- 报警管理模块：负责报警规则配置、报警触发、报警升级、报警通知。
- 可视化模块：负责大屏、看板、报表的渲染和数据绑定。
- 设备管理模块：负责设备注册、配置下发、固件升级、状态监控。
2.3.2 交互流程示例
我拿一个典型的「温度超限报警」场景，给你走一遍流程：
1. 传感器采集温度值 → 通过Modbus TCP上报给边缘网关
2. 边缘网关将数据封装为JSON → 通过MQTT发布到EMQX
3. EMQX将消息转发给Kafka（数据持久化）
4. 实时计算模块从Kafka消费数据 → 与规则引擎中的阈值（80℃）对比
5. 发现超限 → 生成报警事件 → 写入Elasticsearch
6. 报警管理模块从ES读取报警 → 通过WebSocket推送到前端大屏
7. 同时触发短信/邮件通知 → 值班人员手机收到报警
8. 操作员在大屏上确认报警 → 系统记录确认时间与操作人关键点：整个流程从传感器采集到前端显示，延迟控制在1秒以内。如果超过3秒，就要排查网络或消息队列的瓶颈了。
2.4 架构设计的几个忠告
最后，我掏心窝子说几句。这些是我用真金白银换来的教训：
- 别过度设计：一开始就上微服务、容器编排，团队可能连运维都搞不定。先单体，再拆分。
- 预留扩展点：接口设计时留好版本号，字段加个扩展字段。我见过太多因为接口不兼容导致的全量升级。
- 重视可观测性：日志、指标、链路追踪，这三样在架构设计阶段就要考虑。别等出问题了再补。
- 数据备份要自动化：别问我为什么强调这个——我曾经手抖删过一张生产表，还好有自动备份，不然就凉了。
好了，架构设计的框架就聊到这儿。下一章我们深入感知层，聊聊设备接入的那些坑和实战技巧。
公众号:蓝海资料掘金营，微信deep3321