4. EMS软件架构设计

储能EMS的软件架构决定了系统能否在毫秒级响应调度的同时，稳定接入数十万测点、支撑多站协同与长期数据回溯。本节围绕四个相互关联的设计决策展开：分层分布式如何切分职责、微服务与单体如何取舍、实时库与时序库如何分工、容器化如何落地部署。

一、分层分布式架构：把"快"和"稳"分开

储能EMS的典型分层为四层：设备层（PCS、BMS、空调、消防、电表）、边缘控制层（站控EMS/边缘网关）、平台服务层（实时监控、策略调度、告警、历史服务）、应用层（Web组态、报表、运维App、第三方接口）。分层的核心不是"画得好看"，而是把不同时间尺度的任务隔离：设备层与边缘层承担100ms以内的闭环控制，平台层承担秒级策略计算，应用层承担人机交互与分钟级分析。

分布式则体现在两个维度：一是站内分布式，PCS、BMS等设备通过Modbus TCP、IEC 61850 MMS或CAN接入边缘网关，网关做协议归一化后上送；二是多站分布式，各站边缘节点通过MQTT或IEC 104向区域平台汇聚，平台侧按站ID做数据分区。这样单站断网时本地仍可执行削峰填谷、需量控制等策略，平台恢复后补传历史数据。

二、微服务与单体架构对比：按规模选型

单体架构把实时监控、策略、告警、历史等功能打包为一个进程，优点是部署简单、进程内调用无网络开销、调试直观，适合单站或站点数少于5个、测点规模在1万以内的场景。其代价是：任一模块内存泄漏或线程阻塞会拖垮整个进程；策略算法升级需整体重启，影响实时监控连续性。

微服务架构按业务边界拆分为独立进程，例如实时服务、策略服务、告警服务、历史服务各自独立部署，通过消息总线（如Kafka、NATS）或gRPC通信。优势是故障隔离、独立扩缩容、技术栈可异构；代价是引入分布式复杂度——服务发现、链路追踪、数据一致性都需额外设计。对储能EMS而言，一个务实的中间路线是"边缘单体 + 平台微服务"：站控层用单体保证实时性与可靠性，平台层用微服务支撑多站扩展与功能迭代。

三、实时库与时序库选型：各司其职

实时库与时序库不是二选一，而是分工。实时库保存当前值与最新状态，要求微秒到毫秒级读写，典型选型为Redis（Hash结构存测点当前值）、共享内存库或专用实时库（如eDNA、PI的实时缓存层）。时序库保存历史序列，要求高压缩比、高吞吐写入与时间范围查询，典型选型为InfluxDB、TDengine、TimescaleDB。

以一座100MW/200MWh储能站为例，假设测点约8000个，采样周期1s，则日增数据约8000×86400≈6.9亿点。若直接写入关系库，查询与存储都难以承受；而TDengine按"超级表+子表"建模，配合列式压缩，可将存储压缩至原始数据的5%~10%。实时库则只保留8000个测点的当前值与质量码，内存占用约几十MB，供策略服务在100ms内读取。

-- TDengine 建表示例（示意）
CREATE STABLE ems_measure (
  ts TIMESTAMP,
  value DOUBLE,
  quality TINYINT
) TAGS (
  station_id BINARY(32),
  device_id BINARY(64),
  point_id BINARY(64)
);

-- 写入一条PCS有功功率测点
INSERT INTO pcs_01_active_power USING ems_measure
TAGS ('STATION_A', 'PCS_01', 'ActivePower')
VALUES (NOW, 1250.5, 0);

选型判断依据可归纳为：写入吞吐是否超过10万点/秒、查询是否以时间范围聚合为主、是否需要保留原始精度、是否要求SQL兼容。若四项中三项为"是"，优先时序库；若只需当前值快照与订阅推送，实时库即可。

四、容器化部署实践：从镜像到编排

容器化的价值在于把"环境依赖"打包进镜像，使边缘节点与云端平台使用同一套交付物。典型实践是：每个微服务构建为独立Docker镜像，基础镜像选用Alpine或Distroless以减小体积；配置文件通过环境变量或ConfigMap注入；数据卷挂载时序库数据目录与日志目录。

在边缘侧，由于资源受限（常见4核8GB工控机），建议使用Docker Compose而非Kubernetes，减少控制面开销。在平台侧，使用Kubernetes编排，配合HPA按CPU或消息积压量自动扩缩容。一个关键细节是实时服务的网络模式：若采用host网络可降低NAT开销，但会牺牲端口隔离；若采用bridge网络，需确保gRPC长连接的心跳与重连策略合理。

综合来看，储能EMS软件架构的设计顺序应是：先按时间尺度分层，再按规模决定单体或微服务，然后为实时值与历史序列分别选库，最后用容器化统一交付。四者相互约束——例如选择微服务就必须接受网络开销，选择时序库就必须设计好标签模型。架构没有唯一正确答案，只有与站点规模、实时性要求和运维能力相匹配的合理取舍。