简介在工业物联网与能源管理系统中设备协议多样、数据吞吐量大、控制指令安全要求高是后端开发的核心挑战。通过分层架构与适配器模式可统一接入Modbus、MQTT及自定义TCP协议实现设备数据稳定采集借助Redis最新值缓存与MySQL按天分表完成高并发时序数据的存储与查询独立策略引擎与告警规则引擎则保障了储能充放电调度与安全监控。这套设计不仅适用于储能平台也可扩展至微电网、充电桩等场景。以Java生态的Spring Boot框架为例分享一个储能管理平台从架构设计、源码结构到性能优化的完整落地实践。 大概两年前我接手了Lab518储能平台的后端从零到一开发需求很直接用Java写后端把实验室里那套磷酸铁锂储能柜和BMS、PCS、环境传感器全接进来做成一个能看数据、能定策略、能下发充放电指令的Web管理平台。当时团队里有人建议用Python有人建议直接用开源EMG系统改最后还是定了JavaSpring Boot这套方案现在源码也在持续更新。这中间踩过不少坑也积累了一些储能领域后端设计的实操经验这篇就把整个项目的设计思路、核心源码结构和关键实现梳理一遍给正在做类似能源管理平台的Java后端同学一个参考。我尽量把平台涉及到的设备接入、数据采集、策略调度、告警引擎这些模块讲清楚也会把每个关键设计背后的理由和踩坑过程说出来。不论你是在做储能、微电网、充电桩还是其他IoT类后端这套设计思路基本都能复用。1. 项目背景与整体设计思虑Lab518储能平台到底在做什么1.1 储能平台的业务边界与核心需求Lab518这套平台业务范围一句话就能说清围绕一组储能电池柜把“实时监控-策略计算-指令下发-数据分析”这条链路完整跑通。具体拆开是四件事。第一设备接入BMS会实时上报电芯电压、温度、电流、SOC、SOH这些数据PCS则负责执行充放电指令另外还有环境传感器监测柜内温湿度和烟雾。第二数据存储与展示所有采集数据要落库前端要能实时看到曲线、表格和告警列表。第三策略调度用户可以在后台配置峰谷套利、削峰填谷或者手动充放电策略系统按策略自动给PCS下发功率指令。第四告警与安全电池温度过高、SOC越限、通信断线都要能及时告警并且支持规则自定义。这些需求听上去不复杂但真正做起来有几个坑。一个是协议特别杂BMS走Modbus TCPPCS有自定义协议环境传感器走MQTT等于后端要同时处理多种协议栈。另一个是数据量大BMS每秒钟会上报几十上百个测点如果每个测点都直接插库数据库很容易被打爆。还有一个是策略可靠性的问题策略判断错了可能导致电池过充过放这是要命的事。所以后端设计的第一原则不是功能丰富而是分层清晰、采集稳定、策略可控。这也是我在做整体架构时优先考虑的点。1.2 技术选型为什么是Java Spring Boot团队里有人问过为什么不用Python做采集或者直接用Node.js做全栈。我的理由有三点。第一Java生态在设备接入和数据处理这块有天然优势。Netty处理TCP长连接、Modbus协议解析库、MQTT客户端实现都很成熟Spring Boot对多数据源、定时任务、WebSocket支持也开箱即用。储能平台最核心的诉求是稳定长跑Java在内存管理和长时间运行方面比Python脚本更可控比Node.js更适合做复杂业务状态管理。第二团队的技术栈匹配。Lab518项目后续会不断扩展功能比如新增设备类型、接入更多储能柜、对接实验室的能耗管理系统Java后端在人员上手成本和维护性上更有优势。招聘一个熟悉Spring Boot的后端工程师比找一个既懂Python又懂Java还懂储能业务的复合型人才容易得多。第三源码可控性。储能平台涉及功率控制和安全策略不能完全依赖闭源商业软件自研后端意味着每个判断逻辑都能审计、能测试、能快速修复。Java项目的分层结构天然适合这种需要严格把控的领域。选型确定之后核心依赖大概是Spring Boot 2.7.x MyBatis-Plus MySQL 8.0 Redis Netty MQTT客户端Eclipse Paho XXL-Job可选也可以用Spring原生SchedulerJDK用的17。1.3 整体架构分层思路我把整个系统拆成了四层各层职责尽量不重叠。第一层是接入层。统一抽象了ChannelAdapter接口Modbus、MQTT、自定义TCP协议各自实现一套Adapter。上层业务关心的只是“拿到一个设备的数据点”至于数据来自哪种协议接入层自己消化掉。这样做的好处是后续新增一种设备协议不需要动业务代码只加一个Adapter实现。第二层是服务层。包括设备管理、测点管理、实时数据聚合、历史数据查询、策略引擎、告警规则引擎。策略引擎和告警引擎是独立的因为它们的触发频率和业务稳定性要求不同混在一起容易互相影响。第三层是存储层。MySQL负责元数据设备表、测点表、用户表、策略表和告警记录Redis负责实时缓存最新一条测点值、设备在线状态历史时序数据也落MySQL但做了按天分表处理。没有引入专门的时序数据库比如InfluxDB、TDengine是因为Lab518的数据规模还没到那个量级MySQL按天分表完全够用降低部署复杂度。第四层是接口层。提供RESTful API给前端Web管理平台同时通过WebSocket推送实时数据这样前端页面不用轮询就能刷新曲线和告警。这个分层设计的核心是设备接入与业务解耦数据读写分离策略引擎独立可控。到现在为止这套架构已经稳定运行很长一段时间没有出现过需要推倒重来的问题。2. 核心模块拆解从设备接入到能量调度的完整链路2.1 设备接入层Modbus TCP、MQTT和自定义协议的统一处理Lab518的设备接入场景比较典型BMS和PCS都在机房内网通过IP直接访问环境传感器走MQTT主题订阅。三种接入方式对应的技术实现差别很大。先看Modbus TCP接入。BMS作为Modbus Server后端作为Client去轮询寄存器。设备厂商给的寄存器表通常是这样的格式寄存器地址数据类型系数说明0x0100Uint160.1总电压0x0102Int160.01总电流正为充电0x0108Uint160.1SOC0x010AUint160.1SOH0x0110Float321.0最高单体温度这里有个非常容易被坑的点Modbus寄存器地址在协议文档里写的往往是“0x0100”这种PLC地址但实际用Modbus4J或jamod库请求时需要减1变成协议地址因为协议层地址从0开始。Lab518早期接入BMS时因为寄存器地址偏移问题读出来的电压差了一倍排查了半天。实现上我封装了一个ModbusMasterManager管理每个设备的连接和轮询任务。核心逻辑是每个设备对应一个独立连接轮询周期按数据实时性要求配置BMS的电压电流温度这类核心数据1秒轮询一次非核心数据5秒轮询一次。连接断开时自动重连重连失败超过3次就触发告警。再来看MQTT接入。环境传感器数据走的是EMQX Broker后端用Eclipse Paho订阅/sensor//data主题通过通配符接收不同设备的数据。MQTT部分最需要注意的是QoS等级和遗嘱消息传感器断线时通过遗嘱消息通知后端更新设备在线状态这块很多新手会忽略。自定义TCP协议主要用于PCS控制。PCS作为TCP Server等待连接后端发送指令帧PCS返回应答帧。帧格式一般是帧头长度命令字数据体CRC校验。我封装了PcsTcpClient内部维护一个Channel发送指令时加锁避免消息交错超时5秒没有应答就要重试。三种协议统一后对外暴露的接口很简单public interface ChannelAdapter { void start(); void stop(); ListPointValue readPoints(ListDevicePoint points); boolean writePoint(DevicePoint point, Object value); boolean isOnline(); }业务层拿到ListPointValue统一处理不用关心数据来源。这也是整个接入层设计最值得借鉴的部分新增一种协议设备时工作量基本控制在一到两个类。2.2 数据采集与存储时序数据的建模方式设备接进来之后最大的问题是数据怎么存。BMS一秒钟上报几十个测点一个设备跑一天就是几十万条数据如果全量存MySQL单表几个月后查询就废了。我的做法是用“最新值缓存”加“历史值分表”组合方案。最新值直接写Rediskey的设计是device:point:latest:{deviceId}:{pointId}value是当前值时间戳。前端页面实时展示仪表盘数据时全部走Redis不查数据库响应时间基本在毫秒级。历史值落MySQL但做了按天分表表名如energy_data_20250320每天一个表。写入时用MyBatis-Plus的批量插入配合JDBC连接串加上rewriteBatchedStatementstrue参数一次批量插入500条左右实测写入效率提升非常明显。表结构设计如下CREATE TABLE energy_data_20250320 ( id bigint NOT NULL AUTO_INCREMENT, device_id varchar(32) NOT NULL COMMENT 设备ID, point_id varchar(64) NOT NULL COMMENT 测点ID, point_value decimal(10,3) NOT NULL COMMENT 测点值, collect_time datetime NOT NULL COMMENT 采集时间, PRIMARY KEY (id), KEY idx_device_point_time (device_id, point_id, collect_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;查询历史曲线时先根据时间范围算好表名再执行查询配合联合索引(device_id, point_id, collect_time)即使查一个月的数据也能控制在秒级返回。分表逻辑统一封装在DynamicTableNameHandler里业务层不用关心物理表名。这里有一个很重要的经验不要在采集热路径里做复杂的聚合计算。比如前端要展示电池组平均温度不要现查再算而是在写入时把聚合结果冗余存储到另一个redis key里App层直接取。采集链路追求的是快业务查询追求的是准两者要分开。2.3 充放电策略与调度引擎的设计与实现储能平台最核心的业务逻辑就是策略调度。Lab518支持的策略包括手动模式、定时充放电模式、峰谷套利模式。每种模式都由策略引擎统一调度。策略引擎的设计采用“策略定义定时触发执行校验”三段式。策略定义存在MySQL策略表里字段包括策略类型、启停时间、功率上限、目标SOC等。定时触发用Spring的Scheduled实现每个策略类型一个任务每分钟检查一次当前时间是否在策略生效窗口内。执行校验是绝对不能省的一步。每次下发充放电指令前必须做以下校验当前设备是否在线、是否有告警。当前SOC是否在安全范围内过放保护阈值以下不允许继续放电。目标功率是否超过PCS额定功率和策略限制功率取两者最小值。最近一次指令下发时间是否达到最小间隔要求避免频繁抖动。比如峰谷套利策略的判断逻辑简化成代码大致是这样if (strategy.getType() StrategyType.PEAK_VALLEY) { LocalTime now LocalTime.now(); if (strategy.isPeakWindow(now)) { // 峰段放电功率不能超过PCS额定功率和SOC放完上限 double targetPower Math.min(pcsRatedPower, strategy.getMaxDischargePower()); if (batterySoc strategy.getDischargeStopSoc()) { pcsClient.setPower(targetPower, PowerMode.DISCHARGE); } } else if (strategy.isValleyWindow(now)) { // 谷段充电 double targetPower Math.min(pcsRatedPower, strategy.getMaxChargePower()); if (batterySoc strategy.getChargeStopSoc()) { pcsClient.setPower(targetPower, PowerMode.CHARGE); } } }实际生产环境还要把“上次指令时间”和“最小间隔”缓存到Redis防止并发触发重复下发。我在Lab518初期就踩过一次坑两个定时任务同时命中策略窗口给PCS发了两条互相矛盾的指令导致PCS报错。后来所有指令下发都经过CommandGate单线程处理彻底避免了指令竞态。3. 工程实现源码结构、核心模块与数据库设计3.1 Maven多模块工程结构Lab518后端源码用的是Maven多模块结构按业务边界拆模块而不是按技术层拆。工程结构大概是lab518-ems ├── ems-common // 公共工具类、统一返回结构、异常定义 ├── ems-framework // 框架配置Spring Boot启动、安全、Redis配置 ├── ems-system // 系统管理用户、角色、菜单、操作日志 ├── ems-device // 设备管理设备信息、测点管理、协议适配 ├── ems-data // 数据服务采集、存储、历史查询、聚合 ├── ems-alarm // 告警中心规则配置、告警记录、通知 ├── ems-strategy // 策略引擎策略管理、调度、指令下发 └── ems-admin // Web接口层RESTful API、WebSocket推送模块拆分的原则是底层模块不依赖上层模块比如ems-device不依赖ems-alarm告警模块依赖设备模块的接口来查询设备状态。这样后续如果要把告警中心拆成独立服务成本很低。每个模块内部的包结构也做了规范。controller只做参数校验和结果封装service写业务逻辑mapper只做数据访问。领域对象用DTO/VO区分不直接拿数据库实体暴露给前端。3.2 关键源码解析设备状态聚合与告警规则引擎设备状态聚合这块我在Lab518里做了一个比较实用的设计用一个DeviceStatusAggregator组件定时把所有设备的最新状态汇总到Redis里包括在线状态、最近采集时间、最新告警级别、核心测点值。前端页面设备列表不用逐个查库直接取聚合后的HashMap。Component Slf4j public class DeviceStatusAggregator { private final StringRedisTemplate redisTemplate; private final DeviceMapper deviceMapper; // 每10秒刷新一次设备状态缓存 Scheduled(fixedRate 10000) public void aggregate() { ListDevice devices deviceMapper.selectList(null); MapString, Object statusMap new HashMap(); for (Device device : devices) { MapString, Object status new HashMap(); status.put(online, isOnline(device.getId())); status.put(lastCollectTime, getLastCollectTime(device.getId())); status.put(maxAlarmLevel, getMaxAlarmLevel(device.getId())); statusMap.put(device.getId(), status); } redisTemplate.opsForValue().set(device:status:all, JSON.toJSONString(statusMap)); } }这里用固定频率刷新而不是实时更新是为了减少Redis写次数。设备数量少10秒刷新一次足够。告警规则引擎是我自己写的一个轻量级规则引擎没有引第三方规则引擎框架因为储能场景的告警规则相对固定表达式解析用不上那么重的框架。规则由用户配置存的格式是一个JSON对象{ deviceType: BMS, pointCode: temperature_max, condition: , threshold: 55, alarmLevel: URGENT, alarmDuration: 10 }引擎每秒从Redis取最新值如果某个测点连续超过阈值10秒alarmDuration就生成一条告警记录。加持续时间限制是为了防止瞬时毛刺误报这也是实际运行中积累的重要经验。早期没有这个限制BMS通信偶发了一次错误数据导致温度告警刷了一大片后来查了日志才发现是噪声数据。3.3 数据库表设计核心点Lab518的数据库一共有十几张表核心表包括表名用途关键字段device_info设备基础信息id, name, type, protocol, ip, port, statusdevice_point设备测点定义id, device_id, code, name, address, data_type, ratio, unitdevice_alarm_rule告警规则表device_type, point_code, condition, threshold, levelalarm_record告警记录表device_id, rule_id, alarm_content, level, status, alarm_timestrategy_info策略定义表name, type, status, params(JSON), create_timeenergy_data_{yyyyMMdd}每日数据表device_id, point_id, point_value, collect_timesys_user用户表username, password, nickname, status有一张表我想特别说一下就是device_point表。这张表是设备接入和展示层的核心枢纽。每接入一台设备需要把该设备所有的测点解析规则配到这表里比如Modbus寄存器地址、数据类型、缩放系数。采集程序只管按这里的配置去读寄存器读回来的原始值乘上系数就是真实物理量。这样后续新增设备无需改代码只要在后台配测点。这个设计借鉴了IoT平台物模型思路但比物模型轻量很多非常适合中小型储能/能源管理项目。4. 实战中的性能优化与问题排查实录4.1 高并发采集数据入库优化从单条插入到批量合并Lab518上线初期设备数量还没那么多时单条插入没啥问题。随着接入设备增加、采集频率提高MySQL开始出现CPU占用高、插入延迟的情况。慢查询日志一查全是INSERT语句。优化方案分了三步。第一步是JDBC连接串开启批量插入优化jdbc:mysql://localhost:3306/lab518?useSSLfalserewriteBatchedStatementstrue这个参数会让MyBatis-Plus的批量插入真正走JDBC的addBatch/executeBatch而不是一条一条执行。实测插入500条数据从800ms降到了150ms左右。第二步是引入队列缓冲。采集线程不是直接落库而是把PointValue对象丢到内存队列里单独一个入库线程每2秒或者积攒500条再批量写入。这样即使采集瞬时峰值很高数据库压力也很平稳。第三步是启动定时任务在凌晨低峰期把当天分表的数据做分区整理和统计汇总进一步降低高峰期的查询压力。必须强调缓存和批量中间件虽然好用但要注意丢数据风险。Lab518的做法是队列消费失败时把数据丢到Redis的失败重试列表下次启动时补偿写入。对于实时监控场景偶尔丢几条历史数据可以接受但关键测点数据不能丢。4.2 Netty连接断线重连与线程池优化PCS自定义TCP协议这路早期经常出现连接断掉以后不再重连的情况。排查后发现是ChannelInactive事件处理逻辑有问题连接断开后只是打了一条日志没有触发重连。修正后的方案是在Handler里统一处理ChannelInactive和ExceptionCaught触发重连前先关闭旧Channel、清理资源然后启动一个延迟任务做重连。重连次数超过3次就告警并且进入“设备离线”状态。线程池方面我最初用了默认的FixedThreadPool去处理所有设备指令后来发现PCS的指令响应超时会把整个线程池堵死其他设备的指令全部排不上。现在的做法是按设备拆分线程池每台设备一个独立线程池池大小根据设备并发量配置一般2~4个线程另外用一个全局调度线程池处理定时任务两者隔离互不影响。4.3 慢查询与接口超时排查实录有一个典型的接口超时案例前端页面加载某天全部历史曲线数据量大概十几万条查询耗时接近10秒页面直接转圈。分析执行计划发现分表后虽然命中了正确的表但联合索引没有建走了全表扫描。解决办法是在分表建表时统一加上联合索引idx_device_point_time同时把历史曲线接口改成按测点分批查询前端分多次请求每批数据量控制在1万条以内单批查询时间控制在500ms左右用户体验反而更好。另外对温度、电压等高频测点数据做了降采样前端展示时按5分钟粒度聚合而不是原始秒级数据曲线照样平滑查询量少了一大截。另一个排查经验是接口偶发卡顿。最终定位到是Redis连接池默认配置太低高峰时连接被耗尽新请求排队等待。把连接池最大连接数从8调到了64并加了连接池空闲检测参数问题解决。这里建议所有用Redis做缓存的项目上线前一定要做压测不要用默认配置。5. 部署启动与运维实践5.1 环境依赖与配置文件设计Lab518后端部署依赖JDK 17、MySQL 8.0、Redis 6.x、EMQX 4.xMQTT Broker。所有配置都放在application.yml里不同的环境local、dev、prod通过application-{profile}.yml区分。配置文件里几个关键点需要注意。第一个是MySQL连接串必须开启时区指定和时间戳参数spring: datasource: url: jdbc:mysql://localhost:3306/lab518?useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrue username: root password: ${DB_PASSWORD} hikari: maximum-pool-size: 20 minimum-idle: 5第二个是密码不能硬编码。我用了Jasypt对数据库密码和Redis密码做加密启动时通过--jasypt.encryptor.password参数传入解密密钥。密钥本身放在环境变量里不进代码仓库。第三个是定时任务的开关要可控。Lab518里所有策略调度任务都通过配置项控制启停比如strategy.schedule.enabled这样运维要暂时停掉调度时不用改代码重启。5.2 Docker Compose一键启动为了让实验室其他同学能快速拉起整套环境我写了Docker Compose编排文件把MySQL、Redis、EMQX和后端服务一次性启动version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: lab518 MYSQL_DATABASE: lab518 ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql redis: image: redis:6.2 ports: - 6379:6379 emqx: image: emqx/emqx:4.4.3 ports: - 1883:1883 - 18083:18083 ems-backend: build: . depends_on: - mysql - redis - emqx environment: SPRING_PROFILES_ACTIVE: prod DB_PASSWORD: lab518 ports: - 8080:8080启动命令很简单docker-compose up -d。前端项目单独跑在Nginx里通过反向代理把/api转发到后端8080端口跨域问题在Nginx层解决后端不做跨域放行安全上更可控。5.3 日志监控与告警通知日志方面我用了Logback按天滚动error级别单独输出到error.log方便定位线上问题。启动参数里加了-Xms512m -Xmx1024m避免容器内存过大导致宿主机资源紧张。告警通知渠道目前接的是邮件和WebSocket。规则命中后告警引擎会异步发送邮件同时通过WebSocket推送给前端页面。邮件发送走的是Spring Mail异步线程池不能阻塞主流程。短信和企业微信机器人这类通道没有接因为Lab518场景暂时用不上但代码里预留了NotifyChannel接口后续扩展很方便。运维上还有一个实用工具写了个接口/actuator/health配合Spring Boot Actuator做健康检查Docker Compose和监控系统可以直接用它判断服务存活状态。最后再分享两个小技巧Lab518这套后端做下来我个人感受最深的一点是储能这类工业控制场景的后端稳定性优先级永远高于功能优先级。采集链路要尽量简单直接策略下发要有校验有兜底数据库写入要有缓冲有降级。宁可少一些花哨功能也不能出现指令冲突或者数据丢失。第一个小技巧设备接入时一定要把所有协议文档里的寄存器地址、数据类型、大小端说明整理成一份统一格式的Excel然后导入到device_point表。后面所有协议解析都基于这份配置不再看厂商PDF文档。这套办法帮我们省了大量联调时间强烈推荐。第二个小技巧给每条指令下发加上traceId串起“策略触发-指令生成-PCS应答-设备执行”完整链路。排查问题时直接按traceId搜日志不然多台设备同时运行时很难定位是哪条指令出了问题。另外源码里注释我尽量写得比较详细因为实验室项目可能每年都有新同学接手代码的可读性和交接成本比商业项目更值得关注。项目本身的扩展方向也挺多比如接入更多储能柜、加AI负荷预测、对接实验室能耗大屏这些Base架构都已经预留了扩展点后面继续迭代时改动成本不会太大。本文还有配套的精品资源点击获取
Java+Spring Boot储能平台后端实战：从设备接入到策略调度
简介在工业物联网与能源管理系统中设备协议多样、数据吞吐量大、控制指令安全要求高是后端开发的核心挑战。通过分层架构与适配器模式可统一接入Modbus、MQTT及自定义TCP协议实现设备数据稳定采集借助Redis最新值缓存与MySQL按天分表完成高并发时序数据的存储与查询独立策略引擎与告警规则引擎则保障了储能充放电调度与安全监控。这套设计不仅适用于储能平台也可扩展至微电网、充电桩等场景。以Java生态的Spring Boot框架为例分享一个储能管理平台从架构设计、源码结构到性能优化的完整落地实践。 大概两年前我接手了Lab518储能平台的后端从零到一开发需求很直接用Java写后端把实验室里那套磷酸铁锂储能柜和BMS、PCS、环境传感器全接进来做成一个能看数据、能定策略、能下发充放电指令的Web管理平台。当时团队里有人建议用Python有人建议直接用开源EMG系统改最后还是定了JavaSpring Boot这套方案现在源码也在持续更新。这中间踩过不少坑也积累了一些储能领域后端设计的实操经验这篇就把整个项目的设计思路、核心源码结构和关键实现梳理一遍给正在做类似能源管理平台的Java后端同学一个参考。我尽量把平台涉及到的设备接入、数据采集、策略调度、告警引擎这些模块讲清楚也会把每个关键设计背后的理由和踩坑过程说出来。不论你是在做储能、微电网、充电桩还是其他IoT类后端这套设计思路基本都能复用。1. 项目背景与整体设计思虑Lab518储能平台到底在做什么1.1 储能平台的业务边界与核心需求Lab518这套平台业务范围一句话就能说清围绕一组储能电池柜把“实时监控-策略计算-指令下发-数据分析”这条链路完整跑通。具体拆开是四件事。第一设备接入BMS会实时上报电芯电压、温度、电流、SOC、SOH这些数据PCS则负责执行充放电指令另外还有环境传感器监测柜内温湿度和烟雾。第二数据存储与展示所有采集数据要落库前端要能实时看到曲线、表格和告警列表。第三策略调度用户可以在后台配置峰谷套利、削峰填谷或者手动充放电策略系统按策略自动给PCS下发功率指令。第四告警与安全电池温度过高、SOC越限、通信断线都要能及时告警并且支持规则自定义。这些需求听上去不复杂但真正做起来有几个坑。一个是协议特别杂BMS走Modbus TCPPCS有自定义协议环境传感器走MQTT等于后端要同时处理多种协议栈。另一个是数据量大BMS每秒钟会上报几十上百个测点如果每个测点都直接插库数据库很容易被打爆。还有一个是策略可靠性的问题策略判断错了可能导致电池过充过放这是要命的事。所以后端设计的第一原则不是功能丰富而是分层清晰、采集稳定、策略可控。这也是我在做整体架构时优先考虑的点。1.2 技术选型为什么是Java Spring Boot团队里有人问过为什么不用Python做采集或者直接用Node.js做全栈。我的理由有三点。第一Java生态在设备接入和数据处理这块有天然优势。Netty处理TCP长连接、Modbus协议解析库、MQTT客户端实现都很成熟Spring Boot对多数据源、定时任务、WebSocket支持也开箱即用。储能平台最核心的诉求是稳定长跑Java在内存管理和长时间运行方面比Python脚本更可控比Node.js更适合做复杂业务状态管理。第二团队的技术栈匹配。Lab518项目后续会不断扩展功能比如新增设备类型、接入更多储能柜、对接实验室的能耗管理系统Java后端在人员上手成本和维护性上更有优势。招聘一个熟悉Spring Boot的后端工程师比找一个既懂Python又懂Java还懂储能业务的复合型人才容易得多。第三源码可控性。储能平台涉及功率控制和安全策略不能完全依赖闭源商业软件自研后端意味着每个判断逻辑都能审计、能测试、能快速修复。Java项目的分层结构天然适合这种需要严格把控的领域。选型确定之后核心依赖大概是Spring Boot 2.7.x MyBatis-Plus MySQL 8.0 Redis Netty MQTT客户端Eclipse Paho XXL-Job可选也可以用Spring原生SchedulerJDK用的17。1.3 整体架构分层思路我把整个系统拆成了四层各层职责尽量不重叠。第一层是接入层。统一抽象了ChannelAdapter接口Modbus、MQTT、自定义TCP协议各自实现一套Adapter。上层业务关心的只是“拿到一个设备的数据点”至于数据来自哪种协议接入层自己消化掉。这样做的好处是后续新增一种设备协议不需要动业务代码只加一个Adapter实现。第二层是服务层。包括设备管理、测点管理、实时数据聚合、历史数据查询、策略引擎、告警规则引擎。策略引擎和告警引擎是独立的因为它们的触发频率和业务稳定性要求不同混在一起容易互相影响。第三层是存储层。MySQL负责元数据设备表、测点表、用户表、策略表和告警记录Redis负责实时缓存最新一条测点值、设备在线状态历史时序数据也落MySQL但做了按天分表处理。没有引入专门的时序数据库比如InfluxDB、TDengine是因为Lab518的数据规模还没到那个量级MySQL按天分表完全够用降低部署复杂度。第四层是接口层。提供RESTful API给前端Web管理平台同时通过WebSocket推送实时数据这样前端页面不用轮询就能刷新曲线和告警。这个分层设计的核心是设备接入与业务解耦数据读写分离策略引擎独立可控。到现在为止这套架构已经稳定运行很长一段时间没有出现过需要推倒重来的问题。2. 核心模块拆解从设备接入到能量调度的完整链路2.1 设备接入层Modbus TCP、MQTT和自定义协议的统一处理Lab518的设备接入场景比较典型BMS和PCS都在机房内网通过IP直接访问环境传感器走MQTT主题订阅。三种接入方式对应的技术实现差别很大。先看Modbus TCP接入。BMS作为Modbus Server后端作为Client去轮询寄存器。设备厂商给的寄存器表通常是这样的格式寄存器地址数据类型系数说明0x0100Uint160.1总电压0x0102Int160.01总电流正为充电0x0108Uint160.1SOC0x010AUint160.1SOH0x0110Float321.0最高单体温度这里有个非常容易被坑的点Modbus寄存器地址在协议文档里写的往往是“0x0100”这种PLC地址但实际用Modbus4J或jamod库请求时需要减1变成协议地址因为协议层地址从0开始。Lab518早期接入BMS时因为寄存器地址偏移问题读出来的电压差了一倍排查了半天。实现上我封装了一个ModbusMasterManager管理每个设备的连接和轮询任务。核心逻辑是每个设备对应一个独立连接轮询周期按数据实时性要求配置BMS的电压电流温度这类核心数据1秒轮询一次非核心数据5秒轮询一次。连接断开时自动重连重连失败超过3次就触发告警。再来看MQTT接入。环境传感器数据走的是EMQX Broker后端用Eclipse Paho订阅/sensor//data主题通过通配符接收不同设备的数据。MQTT部分最需要注意的是QoS等级和遗嘱消息传感器断线时通过遗嘱消息通知后端更新设备在线状态这块很多新手会忽略。自定义TCP协议主要用于PCS控制。PCS作为TCP Server等待连接后端发送指令帧PCS返回应答帧。帧格式一般是帧头长度命令字数据体CRC校验。我封装了PcsTcpClient内部维护一个Channel发送指令时加锁避免消息交错超时5秒没有应答就要重试。三种协议统一后对外暴露的接口很简单public interface ChannelAdapter { void start(); void stop(); ListPointValue readPoints(ListDevicePoint points); boolean writePoint(DevicePoint point, Object value); boolean isOnline(); }业务层拿到ListPointValue统一处理不用关心数据来源。这也是整个接入层设计最值得借鉴的部分新增一种协议设备时工作量基本控制在一到两个类。2.2 数据采集与存储时序数据的建模方式设备接进来之后最大的问题是数据怎么存。BMS一秒钟上报几十个测点一个设备跑一天就是几十万条数据如果全量存MySQL单表几个月后查询就废了。我的做法是用“最新值缓存”加“历史值分表”组合方案。最新值直接写Rediskey的设计是device:point:latest:{deviceId}:{pointId}value是当前值时间戳。前端页面实时展示仪表盘数据时全部走Redis不查数据库响应时间基本在毫秒级。历史值落MySQL但做了按天分表表名如energy_data_20250320每天一个表。写入时用MyBatis-Plus的批量插入配合JDBC连接串加上rewriteBatchedStatementstrue参数一次批量插入500条左右实测写入效率提升非常明显。表结构设计如下CREATE TABLE energy_data_20250320 ( id bigint NOT NULL AUTO_INCREMENT, device_id varchar(32) NOT NULL COMMENT 设备ID, point_id varchar(64) NOT NULL COMMENT 测点ID, point_value decimal(10,3) NOT NULL COMMENT 测点值, collect_time datetime NOT NULL COMMENT 采集时间, PRIMARY KEY (id), KEY idx_device_point_time (device_id, point_id, collect_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;查询历史曲线时先根据时间范围算好表名再执行查询配合联合索引(device_id, point_id, collect_time)即使查一个月的数据也能控制在秒级返回。分表逻辑统一封装在DynamicTableNameHandler里业务层不用关心物理表名。这里有一个很重要的经验不要在采集热路径里做复杂的聚合计算。比如前端要展示电池组平均温度不要现查再算而是在写入时把聚合结果冗余存储到另一个redis key里App层直接取。采集链路追求的是快业务查询追求的是准两者要分开。2.3 充放电策略与调度引擎的设计与实现储能平台最核心的业务逻辑就是策略调度。Lab518支持的策略包括手动模式、定时充放电模式、峰谷套利模式。每种模式都由策略引擎统一调度。策略引擎的设计采用“策略定义定时触发执行校验”三段式。策略定义存在MySQL策略表里字段包括策略类型、启停时间、功率上限、目标SOC等。定时触发用Spring的Scheduled实现每个策略类型一个任务每分钟检查一次当前时间是否在策略生效窗口内。执行校验是绝对不能省的一步。每次下发充放电指令前必须做以下校验当前设备是否在线、是否有告警。当前SOC是否在安全范围内过放保护阈值以下不允许继续放电。目标功率是否超过PCS额定功率和策略限制功率取两者最小值。最近一次指令下发时间是否达到最小间隔要求避免频繁抖动。比如峰谷套利策略的判断逻辑简化成代码大致是这样if (strategy.getType() StrategyType.PEAK_VALLEY) { LocalTime now LocalTime.now(); if (strategy.isPeakWindow(now)) { // 峰段放电功率不能超过PCS额定功率和SOC放完上限 double targetPower Math.min(pcsRatedPower, strategy.getMaxDischargePower()); if (batterySoc strategy.getDischargeStopSoc()) { pcsClient.setPower(targetPower, PowerMode.DISCHARGE); } } else if (strategy.isValleyWindow(now)) { // 谷段充电 double targetPower Math.min(pcsRatedPower, strategy.getMaxChargePower()); if (batterySoc strategy.getChargeStopSoc()) { pcsClient.setPower(targetPower, PowerMode.CHARGE); } } }实际生产环境还要把“上次指令时间”和“最小间隔”缓存到Redis防止并发触发重复下发。我在Lab518初期就踩过一次坑两个定时任务同时命中策略窗口给PCS发了两条互相矛盾的指令导致PCS报错。后来所有指令下发都经过CommandGate单线程处理彻底避免了指令竞态。3. 工程实现源码结构、核心模块与数据库设计3.1 Maven多模块工程结构Lab518后端源码用的是Maven多模块结构按业务边界拆模块而不是按技术层拆。工程结构大概是lab518-ems ├── ems-common // 公共工具类、统一返回结构、异常定义 ├── ems-framework // 框架配置Spring Boot启动、安全、Redis配置 ├── ems-system // 系统管理用户、角色、菜单、操作日志 ├── ems-device // 设备管理设备信息、测点管理、协议适配 ├── ems-data // 数据服务采集、存储、历史查询、聚合 ├── ems-alarm // 告警中心规则配置、告警记录、通知 ├── ems-strategy // 策略引擎策略管理、调度、指令下发 └── ems-admin // Web接口层RESTful API、WebSocket推送模块拆分的原则是底层模块不依赖上层模块比如ems-device不依赖ems-alarm告警模块依赖设备模块的接口来查询设备状态。这样后续如果要把告警中心拆成独立服务成本很低。每个模块内部的包结构也做了规范。controller只做参数校验和结果封装service写业务逻辑mapper只做数据访问。领域对象用DTO/VO区分不直接拿数据库实体暴露给前端。3.2 关键源码解析设备状态聚合与告警规则引擎设备状态聚合这块我在Lab518里做了一个比较实用的设计用一个DeviceStatusAggregator组件定时把所有设备的最新状态汇总到Redis里包括在线状态、最近采集时间、最新告警级别、核心测点值。前端页面设备列表不用逐个查库直接取聚合后的HashMap。Component Slf4j public class DeviceStatusAggregator { private final StringRedisTemplate redisTemplate; private final DeviceMapper deviceMapper; // 每10秒刷新一次设备状态缓存 Scheduled(fixedRate 10000) public void aggregate() { ListDevice devices deviceMapper.selectList(null); MapString, Object statusMap new HashMap(); for (Device device : devices) { MapString, Object status new HashMap(); status.put(online, isOnline(device.getId())); status.put(lastCollectTime, getLastCollectTime(device.getId())); status.put(maxAlarmLevel, getMaxAlarmLevel(device.getId())); statusMap.put(device.getId(), status); } redisTemplate.opsForValue().set(device:status:all, JSON.toJSONString(statusMap)); } }这里用固定频率刷新而不是实时更新是为了减少Redis写次数。设备数量少10秒刷新一次足够。告警规则引擎是我自己写的一个轻量级规则引擎没有引第三方规则引擎框架因为储能场景的告警规则相对固定表达式解析用不上那么重的框架。规则由用户配置存的格式是一个JSON对象{ deviceType: BMS, pointCode: temperature_max, condition: , threshold: 55, alarmLevel: URGENT, alarmDuration: 10 }引擎每秒从Redis取最新值如果某个测点连续超过阈值10秒alarmDuration就生成一条告警记录。加持续时间限制是为了防止瞬时毛刺误报这也是实际运行中积累的重要经验。早期没有这个限制BMS通信偶发了一次错误数据导致温度告警刷了一大片后来查了日志才发现是噪声数据。3.3 数据库表设计核心点Lab518的数据库一共有十几张表核心表包括表名用途关键字段device_info设备基础信息id, name, type, protocol, ip, port, statusdevice_point设备测点定义id, device_id, code, name, address, data_type, ratio, unitdevice_alarm_rule告警规则表device_type, point_code, condition, threshold, levelalarm_record告警记录表device_id, rule_id, alarm_content, level, status, alarm_timestrategy_info策略定义表name, type, status, params(JSON), create_timeenergy_data_{yyyyMMdd}每日数据表device_id, point_id, point_value, collect_timesys_user用户表username, password, nickname, status有一张表我想特别说一下就是device_point表。这张表是设备接入和展示层的核心枢纽。每接入一台设备需要把该设备所有的测点解析规则配到这表里比如Modbus寄存器地址、数据类型、缩放系数。采集程序只管按这里的配置去读寄存器读回来的原始值乘上系数就是真实物理量。这样后续新增设备无需改代码只要在后台配测点。这个设计借鉴了IoT平台物模型思路但比物模型轻量很多非常适合中小型储能/能源管理项目。4. 实战中的性能优化与问题排查实录4.1 高并发采集数据入库优化从单条插入到批量合并Lab518上线初期设备数量还没那么多时单条插入没啥问题。随着接入设备增加、采集频率提高MySQL开始出现CPU占用高、插入延迟的情况。慢查询日志一查全是INSERT语句。优化方案分了三步。第一步是JDBC连接串开启批量插入优化jdbc:mysql://localhost:3306/lab518?useSSLfalserewriteBatchedStatementstrue这个参数会让MyBatis-Plus的批量插入真正走JDBC的addBatch/executeBatch而不是一条一条执行。实测插入500条数据从800ms降到了150ms左右。第二步是引入队列缓冲。采集线程不是直接落库而是把PointValue对象丢到内存队列里单独一个入库线程每2秒或者积攒500条再批量写入。这样即使采集瞬时峰值很高数据库压力也很平稳。第三步是启动定时任务在凌晨低峰期把当天分表的数据做分区整理和统计汇总进一步降低高峰期的查询压力。必须强调缓存和批量中间件虽然好用但要注意丢数据风险。Lab518的做法是队列消费失败时把数据丢到Redis的失败重试列表下次启动时补偿写入。对于实时监控场景偶尔丢几条历史数据可以接受但关键测点数据不能丢。4.2 Netty连接断线重连与线程池优化PCS自定义TCP协议这路早期经常出现连接断掉以后不再重连的情况。排查后发现是ChannelInactive事件处理逻辑有问题连接断开后只是打了一条日志没有触发重连。修正后的方案是在Handler里统一处理ChannelInactive和ExceptionCaught触发重连前先关闭旧Channel、清理资源然后启动一个延迟任务做重连。重连次数超过3次就告警并且进入“设备离线”状态。线程池方面我最初用了默认的FixedThreadPool去处理所有设备指令后来发现PCS的指令响应超时会把整个线程池堵死其他设备的指令全部排不上。现在的做法是按设备拆分线程池每台设备一个独立线程池池大小根据设备并发量配置一般2~4个线程另外用一个全局调度线程池处理定时任务两者隔离互不影响。4.3 慢查询与接口超时排查实录有一个典型的接口超时案例前端页面加载某天全部历史曲线数据量大概十几万条查询耗时接近10秒页面直接转圈。分析执行计划发现分表后虽然命中了正确的表但联合索引没有建走了全表扫描。解决办法是在分表建表时统一加上联合索引idx_device_point_time同时把历史曲线接口改成按测点分批查询前端分多次请求每批数据量控制在1万条以内单批查询时间控制在500ms左右用户体验反而更好。另外对温度、电压等高频测点数据做了降采样前端展示时按5分钟粒度聚合而不是原始秒级数据曲线照样平滑查询量少了一大截。另一个排查经验是接口偶发卡顿。最终定位到是Redis连接池默认配置太低高峰时连接被耗尽新请求排队等待。把连接池最大连接数从8调到了64并加了连接池空闲检测参数问题解决。这里建议所有用Redis做缓存的项目上线前一定要做压测不要用默认配置。5. 部署启动与运维实践5.1 环境依赖与配置文件设计Lab518后端部署依赖JDK 17、MySQL 8.0、Redis 6.x、EMQX 4.xMQTT Broker。所有配置都放在application.yml里不同的环境local、dev、prod通过application-{profile}.yml区分。配置文件里几个关键点需要注意。第一个是MySQL连接串必须开启时区指定和时间戳参数spring: datasource: url: jdbc:mysql://localhost:3306/lab518?useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrue username: root password: ${DB_PASSWORD} hikari: maximum-pool-size: 20 minimum-idle: 5第二个是密码不能硬编码。我用了Jasypt对数据库密码和Redis密码做加密启动时通过--jasypt.encryptor.password参数传入解密密钥。密钥本身放在环境变量里不进代码仓库。第三个是定时任务的开关要可控。Lab518里所有策略调度任务都通过配置项控制启停比如strategy.schedule.enabled这样运维要暂时停掉调度时不用改代码重启。5.2 Docker Compose一键启动为了让实验室其他同学能快速拉起整套环境我写了Docker Compose编排文件把MySQL、Redis、EMQX和后端服务一次性启动version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: lab518 MYSQL_DATABASE: lab518 ports: - 3306:3306 volumes: - ./data/mysql:/var/lib/mysql redis: image: redis:6.2 ports: - 6379:6379 emqx: image: emqx/emqx:4.4.3 ports: - 1883:1883 - 18083:18083 ems-backend: build: . depends_on: - mysql - redis - emqx environment: SPRING_PROFILES_ACTIVE: prod DB_PASSWORD: lab518 ports: - 8080:8080启动命令很简单docker-compose up -d。前端项目单独跑在Nginx里通过反向代理把/api转发到后端8080端口跨域问题在Nginx层解决后端不做跨域放行安全上更可控。5.3 日志监控与告警通知日志方面我用了Logback按天滚动error级别单独输出到error.log方便定位线上问题。启动参数里加了-Xms512m -Xmx1024m避免容器内存过大导致宿主机资源紧张。告警通知渠道目前接的是邮件和WebSocket。规则命中后告警引擎会异步发送邮件同时通过WebSocket推送给前端页面。邮件发送走的是Spring Mail异步线程池不能阻塞主流程。短信和企业微信机器人这类通道没有接因为Lab518场景暂时用不上但代码里预留了NotifyChannel接口后续扩展很方便。运维上还有一个实用工具写了个接口/actuator/health配合Spring Boot Actuator做健康检查Docker Compose和监控系统可以直接用它判断服务存活状态。最后再分享两个小技巧Lab518这套后端做下来我个人感受最深的一点是储能这类工业控制场景的后端稳定性优先级永远高于功能优先级。采集链路要尽量简单直接策略下发要有校验有兜底数据库写入要有缓冲有降级。宁可少一些花哨功能也不能出现指令冲突或者数据丢失。第一个小技巧设备接入时一定要把所有协议文档里的寄存器地址、数据类型、大小端说明整理成一份统一格式的Excel然后导入到device_point表。后面所有协议解析都基于这份配置不再看厂商PDF文档。这套办法帮我们省了大量联调时间强烈推荐。第二个小技巧给每条指令下发加上traceId串起“策略触发-指令生成-PCS应答-设备执行”完整链路。排查问题时直接按traceId搜日志不然多台设备同时运行时很难定位是哪条指令出了问题。另外源码里注释我尽量写得比较详细因为实验室项目可能每年都有新同学接手代码的可读性和交接成本比商业项目更值得关注。项目本身的扩展方向也挺多比如接入更多储能柜、加AI负荷预测、对接实验室能耗大屏这些Base架构都已经预留了扩展点后面继续迭代时改动成本不会太大。本文还有配套的精品资源点击获取
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
