智能电表API接口开发指南

做过能耗平台的开发都知道，智能电表API接口是整条数据链路的核心枢纽。电表采集的原始数据经过网关汇聚后，必须通过API才能被上层应用调用。接口设计得好，平台响应快、扩展易、维护省心；设计得烂，三天两头出问题，不是数据丢包就是接口超时。一个2000台电表规模的系统，API每分钟要处理上千次请求，架构没规划好上线**天就崩。

一、接口协议选哪套

协议选型直接决定了系统的兼容性和扩展性。主流方案有三套：

1. RESTful HTTP：最通用的方案，所有编程语言都支持。适合数据量不大、实时性要求不高的场景——比如查历史日电量、拉取月度报表。每次请求一个HTTP连接，简单但高频调用时开销大。

2. MQTT：物联网标配，基于发布/订阅模式。电表网关作为发布者推送数据到Broker，平台订阅Topic接收。适合实时数据上报，单连接可以传上千台表的数据，带宽利用率高。

3. WebSocket：双向实时通信，适合需要平台主动下发指令的场景——比如远程拉合闸、参数下发。和MQTT的区别是WebSocket面向前端实时展示，MQTT面向设备端数据上报。

实际项目中通常是混合用：设备端MQTT上报，应用端RESTful查询，大屏推送走WebSocket。

二、数据模型怎么设计

智能电表API接口的数据模型设计核心原则：一个接口只干一件事。别图省事设计一个大而全的接口返回所有数据，调用方解析费劲，服务端查询也慢。拆分逻辑：

1. 实时数据接口：返回单台或批量电表的当前瞬时值——电压、电流、功率、功率因数。数据量小，响应快，适合前端轮询或大屏刷新。

2. 历史数据接口：按时间范围查询电量数据，支持小时、日、月三种粒度。必须做分页和限流，一个请求拉一年分钟级数据会把数据库拖死。

3. 设备管理接口：电表的注册、注销、参数配置下发。这类接口走写操作，必须有事务回滚和操作日志。

4. 控制指令接口：拉闸、合闸、复位。必须做二次确认——API收到指令后先返回一个待确认Token，调用方带Token二次请求才真正执行。

三、认证和安全不能省

能耗平台的API接口暴露在内网或公网上，安全机制是底线。见过不少项目图省事直接裸奔，接口没有认证，随便谁都能调。安全设计三条铁律：

1. Token认证：调用方先通过账号密码换取JWT Token，后续请求Header里带Token。Token有效期设2小时，过期后刷新。别用**Token，泄露了没法控制风险。

2. 接口签名：对请求参数按固定规则拼接后做HMAC-SHA256签名，服务端验签。防止参数被篡改——比如把拉合闸指令的电表编号改成别人的。

3. HTTPS强制：所有接口走HTTPS，别用HTTP明文传输。内网环境也建议加，防止内网嗅探。证书用Let's Encrypt免费签发，成本低。

四、性能瓶颈怎么破

系统上线后性能问题迟早会来。2000台表每分钟上报一次，API每分钟处理2000条写入加几百次查询，数据库CPU飙到80%以上。优化方向：

1. 写入用批量插入：一条一条写数据库是灾难。网关端攒一批数据打包发送，API收到后用批量INSERT语句一次写入。100条一批比单条写快10倍以上。

2. 时序数据库换掉MySQL：电表数据天然是时序数据，用InfluxDB或TDengine替代MySQL做存储，写入性能提升5-10倍，查询历史数据也有专门优化。

3. 查询加缓存：实时数据接口的结果缓存5-15秒。15秒内同一台表的瞬时数据不变，缓存命中直接返回不查库。历史数据用Redis缓存热点查询。

选型建议：开发智能电表API接口时别自己从零造轮子。主流电表厂商的网关已经内置了MQTT和RESTful接口，直接对接就行。如果需要自定义开发，技术栈选Python+FastAPI或Go+Gin，性能足够且开发效率高。数据库别选MySQL，用TDengine或InfluxDB做时序存储，后期扩容少踩很多坑。

常见问题

问：API接口每秒能承受多少并发请求？

答：取决于架构。单体部署用Python+FastAPI约500 QPS。如果加Redis缓存和异步写入，能到2000 QPS。分布式部署加负载均衡，单节点2000 QPS，三节点集群6000 QPS。2000台表规模的系统500 QPS绰绰有余。

问：电表断网后数据怎么补？

答：网关本地缓存断网期间的数据，恢复连接后按时间顺序补传。API端需要做幂等处理——同一条数据重复提交不会导致重复写入。用数据时间戳+电表编号做**索引，重复数据自动覆盖。

问：第三方系统调用API需要什么权限？

答：分只读和读写两种。只读权限只能查询数据和报表，不能下发控制指令。读写权限可以拉合闸和修改参数，一般只给运维系统。权限绑定到Token上，不同Token不同权限级别。