第二章：系统架构设计
好，咱们进入正题。系统架构这东西，说白了就是搭骨架。骨架搭歪了，后面填肉填得再好看也白搭。我这些年看过太多项目，上来就写代码，写到一半发现数据流不通，回头重构——那叫一个痛苦。
实时电力数据可视化系统，它的核心挑战是什么？我总结就三个字：快、准、稳。数据采集要快，处理要准，系统要稳。你想想看，电力数据可不是闹着玩的，一秒几十万条数据涌进来，系统崩了，那可不是重启一下那么简单。
2.1 整体架构分层
我习惯把系统切成四层，每层各司其职。就像盖楼，地基、框架、装修、软装，缺一不可。
四层架构总览：
- 数据采集层 —— 负责从各种电力设备、传感器、SCADA系统里把数据捞上来
- 数据处理层 —— 清洗、转换、聚合，把原始数据变成有价值的信息
- 数据存储层 —— 存得住、查得快，时序数据、关系数据各得其所
- 可视化展示层 —— 把数据变成图表、仪表盘，让人一眼看懂
2.1.1 数据采集层
这一层是系统的「眼睛」和「耳朵」。电力数据源五花八门：智能电表、PMU（相量测量单元）、RTU（远程终端单元）、甚至还有手工录入的抄表数据。
我在项目中遇到过最头疼的问题是什么？协议不统一。有的设备走Modbus，有的走IEC 61850，还有的用私有协议。你想想看，光解析协议就能写出一堆if-else，维护起来简直噩梦。
我的建议： 在采集层前面加一个协议适配器。每个协议写一个独立的插件，新增设备时只加插件，不动主流程。我曾经用这个方案帮客户省了至少60%的集成时间。
采集频率也是个坑。电力数据有些需要毫秒级采集（比如故障录波），有些分钟级就够了（比如日用电量）。别一刀切，否则要么浪费带宽，要么漏掉关键数据。
2.1.2 数据处理层
数据进了系统，不能直接扔给数据库。为什么？因为原始数据太「脏」了。传感器可能漂移，通信可能丢包，甚至还有恶意注入的假数据。
这一层我通常做三件事：
- 数据清洗 —— 去重、补缺、剔除异常值。比如电压突然飙到1000kV，明显是传感器坏了，直接扔掉。
- 数据转换 —— 把不同格式的数据统一成标准格式。比如时间戳全部转成UTC，单位统一成国际标准。
- 数据聚合 —— 秒级数据聚合成分钟级、小时级，减少存储压力。但注意，聚合后的数据要保留原始数据的统计特征（均值、峰值、方差等）。
注意： 数据处理层最容易犯的错误是「过度清洗」。我曾经有个同事，把一些看起来异常但实际是真实故障的数据给洗掉了，结果导致后续分析完全偏离。所以，清洗规则一定要留有余地，异常数据先标记，再决定是否丢弃。
2.1.3 数据存储层
存储层是系统的「记忆」。电力数据有两个特点：一是量大，二是时序性强。普通的关系数据库（比如MySQL）存几亿条时序数据，查询慢得你想哭。
我个人的经验是：
- 时序数据（比如电压、电流、功率的连续采样）→ 用InfluxDB或TimescaleDB。查询快，压缩率高，存储成本低。
- 关系数据（比如设备信息、用户信息、告警规则）→ 用PostgreSQL。稳定、功能强、支持复杂查询。
- 缓存数据（比如最近1小时的实时数据）→ 用Redis。读写快，适合仪表盘实时刷新。
嗯，这里要注意：别把所有数据都塞进一个数据库。我曾经见过一个项目，把所有数据都放MongoDB里，结果查询时序数据时慢得像蜗牛。分层存储，各取所长，才是正道。
2.1.4 可视化展示层
这一层是系统的「脸面」。数据再准，展示不好看，用户照样不买账。
可视化展示层我通常分两部分：
- 实时仪表盘 —— 展示当前电力状态，比如实时负荷、电压曲线、设备运行状态。刷新频率1-5秒。
- 历史分析面板 —— 展示趋势分析、报表统计、异常事件回溯。用户可以自由选择时间范围。
做可视化有个坑：别炫技。我见过有人用3D地球展示电力数据，看着酷，但用户根本找不到关键信息。电力行业的用户要的是「一目了然」，不是「眼花缭乱」。
2.2 技术选型对比
技术选型这事儿，没有银弹。每个项目都有自己的约束条件。我列个对比表，你根据实际情况选。
| 层级 | 技术方案 | 优点 | 缺点 | 我的推荐场景 |
|---|---|---|---|---|
| 数据采集 | EMQ X + MQTT | 高并发、低延迟、支持百万级设备接入 | 部署配置稍复杂 | 大规模分布式电力设备采集 |
| 数据采集 | Flume + Kafka | 成熟稳定、生态丰富 | 资源消耗较大 | 已有Hadoop生态的企业 |
| 数据处理 | Apache Flink | 真正的流处理、毫秒级延迟、Exactly-Once语义 | 学习曲线陡峭 | 需要精确计算的实时场景（如电费结算） |
| 数据处理 | Spark Streaming | 生态完善、与批处理统一 | 微批次模式延迟较高（秒级） | 对延迟要求不苛刻的分析场景 |
| 数据存储 | InfluxDB | 时序数据写入快、查询语法简洁 | 集群版收费 | 中小规模时序数据（单机版够用） |
| 数据存储 | TimescaleDB | 基于PostgreSQL、支持SQL、自动分区 | 写入性能略低于InfluxDB | 需要复杂SQL查询的时序场景 |
| 可视化 | Grafana | 开箱即用、插件丰富、支持告警 | 自定义图表能力有限 | 标准仪表盘、运维监控 |
| 可视化 | ECharts + Vue | 高度自定义、交互丰富 | 开发工作量大 | 需要定制化展示的电力分析系统 |
我的选型原则： 能不自己造的轮子就别造。Grafana能搞定的仪表盘，就别自己写ECharts。但如果是给客户做定制化产品，那ECharts的灵活性就值回票价了。说白了，看预算和需求。
2.3 架构设计避坑指南
最后，分享几个我踩过的坑：
- 别低估数据量。 我曾经给一个变电站做系统，预估每天100万条数据，结果上线后每天500万条。存储和带宽差点崩了。所以，设计时至少留3倍余量。
- 网络分区要考虑。 电力系统经常有内外网隔离。采集层可能在内网，展示层在外网。中间怎么传数据？用消息队列做缓冲，或者用单向网闸。别想着直连。
- 容错设计不能少。 数据采集断了怎么办？处理节点挂了怎么办？我习惯在每个环节加「死信队列」，处理失败的数据先存起来，等系统恢复后再重试。
好了，架构设计就聊到这儿。下一章咱们深入数据采集层，聊聊怎么搞定那些「不听话」的电力设备。