引言

Cloudflare 的免费计划一直以“慷慨”著称——Workers 每日 10 万次请求、D1 数据库 5GB 存储、Pages 无限带宽。这些数字看起来足够个人开发者随意使用，但当你真的试图在免费额度内构建一个生产级应用时，你会发现这些数字背后隐藏着大量的边界条件和隐性约束。

Nexknit 是一个完全寄生在 Cloudflare 免费计划上的开源监控系统。在它的设计过程中，我们不得不深入理解 CF 每一项免费指标的底层逻辑，才能在“完全不花钱”的前提下，实现 120 节点·小时的稳定运行。本文先梳理 Cloudflare Workers 和 D1 的免费额度全貌，再以 NexKnit 的计费模型为案例，展示如何在实际项目中实践这套精算逻辑。

---

一、Cloudflare 免费计划：Workers 与 D1 额度速览

NexKnit 只使用了 Cloudflare 两项免费服务——Workers（计算）和 D1（存储）。以下是与我们直接相关的免费额度。

Workers 免费计划

指标	免费额度	说明
请求次数	每日 100,000 次	所有打到 Worker 的 HTTP 请求（包括 OPTIONS 预检、Cron Trigger）均计入
CPU 时间	每次请求 10 毫秒	硬性限制，超出直接抛 1102 错误
墙钟时间	每次请求 30 秒	包括等待 I/O 的时间，不消耗 CPU 时间额度
Cron Trigger	无额外计费	定时任务的执行请求计入每日 10 万次额度

D1 免费计划

指标	免费额度	说明
数据库数量	最多 10 个	每个数据库独立存储配额
每个数据库存储	500 MB	总存储上限 5 GB（10 × 500 MB）
行写入	每日 100,000 次	全局计费，所有数据库共享，INSERT / UPDATE / DELETE 均计入
行读取	每日 1,000,000 次	全局计费，所有数据库共享，每次查询返回的行数均计入

注意：以上数据基于 Cloudflare 截至 2026 年 5 月公布的官方计划。D1 的行写入和行读取为账户级别全局共享，而非每个数据库独立配额。NexKnit 仅使用 Workers 和 D1，因此本文不涉及 R2、KV、Queue 等其他服务的免费额度。

---

二、免费额度的精算视角：这些数字意味着什么

Workers 每天 10 万次请求、D1 每天 10 万次写入——这些数字放在文档里看起来不小，但当你试图在它们的约束下设计一个监控系统时，每一项额度都会转化为具体的设计决策。

2.1 Workers 每日 10 万次请求：经不起“对称消耗”

一个每 5 秒推送一次数据的监控系统，天然面临推送与拉取的对称消耗。在 NexKnit 中，“节点”定义为两类——前端节点（浏览器仪表盘，负责轮询拉取数据）和后端节点（Python 网关，负责推送数据）。每个后端节点每 5 秒向 Worker 推送一次（POST /api/push），每个前端节点每 5 秒轮询一次（GET /api/state），每分钟各产生 12 次请求，每小时各 720 次，全天各 17,280 次。如果加上每分钟一次的节点列表轮询（GET /api/nodes，每小时 60 次，全天 1,440 次），一个前端节点全天总消耗约 18,720 次。一个前端 + 一个后端两节点组合，全天合计约 36,000 次——已占免费额度的 36%。

2.2 存储的取舍：写入配额是主因，存储大小是次因

NexKnit 选择不做历史存储，最核心的约束来自 D1 的写入配额——每日 10 万次，全局共享，且 INSERT、UPDATE、DELETE 均计入。如果你试图循环保存历史数据，写入次数会直接翻倍，每次写入新记录的同时需要 DELETE 一条最旧的记录，5 个后端节点每天的写入量就会从 86,400 次 UPSERT 变为 172,800 次（UPSERT + DELETE），直接超出每日 10 万次的写入限额。

存储大小是次要约束，但它从另一个方向封堵了“存数据”的可能性。500MB 的存储上限分摊给 5 个节点，每个节点只有约 100MB。每天 17,280 条记录，每条记录平均能用的空间只有约 6KB。对于监控数据来说，这个大小足够存放当前快照，但完全无法支撑有意义的历史回溯——即使写入配额允许，你也只能保存不到一天的数据，而这对于运维排障来说价值极其有限。考虑到每条 payload 的大小不固定，实际可用空间可能更紧张。

如果想绕过写入配额限制——比如引入 R2 对象存储来存放历史数据，或者阶段性的清空历史——又会引入新的复杂度：额外的服务依赖、额外的费用评估、额外的代码维护。这些方案我们都在审慎评估中，但在当前阶段，透传模式是唯一能在写入配额和存储大小的双重约束下稳定运行的方案。

2.3 D1 读取额度的意外宽裕

相比写入额度，D1 的读取额度要宽裕得多。前端每 5 秒轮询一次 /api/state，每次读取 1 行，单节点全天 17,280 次。节点列表轮询每分钟一次，每次读取 5 行（假设有 5 个活跃节点），全天 7,200 次。在极限工况下，全天总读取次数仅占免费额度的 11% 左右，真正的瓶颈永远是写入，而不是读取。

2.4 为什么几乎所有免费计划都不支持长连接

Workers 免费计划对 CPU 时间有严格的 10ms 限制（每次请求）。长连接（WebSocket、gRPC）虽然实时性更好，但一旦建立连接，Worker 就需要持续占用 CPU 资源来维持连接。在按 CPU 时间计费的模型下，长连接用户本质上是在“免费占用”计算资源——这显然不会被免费计划容忍。全栈短连接并非技术倒退，而是在零预算约束下唯一能精确控制资源消耗的方案。

---

三、NexKnit 的计费模型：目标决定设计

NexKnit 的计费模型不是从“我们想监控多少东西”出发的，而是从“我们想在免费额度内稳定运行多长时间”出发的。

3.1 设计起点：5 个节点 × 24 小时 = 120 节点·小时

NexKnit 的设计目标是在不超出 Cloudflare 免费额度上限的前提下，支撑 5 个节点全天候运行——例如一个 AI 训练机、一台 NAS、一个 Homelab 服务器、一个远程开发机、再加一个全天在线的前端。这就是我们对外承诺的“120 节点·小时”的由来。

3.2 从目标倒推：每个节点每日上限 17,280 次

要实现 5×24 的目标，每个节点每天的请求消耗不能超过 100,000 ÷ 5 = 20,000 次。考虑到网络波动和临时峰值，我们为每个节点设定了更保守的设计上限：17,280 次/天（24 × 60 × 60 ÷ 5 = 17,280），这是每 5 秒推送一次的理论最大值。有了这个上限，我们反向推导出所有超参：推送间隔 5 秒、拉取间隔 5 秒、节点列表轮询间隔 1 分钟——每一项都服务于同一个目标：确保 5 个节点全天候运行时，总请求数不超过 100,000 次。

3.3 为什么需要滑动窗口：不增加请求次数，但增加可靠性

5 秒推送间隔解决了“请求次数不超标”的问题，但它带来了一个新问题：公网不稳定。我们在真实跨国网络上测得的 HTTP 连接失败率约 15.05%——每 100 次推送里，大约 15 次会在公网上丢失或延迟。如果没有额外的可靠性机制，用户看到的仪表盘会频繁出现数据断裂和状态灯闪烁。

传统的可靠性方案在这里全部失效。TCP 重传需要长连接，但 NexKnit 每次推送都是独立的短连接，上一个连接的丢包无法在下一次自动补发。ACK 确认需要入站通道，但 NexKnit 的网关不监听任何端口，Worker 无法主动向网关索要丢失的数据。增加额外的重试请求会消耗免费额度，违背了 120 节点·小时的设计目标。

在零入站、短连接、免费额度的三重约束下，唯一可行的可靠性方案是应用层冗余——每次推送不只携带当前批次的数据，还附带前两次的旧批次。这就是 NexKnit 滑动窗口的核心设计逻辑。它不增加请求次数——每次推送仍然是独立的一次 HTTPS 请求，只是在 payload 里多带了两份旧数据。经过字段聚合优化后，包体从 8.5KB 压缩到 6.5KB，三倍冗余的带宽开销被部分抵消。

滑动窗口的另一个优势在于，它的可靠性提升和 Jitter Buffer 的平滑展示是协同设计的。前端 Jitter Buffer 设定了 13 秒的固定延迟，这个窗口恰好覆盖了滑动窗口的冗余等待时间——一个数据包在第一次推送失败后，有两次额外的机会在 Jitter Buffer 释放它之前抵达。两者配合，用户在仪表盘上看到的是连续平滑的折线图，而不是频繁断裂的数据点。

3.4 为什么需要网关整流：确保每 5 秒只发一次

NexKnit 的网关有一个关键职责——它不对采集器的数据做任何语义理解，但它严格控制推送的节奏。采集器可以以任意频率向网关推送数据——每秒一次、每 10 秒一次、甚至突发性的大量推送——但网关每 5 秒只向 Worker 发送一次 HTTP 请求。这意味着即使采集器产生了瞬时的高频数据，Worker 侧看到的请求频率仍然是稳定可控的。

这个“整流”设计有两个核心目的。第一，它确保了免费额度不会被意外的采集器行为打乱——用户可能写了一个每秒推送一次的采集器，但 Worker 侧仍然每 5 秒才收到一次请求，全天消耗始终控制在 17,280 次以内。第二，它与滑动窗口的批次聚合相配合——网关在 5 秒窗口内收集到的所有数据会被打包成一个批次，然后滑动窗口自动附带前两次的旧数据。这种“整流 + 聚合 + 冗余”的三层设计，让 NexKnit 的计费模型始终保持在可预测的边界内。

3.5 实测验证：理论值 17,280 vs 实测值 15,960

在 12 小时三节点压测中，单节点每小时实际消耗约 665 次，全天约 15,960 次。这个数字低于理论最大值 17,280，差值来自 HTTP 连接失败率约 15.05%——失败请求不会消耗额度。实测结果验证了我们的计费模型是保守的：实际消耗始终低于设计上限。

3.6 D1 写入额度的极限分析

单节点全天 UPSERT 写入 17,280 次。5 个节点的极限工况下，全天写入 86,400 次，占每日写入额度的 86.4%。如果扩展到 6 个节点，全天写入将达到 103,680 次，超出每日 10 万次的写入限额。这就是为什么 NexKnit 对外承诺“5 个全天候节点”的底层数学依据——不是 Workers 请求次数不够，而是 D1 写入额度恰好卡在了这个位置。

3.7 透传模式：写入配额主导的必然选择

如果保留历史数据，每个节点每天需要额外的 DELETE 操作来清理过期记录。以保留 15 分钟历史（约 180 条/节点）为例，5 个节点每天需要 86,400 次 DELETE，加上正常写入 86,400 次 UPSERT，总计 172,800 次写入——直接超出每日 10 万次的写入限额。透传模式不是“设计偏好”，而是被 D1 写入额度逼出来的唯一解。存储大小的限制则从另一个维度封堵了“存数据”的可能性：即使写入配额允许，500MB 分摊到 5 个节点也只有 100MB，每天 17,280 条记录，每条平均不到 6KB，只能保存不到一天的数据，对运维排障来说价值极其有限。

3.8 “每周清空”的防御性兜底

即使透传模式已将存储压到极低，我们仍配置了每周日的 Cron Trigger 自动清空 device_log 表。这是针对极端情况的防御性设计——如果未来版本引入未知 Bug 导致数据异常膨胀，每周的清空操作会强制重置数据库。节点被清空后，网关下一次推送会自动重新注册并写入最新状态。

---

四、对 Cloudflare 开发者的建议

1. 从目标倒推设计：先确定你希望在免费额度内做些什么，再反向推导推送间隔和存储策略。

2. 把删除成本纳入计算：D1 的写入额度是全局共享的，DELETE 和 INSERT 一样消耗配额。任何形式的历史数据清理都是有成本的。

3. 写入配额是存储决策的首要约束：存储大小决定能存多久，但写入配额直接决定能不能存。如果写不进去，再大的空间也没用。

4. 实测比理论更重要：理论模型预测单节点每小时 720 次请求，实测只有 665 次。15% 的 HTTP 连接失败率是理论模型无法精确预测的，但它恰好给了我们额外的安全边际。

---

五、总结

“免费不是恩赐，是数学。”NexKnit 的计费模型不是在“猜测”免费额度的边界，而是在精确计算每一行代码、每一次推送、每一个数据包的成本。这篇文章分享的不仅是 NexKnit 的精算方法，更是一套可以在任何 Cloudflare 免费项目上复用的实践框架。

NexKnit 是一款基于约束开发的、完全开源免费的内网设备监控系统。它的网关只有 Python  标准库，单文件部署，零依赖，极易审查和集成。采集器和网关之间通过 TCP 环回通信，任何语言、任何工具，只要能在本地发一行文本，就能完成一次指标上报。云端寄生在 Cloudflare Workers 的免费额度上，全程无需信用卡，同时支持一键部署 。并且可以通过采集器矩阵实现自动警告。

NexKnit 已完全开源，所有压测数据和计费模型均可在 GitHub 仓库中查看。如果你也有一个想要零成本运行的项目，希望这篇文章能给你一些启发。

主仓库见COLLECTORS_GUIDE_CN.md at nexknit-dev/nexknit-gateway

快速部署见NexKnit快速部署指南：三分钟白嫖 Cloudflare，打造零依赖内网监控面板

架构设计见NexKnit：基于约束开发的开源免费监控-CSDN博客

采集器矩阵指引见Nexknit Gateway v0.2.0：全新采集器与告警系统上线-CSDN博客

本文以开源监控系统NexKnit为例，深度解析如何精准利用Cloudflare免费计划构建生产级应用。关键发现包括：1. Workers每日10万次请求和D1数据库10万次写入构成核心限制；2. 通过5秒间隔轮询、滑动窗口冗余、网关整流等技术实现消耗可计算；3. D1写入配额是存储策略的决定性因素，而且需要考虑DELETE。文章提炼出一套可复用的精算方法论，强调从目标倒推设计、实测验证理论、将删除成本纳入计算等原则，为开发者提供了在免费额度内构建可靠系统的实践框架。