ARTICLE · 1303191
深度解读|MyEMS架构设计文档:一套面向双碳场景的开源能源管理系统
“取数、算数、看数、出报表”，这八个字基本概括了 MyEMS 开源能源管理系统的核心定位。近期 MyEMS 发布社区版 v6.10.0，并同步更新完整架构设计文档，把这套已在上千个项目中落地、兼容 ISO50001（GB/T23331-2020）的开源能源管理系统底层逻辑完整公开出来。
与市面上侧重画面组态的软件不同，MyEMS 更强调计量关系建模，能够同时支持建筑、工厂、园区、医院、商场等不同类型项目，并围绕能耗、成本、碳排放三条主线开展核算。本文从架构视角出发，分析这套 MIT 协议开源的能源管理平台。
系统定位：不是组态软件，是能碳数据核算平台
很多人会把能源管理系统理解为组态画面工具，但 MyEMS 走的是另一条路线：
遵循国标 GB/T 23331-2020 能源管理体系要求，重点面向能碳数据全生命周期管理； 支持电、水、气、冷、热、蒸汽等多类能源，也支持人工离线录入和虚拟计算表； 在同一套原始数据基础上，支持空间、设备、租户、门店、车间、组合设备等多维度统计分析； 采用 MIT 开源协议，可用于商业项目；社区版需保留官方版权 LOGO，不得直接贴牌修改品牌标识。
系统边界主要包括取数、算数、看数和出报表，不做 SCADA 组态画面，不做贸易级计量检定，也不内置消息中间件。组件之间不依赖消息总线，而是以数据库表作为协作介质，这种设计有利于离线部署和降低运维成本，但也存在相应的技术取舍。
五层分层架构：采集 - 存储 - 计算 - 服务 - 展示
MyEMS 在逻辑上划分为五层，每层对应独立进程或容器，可以分别启停和扩展。单个采集协议出现故障，通常不会影响整个系统运行。
采集层：多协议接入现场设备
采集层包含 4 套独立采集服务，分别对应 Modbus-TCP、BACnet/IP、S7 和 OPC UA，同时支持通过 Excel 离线导入人工抄表数据。
每个协议作为独立进程运行，只负责协议解析，不处理业务逻辑；采集周期、设备地址等参数都保存在数据库配置中。需要注意的是，修改采集配置后，需要重启对应采集服务才能生效，系统不支持配置热更新。
存储层：13 个数据库分工存储数据
MyEMS 在存储设计上比较有特点，采用算存分离方式，按业务用途拆分为 13 套 MySQL 系数据库。数据库之间不使用外键，关联逻辑主要放在应用代码层处理。
表格
数据处理分为多个层级：L0 原始测点、L1 标准化能耗值、L2 多维聚合值、L3 成本和碳排放派生核算。当口径出现问题时，可以只重算对应层级，不必重新采集全部原始数据，从而降低修正成本。
计算层：流水线式数据加工
数据处理采用串行流水线方式，主要通过三类定时批处理任务完成：
- 规范化
：将原始瞬时读数转换为小时维度能耗； - 清洗
：识别越限、缺数、表计倒走等异常情况，通过 is_bad标记坏数据，但不直接删除原始记录； - 汇总
：按 7 类业务对象和 4 种时间粒度进行预聚合，同时完成成本和碳排放换算。
这一层的核心设计思路是预物化聚合结果，用存储空间换取报表查询性能。前端报表请求不直接做实时大表关联查询，而是读取已经计算完成的聚合表，以保证大数据量下的页面响应速度。
服务层 myems-api：系统唯一对外出口
服务层基于 Python-Falcon 框架实现全部 RESTful 接口，权限校验、报表查询、Excel 导出和第三方集成都通过这一层完成。
服务层采用无状态设计，多实例部署时只需共享数据库即可。Excel 导出由服务端直接生成带图表的完整 xlsx 文件，而不是简单的 csv 文件。系统支持两种鉴权方式：浏览器登录使用 Token，程序对接使用 API-Key 密钥。
展示层两套前端
MyEMS 包含两套前端界面：
- MyEMS-Web
：面向能源分析人员，用于查看图表、趋势和报表； - MyEMS-Admin
：面向运维管理人员，用于配置台账和采集参数。
两套前端采用不同技术栈，主要由历史演进形成，长期维护会带来一定压力。
完整数据流：从仪表到报表全链路
数据链路为：现场仪表 → 采集服务写入原始时序库 → 规范化计算小时能耗 → 清洗标记坏数据 → 多维汇总生成能耗、成本、碳排放聚合表 → API 读取聚合数据，前端展示并导出报表。
需要说明的是，采集按分钟级轮询，计算任务按小时级批处理，因此报表数据通常会存在约一小时的滞后。这是架构设计带来的结果，不属于系统缺陷。
系统支持按时间段重算：
修改电价或碳排放因子时，只需重算 L3 派生层； 修改计量表和点位绑定关系时，从 L1 标准化层重新计算； 只有在采集缺失时，才需要回到 L0 原始数据补数。
通过is_published标记，重算过程可以隐藏未完成数据，避免报表展示错误中间结果。
关键技术权衡：没有完美架构，只有适合业务的取舍
这份架构文档的价值，不仅在于说明系统如何运行，也在于明确披露了设计取舍。项目选型时，需要理解这些权衡背后的适用条件。
不使用消息中间件，以数据库表作为组件通信总线
这种设计的优势是部署简单，单机可通过 docker-compose 快速运行，适合离线私有化环境。代价是组件之间的契约体现在表结构中，表结构变更会影响多个模块，并且系统本身不具备事件重放能力。
预生成大量聚合表
预聚合可以显著提升报表查询速度，即使原始测点数据达到千万级，页面也不容易卡顿。但代价是新增业务对象时，通常需要新增整套聚合表，二次开发成本较高。
兼容 MySQL 生态及部分国产数据库
系统能够适配 MySQL 生态，也支持 GoldenDB、OceanBase 等国产数据库，适合国内信创私有化项目。但为了兼容不同数据库，只能使用通用 SQL 子集，无法深度依赖特定数据库的高级功能。
轮询采集与小时批处理计算
这种方式适合存量老旧仪表和 PLC 环境，不需要对现场设备进行大规模改造。但系统不支持秒级实时闭环控制，如果项目有高实时控制需求，建议搭配独立实时系统。
部署模式：从单机到扩展
单机 docker-compose 部署
单机部署适合快速验证和中小型项目，所有组件运行在同一台主机上。Web 访问默认通过 80 端口，管理员配置页面通过 8001 端口，数据库应保持内网隔离，不对外网开放。
扩展部署策略
采集服务可以按网段拆分任务，部署多个实例； API 服务可以通过多实例和 Nginx 负载均衡扩展； 数据库没有内置读写分离能力，需要在项目侧通过主从副本分担查询压力。
原生单机部署中的数据库存在单点风险，高可用场景需要额外部署数据库主从集群。
二次开发指南：哪些扩展简单，哪些成本较高
成本较低的扩展
- 新增能源类型
直接在能源分类表中增加记录，并配置单位、标煤和碳排放因子即可，不需要新建聚合表。 - 新增采集协议
可以参考现有采集服务模板，按照统一的读写库契约进行开发。
成本较高的扩展
- 新增业务对象
例如新增一类管理单元，通常需要新建实体表、关联表和全套聚合表，并修改汇总计算逻辑，同时适配两套前端界面。这类改动工作量较大，建议优先通过现有空间或关联表进行分组，避免新增对象。
项目实施风险提示
原始时序库会持续增长，系统没有自带自动归档能力，项目实施时需要自行制定归档策略，并根据审计重算需求确定原始数据保存周期，一般为 1 到 3 年。 多租户逻辑采用单实例逻辑隔离，而非数据库物理隔离。大型集团或多项目场景建议分实例部署。 系统不自带接口限流，需要在 Nginx 反向代理层配置限流保护。 初始账号为 administrator，上线后必须修改默认密码。数据库账号应遵循最小权限原则。 碳排放和标煤折算因子在系统中可能只是示例值，项目实施时必须替换为当地官方统计口径，否则报表结果会出现系统性偏差。
写在最后
MyEMS架构设计文档的公开，为能源数字化从业者提供了一份有价值的参考。开源能源管理系统不等于简单的演示平台，它已经考虑了国标合规、坏数据处理、重算回溯、国产数据库适配、离线私有化部署等工程问题。
但开源也不意味着可以直接开箱解决所有业务问题。理解架构背后的取舍，才能判断它是否适合具体项目场景。
你有没有使用开源能源管理平台的经历？欢迎在评论区交流。
如果文章对你有帮助，欢迎点赞、在看，并转发给更多能源数字化从业者。
