SHOW HN：用于 Cloudflare Workers 的使用量断路器

Source: Hacker News

背景

我运营 3mins.news（https://3mins.news），这是一个完全基于 Cloudflare Workers 的 AI 新闻聚合平台。后端有 10 多个 cron 触发器每隔几分钟运行一次——RSS 抓取、文章聚类、LLM 调用、邮件投递。

问题

Workers 付费计划有硬性的月度限制（1000 万请求、100 万 KV 写入、100 万 队列操作 等）。没有内置的“达到上限后暂停”机制——Cloudflare 会直接对超额部分计费。KV 写入超额费用为 5 美元/百万次，所以一次重试循环的 bug 很快就会变得昂贵。

AWS 提供预算警报，但那只是被动通知——等你看到邮件时，损失已经发生。我需要一种主动的、在应用层面的自我保护机制。

解决方案：面向内部的熔断器

我实现了一个面向内部的熔断器——它不是用来防御下游故障（Hystrix 模式），而是监控自己的资源消耗，并在接近上限时优雅降级。

关键设计决策

• 按资源阈值

  • Workers 请求（超额费用 $0.30 / M）仅在 80 % 时发出警告。
  • KV 写入（超额费用 $5 / M）在 90 % 时触发熔断。
  • 并非所有资源的风险相同，因此有些资源配置为 仅警告（trip = null）。

• 滞后（Hysteresis）
  在 90 % 时触发，85 % 时恢复。5 % 的间隙防止振荡——如果没有滞后，系统会在每个检查周期之间来回切换。

• 监控失败时的安全保底
  如果 Cloudflare 使用量 API 挂掉，保持上一次已知状态，而不是假设“一切正常”。监控中断不应掩盖使用量激增。

• 警报去重
  按资源、按月去重。否则一旦资源达到 80 % 后，整个月会收到约 8,600 封相同的邮件。

实现

每 5 分钟，系统：

1. 并行查询 Cloudflare 的 GraphQL API（请求、CPU、KV、队列）以及 Observability Telemetry API（日志/追踪）。
2. 评估八个资源维度。
3. 将得到的状态缓存到 KV。

在两次检查之间，应用只进行一次 KV 读取——几乎免费。

当熔断器被触发时，所有计划任务都会被跳过。cron 触发器仍会执行（无法停止），但它首先会检查熔断器，如果已触发则直接退出。

结果

• 已在生产环境运行两周。
• 本月初捕获到一次 KV 读取峰值（82 %），只发送了一封警告邮件，调查并修复根因，随后再未触及触发阈值。

适用范围

该模式可应用于任何计量的无服务器平台（Lambda、Vercel、Supabase）或任何有预算上限的 API（OpenAI、Twilio）。核心思路：把自己的资源预算当作健康信号，就像对待下游服务的错误率一样。

进一步阅读

完整的实现代码与测试文档：

Comments URL: