Cloudflare 推出支出管理功能 Spend Management

在我们的开发者平台上，支出控制长期以来都是开发者呼声最高的功能之一。如今已有 1000 多万名开发者在 Cloudflare 上进行构建，这项功能的重要性更是前所未有。

虽然付费计划早已支持用量通知和预算预警，但并没有彻底解决问题——知道花了多少钱，和能管住花多少钱完全是两码事。

现在，你可以设定支出阈值，并让 Cloudflare 在达到上限时自动暂停服务，从而避免因计划外用量产生高额账单。今天，我们正式面向所有按量计费（PayGo）客户推出 Beta 版支出管理（Spend Management）功能，首批支持 Workers 和 Durable Objects。

结合使用支出管理与 AI Gateway 支出上限，你可以统筹管理应用的计算成本和 AI 推理费用。AI Gateway 目前已支持针对 Workers AI 及其他 AI 服务商，按用户和模型维度设置预算，并应用于所有经由网关转发的请求。

工作原理

你可以通过控制台、cf CLI 或 REST API 开始使用支出管理功能。

打开控制台，前往“管理账户 > 账单 > 支出上限”，然后为你想要控制支出的产品开启该功能。

为某个产品开启控制后，你可以设定支出上限、指定接收通知的邮箱，并设置一个或多个预警阈值。

配置通知邮箱后，当系统核算出的支出达到预警阈值或支出上限时，Cloudflare 会发送邮件提醒。一旦触及支出上限，系统将执行阻断策略，自动暂停该产品。

在控制台中，你可以近乎实时（延迟 10 分钟以内）地查看各受支持产品在当前账单周期的费用，并在该页面管理相关设置与阈值。概览面板会列出已配置阈值和上限的产品。在这个示例中，Workers 在触及硬性上限前触发了两次告警。

需要说明的是，账单周期始于付费订阅生效之时，而非部署 Worker 或创建支出上限的时间；例如 10 月 10 日开始的订阅，其账单周期通常是 10 月 10 日至 11 月 10 日，而不是自然月。

控制台还提供了审计日志，方便查看是谁在何时修改了限额，或者上限是在何时被触发的。

与绝大多数 Cloudflare 服务一样，支出管理也提供了可供编程调用的 API，相关文档已收录在开发者文档中。以下是使用 API 的配置示例：

curl --fail-with-body --request POST \
  "https://api.cloudflare.com/client/v4/accounts/${CLOUDFLARE_ACCOUNT_ID}/billing/spend-policies" \
  --header "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Workers spending cap",
    "product_id": "workers",
    "enabled": true,
    "threshold_cents": 10000,
    "action": "usage_block",
    "notification_email": "me@example.com"
  }'

当然，你也可以使用 cf（覆盖 Cloudflare 完整 API 的命令行工具）：

cf billing spend-policies list
cf billing spend-policies create
cf billing spend-policies get
cf billing spend-policies update
cf billing spend-policies delete
cf billing spend-policies audit list
cf billing spend-policies activity list

cf billing spend-policies create --body '{
  "name": "Workers spending cap",
  "product_id": "workers",
  "enabled": true,
  "threshold_cents": 10000,
  "action": "usage_block",
  "notification_email": "me@example.com"
}'

上限一旦生效，系统就会拒绝该产品的新调用。请注意，我们只暂停会产生费用的客户代码调用——以 Workers 为例，Cron 触发器和队列消费调用会被暂停，但静态资源仍会继续正常提供服务。

如需恢复服务，你可以：

将支出上限调高至当前周期累计支出之上。
禁用或删除阻断策略。
等待现有阻断在下一个账单周期自动失效。

就这么简单。即日起，你就可以在 Workers 和 Durable Objects 中使用 Spend Management，其他产品也将很快跟进。

接下来，本文将带你了解我们是如何构建这套系统的，以及后续规划。

我们是如何构建 Spend Management 的

表面看似简单直接，但要在 Cloudflare 这种规模下构建此类系统绝非易事。从分布式网络上任意一处调用的发起，到需要全局下发的拦截决策，构建 Spend Management 不仅需要跨多个团队紧密协作，还得改造现有系统的代码，甚至从零搭建全新系统。

我们先从宏观视角来看看一个触发限额的计费事件处理流程：

现在我们来深入剖析细节。

在靠近数据源头处完成收集与聚合

每次调用都会产生使用量指标，具体取决于产品类型，比如请求数、CPU 时间、执行时长或存储操作等。但如果把如此庞大的原始数据一路从源头直接传输并交给计费引擎处理，系统既无法扩展，也难言高效。

因此，我们的做法是尽可能靠近源头来收集并聚合这些测量数据。我们采用了一套两阶段的计量流水线，将事件聚合成使用量汇总数据，这样引擎看到的就是累计用量，而不必逐一处理每个具体事件。

来看一下架构图。

第一阶段在解析环节附近对原始事件进行大幅削减，将其归整为 1 分钟的时间窗口。每个计量解析器先将原始事件转化为用量数据，再将匹配的数据归入通常为 1 分钟的时间桶内。不过此时，仍可能存在多条记录对应同一账户和同一时间窗口的情况。

到了第二阶段，由一个独立服务按照相同的分组规则，将第一阶段生成的局部聚合数据按通常为 5 分钟的时间窗口进一步合并，从而在进入下游 Usage Engine 处理前再次大幅压缩数据量。在此阶段，我们还会对合并后的汇总数据做归档，为后续的数据分析与对账保留一份持久化数据集。

这种两阶段流水线的妙处在于，它能在链路早期就大幅削减原始事件量，让下游引擎只需处理计算支出并执行控制所需的聚合用量数据。正是这一点，让整套方案在 Cloudflare 的庞大规模下具备了可行性。

Usage Engine：基于账户分区的处理

Usage Engine 负责将聚合后的测量数据转化为标准用量记录。这些标准化记录包含账户、用量窗口、指标、数量及相关维度等信息。换句话说，它将不同产品特有的计量数据映射为了系统统一支持的用量指标。

我们按账户进行分区处理，让同一账户的用量与订阅信息汇聚在同一处。这样一来，我们就能直接维护账户的累计用量并套用包含的额度配额，而无需在每次更新时都跨定价处理器进行复杂的协同。

如你所见，不同分区是并行运行的，这让我们既能把不同账户的负载分散开来，又能将单个账户的计费状态保持在同一位置。此外，每个分区不仅在本地维护用于快速访问的状态，还将变更日志持久化记录在磁盘的预写日志（WAL）中。这为我们带来了以下优势：

减少跨分区协同：每个账户的用量和订阅状态都集中在一起。
计费一致性：用量更新共享相同的免费额度和累计支出状态。
并行处理：不同分区可以彼此独立地计算支出。
可恢复性：具备持久化状态，一旦发生故障，备用处理器可以在需要时快速重建并恢复运行。

最后，这些用量指标会被传入计费引擎。

计费引擎

计费引擎是支出管理（Spend Management）中最核心的模块。它负责将用量换算成实际金额，解答这样一个关键问题：“结合该账户的实际消耗、订阅方案和计价规则，到目前为止一共花了多少钱？”

它的工作原理如下：

从本质上看，计费引擎整合了三项数据：

用量记录：包括请求次数、CPU 毫秒数等指标。
订阅信息：账户的账单周期以及套餐变更记录。
计价规则：费率、包含的免费额度以及账单舍入规则。

用量数据与订阅信息分属独立数据流

用量数据和订阅更新是作为两条独立的数据流分别到达的，因此无法预设它们会按先后顺序进入计费引擎。此外，系统还必须具备容错能力，以应对数据处理故障，或因 Webhook 失败等原因导致的订阅信息缺失。

如果用量数据先于计价所需的订阅信息到达，我们会将其标记为待处理状态，待订阅信息就绪后再行计算。这样既能包容短暂的延迟，又不会把尚未核算费用的用量误当作免费处理。

累计支出追踪

最后一步是计算并追踪累计支出。计费引擎结合账户的订阅信息，通过产品目录数据库调取各项用量指标的免费额度、费率和取整规则。例如，消耗 100 万 CPU 毫秒并不一定意味着会产生额外费用：引擎会先扣除套餐内包含的 CPU 额度，仅对超额部分计费。此外，计价是针对累计用量统一核算，而不是对每次请求单独取整扣费。

计算出累计支出后，紧接着会执行两个步骤：

策略评估：判断是否已达到预警阈值或阻断阈值。
报告呈现：通过 API 在控制台中展示预估用量费用；必要时还会通过 Cloudflare 邮件服务发送预警邮件。

异步限额执行

计费引擎并不处于请求路径中，也不会直接拒绝请求。相反，策略服务会将设定的限额下发至运行时配置服务以及 Quicksilver（Cloudflare 自研的内部键值存储系统，支持全球范围内的极速复制与超低延迟访问）。限额信息随后会被异步分发到所有节点。

限额数据同步至 Quicksilver 后，运行时环境会在定期刷新时拉取最新状态，并开始拦截超出限额的调用或操作。

换言之，限制的执行完全基于本地状态，因此请求完全无需等待计费引擎响应。通过复用现有的运行时账户限额架构，我们既避免了计费逻辑阻塞请求路径，又能将限额策略快速分发至全球网络。

下一步计划

现在，所有按量付费客户均可开始体验支出管理功能。这不仅是路线图上的一个重要里程碑，更是一个全新的起点。以下是我们未来数周及数月内的规划。

支持更多产品

我们目前首先支持对 Workers 和 Durable Objects 设置上限，但在不久的将来，你就能对 Cloudflare 的更多产品和基础组件进行计量与限额。我们架构这套系统时，就考虑到了让旗下产品能够轻松、无缝地接入，因此后续支持的产品目录还会不断扩充。

进一步贴近实时

虽然 10 分钟以内的准实时表现已经相当亮眼，但我们并不满足。工程师骨子里的执着让我们想到了不少好办法，能把这个延迟压得更低。未来我们会逐步缩短从计量到执行封顶的间隔，理想目标是控制在 1 分钟以内。

面向智能体与应用的预算控制

目前我们是按产品和基础组件来统计支出的，但在控制成本时，还有其他维度值得探索。比如，开发者可能希望监控某个具体应用的开销——比如一个调用了 R2 或 Workers AI 等其他组件的 Worker 脚本。我们该如何统计整套应用的累计成本，并单独暂停该应用，而不是把客户旗下所有应用所依赖的底层组件通通关停？

成本控制的另一个重要场景是 AI 智能体。大家都听说过失控智能体的恐怖故事：陷入无休止的递归推理死循环去硬解难题，高频调用高昂的 API，瞬间烧掉数千美元，更不用说还会对数据库等服务造成拒绝服务（DoS）攻击。AI Gateway 已经允许大家为经由它路由的智能体请求设置预算。不过，一项任务往往还会消耗算力、数据库和存储资源。我们希望让预算控制能覆盖这类跨产品的更广泛资源消耗。

届时你将能为智能体发出的调用打上标签，我们的数据链路会把这些元数据从运行时一直传递到计费引擎（Rating Engine）。这样一来，我们就能厘清支出归属，在跨产品维度上暂停某个应用或智能体任务，同时完全不影响其他无关应用的正常运行。

立即体验

让支出控制像部署代码、监控应用一样，成为在 Cloudflare 上开发不可或缺的常规环节，这次发布只是迈出的第一步。

欢迎查阅账单开发者文档了解更多详情。立即体验 Spend Management，并告诉我们哪些功能好用、哪些还不够完善，或者在哪些场景下需要更细粒度的预算控制。

欢迎加入我们的 Discord 或在社交媒体上留言，我们随时倾听你的反馈！