Newshot 推出 Spend Management：为 Cloudflare 提供支出限额与告警
很长一段时间以来，支出控制一直是我们开发者平台上开发者最迫切需要的功能之一。如今有超过 1000 万名开发者在 Cloudflare 上构建应用，这件事比以往任何时候都更重要。
尽管我们早就为付费套餐提供了用量通知和预算告警，但这并不能彻底解决问题；告知并不等同于控制。
现在你可以设置支出阈值，并选择在达到这些限额时让 Cloudflare 暂停相关活动，从而避免因计划外用量而产生意外账单。今天，我们推出 Beta 版的 Spend Management，面向所有按量付费（PayGo）客户，首批支持 Workers 和 Durable Objects。
你可以将 Spend Management 与 AI Gateway 的支出限额配合使用，管理整个应用的计算和 AI 推理成本。AI Gateway 已支持为 Workers AI 及其他 AI 提供商设置按用户和按模型的预算，作用于经由你的网关路由的请求。
工作原理
你可以通过 dashboard、cf CLI 或 REST API 开始使用 Spend Management。
在 dashboard 中，前往 Manage Account > Billing > Spend limits，启用你想要控制支出的产品。
当你为某个产品启用控制后，可以定义支出限额、指定用于接收通知的收件人邮箱，并设置一个或多个告警阈值。
如果你配置了收件人邮箱，当评估出的支出达到某个阈值或你的支出限额时，Cloudflare 会发送通知。当达到限额时，将强制执行阻断策略，你的产品会被自动暂停。
如果你进入 dashboard，可以近乎实时地（10 分钟以内）查看每个受支持产品在当前计费周期的费用，并在那里管理你的设置和阈值。概览面板会告诉你哪些产品已配置阈值和限额。在这个示例中，你可以看到 Workers 在触及硬性限额之前触发了两次告警。
请注意，计费周期从付费订阅开始时算起，而不是从你部署 Worker 或创建支出上限时算起；10 月 10 日开始的订阅，其周期通常是 10 月 10 日至 11 月 10 日，而不是一个自然月。
dashboard 还会显示审计日志，你可以看到谁在何时修改了限额，或者上限是在何时被触及的。
与大多数 Cloudflare 服务一样，Spend Management 也是一个可以通过编程方式使用的 API；相关文档可在我们的 Developer Documentation 中找到。下面是一个使用该 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": "[email protected]"
}'
当然，你也可以使用 cf，即用于整个 Cloudflare API 的 CLI：
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": "[email protected]"
}'
一旦上限被强制执行，该产品的新调用就会被拒绝。请注意，我们只会暂停会产生费用的客户代码调用——例如在 Workers 中，Cron Triggers 和 Queue consumer 调用会被暂停，但静态资源仍会继续提供。
要恢复服务，你可以：
- 将限额提高到当前周期已累计支出之上。
- 禁用或删除该阻止策略。
- 等到下一个计费周期，届时现有的阻止会自动过期。
就是这样。你今天就可以为 Workers 和 Durable Objects 使用 Spend Management，其他产品很快也会跟进。
继续阅读，了解我们是如何构建这套系统的，以及接下来会发生什么。
我们是如何构建 Spend Management 的
表面上看，这样一套系统似乎简单直接，但在 Cloudflare 的规模上构建它绝非易事。从我们分布式网络中任意位置的一次调用，到需要全球应用的阻止决策，构建 Spend Management 需要与多个团队协作、修改现有系统中的代码，并从零开始创建新的系统。
我们先从鸟瞰视角看一次受上限约束的可计费事件：
现在我们再深入看看。
在靠近源头的地方收集与聚合
每次调用都会产生用量测量值：请求数、CPU 时间、执行时长或存储操作，具体取决于产品。但把如此海量的原始数据从源头一路传输并处理到 rating engine，既无法扩展，也不高效。
所以我们做的是，使用两阶段计量流水线，尽可能在靠近源头的地方收集并聚合这些测量值，把事件合并成用量聚合结果，这样引擎看到的是累计用量，而不必逐个处理所有事件。
我们来看一张图。
第一阶段在靠近解析的位置把原始事件量压缩到一分钟窗口。每个计量解析器把原始事件转换为用量测量值，然后把匹配的测量值合并为通常一分钟的桶。不过，仍可能有多条记录描述同一个账户和同一时间窗口。
在第二阶段，一个独立服务按照相同的分组规则合并这些第一阶段的部分聚合结果，但通常是在五分钟窗口上，并在 Usage Engine 进行下游处理之前进一步压缩数据量。这里我们还会归档合并后的聚合结果；这为我们提供了一个持久的数据集，用于后续的分析与对账。
这条两阶段流水线的好处在于，它早早地降低了原始事件量，因此下游引擎只需处理计算支出和据此采取行动所需的聚合用量。这正是让它在 Cloudflare 的规模下变得可行的原因。
Usage Engine：按账户分区的处理
Usage Engine 把聚合后的测量值转换为用量记录，即包含账户、用量窗口、指标、数量和相关维度的标准化记录。换句话说，它把产品特定的计量器映射为受支持的用量指标。
我们按账户划分处理，因此一个账户的用量和订阅信息会在同一个地方汇合。这样我们就能维护其累计用量并应用所含额度，而无需在每次更新时跨多个定价处理器进行协调。
如你所见，我们并行运行不同的分区，这让我们能够把工作分散到各个账户上，同时让每个账户的定价状态保持在一起。另外请注意，每个分区既保留本地状态以实现快速访问，也在磁盘上保留持久的预写日志（WAL）变更日志。这为我们带来：
- 更少的跨分区协调：每个账户的用量和订阅状态保持在一起。
- 一致的定价：用量更新共享相同的额度和累计支出状态。
- 并行处理：不同分区独立计算支出。
- 可恢复性：持久状态让替换的处理器在必要时能够重建并恢复。
最后，用量指标会被送入 Rating Engine。
Rating Engine
Rating Engine 是 Spend Management 中最重要的模块；它将用量转化为货币价值，并且能够回答这个问题：“考虑到该账户已消耗的资源、其订阅和定价，到目前为止它花了多少钱？”
其工作方式如下。
本质上，Rating Engine 汇集了三样东西：
- 用量记录：请求数和 CPU 毫秒数等数量。
- 订阅信息：账户的计费周期和套餐变更。
- 定价规则：费率、所含额度和计费舍入。
用量数据和订阅是相互独立的流
用量更新和订阅更新以相互独立的流到达，因此我们不能假设它们按顺序到达 Rating Engine。此外，我们还必须能够从数据处理失败或订阅信息缺失（例如 webhook 失败）中恢复。
如果用量在为其定价所需的订阅信息之前到达，我们会将其保留为待处理状态，并在该信息可用时重新处理。这让我们能够容忍临时延迟，而不会将未定价的用量视为免费。
跟踪累计支出
最后，我们计算并跟踪累计支出。Rating Engine 使用一个产品目录数据库，该数据库定义了用量指标，包括额度、费率和舍入规则，并结合账户的订阅信息。一百万 CPU 毫秒并不一定意味着额外收费：引擎会先应用账户所含的 CPU 额度，然后对任何超出部分定价。它对累计用量进行定价，而不是对每个请求独立舍入并收费。
累计支出计算完成后，接下来有两个步骤：
- 策略评估：判断是否已达到一个或多个警告或阻断阈值。
- 报告：我们通过 API 在仪表板中显示预估用量费用，并在必要时（通过 Cloudflare Email Service）发送电子邮件警报。
异步上限执行
Rating Engine 不位于请求路径中，也不直接拒绝请求。相反，策略服务将上限发送到我们的运行时配置服务和 Quicksilver——我们内部开发的键值存储，旨在实现全球规模的快速复制和低延迟访问。这会以异步方式将其传播到我们所有的节点。
一旦上限到达 Quicksilver，运行时会在其定期刷新期间获取该上限，并开始拒绝已达到上限的调用或操作。
换句话说，执行使用的是本地状态，因此请求永远不必等待 Rating Engine。通过复用现有的运行时账户限制架构，我们将评级排除在请求路径之外，同时在全局网络中分发上限。
下一步
任何按量付费客户今天就可以开始使用 Spend Management。虽然这是我们路线图中的一个重要里程碑，但这也只是开始。让我们分享未来几周和几个月的一些计划。
更多产品
我们首先为 Workers 和 Durable Objects 提供上限，但在不久的将来，你将能够测量并限制许多其他 Cloudflare 产品和原语。我们构建该系统的方式让我们的产品能够轻松且熟悉地接入，因此预计目录会不断扩大。
更接近实时
虽然 10 分钟以内的近实时是一个很好的基准，但我们并不满足于此，而且作为固执的工程师，我们有相当不错的想法来进一步缩短这个时间。预计我们会随着时间的推移缩短测量与执行之间的差距，希望缩短到一分钟以内。
基于代理和应用程序的预算
目前，我们按产品和原语衡量支出，但在控制成本时还有其他有用的维度可供探索。例如，开发者可能希望监控特定应用程序的成本——比如一个使用了 R2 或 Workers AI 等其他原语的 Worker 脚本。我们如何衡量整个应用程序的聚合成本，并暂停该应用程序，而不是在所有客户应用程序中禁用底层原语？
成本控制的另一个引人注目的用例是 AI 代理。我们都读过一些恐怖故事：失控的代理进入不受约束的递归推理循环来暴力解决问题——通过高频、昂贵的 API 调用产生数千美元的成本，更不用说还会导致数据库和其他服务出现拒绝服务（DoS）问题。AI Gateway 已经允许你为通过它路由的 AI 请求给代理设定预算。任务还可能消耗计算、数据库和存储资源。我们希望让跨产品为更广泛的资源使用编制预算成为可能。
你将能够标记来自代理的调用，我们的管道会将该元数据从运行时一路传递到 Rating Engine。这将使我们能够归因支出，并跨产品暂停某个应用程序或代理任务，而不会中断其他不相关的应用程序。
开始使用
此次发布是朝着让支出控制成为在 Cloudflare 上构建应用的常规部分迈出的第一步，与部署代码和监控应用程序并列。
查看计费开发者文档以了解更多信息。开始使用 Spend Management，并告诉我们哪些功能有效、缺少什么，或者在哪里更细粒度的预算会有帮助。
在 Discord 或我们的社交媒体上加入我们。我们在倾听！