简介本资源是上海交通大学电气工程学院Lab518储能平台的后端系统完整源码实现面向高校电力/能源方向的Java后端开发者、课程设计学生及智能电网相关科研实践者聚焦于储能监控系统的数据接入、状态管理与日志归档等核心功能。压缩包共69个文件总大小271KB涵盖56个Java业务与实体类源码集中于src目录、2个XML配置文件含Maven构建核心pom.xml、2个Gzip压缩日志energy.log.2024-03-07.0.gz等体现真实运行时日志轮转机制、1个Maven Wrapper启动脚本mvnw、1个.gitignore及readme.txt等工程规范文件结构清晰反映典型Spring Boot/Maven项目组织方式。已有283人学习下载可直接导入IDE运行调试获取完整的储能平台后端架构实践案例包括日志分级处理逻辑、属性配置加载方式、GitMaven标准化协作流程以及面向电类场景的轻量级服务封装范式。1. 项目不是“系统开发”而是“平台底座搭建”先说清楚这个项目到底在做什么。上海交大电院Lab518的储能平台本质上是一个面向实验室科研场景的能量管理与设备监控系统。它不是我理解中常见的业务管理系统——不是管订单、管用户、管审批那一套而是需要持续对接电池簇、PCS变流器、BMS电池管理系统、温控机组等硬件设备完成遥测数据采集、状态监控、控制指令下发、告警管理、历史数据沉淀等一系列任务。标题里“后端设计源码”这几个字很容易让人误以为是个普通的管理后台项目。实际接触下来你会发现这类项目的技术难点根本不在CRUD而在三个方面一是数据接入层的通信协议适配储能设备基本走Modbus TCP、IEC 61850或者厂家私有协议每种协议的数据模型都不一样二是时序数据的存储与查询设计一套实验室储能系统动辄几十个采集点秒级采集一天就是几百万条记录三是控制指令的可靠性和安全性远程下发充放电指令不能有半点含糊链路要可追踪、状态要可回读。我做的这套后端拿Java生态做底座Spring Boot做应用框架存储上MySQL负责业务管理数据、TDengine负责时序数据通信层用Netty做设备接入网关。整套架构跑下来核心目标就一句话让实验室的储能系统像工业级的能量管理平台一样稳定、可观测、可溯源。适合参考这套设计的同学应该是接下来要做能源物联网、工业数据采集、设备监控类项目的Java后端工程师。如果你接手的项目也需要高频写入设备数据、需要把设备通信和业务系统打通那这篇文章提到的很多设计决策和踩坑经历都可以直接借鉴。2. 储能平台后端到底要解决什么问题动手写代码之前最关键的一件事是先把问题定义清楚。储能平台的业务边界和普通管理系统完全不同我把Lab518平台实际要面对的问题拆成了四层。层级核心问题对应后端功能设备接入层多种储能设备、多种通信协议、数据格式不一致Netty网关、协议解析、指令下发通道数据存储层高频遥测数据写入量大、历史查询要求快TDengine时序库、MySQL业务库、分层存储业务逻辑层充放电策略、告警规则、设备管理Spring Boot服务、规则引擎、任务调度展示交互层前端大屏、Web管理界面、移动端查看REST API、WebSocket推送、权限控制2.1 设备接入层是储能平台最容易翻车的地方很多做传统Java业务系统的人接手储能平台第一个不适应的地方就是设备通信。你面对的不是前端页面传过来的JSON数据而是字节流——Modbus协议里一个16位寄存器拆成两个字节高低位顺序颠倒就能让你解析出完全错误的数据。我在这套项目里用Netty搭建了一个独立的设备接入服务没有把它和业务服务混在一起。原因很直接设备通信是长连接、高并发、持续读写的场景Netty的NIO模型天然适合处理几百台设备同时保持TCP长连接的需求。业务服务则更偏向请求响应模式两者混在一起任何一个方向的压力抖动都会影响另一端。Netty这边的核心结构是这样的每个设备一个ChannelChannel上绑定协议解析Handler消息进来之后先经过拆包粘包处理再进入协议解析器。储能设备绝大多数都是Modbus TCP协议所以我在解析器里专门实现了Modbus的MBAP头和PDU体解析对线圈状态、寄存器值、异常响应做了完整的处理。解析出来的数据统一封装成一个内部的消息POJO通过消息队列丢给后端的业务服务处理Netty本身不做任何业务操作只负责连接管理和数据透传。提示Netty设备接入服务和业务服务之间一定要用消息队列解耦。直接Feign调用或者Redis发布订阅看起来简单但设备数据洪峰来的时候消费者速度跟不上消息积压会导致业务服务雪崩。2.2 数据存储层要划分“业务数据”和“时序数据”两条线储能系统里的数据可以简单分成两类。一类是设备档案、用户信息、策略配置、告警记录这类数据量不大、结构相对固定MySQL完全应付得过来。另一类是电池簇电压、电流、SOC、温度、功率这类遥测数据每个采集点固定时间间隔上报一次一天产生的数据量非常可观。MySQL支撑不了高频时序数据这一点实践下来是肯定的。早期图省事我把遥测数据也塞进MySQL一张表一天涨几百万行查询效率急剧下降一个聚合查询动不动几秒钟。后来换成了TDengine专门存时序数据情况完全不一样。TDengine的核心设计是“一个采集点一张表”加上超级表自动分区按时间维度做数据切片。我在项目里给每个电池簇建了一张超级表标签字段是设备ID和采集点类型列字段是时间戳和值。写入的时候直接用参数绑定接口批量写入单台设备的数据落库延迟在毫秒级别。业务数据和时序数据分开之后还有一个隐藏的好处备份和清理策略可以各自独立。MySQL做日常备份时序库按保留策略自动滚动清理不用人工介入。2.3 业务逻辑层是平台的大脑平台真正体现智能的地方在业务逻辑层。储能平台不仅仅是“看数据”还要根据数据产生动作。策略管理这块我实现了两种模式一种是本地策略就是设备本身自带的充放电策略后端只需要把配置参数下发到设备即可相当于远程改参数另一种是云端策略由平台根据电价时段、负载情况、电池SOC状态计算后生成充放电计划下发给PCS执行。告警规则是另一块重要内容。储能系统的告警和传统IT系统不一样很多告警不是单纯的阈值触发而是要基于变化趋势判断的。比如电池温度超过55摄氏度是立刻告警但温度在10分钟内上升了10摄氏度这个趋势也是紧急告警。我在告警引擎里实现了两类规则一类是静态阈值规则一类是变化率规则配合定时任务扫描基本覆盖了实验室场景下的主要风险场景。3. 整体架构设计与选型逻辑架构设计这块没什么玄学关键是把问题理清楚让每一层各司其职同时保证链路可追踪。我最终落地的架构分成了四层每层解决自己的问题层与层之间用规范的接口通信。设备终端 → Netty设备接入网关 → 消息队列 → 数据处理服务 → MySQL/TDengine → REST API/WebSocket → Web前端 ↓ 告警服务 → 通知/工单3.1 技术选型不是“谁火用谁”而是“谁合适用谁”Java生态里能选择的框架和中间件非常多选型的时候我遵循了几个原则社区活跃度、团队技术栈匹配度、运维复杂度。实验室项目不是互联网大厂没有专门的基础设施团队能用简单的方案就不用复杂的。Spring Boot作为应用框架没有悬念它解决了配置、依赖管理、自动装配这些繁琐的事让项目开发效率提升非常明显。MyBatis-Plus负责和MySQL交互主要是看重它的代码生成和条件构造器业务CRUD写起来非常省事。Netty负责设备接入这个前面已经说过。消息队列我选择了RocketMQ分组消费和延迟消息的特性在设备数据分发和告警通知里都用得上。有一个选型细节值得单独说一下为什么不用Spring Cloud全家桶因为实验室项目根本不需要微服务。微服务解决的是大团队并行开发、独立部署、弹性伸缩的问题储能平台的并发量远没到那个程度强行拆成微服务只会增加运维成本。我把服务拆成了网关接入、数据入库、告警处理、业务管理几个模块还是单一应用部署模块之间通过依赖注入和消息解耦灵活性和简单性都保住了。3.2 项目分层结构怎么组织才不乱代码结构我采用的是经典的分层架构但边界和命名都做了适配储能业务场景的调整com.lab518.storage ├── common // 通用工具类、统一返回体、异常处理 ├── gateway // Netty设备接入网关、协议解析 ├── collector // 数据采集与入库、消息消费 ├── domain // 设备信息、BMS数据、PCS数据、告警规则等核心模型 ├── service // 业务逻辑策略管理、告警引擎、报表服务 ├── controller // REST API层 └── task // 定时任务数据对账、趋势告警扫描、设备状态探测这里有一个对Java后端新人非常重要的经验不要为了“分层”而分层而是要让每一层真的在解决对应的问题。我以前见过很多项目controller里面直接new serviceservice里面直接写SQL表面上分了包实际上耦合成一坨。这套项目里我严格执行了“controller只做参数校验和结果封装、service层处理业务规则、然后通过mapper或仓库访问数据”的规则保证任何一层替换或者升级的时候不会牵连其他层。实际上对于设备接入服务的Channel管理我用了一个ChannelGroup来维护所有在线设备的连接同时用设备编号作为key建了一张Channel映射表指令下发的时候可以迅速找到对应设备的连接通道。这个映射表放在本地内存里因为单机部署模式下设备连接不涉及跨节点转发问题如果未来需要水平扩展再把映射关系放到Redis里就好。3.3 统一配置与多环境管理实验室项目有一个经常被忽略的问题环境多。开发环境、测试环境、实验室现场环境配置都不一样。设备IP、端口、数据库地址、NTP时间源这些配置如果散落在代码里每次部署都要改一堆地方容易出错。我在项目里用了Spring Profile机制管理多环境配置每个环境对应一个application-{profile}.yml文件公共配置放在application.yml里。设备地址和点位映射表这种现场强相关的配置放在Nacos配置中心统一管理改动配置不需要重启服务通过监听机制自动刷新到运行中的服务实例。4. 数据采集链路从设备字节流到前端图表的完整过程数据采集是这个项目最核心的链路很多后台开发不熟悉嵌入式设备的交互方式这里我把整条链路从底到上完整拆解一遍这部分也是我做这个项目时调试时间最长的地方。4.1 Netty网关如何实现Modbus TCP协议解析Modbus TCP协议的报文结构不算复杂但它有一套自己的规矩。报文由MBAP头7字节和PDU体功能码数据组成。MBAP头包括事务标识符、协议标识符、长度、单元标识符。PDU体就是具体要读取或写入的数据。解析的难点在于理解不同功能码的含义。读取保持寄存器是0x03读取输入寄存器是0x04写单个寄存器是0x06写多个寄存器是0x10。储能设备里BMS的数据绝大部分是保持寄存器PCS的一些参数如工作模式、功率设定值也是保持寄存器。我的解析器里针对常用功能码写了对应的解码器和编码器解码器负责把字节流变成我们内部定义的协议对象编码器负责把指令对象变成字节流发出去。拆包粘包是Netty开发中必踩的坑。Modbus TCP协议有个特点是报文长度字段明确因此可以用基于长度字段的拆包器。我使用了LengthFieldBasedFrameDecoder参数设置成maxFrameLength1024, lengthFieldOffset4, lengthFieldLength2。这个4和2怎么确定的MBAP头里长度字段在字节4和字节5占2个字节所以长度字段偏移量是4、长度是2。设置对了之后粘包问题从根上解决了。4.2 数据解析之后为什么先走消息队列设备数据经过协议解析之后变成一条条标准化消息。这个时候的处理策略决定了系统的稳定上限。如果直接在Netty的Handler里写入库逻辑会有一个问题设备上报频率高的时候Handler线程池会被数据库写入阻塞导致设备连接超时或断开。我在Handler里只负责把消息变成JSON格式然后发送到RocketMQ的device-data-topic发送成功之后立即返回让Netty线程能够继续处理下一个请求。消费端的处理逻辑写在collector模块里。消费线程从消息队列拉取批量数据按设备维度分组再调用TDengine的批量写入接口一次性写入对应超级表。这里的关键技巧是批量写入的批大小控制太少了写入频繁影响吞吐太多了单次写入耗时长消息积压时消费进度跟不上。我实测下来500条一批在实验室环境下的综合性能最好。4.3 WebSocket推送让前端图表动起来储能平台的大屏展示要求数据实时刷新。刚开始我用的方式是前端每3秒轮询一次REST接口虽然能跑但体验很差刷新频率高了后端压力大频率低了图表看起来一顿一顿的。后来改用WebSocket主动推送。后端维护一个推送服务消费消息队列里的实时数据经过简单的聚合计算后按照主题推送给前端。前端收到数据直接更新图表延迟在1秒以内。提示如果前端页面同时打开多个标签页每个页面都建立一个WebSocket连接数据量叠起来对推送服务压力不小。我在前端做了处理同一浏览器只保留一个WebSocket连接对象页面间共享数据。5. 存储层设计MySQL与TDengine的分工协作存储层的设计是储能平台数据架构的关键。很多同类项目的数据库最后变成了“大泥球”就是因为没有在一开始厘清存储职责。我这套项目的存储方案分成几个部分逐一说明。5.1 业务库MySQL的表结构设计思路MySQL这边管理的是业务数据。设备信息表、采集点配置表、用户表、角色权限表、告警记录表、策略配置表、操作日志表总共十几张表关系不算复杂但有几个设计细节值得注意。设备信息表里我专门加了协议类型字段和解析器名称字段。为什么要这样做因为储能设备虽然有标准的Modbus协议但不同厂家对寄存器的地址定义不一样。有的设备SOC存在寄存器100有的存在寄存器200这个差异必须通过配置表来适配不能写死在代码里。采集点配置表是把设备数据变成“可配置业务资产”的核心。表结构大致是设备ID、采集点编号、采集点名称、数据类型电压/电流/SOC/温度等、寄存器地址、数据精度、倍率、单位。有了这张表新接入一种设备的时候只需要配置采集点不需要改代码就能完成对接。告警记录表的设计有些特殊。除了必须包含的告警时间、设备ID、告警级别、告警内容之外我还增加了告警状态字段和处理人、处理备注字段。这样告警不只是被记录还能形成闭环产生告警、确认告警、处理告警、解除告警整个生命周期在系统里可查。这个设计对后续做设备故障分析非常有用。5.2 TDengine超级表与标签设计时序数据入库TDengine的超级表是这类场景的最优解。超级表的含义是把一批结构相同的表归为一张逻辑表每张具体的子表有自己的标签值查询的时候可以按标签过滤。我创建超级表的SQL大体是这样的CREATE STABLE IF NOT EXISTS meter_data ( ts TIMESTAMP, value FLOAT, quality INT ) TAGS ( device_id BINARY(32), point_id BINARY(32) );实际写入的时候每个采集点对应一张子表子表名格式是device_id _ point_id。标签字段是设备和采集点的标识这样查询某一台设备的所有数据、或者查询某一种采集点类型跨设备对比都非常方便。关于数据保留策略我设置了不同的保存周期。原始遥测数据保存3个月聚合数据保存2年。聚合数据是怎么来的通过TDengine的连续查询功能把原始数据按1分钟、5分钟、1小时三个粒度做降采样聚合分别存入对应的聚合表。前端报表页面在查看历史趋势的时候不会直接查原始数据表而是根据时间范围自动选择合适粒度的聚合表。这样既保证了查询速度又不会丢失历史分析价值。5.3 冷热数据分离与文件归档数据量再大一点纯数据库存储的成本问题就会浮现。实验室场景虽然数据量没那么夸张但我在设计时还是考虑了冷数据归档方案。我实现了一个简单的归档机制每季度执行一次定时任务把超过6个月的原始数据从TDengine导出压缩后存到NFS文件服务器上数据库里只保留聚合数据。归档后的文件在报表需要查询时通过一个离线的查询接口手动加载。这个方案的好处是控制数据库存储成本的增长坏处是查询历史明细数据没法做到实时但对实验室场景完全够用。6. 控制链路从平台按钮到设备动作的完整闭环储能平台里比数据采集更重要、也更容易出错的是控制链路。这个项目里远程控制功能包括启动待机切换、充放电模式切换、功率设定、紧急停机。每一条指令的流转路径都必须严密设计因为储能设备的误操作带来的后果不像普通业务数据出错那么简单是实打实的功率和电能的改变涉及安全问题。6.1 控制指令的封装与下发流程控制指令的封装我放在了domain层里定义了一个统一的ControlCommand对象包含指令ID、设备ID、指令类型、指令参数、时间戳、来源用户、审批状态等字段。每次前端发起控制请求后端先把请求转换成ControlCommand对象然后走完整的审批和下发链路。链路设计为前端发起控制请求后端创建控制指令并写入MySQL控制指令表状态是待下发。如果有审批流程就需要审批人审核通过状态变成已批准。然后通过Netty网关下发到设备。设备执行之后会返回响应消息后端根据响应更新指令状态为执行成功或执行失败。整个过程中前端通过WebSocket实时收到指令状态变更通知。这个设计保证了一点任何控制操作都有完整的操作日志操作之后设备有没有执行、执行结果如何所有环节都可追溯。这在储能场景里是必须的死要求不能省。6.2 设备执行结果的双重确认机制下发指令之后设备返回“收到指令”和“指令执行成功”是完全不同的概念。我曾经遇到过一个情况设备返回了成功响应但实际上功率参数没有变化重新读寄存器发现值还是旧的。为了保证指令执行结果可信我在设计里加了双重确认机制。第一重确认是设备对指令的响应代表设备收到了指令。第二重确认是下发指令之后主动回读寄存器确认设备实际状态已经变成目标状态。对于功率设定这类指令回读持续做3次间隔5秒确保状态稳定后才把指令状态标记为成功。这个设计还引出了一个安全保护功能校时与心跳。平台每30秒向设备发送一次心跳包确认设备连接正常。如果连续3次心跳没有响应平台判定设备离线推送告警并禁止任何控制指令下发。这从根本上避免了平台在设备失联状态下盲发指令的危险情况。6.3 权限控制与操作安全控制指令不是所有人都能操作的。这套系统在用户权限上做了比较精细的设计普通用户只能查看数据和告警操作员可以下发常规控制指令管理员拥有全部权限。权限控制基于Spring Security和JWT实现接口层面做方法级权限校验。但光有权限还不够控制指令还做了二次确认。前端在下发指令前需要填写操作确认原因后端在接口层校验原因不能为空。这个设计看似多余实际使用的时候非常有用有一次操作人员误把功率设定值填成了超出设备额定功率的数值就是因为填写原因时多看了两眼及时发现并取消了操作。注意控制接口一定要做幂等处理。同一个指令ID重复提交后端直接拒绝。否则网络超时后前端重试指令被发送两次设备可能执行两次同样的操作在某些场景下会造成危险。7. 告警引擎阈值触发只是入门趋势判断才是关键告警模块是储能平台里用户感知最强的一部分。刚开始我以为告警就是简单的值超过阈值就触发写过之后才发现真正实用且有价值的告警系统要处理的东西远比阈值判断复杂。7.1 告警规则的配置化设计告警规则我设计成可配置的而不是硬编码在代码里。规则表主要字段包括规则名称、关联设备类型、关联采集点、告警级别、触发条件类型、阈值参数、持续时间、通知方式。触发条件类型我实现了两大类。第一类是数值比较大于、小于、等于、区间内、区间外。第二类是变化率比较比如5分钟内温度上升超过3摄氏度、1分钟内SOC下降超过5个百分点。第二类告警需要依赖历史数据进行计算我在定时任务里做滑动窗口扫描每30秒执行一次对活跃的采集点进行变化率计算。配置化的好处很快就能体现出来实验室的管理人员可以根据不同电池的老化状态、不同季节的环境条件灵活调整告警规则不需要开发人员介入。7.2 告警风暴的抑制策略告警风暴是物联网项目里一定会遇到的问题。某个电池簇出现电压异常一分钟内可能上报几十条告警如果全部推送给用户用户反而不重视了。我做了三级抑制策略。第一级是告警去重同一个设备、同一个规则、在10分钟内只产生一条告警后续重复触发的延长告警持续时长但不再新增记录。第二级是告警聚合同一台设备、同一时间段内触发的多条告警合并成一条汇总告警标明涉及的采集点列表。第三级是告警升级如果一条告警持续超过30分钟没有被确认自动把级别提升并通过邮件、短信等渠道通知值班人员。这套抑制策略上线后告警洪峰期间的通知量减少了大概80%而关键告警一条都没漏。7.3 告警与设备健康的联动分析告警数据积累一段时间之后可以做更有价值的联动分析。我在告警处理完成时要求处理人选择告警原因分类设备老化、参数配置错误、环境因素、通信瞬断、人为误操作等。有了这些分类数据后续可以通过报表统计出哪些设备出故障频率最高、哪些告警类型的处理耗时最长、哪些设备的告警和气候环境相关。这套分析数据对实验室的研究方向很有帮助。Lab518是电气工程相关的实验室这些电池循环寿命、故障分布的数据可以反过来用于电池管理策略的研究。这也是我认为储能平台不同于普通业务系统的另一个点它的数据本身就有科研价值后端在存储和呈现这些数据时应该具备长远的可分析意识。8. 接口设计与前后端协作规范后端接口的设计直接决定前端开发的体验。我对接口的规范要求比较简单但严格Restful风格、统一响应结构、明确的错误码。8.1 统一响应结构与错误处理所有接口的响应格式统一为{ code: 0, message: success, data: {} }code为0表示成功非0表示业务异常。错误码分段管理1xxx是通用的系统错误2xxx是参数错误3xxx是权限错误4xxx是设备相关错误。每一类错误在message里返回便于前端提示的信息同时后端日志里记录详细的堆栈。关键的地方在于全局异常处理器。我实现了一个RestControllerAdvice针对业务异常、参数校验异常、运行时异常分别做了处理。这样controller层不需要每个接口都写try-catch代码干净了很多。8.2 分页查询的参数设计储能平台里有大量列表查询场景告警记录、操作日志、历史数据、设备列表。分页是所有接口里最容易设计随意的地方。我统一采用了页码加每页条数的分页方式并且严格限制每页最大条数为200。对于需要导出Excel的场景单独提供导出接口避免一次性查询全量数据导致内存溢出。时间范围查询是所有储能数据查询的标配。我在接口里强制要求时间参数必须成对出现startTime和endTime必须同时传或者同时不传不传默认最近30分钟。这个默认值的选择也是经过考虑的避免了前端忘记传时间导致全表扫描的问题。8.3 接口文档与联调工具接口文档用的是Swagger基于OpenAPI 3.0在Spring Boot项目里集成非常方便。文档里完整标注每个字段的含义、是否必传、示例值。前后端联调时前端根据文档生成接口请求代码效率和准确性都非常高。提示Swagger上线时一定要关闭。生产环境暴露接口文档存在安全隐患我在配置里用Profile控制只有开发环境才开启Swagger。9. 部署运维与实测性能表现代码写完之后真正的考验在部署和运维阶段。这部分内容往往在教科书里被一笔带过但在实际项目里占用的时间比重一点不比写代码少。9.1 服务器规划与部署形态部署形态我选择了最简单的单机加几个基础服务的方案。服务器配置是8核16G内存系统是Ubuntu 20.04Docker运行中间件。Java应用直接打成jar包使用systemd服务管理。部署架构组件部署方式资源配置Spring Boot应用直接运行jar包4GB堆内存MySQLDocker容器容器内数据卷持久化TDengineDocker容器默认配置数据目录挂载RocketMQDocker容器默认配置NginxDocker容器静态资源与反向代理9.2 JVM参数调优Spring Boot应用启动的时候JVM参数设置如下-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis1004G的堆内存对这套业务规模足够G1GC保证GC停顿可控。设备接入和数据入库的线程池参数也单独做了配置Netty的boss线程数设置为cpu核心数worker线程数设置为核心数的两倍。这里有一个很容易踩的坑如果你的服务器内存只有8G给Java应用分配4G堆内存剩下的内存还要给MySQL、TDengine、RocketMQ、Nginx用内存分配会很紧张。我给部署机器预留了内存规划让四个核心中间件各有弹性空间避免一个组件内存溢出拖垮整个机器。9.3 实测性能数据系统跑起来之后我做了几组性能测试数据对实验室场景完全够用这里列几个关键指标供参考。指标测试结果说明设备接入数2000 长连接实验室实测场景几十台远未到瓶颈遥测数据写入吞吐约20000条/秒批量写入TDengineAPI响应时间P99在200ms以内常规查询接口历史聚合查询10亿条数据聚合查询1秒以内基于TDengine预聚合告警推送延迟从产生到前端展示约2秒含消息链路和规则判断实际运行过程中系统的CPU占用率平均在30%左右内存稳定在5G上下。对于Lab518这类实验室项目这个性能表现是绰绰有余的而且还有比较大的性能冗余空间如果未来接入更多设备扩容路径也已经预留好了。10. 一路走过来遇到的那些坑做这类系统踩坑才是最有价值的经验积累。我挑几个印象深刻的记录下来给大家提个醒。10.1 Netty内存泄漏排查第一个坑发生在设备接入服务刚上线的时候。运行一段时间后内存占用缓慢上涨怀疑是内存泄漏。因为Netty使用堆外内存直接内存导致的内存泄漏用常规jmap不容易看到排查起来比较费劲。排查思路先用jstat -gcutil观察GC情况发现老年代在持续增长。再通过jmap -dump导出堆转储用MAT分析发现大量DefaultByteBufHolder对象没有被释放。再检查代码发现是在协议解析器的channelRead里有异常路径没有调用ReferenceCountUtil.release(msg)导致ByteBuf引用计数泄漏。修复方式很简单把消息处理改成try-finally结构确保每个报文在消费完之后释放引用。同时把Netty的ALLOCATOR设置为PooledByteBufAllocator.DEFAULT并开启-Dio.netty.leakDetection.levelparanoid及时捕获泄漏对象。10.2 时区问题导致数据错乱有一次发现告警时间和实际时间差了好几个小时排查后发现是TDengine时区配置的问题。TDengine默认使用UTC时间而应用服务器使用的是东八区时间。写入数据的时候时间戳虽然看起来是对的但是TDengine内部存储的是UTC查询时如果不做时区转换展示出来的数据就偏了。解决方案是在TDengine初始化连接串里加上时区参数并且在应用层统一使用同一个时区工具类处理所有时间转换。从那以后所有涉及时间的字段我在代码里强制使用ZonedDateTime不在任何地方使用不带时区的本地时间。10.3 设备连接不稳定的检测与自动恢复设备连接不稳定这个坑在实验室环境里尤其明显。设备跑电测试的时候会掉电重启如果平台不能自动重连每次都需要人工恢复运维成本很高。我在Netty网关里实现了完整的断线重连机制。客户端设备侧在TCP层做了一个心跳监测器当超过30秒没有收到服务端响应主动断开连接并重连。服务端这边每60秒检查一次设备连接的空闲状态对超过90秒无数据交互的连接主动关闭释放资源。每次重连成功之后服务端自动触发一次全量数据同步机制向设备请求当前全部状态参数保证平台数据和设备实际状态一致。这套机制上线之后设备断电恢复后无需人工干预平台自动恢复数据同步。11. 这个项目还能怎么继续演进目前这套平台在Lab518已经稳定运行了一个阶段日常的数据采集、告警监控、远程控制、报表分析功能都正常。不过作为一套面向科研场景的储能平台我觉得它还有几个非常值得演进的方向。储能平台的数据质量直接影响上层算法和策略的研究结论。下一步我计划在数据接入层增加数据清洗和质量评估模块对异常值、缺测值做标记和插值处理保证进入分析层的数据是干净可用的。控制策略智能化是另一个重要的演进方向。当前平台还是人工设置充放电策略为主后续可以接入基于深度学习或强化学习的电池充放电控制算法平台提供策略下发和效果跟踪的闭环机制。这个方向上现有的控制链路设计和双重确认机制已经选好了底子扩展起来路径是通的。多平台联动和数据共享也值得考虑。多个实验室或不同校区的储能设备可以通过平台进行统一调度和数据汇总实现更宏观层面的能量管理研究。这就需要把现有的设备接入能力做成标准化的服务对外提供数据接入API让其他平台也能基于这套架构扩展。储能平台这类项目技术的复杂度不在于某一个点有多深而在于把设备、数据、控制、业务、展示整条链路串起来每一个环节都不能有明显的短板。Java生态在接口开发、业务建模、领域设计上的成熟经验配合Netty解决设备通信、TDengine解决时序数据整个技术组合是经得起实际考验的。希望这篇内容对准备做能源物联网项目后端开发的同学有所启发也欢迎大家在实际落地时多交流踩坑体验。本文还有配套的精品资源点击获取 储能平台后端架构设计：从设备接入到数据管理的Java实践
简介本资源是上海交通大学电气工程学院Lab518储能平台的后端系统完整源码实现面向高校电力/能源方向的Java后端开发者、课程设计学生及智能电网相关科研实践者聚焦于储能监控系统的数据接入、状态管理与日志归档等核心功能。压缩包共69个文件总大小271KB涵盖56个Java业务与实体类源码集中于src目录、2个XML配置文件含Maven构建核心pom.xml、2个Gzip压缩日志energy.log.2024-03-07.0.gz等体现真实运行时日志轮转机制、1个Maven Wrapper启动脚本mvnw、1个.gitignore及readme.txt等工程规范文件结构清晰反映典型Spring Boot/Maven项目组织方式。已有283人学习下载可直接导入IDE运行调试获取完整的储能平台后端架构实践案例包括日志分级处理逻辑、属性配置加载方式、GitMaven标准化协作流程以及面向电类场景的轻量级服务封装范式。1. 项目不是“系统开发”而是“平台底座搭建”先说清楚这个项目到底在做什么。上海交大电院Lab518的储能平台本质上是一个面向实验室科研场景的能量管理与设备监控系统。它不是我理解中常见的业务管理系统——不是管订单、管用户、管审批那一套而是需要持续对接电池簇、PCS变流器、BMS电池管理系统、温控机组等硬件设备完成遥测数据采集、状态监控、控制指令下发、告警管理、历史数据沉淀等一系列任务。标题里“后端设计源码”这几个字很容易让人误以为是个普通的管理后台项目。实际接触下来你会发现这类项目的技术难点根本不在CRUD而在三个方面一是数据接入层的通信协议适配储能设备基本走Modbus TCP、IEC 61850或者厂家私有协议每种协议的数据模型都不一样二是时序数据的存储与查询设计一套实验室储能系统动辄几十个采集点秒级采集一天就是几百万条记录三是控制指令的可靠性和安全性远程下发充放电指令不能有半点含糊链路要可追踪、状态要可回读。我做的这套后端拿Java生态做底座Spring Boot做应用框架存储上MySQL负责业务管理数据、TDengine负责时序数据通信层用Netty做设备接入网关。整套架构跑下来核心目标就一句话让实验室的储能系统像工业级的能量管理平台一样稳定、可观测、可溯源。适合参考这套设计的同学应该是接下来要做能源物联网、工业数据采集、设备监控类项目的Java后端工程师。如果你接手的项目也需要高频写入设备数据、需要把设备通信和业务系统打通那这篇文章提到的很多设计决策和踩坑经历都可以直接借鉴。2. 储能平台后端到底要解决什么问题动手写代码之前最关键的一件事是先把问题定义清楚。储能平台的业务边界和普通管理系统完全不同我把Lab518平台实际要面对的问题拆成了四层。层级核心问题对应后端功能设备接入层多种储能设备、多种通信协议、数据格式不一致Netty网关、协议解析、指令下发通道数据存储层高频遥测数据写入量大、历史查询要求快TDengine时序库、MySQL业务库、分层存储业务逻辑层充放电策略、告警规则、设备管理Spring Boot服务、规则引擎、任务调度展示交互层前端大屏、Web管理界面、移动端查看REST API、WebSocket推送、权限控制2.1 设备接入层是储能平台最容易翻车的地方很多做传统Java业务系统的人接手储能平台第一个不适应的地方就是设备通信。你面对的不是前端页面传过来的JSON数据而是字节流——Modbus协议里一个16位寄存器拆成两个字节高低位顺序颠倒就能让你解析出完全错误的数据。我在这套项目里用Netty搭建了一个独立的设备接入服务没有把它和业务服务混在一起。原因很直接设备通信是长连接、高并发、持续读写的场景Netty的NIO模型天然适合处理几百台设备同时保持TCP长连接的需求。业务服务则更偏向请求响应模式两者混在一起任何一个方向的压力抖动都会影响另一端。Netty这边的核心结构是这样的每个设备一个ChannelChannel上绑定协议解析Handler消息进来之后先经过拆包粘包处理再进入协议解析器。储能设备绝大多数都是Modbus TCP协议所以我在解析器里专门实现了Modbus的MBAP头和PDU体解析对线圈状态、寄存器值、异常响应做了完整的处理。解析出来的数据统一封装成一个内部的消息POJO通过消息队列丢给后端的业务服务处理Netty本身不做任何业务操作只负责连接管理和数据透传。提示Netty设备接入服务和业务服务之间一定要用消息队列解耦。直接Feign调用或者Redis发布订阅看起来简单但设备数据洪峰来的时候消费者速度跟不上消息积压会导致业务服务雪崩。2.2 数据存储层要划分“业务数据”和“时序数据”两条线储能系统里的数据可以简单分成两类。一类是设备档案、用户信息、策略配置、告警记录这类数据量不大、结构相对固定MySQL完全应付得过来。另一类是电池簇电压、电流、SOC、温度、功率这类遥测数据每个采集点固定时间间隔上报一次一天产生的数据量非常可观。MySQL支撑不了高频时序数据这一点实践下来是肯定的。早期图省事我把遥测数据也塞进MySQL一张表一天涨几百万行查询效率急剧下降一个聚合查询动不动几秒钟。后来换成了TDengine专门存时序数据情况完全不一样。TDengine的核心设计是“一个采集点一张表”加上超级表自动分区按时间维度做数据切片。我在项目里给每个电池簇建了一张超级表标签字段是设备ID和采集点类型列字段是时间戳和值。写入的时候直接用参数绑定接口批量写入单台设备的数据落库延迟在毫秒级别。业务数据和时序数据分开之后还有一个隐藏的好处备份和清理策略可以各自独立。MySQL做日常备份时序库按保留策略自动滚动清理不用人工介入。2.3 业务逻辑层是平台的大脑平台真正体现智能的地方在业务逻辑层。储能平台不仅仅是“看数据”还要根据数据产生动作。策略管理这块我实现了两种模式一种是本地策略就是设备本身自带的充放电策略后端只需要把配置参数下发到设备即可相当于远程改参数另一种是云端策略由平台根据电价时段、负载情况、电池SOC状态计算后生成充放电计划下发给PCS执行。告警规则是另一块重要内容。储能系统的告警和传统IT系统不一样很多告警不是单纯的阈值触发而是要基于变化趋势判断的。比如电池温度超过55摄氏度是立刻告警但温度在10分钟内上升了10摄氏度这个趋势也是紧急告警。我在告警引擎里实现了两类规则一类是静态阈值规则一类是变化率规则配合定时任务扫描基本覆盖了实验室场景下的主要风险场景。3. 整体架构设计与选型逻辑架构设计这块没什么玄学关键是把问题理清楚让每一层各司其职同时保证链路可追踪。我最终落地的架构分成了四层每层解决自己的问题层与层之间用规范的接口通信。设备终端 → Netty设备接入网关 → 消息队列 → 数据处理服务 → MySQL/TDengine → REST API/WebSocket → Web前端 ↓ 告警服务 → 通知/工单3.1 技术选型不是“谁火用谁”而是“谁合适用谁”Java生态里能选择的框架和中间件非常多选型的时候我遵循了几个原则社区活跃度、团队技术栈匹配度、运维复杂度。实验室项目不是互联网大厂没有专门的基础设施团队能用简单的方案就不用复杂的。Spring Boot作为应用框架没有悬念它解决了配置、依赖管理、自动装配这些繁琐的事让项目开发效率提升非常明显。MyBatis-Plus负责和MySQL交互主要是看重它的代码生成和条件构造器业务CRUD写起来非常省事。Netty负责设备接入这个前面已经说过。消息队列我选择了RocketMQ分组消费和延迟消息的特性在设备数据分发和告警通知里都用得上。有一个选型细节值得单独说一下为什么不用Spring Cloud全家桶因为实验室项目根本不需要微服务。微服务解决的是大团队并行开发、独立部署、弹性伸缩的问题储能平台的并发量远没到那个程度强行拆成微服务只会增加运维成本。我把服务拆成了网关接入、数据入库、告警处理、业务管理几个模块还是单一应用部署模块之间通过依赖注入和消息解耦灵活性和简单性都保住了。3.2 项目分层结构怎么组织才不乱代码结构我采用的是经典的分层架构但边界和命名都做了适配储能业务场景的调整com.lab518.storage ├── common // 通用工具类、统一返回体、异常处理 ├── gateway // Netty设备接入网关、协议解析 ├── collector // 数据采集与入库、消息消费 ├── domain // 设备信息、BMS数据、PCS数据、告警规则等核心模型 ├── service // 业务逻辑策略管理、告警引擎、报表服务 ├── controller // REST API层 └── task // 定时任务数据对账、趋势告警扫描、设备状态探测这里有一个对Java后端新人非常重要的经验不要为了“分层”而分层而是要让每一层真的在解决对应的问题。我以前见过很多项目controller里面直接new serviceservice里面直接写SQL表面上分了包实际上耦合成一坨。这套项目里我严格执行了“controller只做参数校验和结果封装、service层处理业务规则、然后通过mapper或仓库访问数据”的规则保证任何一层替换或者升级的时候不会牵连其他层。实际上对于设备接入服务的Channel管理我用了一个ChannelGroup来维护所有在线设备的连接同时用设备编号作为key建了一张Channel映射表指令下发的时候可以迅速找到对应设备的连接通道。这个映射表放在本地内存里因为单机部署模式下设备连接不涉及跨节点转发问题如果未来需要水平扩展再把映射关系放到Redis里就好。3.3 统一配置与多环境管理实验室项目有一个经常被忽略的问题环境多。开发环境、测试环境、实验室现场环境配置都不一样。设备IP、端口、数据库地址、NTP时间源这些配置如果散落在代码里每次部署都要改一堆地方容易出错。我在项目里用了Spring Profile机制管理多环境配置每个环境对应一个application-{profile}.yml文件公共配置放在application.yml里。设备地址和点位映射表这种现场强相关的配置放在Nacos配置中心统一管理改动配置不需要重启服务通过监听机制自动刷新到运行中的服务实例。4. 数据采集链路从设备字节流到前端图表的完整过程数据采集是这个项目最核心的链路很多后台开发不熟悉嵌入式设备的交互方式这里我把整条链路从底到上完整拆解一遍这部分也是我做这个项目时调试时间最长的地方。4.1 Netty网关如何实现Modbus TCP协议解析Modbus TCP协议的报文结构不算复杂但它有一套自己的规矩。报文由MBAP头7字节和PDU体功能码数据组成。MBAP头包括事务标识符、协议标识符、长度、单元标识符。PDU体就是具体要读取或写入的数据。解析的难点在于理解不同功能码的含义。读取保持寄存器是0x03读取输入寄存器是0x04写单个寄存器是0x06写多个寄存器是0x10。储能设备里BMS的数据绝大部分是保持寄存器PCS的一些参数如工作模式、功率设定值也是保持寄存器。我的解析器里针对常用功能码写了对应的解码器和编码器解码器负责把字节流变成我们内部定义的协议对象编码器负责把指令对象变成字节流发出去。拆包粘包是Netty开发中必踩的坑。Modbus TCP协议有个特点是报文长度字段明确因此可以用基于长度字段的拆包器。我使用了LengthFieldBasedFrameDecoder参数设置成maxFrameLength1024, lengthFieldOffset4, lengthFieldLength2。这个4和2怎么确定的MBAP头里长度字段在字节4和字节5占2个字节所以长度字段偏移量是4、长度是2。设置对了之后粘包问题从根上解决了。4.2 数据解析之后为什么先走消息队列设备数据经过协议解析之后变成一条条标准化消息。这个时候的处理策略决定了系统的稳定上限。如果直接在Netty的Handler里写入库逻辑会有一个问题设备上报频率高的时候Handler线程池会被数据库写入阻塞导致设备连接超时或断开。我在Handler里只负责把消息变成JSON格式然后发送到RocketMQ的device-data-topic发送成功之后立即返回让Netty线程能够继续处理下一个请求。消费端的处理逻辑写在collector模块里。消费线程从消息队列拉取批量数据按设备维度分组再调用TDengine的批量写入接口一次性写入对应超级表。这里的关键技巧是批量写入的批大小控制太少了写入频繁影响吞吐太多了单次写入耗时长消息积压时消费进度跟不上。我实测下来500条一批在实验室环境下的综合性能最好。4.3 WebSocket推送让前端图表动起来储能平台的大屏展示要求数据实时刷新。刚开始我用的方式是前端每3秒轮询一次REST接口虽然能跑但体验很差刷新频率高了后端压力大频率低了图表看起来一顿一顿的。后来改用WebSocket主动推送。后端维护一个推送服务消费消息队列里的实时数据经过简单的聚合计算后按照主题推送给前端。前端收到数据直接更新图表延迟在1秒以内。提示如果前端页面同时打开多个标签页每个页面都建立一个WebSocket连接数据量叠起来对推送服务压力不小。我在前端做了处理同一浏览器只保留一个WebSocket连接对象页面间共享数据。5. 存储层设计MySQL与TDengine的分工协作存储层的设计是储能平台数据架构的关键。很多同类项目的数据库最后变成了“大泥球”就是因为没有在一开始厘清存储职责。我这套项目的存储方案分成几个部分逐一说明。5.1 业务库MySQL的表结构设计思路MySQL这边管理的是业务数据。设备信息表、采集点配置表、用户表、角色权限表、告警记录表、策略配置表、操作日志表总共十几张表关系不算复杂但有几个设计细节值得注意。设备信息表里我专门加了协议类型字段和解析器名称字段。为什么要这样做因为储能设备虽然有标准的Modbus协议但不同厂家对寄存器的地址定义不一样。有的设备SOC存在寄存器100有的存在寄存器200这个差异必须通过配置表来适配不能写死在代码里。采集点配置表是把设备数据变成“可配置业务资产”的核心。表结构大致是设备ID、采集点编号、采集点名称、数据类型电压/电流/SOC/温度等、寄存器地址、数据精度、倍率、单位。有了这张表新接入一种设备的时候只需要配置采集点不需要改代码就能完成对接。告警记录表的设计有些特殊。除了必须包含的告警时间、设备ID、告警级别、告警内容之外我还增加了告警状态字段和处理人、处理备注字段。这样告警不只是被记录还能形成闭环产生告警、确认告警、处理告警、解除告警整个生命周期在系统里可查。这个设计对后续做设备故障分析非常有用。5.2 TDengine超级表与标签设计时序数据入库TDengine的超级表是这类场景的最优解。超级表的含义是把一批结构相同的表归为一张逻辑表每张具体的子表有自己的标签值查询的时候可以按标签过滤。我创建超级表的SQL大体是这样的CREATE STABLE IF NOT EXISTS meter_data ( ts TIMESTAMP, value FLOAT, quality INT ) TAGS ( device_id BINARY(32), point_id BINARY(32) );实际写入的时候每个采集点对应一张子表子表名格式是device_id _ point_id。标签字段是设备和采集点的标识这样查询某一台设备的所有数据、或者查询某一种采集点类型跨设备对比都非常方便。关于数据保留策略我设置了不同的保存周期。原始遥测数据保存3个月聚合数据保存2年。聚合数据是怎么来的通过TDengine的连续查询功能把原始数据按1分钟、5分钟、1小时三个粒度做降采样聚合分别存入对应的聚合表。前端报表页面在查看历史趋势的时候不会直接查原始数据表而是根据时间范围自动选择合适粒度的聚合表。这样既保证了查询速度又不会丢失历史分析价值。5.3 冷热数据分离与文件归档数据量再大一点纯数据库存储的成本问题就会浮现。实验室场景虽然数据量没那么夸张但我在设计时还是考虑了冷数据归档方案。我实现了一个简单的归档机制每季度执行一次定时任务把超过6个月的原始数据从TDengine导出压缩后存到NFS文件服务器上数据库里只保留聚合数据。归档后的文件在报表需要查询时通过一个离线的查询接口手动加载。这个方案的好处是控制数据库存储成本的增长坏处是查询历史明细数据没法做到实时但对实验室场景完全够用。6. 控制链路从平台按钮到设备动作的完整闭环储能平台里比数据采集更重要、也更容易出错的是控制链路。这个项目里远程控制功能包括启动待机切换、充放电模式切换、功率设定、紧急停机。每一条指令的流转路径都必须严密设计因为储能设备的误操作带来的后果不像普通业务数据出错那么简单是实打实的功率和电能的改变涉及安全问题。6.1 控制指令的封装与下发流程控制指令的封装我放在了domain层里定义了一个统一的ControlCommand对象包含指令ID、设备ID、指令类型、指令参数、时间戳、来源用户、审批状态等字段。每次前端发起控制请求后端先把请求转换成ControlCommand对象然后走完整的审批和下发链路。链路设计为前端发起控制请求后端创建控制指令并写入MySQL控制指令表状态是待下发。如果有审批流程就需要审批人审核通过状态变成已批准。然后通过Netty网关下发到设备。设备执行之后会返回响应消息后端根据响应更新指令状态为执行成功或执行失败。整个过程中前端通过WebSocket实时收到指令状态变更通知。这个设计保证了一点任何控制操作都有完整的操作日志操作之后设备有没有执行、执行结果如何所有环节都可追溯。这在储能场景里是必须的死要求不能省。6.2 设备执行结果的双重确认机制下发指令之后设备返回“收到指令”和“指令执行成功”是完全不同的概念。我曾经遇到过一个情况设备返回了成功响应但实际上功率参数没有变化重新读寄存器发现值还是旧的。为了保证指令执行结果可信我在设计里加了双重确认机制。第一重确认是设备对指令的响应代表设备收到了指令。第二重确认是下发指令之后主动回读寄存器确认设备实际状态已经变成目标状态。对于功率设定这类指令回读持续做3次间隔5秒确保状态稳定后才把指令状态标记为成功。这个设计还引出了一个安全保护功能校时与心跳。平台每30秒向设备发送一次心跳包确认设备连接正常。如果连续3次心跳没有响应平台判定设备离线推送告警并禁止任何控制指令下发。这从根本上避免了平台在设备失联状态下盲发指令的危险情况。6.3 权限控制与操作安全控制指令不是所有人都能操作的。这套系统在用户权限上做了比较精细的设计普通用户只能查看数据和告警操作员可以下发常规控制指令管理员拥有全部权限。权限控制基于Spring Security和JWT实现接口层面做方法级权限校验。但光有权限还不够控制指令还做了二次确认。前端在下发指令前需要填写操作确认原因后端在接口层校验原因不能为空。这个设计看似多余实际使用的时候非常有用有一次操作人员误把功率设定值填成了超出设备额定功率的数值就是因为填写原因时多看了两眼及时发现并取消了操作。注意控制接口一定要做幂等处理。同一个指令ID重复提交后端直接拒绝。否则网络超时后前端重试指令被发送两次设备可能执行两次同样的操作在某些场景下会造成危险。7. 告警引擎阈值触发只是入门趋势判断才是关键告警模块是储能平台里用户感知最强的一部分。刚开始我以为告警就是简单的值超过阈值就触发写过之后才发现真正实用且有价值的告警系统要处理的东西远比阈值判断复杂。7.1 告警规则的配置化设计告警规则我设计成可配置的而不是硬编码在代码里。规则表主要字段包括规则名称、关联设备类型、关联采集点、告警级别、触发条件类型、阈值参数、持续时间、通知方式。触发条件类型我实现了两大类。第一类是数值比较大于、小于、等于、区间内、区间外。第二类是变化率比较比如5分钟内温度上升超过3摄氏度、1分钟内SOC下降超过5个百分点。第二类告警需要依赖历史数据进行计算我在定时任务里做滑动窗口扫描每30秒执行一次对活跃的采集点进行变化率计算。配置化的好处很快就能体现出来实验室的管理人员可以根据不同电池的老化状态、不同季节的环境条件灵活调整告警规则不需要开发人员介入。7.2 告警风暴的抑制策略告警风暴是物联网项目里一定会遇到的问题。某个电池簇出现电压异常一分钟内可能上报几十条告警如果全部推送给用户用户反而不重视了。我做了三级抑制策略。第一级是告警去重同一个设备、同一个规则、在10分钟内只产生一条告警后续重复触发的延长告警持续时长但不再新增记录。第二级是告警聚合同一台设备、同一时间段内触发的多条告警合并成一条汇总告警标明涉及的采集点列表。第三级是告警升级如果一条告警持续超过30分钟没有被确认自动把级别提升并通过邮件、短信等渠道通知值班人员。这套抑制策略上线后告警洪峰期间的通知量减少了大概80%而关键告警一条都没漏。7.3 告警与设备健康的联动分析告警数据积累一段时间之后可以做更有价值的联动分析。我在告警处理完成时要求处理人选择告警原因分类设备老化、参数配置错误、环境因素、通信瞬断、人为误操作等。有了这些分类数据后续可以通过报表统计出哪些设备出故障频率最高、哪些告警类型的处理耗时最长、哪些设备的告警和气候环境相关。这套分析数据对实验室的研究方向很有帮助。Lab518是电气工程相关的实验室这些电池循环寿命、故障分布的数据可以反过来用于电池管理策略的研究。这也是我认为储能平台不同于普通业务系统的另一个点它的数据本身就有科研价值后端在存储和呈现这些数据时应该具备长远的可分析意识。8. 接口设计与前后端协作规范后端接口的设计直接决定前端开发的体验。我对接口的规范要求比较简单但严格Restful风格、统一响应结构、明确的错误码。8.1 统一响应结构与错误处理所有接口的响应格式统一为{ code: 0, message: success, data: {} }code为0表示成功非0表示业务异常。错误码分段管理1xxx是通用的系统错误2xxx是参数错误3xxx是权限错误4xxx是设备相关错误。每一类错误在message里返回便于前端提示的信息同时后端日志里记录详细的堆栈。关键的地方在于全局异常处理器。我实现了一个RestControllerAdvice针对业务异常、参数校验异常、运行时异常分别做了处理。这样controller层不需要每个接口都写try-catch代码干净了很多。8.2 分页查询的参数设计储能平台里有大量列表查询场景告警记录、操作日志、历史数据、设备列表。分页是所有接口里最容易设计随意的地方。我统一采用了页码加每页条数的分页方式并且严格限制每页最大条数为200。对于需要导出Excel的场景单独提供导出接口避免一次性查询全量数据导致内存溢出。时间范围查询是所有储能数据查询的标配。我在接口里强制要求时间参数必须成对出现startTime和endTime必须同时传或者同时不传不传默认最近30分钟。这个默认值的选择也是经过考虑的避免了前端忘记传时间导致全表扫描的问题。8.3 接口文档与联调工具接口文档用的是Swagger基于OpenAPI 3.0在Spring Boot项目里集成非常方便。文档里完整标注每个字段的含义、是否必传、示例值。前后端联调时前端根据文档生成接口请求代码效率和准确性都非常高。提示Swagger上线时一定要关闭。生产环境暴露接口文档存在安全隐患我在配置里用Profile控制只有开发环境才开启Swagger。9. 部署运维与实测性能表现代码写完之后真正的考验在部署和运维阶段。这部分内容往往在教科书里被一笔带过但在实际项目里占用的时间比重一点不比写代码少。9.1 服务器规划与部署形态部署形态我选择了最简单的单机加几个基础服务的方案。服务器配置是8核16G内存系统是Ubuntu 20.04Docker运行中间件。Java应用直接打成jar包使用systemd服务管理。部署架构组件部署方式资源配置Spring Boot应用直接运行jar包4GB堆内存MySQLDocker容器容器内数据卷持久化TDengineDocker容器默认配置数据目录挂载RocketMQDocker容器默认配置NginxDocker容器静态资源与反向代理9.2 JVM参数调优Spring Boot应用启动的时候JVM参数设置如下-Xms4g -Xmx4g -XX:UseG1GC -XX:MaxGCPauseMillis1004G的堆内存对这套业务规模足够G1GC保证GC停顿可控。设备接入和数据入库的线程池参数也单独做了配置Netty的boss线程数设置为cpu核心数worker线程数设置为核心数的两倍。这里有一个很容易踩的坑如果你的服务器内存只有8G给Java应用分配4G堆内存剩下的内存还要给MySQL、TDengine、RocketMQ、Nginx用内存分配会很紧张。我给部署机器预留了内存规划让四个核心中间件各有弹性空间避免一个组件内存溢出拖垮整个机器。9.3 实测性能数据系统跑起来之后我做了几组性能测试数据对实验室场景完全够用这里列几个关键指标供参考。指标测试结果说明设备接入数2000 长连接实验室实测场景几十台远未到瓶颈遥测数据写入吞吐约20000条/秒批量写入TDengineAPI响应时间P99在200ms以内常规查询接口历史聚合查询10亿条数据聚合查询1秒以内基于TDengine预聚合告警推送延迟从产生到前端展示约2秒含消息链路和规则判断实际运行过程中系统的CPU占用率平均在30%左右内存稳定在5G上下。对于Lab518这类实验室项目这个性能表现是绰绰有余的而且还有比较大的性能冗余空间如果未来接入更多设备扩容路径也已经预留好了。10. 一路走过来遇到的那些坑做这类系统踩坑才是最有价值的经验积累。我挑几个印象深刻的记录下来给大家提个醒。10.1 Netty内存泄漏排查第一个坑发生在设备接入服务刚上线的时候。运行一段时间后内存占用缓慢上涨怀疑是内存泄漏。因为Netty使用堆外内存直接内存导致的内存泄漏用常规jmap不容易看到排查起来比较费劲。排查思路先用jstat -gcutil观察GC情况发现老年代在持续增长。再通过jmap -dump导出堆转储用MAT分析发现大量DefaultByteBufHolder对象没有被释放。再检查代码发现是在协议解析器的channelRead里有异常路径没有调用ReferenceCountUtil.release(msg)导致ByteBuf引用计数泄漏。修复方式很简单把消息处理改成try-finally结构确保每个报文在消费完之后释放引用。同时把Netty的ALLOCATOR设置为PooledByteBufAllocator.DEFAULT并开启-Dio.netty.leakDetection.levelparanoid及时捕获泄漏对象。10.2 时区问题导致数据错乱有一次发现告警时间和实际时间差了好几个小时排查后发现是TDengine时区配置的问题。TDengine默认使用UTC时间而应用服务器使用的是东八区时间。写入数据的时候时间戳虽然看起来是对的但是TDengine内部存储的是UTC查询时如果不做时区转换展示出来的数据就偏了。解决方案是在TDengine初始化连接串里加上时区参数并且在应用层统一使用同一个时区工具类处理所有时间转换。从那以后所有涉及时间的字段我在代码里强制使用ZonedDateTime不在任何地方使用不带时区的本地时间。10.3 设备连接不稳定的检测与自动恢复设备连接不稳定这个坑在实验室环境里尤其明显。设备跑电测试的时候会掉电重启如果平台不能自动重连每次都需要人工恢复运维成本很高。我在Netty网关里实现了完整的断线重连机制。客户端设备侧在TCP层做了一个心跳监测器当超过30秒没有收到服务端响应主动断开连接并重连。服务端这边每60秒检查一次设备连接的空闲状态对超过90秒无数据交互的连接主动关闭释放资源。每次重连成功之后服务端自动触发一次全量数据同步机制向设备请求当前全部状态参数保证平台数据和设备实际状态一致。这套机制上线之后设备断电恢复后无需人工干预平台自动恢复数据同步。11. 这个项目还能怎么继续演进目前这套平台在Lab518已经稳定运行了一个阶段日常的数据采集、告警监控、远程控制、报表分析功能都正常。不过作为一套面向科研场景的储能平台我觉得它还有几个非常值得演进的方向。储能平台的数据质量直接影响上层算法和策略的研究结论。下一步我计划在数据接入层增加数据清洗和质量评估模块对异常值、缺测值做标记和插值处理保证进入分析层的数据是干净可用的。控制策略智能化是另一个重要的演进方向。当前平台还是人工设置充放电策略为主后续可以接入基于深度学习或强化学习的电池充放电控制算法平台提供策略下发和效果跟踪的闭环机制。这个方向上现有的控制链路设计和双重确认机制已经选好了底子扩展起来路径是通的。多平台联动和数据共享也值得考虑。多个实验室或不同校区的储能设备可以通过平台进行统一调度和数据汇总实现更宏观层面的能量管理研究。这就需要把现有的设备接入能力做成标准化的服务对外提供数据接入API让其他平台也能基于这套架构扩展。储能平台这类项目技术的复杂度不在于某一个点有多深而在于把设备、数据、控制、业务、展示整条链路串起来每一个环节都不能有明显的短板。Java生态在接口开发、业务建模、领域设计上的成熟经验配合Netty解决设备通信、TDengine解决时序数据整个技术组合是经得起实际考验的。希望这篇内容对准备做能源物联网项目后端开发的同学有所启发也欢迎大家在实际落地时多交流踩坑体验。本文还有配套的精品资源点击获取