第二章：数据接入架构设计
好，咱们进入正题。数据接入架构，说白了就是解决一个问题——怎么把现场乱七八糟的设备数据，稳定、可靠地送到你的监控大屏上。
我做了这么多年能源项目，见过太多上来就写代码的团队。结果呢？采集层扛不住并发，传输层丢包，处理层数据对不上。最后全在加班修bug。所以这一章，咱们把架构先聊透。
2.1 分层架构：四层模型
我个人习惯把数据接入分成四层。你想想看，这就像盖楼——地基、管道、装修、入住，一层管一层的事。
核心四层：
- 采集层：负责跟硬件设备打交道。电表、PLC、逆变器、传感器……协议五花八门（Modbus、IEC 104、MQTT、OPC UA）。
- 传输层：把采集到的数据安全送到后端。说白了就是消息队列+网络通道。
- 处理层：数据清洗、规整、计算。比如把原始报文里的“0x1A2B”转成“电压220.5V”。
- 应用层：给上层业务用。监控大屏、告警、报表、历史查询。
我在项目中遇到过一种情况：某光伏电站，采集层直接往数据库写数据。结果设备一多，数据库连接池爆了。这就是典型的“层没分清楚”。
2.2 数据流设计：从设备到应用
数据怎么流？我画了一张图，你一看就明白。
数据流其实就一条线：设备 → 采集 → 传输 → 处理 → 应用。但这里有个坑——数据不能跳层。比如采集层直接去调应用层的接口，那架构就乱了。
我的经验：每层之间用标准接口隔开。采集层只管收数据，传输层只管送数据。这样哪一层出问题，替换起来都方便。我曾经把一个项目的采集层从Modbus换成MQTT，只改了采集层代码，上层完全没动。
2.3 高可用设计原则
能源系统最怕什么？数据断了。你想想看，一个工厂的用电数据突然没了，调度员直接懵了。所以高可用是命根子。
我总结了三条原则：
- 冗余部署：采集网关至少两台，一台挂了另一台顶上。传输层的消息队列做集群。
- 数据缓冲：网络断了怎么办？本地先存着。等网络恢复了再补传。这叫“断点续传”。
- 心跳检测：每层之间定期发心跳包。超过3次没收到，立刻告警。
⚠️ 注意：高可用不是堆硬件。我曾经见过一个项目，上了三台采集服务器，结果共享一个数据库。数据库一挂，全完蛋。真正的冗余是全链路冗余——从采集到存储，每一层都要有备份。
2.4 避坑指南
嗯，这里我要多说几句。都是真金白银换来的教训。
- 协议兼容性：不同厂家的Modbus实现不一样。有的地址从0开始，有的从1开始。我建议统一做一层协议适配。
- 数据时序：采集时间戳一定要用设备本地时间，别用服务器时间。否则网络延迟会导致数据乱序。
- 流量控制：1000个设备同时上报，消息队列扛得住吗？我建议做限流，比如每秒最多处理500条。
我曾经踩过的坑：某次项目，采集层用HTTP轮询，每5秒请求一次。结果设备数量从50台涨到500台，HTTP连接数直接打爆了网关。后来改成MQTT长连接，问题才解决。所以能不用HTTP就别用，能源场景首选MQTT或Modbus TCP。
2.5 架构选型建议
最后给个参考。不同规模的项目，架构可以灵活调整。
| 项目规模 | 采集层 | 传输层 | 处理层 | 应用层 |
|---|---|---|---|---|
| 小型（<50台设备） | 单网关 + Modbus | 直接TCP | 单机处理 | 简单Web |
| 中型（50-500台） | 双网关 + MQTT | Kafka单节点 | 流处理引擎 | 实时大屏 |
| 大型（>500台） | 网关集群 + 多协议 | Kafka集群 | 分布式流处理 | 微服务架构 |
说白了，架构没有银弹。我建议你从小做起，先跑通一条链路，再慢慢扩展。别一上来就搞分布式，容易把自己绕进去。
好，这一章就到这。记住一句话：架构设计，三分技术，七分经验。多踩坑，多总结，慢慢就有感觉了。
公众号:蓝海资料掘金营，微信deep3321