别再暴力轮询了：我们处理 500 个电站 API 限流时的排队机方案

去年 7 月我们在山东接手了一个 50MW 的分布式工商业项目涉及 80 多个屋顶电站混合了华为、阳光、古瑞瓦特等四个品牌的逆变器。当时为了追求所谓的“实时性”我们直接在业务层写了个死循环去调厂家的 OpenAPI每隔 15 秒拉一次实时功率。结果上线不到 48 小时运维群里就开始疯狂报错HTTP 状态码 429Too Many Requests刷屏紧接着就是厂家云端的 API 访问权限被封禁了 24 小时。这种“暴力轮询”的方式在实验室环境跑 1 台设备没问题但在面对数十个账号、几百台逆变器时无异于在搞 DDoS 攻击。很多厂家云平台的限流逻辑非常粗暴有的是按 IP 限流有的是按 AppKey 限流最难受的是按单一账号Account的并发数限流。一旦触发限流整个平台的监控数据就会出现长达数小时的“断流”如果是带了告警推送的业务那简直是灾难。本文想聊聊我们团队在经历了几次“封禁毒打”后是如何通过分布式调度和多级缓存方案把原本脆弱的 API 对接做成高可靠中间层的。为什么厂家的 API 文档总是“骗人”的如果你仔细翻过各大逆变器厂商的接口文档你会发现关于频率限制Rate Limit的描述通常很模糊。有的写着“建议间隔 5 分钟”有的写着“最大并发 10”但实际运行中你可能会遇到各种隐藏的坑。我们在某主流品牌代号 H的对接中发现虽然文档宣称支持 1 分钟采集一次但如果你同时发起了 5 个分页查询请求它会瞬间触发保护机制。而在另一个品牌代号 G的场景下虽然接口不限流但在电站运维高峰期接口响应时间会从正常的 200ms 飙升到 15s导致你的采集线程池被瞬间占满整个系统卡死。为了量化这些风险我们整理了一份“多品牌 API 限制特性表”基于 2023 年下半年实测厂商类别限流单位实测限制阈值参考值封禁后果恢复机制第一梯队 (H/S)账号IP1000次/小时并发 5接口返回 429封禁 1 小时自动解封第二梯队 (G/S)AppKey5秒1次单设备响应超时或 503人工介入欧美品牌 (SE/SMA)每日配额300次/天基础版直接停用接口需购买高级版这些数据告诉我们一个事实想在自己的监控平台上实现“秒级监控”靠直接调厂家的云 API 是走不通的。你必须在你的采集架构和厂家云之间加一个能够控制流量节奏的“阀门”。架构升级从“主动拉取”到“分布式任务队列”为了解决限流问题我们放弃了在业务逻辑里直接调 API 的做法转而构建了一套基于 Redis 的分布式调度系统。说白了就是把“拉取数据”这个动作变成一个个“任务Task”丢进队列里排队执行。1. 令牌桶算法与流量整形我们引入了令牌桶Token Bucket算法。针对每一个厂家 AppKey我们维护一个独立的令牌桶。比如厂家限制每分钟 60 次请求那我们就每秒往桶里放 1 个令牌。采集任务在执行前必须先拿到令牌拿不到就回滚到队列末尾等待。这种方式比简单的计数器要平滑得多不会出现“前 10 秒把配额用完后 50 秒全在报错”的情况。2. 任务的分级与优先级调度不是所有数据都需要高频采集。我们将任务分成了三个优先级P0实时告警/故障优先级最高优先占用令牌采集频率 1-2 分钟。P1核心遥测数据如功率、电压、电流频率设定在 5-10 分钟。P2静态信息/配置如逆变器型号、序列号、电站名称每天同步一次即可。通过这种分级当 API 限流发生时我们至少能保证 P0 级的告警数据能先跑通而不是被大量的 P2 同步任务给挤掉。# 伪代码基于任务优先级的调度逻辑defschedule_task(task_type,device_id):priorityget_priority(task_type)ifnottoken_bucket.get_token(brand_key):# 令牌不足根据优先级决定重试策略delay30ifpriorityP0else300retry_queue.put(task_id,delaydelay)return# 执行实际的 API 调用resultcall_vendor_api(task_type,device_id)handle_response(result)解决“断连”幻觉高频缓存策略很多 EPC 工程师问过我们如果我把频率降到 10 分钟一次那我的监控大屏上数据岂不是老半天不动这在运维端会被误认为是“通讯中断”。这里的解决思路是“虚实结合”。在我们的数据库通常是 IoT 专用时序库和前端展示层之间加一层 Redis 实时缓存。前端请求数据时永远先读缓存。即使 API 因为限流或者厂家服务器抖动晚回来了 2 分钟我们也可以根据上一时刻的功率斜率进行平滑处理或者在前端展示“数据更新于 2 分钟前”的字样而不是直接给用户报个红色的“离线”。更关键的一点是处理Token 刷新。很多厂家云 API 的 AccessToken 有有效期比如 2 小时如果你在 500 个采集线程里同时发现 Token 过期并去调用 RefreshToken 接口那这个账号瞬间就会因为并发过高被封。我们现在的做法是由一个单线程的 Cron Job 提前 15 分钟把 Token 刷好并存入 Redis所有的采集 Worker 只从 Redis 读 Token绝对不允许在采集逻辑里触发刷新操作。踩坑小贴士那些文档里没写的细节在对接了 30 多家厂商后我们总结了几个非常隐蔽的坑位时区陷阱国内厂家默认北京时间但像 SMA 或 SolarEdge 这种返回的可能是 UTC 时间甚至电站当地时间。如果你的调度系统没处理好时区偏移在拉取“当日发电量”时可能会因为时间未到而拉回一堆空值导致你的统计报表全乱了。补传机制的缺失大部分 API 只能拉到“当前时刻”的数据。如果厂家云端在凌晨 2 点挂了早上 8 点才恢复这中间的 6 小时数据在 API 里是永远消失的。针对这种情况我们被迫开发了“历史数据回溯任务”在系统空闲时如凌晨去尝试调用其历史数据接口补齐空档虽然这会消耗额外的配额但对资产方的对账至关重要。分页查询的隐形消耗如果你一个账号下有 200 个电站有些接口支持分页返回。千万不要以为“分 10 页”只算 1 次请求在厂家的计费或限流逻辑里每一页翻页往往都被计为一次独立的 API Call。我们的取舍与建议在光伏监控平台这条赛道上数据接入层其实是最脏、最累、也最容易出问题的活。很多公司在起步阶段想自建这套体系结果往往是接第一个品牌用了 2 周接第十个品牌时发现系统架构要推倒重来因为之前的并发模型根本扛不住多厂商的差异化限流。如果你目前管理的电站规模在 100MW 以下通过引入 Celery 或类似的分布式任务框架配合严格的令牌桶限流基本能解决 80% 的 API 稳定性问题。但如果你的业务增长很快面临几十个厂家 API 的高频维护其实可以考虑把这一层剥离出来。我们团队把这些年踩过的 API 坑、总结的归一化算法全部封装进了一套名为 ZenovaConnect 的中间件里。它的逻辑很简单你不用再管华为还是阳光也不用管 API 什么时候限流、什么时候 Token 过期你只需要像查本地数据库一样调我们的归一化接口。剩下的流量整形、字段对齐、告警去重全都由我们在后台默默搞定。这种“把复杂留给中间层把简单留给业务层”的思路是我们认为目前解决多品牌接入最务实的路径。最后留个问题给各位同行在你们的场景下电站运维大屏的数据延迟容忍度是多少1 分钟还是 5 分钟欢迎在评论区聊聊你们在对接厂家 API 时最想吐槽的一个设计。了解 ZenovaConnect 完整方案