P-01
用户看到的是换电柜，客户面对的是实时 IoT 网络
- 电池身份识别
- SoC / SoH 状态同步
- 设备在线状态
- 柜门控制
- 用户订单
- 账户计费
- 云端通讯
IMPACT
任何一个环节异常，都会直接影响用户体验。
CASE / 2026 · 已脱敏 新能源 · 实时基础设施CODE · GSFA-2026-EV-001
新能源
智能充换电平台
把"找地方充电"，变成 实时调度8 → 3 分钟28 城上线10 万+用户99% 可用性AI 数据决策8 → 3 分钟。
覆盖设备、用户、订单、运营与数据的完整新能源基础设施。
0 城
业务覆盖
0 万+
活跃用户
0 万次/天
日换电请求
0.0%
系统可用性
深圳广州杭州上海成都重庆西安武汉长沙南京苏州宁波厦门福州天津北京青岛济南郑州合肥南昌贵阳昆明南宁佛山东莞无锡温州深圳广州杭州上海成都重庆西安武汉长沙南京苏州宁波厦门福州天津北京青岛济南郑州合肥南昌贵阳昆明南宁佛山东莞无锡温州
01 · PROJECT BACKGROUND真正难的从来不是做一个换电柜，
真正难的从来不是做一个换电柜，
而是让全国所有换电柜同时稳定工作。
客户是一家新能源换电业务运营方，已拥有换电柜设备、电池资源与市场运营团队。 随着业务在 28 个城市扩张，设备开始变成"孤岛"——状态无法实时同步、用户流程复杂、高峰系统不稳定。
REAL-TIME IOT NETWORK 99.2% Uptime
一次换电的背后，是一张实时运行的城市级 IoT 网络。
扫码 → 开柜 → 换电 → 关柜，看似 4 步；系统背后同时在处理电池身份识别、SoC / SoH 同步、柜门控制、订单创建、账户计费、云端通讯。
已有资源
换电柜 · 电池 · 运营团队
已有挑战
设备孤岛 · 状态难同步
高峰风险
指令延迟 · 柜门异常
项目目标
覆盖设备 · 用户 · 订单 · 数据
"真正压垮系统的，不是单个设备，而是规模化增长。"
— 客户方新能源项目负责人 · 项目复盘
02 · WHY GENERIC ADMIN BACKENDS FAILED客户尝试过 IoT 后台、通用 SaaS、设备管理系统，
客户尝试过 IoT 后台、通用 SaaS、设备管理系统，
但真实业务链路会同时压向所有系统。
新能源换电业务，本质上是一个实时基础设施系统。它同时涉及用户、电池、IoT 设备、支付、运维、数据分析与城市级运营。
P-02
真正危险的，是设备开始大规模增长
- 数十万级设备通讯
- 高频实时数据同步
- 高并发订单请求
- 多城市运维管理
IMPACT
高峰时段出现指令延迟、电池状态不同步、柜门响应异常。
P-03
有些设备甚至「不会说话」
- 仅能通电与接收指令
- 无法主动上传状态
- 电池归还无法确认
- 柜门关闭无法确认
IMPACT
业务链路无法形成闭环。
03 · OUR APPROACH我们没有"再做一个后台"，
我们没有"再做一个后台"，
而是把它当作实时基础设施来构建。
把业务难题翻译成系统问题，再翻译成产品形态——这是滚水科技在每个项目里的底层方法论。
DIAGNOSE
把「业务难题」翻译为「系统问题」
调研真实链路、识别瓶颈环节，先明确「哪里在堵」，再决定「建什么」。
MODEL
围绕实时数据建模
把设备 / 用户 / 订单 / 资金流抽象为统一事件模型，作为后续所有系统的共同语言。
DELIVER
可演进的工程交付
MVP → 上线 → 复盘 → 持续演进，配套蓝绿部署、金丝雀发布与可观测体系。
04 · ONE BATTERY SWAP, END-TO-END一次换电，5 个环节，
一次换电，5 个环节，
从「人工经验」走向「实时自动化」。
我们把一个真实用户的完整换电流程（脱敏后）完整跑了一遍，并把每一步映射到一个真实小程序界面。
01
STEP 01
找柜
原始纸质 / 口口相传
新系统门店地图 + 实时柜机状态
02
STEP 02
扫码识别
原始人工判断设备状态
新系统自动校验设备与账户
03
STEP 03
下单支付
原始本地记录 · 易出错
新系统多系统实时同步 · 优惠券 · 微信支付
04
STEP 04
电池识别
原始基础电池读取
新系统SoC / SoH / 循环次数实时回传
05
STEP 05
异常 & 回滚
原始人工介入 · 退款慢
新系统自动预警 + 1–3 工作日自动退款
PEAK-HOUR SCENARIO
晚高峰，大量骑手同时换电——系统必须在极短时间内完成 6 件事。
用户认证
电池识别
设备通讯
订单创建
分佣结算
数据同步
通过私有通讯协议、Kafka 消息队列、异步指令调度与冗余状态判断，平台稳定支撑数十万级日换电请求。
RESULT
换电时间
8 min3 min
-62%
故障处理
4 h16 min
-93%
"以前我们是在管理设备，现在系统开始像城市级能源网络一样运行。"
05 · CAPABILITY CHAINS最终被拆成的 5 条核心能力链路，
最终被拆成的 5 条核心能力链路，
从 IoT 通讯一直延伸到 AI 数据决策。
每一条链路都对应真实运行的子系统，下面的卡片同时呈现界面截图、实时指标与关键设计决策。
STEP 01
IoT 设备实时通讯
IoT 网关 + 私有通讯协议 + MQTT / TCP，实现换电柜实时在线、电池状态同步、指令实时下发与设备状态追踪。
在线设备
0台
心跳延迟
< 200ms
协议类型
MQTT · TCP私有
STEP 02
电池状态智能管理
实时同步 SoC、SoH、电池生命周期与充放电状态，输出电池健康管理、风险识别、生命周期分析与异常预警。
STEP 03
订单与业务系统协同
平台同时是业务运营中台：内置 CRM、商城、活动系统、分销机制与多层权限体系，支撑用户运营、市场裂变、分佣结算与城市级业务扩张。
- CRM · 用户运营
- 商城 · 优惠券 · 活动
- 分销 · 多层分佣
- 城市 · 多区域权限
STEP 04
数据分析 & AI 决策支持
Kafka + ClickHouse + Airflow + BI，输出城市运营分析、用户行为分析、电池调度预测与高峰期换电预测。
STEP 05
实时运维 & 安全体系
自动告警系统、蜜罐与安全扫描、应急响应、蓝绿部署与金丝雀发布—— 最终实现 > 99% 系统可用性，平均故障处理时间从 4 小时缩短到 16 分钟。
可用性
99.2%
MTTR
16min
发布策略
Blue · Canary
告警通道
Webhook · IM
车 / 电 / 柜全要素地理轨迹，支持失联设备秒级定位与运维派单。
QPS · 高峰
30k+
实时事件
Kafka
数据仓
ClickHouse
告警
<1 min
06 · SYSTEM ARCHITECTURE五层架构，把设备 / 数据 / 算法 / 业务 / 应用
五层架构，把设备 / 数据 / 算法 / 业务 / 应用
重新拼回一张实时网络。
架构以 IoT 与数据为底座，业务与算法在中间形成闭环，应用层只负责把能力交给运营和用户。
L5 · Application
应用层
用户平台CRM商城运维后台
── 上行
L4 · Business
业务层
订单系统分佣系统活动运营多城市运营管理
── 上行
L3 · Algorithm
算法层
电池健康分析调度预测风险预警BI 数据分析
── 上行
L2 · Data
数据层
KafkaClickHouseAirflow用户数据 / 电池状态池
── 上行
L1 · IoT Edge
IoT 层
换电柜电池 BMSIoT 网关私有协议 · 实时指令系统
── 上行
↑ 数据 / 状态 上行↓ 指令 / 配置 下发
TECH STACK
KafkaClickHouseAirflowMQTTTCP/PrivateBI StudioBlue/GreenCanary
KEY DECISIONS
- 与硬件厂商联合重构通讯协议，让"无通讯硬件"的旧设备也能形成状态闭环。
- 指令异步调度 + 冗余状态判断，避免高峰指令阻塞。
- 数据层独立化，让算法与 BI 能脱离业务库直接消费。
07 · OUTCOMES
6 个月，把高峰期失败率砍到原来的 1/9。
平台上线后，业务规模、系统稳定性、用户体验三个维度同时上行。
覆盖城市
0 城
+8 城/年
活跃用户
0 万+
MoM +24%
日换电峰值
0 万次
+3.6× YoY
系统可用性
0.0%
↑ 12pp
UPTIME · 12-MONTH
上线后 12 个月的系统可用性变化
迁移前平台上线
峰值 QPS 30k+指令调度延迟 < 200msMTTR 从 4h → 16min
换电耗时
8min3min
-62%
故障处理
240min16min
-93%
在线设备
1200台3284台
+174%
日订单
4.2万32万
+661%
"以前我们是在管理设备，
现在系统开始像城市级能源网络一样运行。
FOR BOILINGWATER
这套实时基础设施可被复用于：
- 充换电站 / 共享车队
- 工业制造 IoT 接入
- 城市级能源调度
- 高并发 LBS 业务平台