没有主机的个人云：基于Cloudflare Workers的无服务器架构实践-北京尧图网络

凌晨三点的钉钉告警把我吵醒这已经是这个月第三次。SSH 连不上、磁盘 100%、两个 Docker 容器莫名退掉……我当时真想把这台 VPS 扔出窗外。冷静下来后我意识到问题不是“这台服务器不够好”而是“我真的需要一台服务器吗”。于是我用一个周末的时间把个人项目的基础设施全部搬到 Cloudflare 生态上并给这套方案起了个代号cloudflare-os。它不是某个官方系统而是我自己的“无主机个人云”静态页面交给 Pages服务逻辑塞进 Workers数据丢进 D1 和 KV文件放到 R2内网服务用 Tunnel 和 Access 包住。站在用户角度它就是一个网站、一个 App、一个存储服务站在我这边它是一台跑在全球 300 多个边缘节点、没有主机、没有运维、几乎所有场景都免费的云端操作系统。这篇文章就把我搭建 cloudflare-os 的完整思路、选型逻辑、实操步骤和踩过的坑拆开讲一遍适合手里有小项目、想省掉服务器维护成本、又对 Serverless 和边缘计算感兴趣的同学参考。1. 为什么我会把“操作系统”建在 Cloudflare 上想理解了这套方案得先回到我决定重构的那个晚上。当时我手上有几个流量不大但必须稳定在线的个人项目一个博客、一个文件分享页、几个给朋友用的工具 API。它们原本挤在一台 2C4G 的 VPS 上每个月续费不算贵贵的是我自己的精力。1.1 传统自托管给我带来的三个噩梦第一安全水位全靠自觉。VPS 一开 SSH扫描流量就来了。我见过日志里有人用 root 账号密码爆破见过 Docker 端口不小心暴露到公网还见过因为忘了关某个调试路由导致数据库被拉出公网。维护一台暴露在公网的 Linux 机器本质上是在和全网不怀好意的爬虫与脚本对抗。第二性能规划永远两难。买低了某个慢查询或者突发流量就能把 CPU 打满整个网站跟着卡买高了日常闲置 90%钱白花。我当时的 VPS 高峰期和低谷期负载能差出十几倍但服务器规格是固定的只能按峰值买。第三存量维护成本极高。操作系统要打补丁Nginx 要调配置Node 版本要升级证书要续期日志要清理磁盘满了要扩容。每一样本身都不难但它们会在你不想动服务器的时候突然跳出来找你要时间。我经常半夜爬起来修完问题第二天还得正常上班。这三件事单看都能忍合在一起就让人很想换一条路。1.2 没有主机的“主机”边缘平台怎么承担系统职责Cloudflare 不会给你一台能插网线的机器但它提供的东西拼在一起从功能上几乎覆盖了一套操作系统该有的全部模块Workers 负责跑计算逻辑相当于 CPU 上的进程KV 负责跨区域的高频读取缓存相当于内存和缓存层D1 提供结构化数据表相当于需要持久化的磁盘分区R2 是对象存储相当于文件系统Cron Triggers 是定时调度器相当于系统里的计划任务Access 和 Tunnel 则承担了网关和加密通道的职责。如果你用过自托管会发现这套组合拳最爽的地方是你不用管任何底层环境。传统 VPS 像你买了一套毛坯房装修、水电、物业全得自己办而 cloudflare-os 更像住在共享公寓自己房间内部随便布置楼体结构、电梯维护、安防巡逻都交给大楼物业。代价是有些“承重墙”不能砸比如 Worker 的单请求 CPU 时间上限、KV 的一致性边界、D1 的连接模式都需要代码去配合平台而不是平台配合你的代码。1.3 这套方案真正适合谁不适合谁我踩了一圈之后给自己列了个对照清单现在每次开新项目都先拿它过一遍。适合丢上来的个人博客、作品集、内容型产品、工具型 API、数据看板、用 Markdown 写作的站点、图片和图床服务、小程序后端接口、定时跑的数据采集任务。这些项目共同点是请求轻、状态少、不需要长连接天然适合在边缘计算环境里跑。不适合硬扛的需要多人在线实时协同的长连接应用、必须本地磁盘处理 GB 级文件的任务、强事务强一致性要求极高的金融类逻辑、延迟要求极其苛刻的实时游戏服务。这些要么突破 Worker 的墙钟限制要么会把 KV 的最终一致性缺陷放大到不可接受。很多文章把 Serverless 吹得万能那是没把真实限制写进来。看清边界才知道怎么扬长避短。2. cloudflare-os 的整体骨架用全家桶拼出一台“云电脑”如果你把“操作系统”这个词当真cloudflare-os 的架构其实很好理解。我需要一张映射表把传统概念迁移到 Cloudflare 的组件上后面所有代码和配置都按这个骨架来。2.1 组件对应关系与选型逻辑传统操作系统概念cloudflare-os 对应服务在我的架构里承担的角色CPU / 进程调度Cloudflare Workers跑所有服务端逻辑按 HTTP 请求触发内存 / 缓存层Workers KV存放高频读取的状态、配置、短文本数据磁盘结构化数据Cloudflare D1存用户表、笔记表、订单等需要 SQL 的数据文件系统Cloudflare R2存图片、附件、备份、任意二进制对象定时调度器Cron Triggers每天/每小时自动触发 Worker 里的任务网关与防火墙Cloudflare Access / Tunnel保护内网服务只允许指定身份访问DNS 与流量调度Cloudflare DNS / Load Balancing把域名解析到最近的边缘节点这套选型有一个贯穿始终的原则数据要靠近逻辑。以前自建架构里数据库在一台机器上代码在另一台用户请求要先跨机房才能拿到数据在 cloudflare-os 里静态资源被 CDN 缓存动态请求由最近的边缘节点接管D1 和 R2 也都跑在 Cloudflare 自家的网络上。代码和数据之间的距离越短用户感知到的延迟就越低。2.2 路由设计一个域名、三种流量整个系统我建议只用一个主域名通过路径把流量分给不同组件。比如example.com对外是内容站静态部分由 Pages 托管example.com/api/*被反向代理到 Workers 上的 API 服务文件访问走example.com/files/*由 Worker 校验权限后从 R2 取流。Pages 本身支持自定义域名Workers 也支持routes配置。在wrangler.toml里做类似下面的路由声明name cloudflare-os-api main src/index.js compatibility_date 2025-01-01 routes [ { pattern example.com/api/*, zone_id 你的zone_id } ]这样用户访问example.com/api/notes时DNS 解析到 Cloudflare请求直接进入指定的 Worker不需要额外暴露端口也不存在传统方式里常见的“忘了改防火墙规则导致端口裸奔”的问题。2.3 成本试算一台云主机一年要花多少钱我按当时公开的免费额度做了一个估算表个人项目基本上可以维持 $0/月。组件免费额度以写作时公开档位为准我的实际用量Workers每天 10 万次请求日均几百到几千远用不完Pages静态请求不单独计费个人站流量忽略不计KV读操作每天十万级、写操作每天千级只存低频改动的配置绰绰有余D15GB 存储、每天百万行级别读取个人项目数据几 MBR210GB 存储、每月百万次 A 类操作、千万次 B 类操作存几个 GB 的附件Access免费版支持最多 50 个用户只给我自己加两三个人用即使哪天流量上去了Workers 付费版也就每月 5 美元对比之前一台 VPS 一年几百上千的续费这笔账在国内和国际社区里都算性价比很高的方案。真正的大头从来不是钱是省下来的运维精力。3. 从零搭建把静态层、逻辑层、数据层跑通理论说太多容易飘直接按我当时的操作顺序走一遍。整套流程大概需要半天时间前提是已经注册好 Cloudflare 账号并把域名接入 CDN。在动手前先把四件事写成清单前端静态资源发布到 Pages后端 API 发布到 Workers创建 D1 数据库并和 Worker 绑定创建 R2 存储桶并和 Worker 绑定3.1 第一步用 Pages 托管所有静态前端Pages 本质上是一个 JAMStack 托管平台支持直接连接 Git 仓库每次 push 自动构建和发布。我以前博客用 Hexo 生成本地hexo generate产出 public 目录构建命令设为npm run build输出目录填publicpush 上去就完事。建好后别忘了加两个文件。_headers控制安全响应头/* X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Referrer-Policy: strict-origin-when-cross-origin_redirects做路径转发把 API 请求导到 Workers/api/* https://example.com/api/:splat 200这一步的关键是让静态资源完全命中最优缓存Pages 里的文件本质上会被 Cloudflare 的 CDN 缓存到全球节点访问速度比我原来那台单点 VPS 快得多。3.2 第二步用 Workers 做统一 API 入口Workers 是这套系统里唯一需要认真写代码的部分。初始化npx wrangler login npm create cloudflarelatest cloudflare-os-api我建议把 Worker 设计成一个“网关业务执行器”所有/api/*请求都先进到这里然后根据路径分发给内部函数。一个最小可跑的示例如下export default { async fetch(request, env, ctx) { const url new URL(request.url); if (url.pathname.startsWith(/api/notes)) { const { results } await env.DB.prepare( SELECT * FROM notes ORDER BY created_at DESC ).all(); return Response.json({ ok: true, data: results }); } if (url.pathname.startsWith(/api/health)) { return Response.json({ ok: true, time: Date.now() }); } return new Response(not found, { status: 404 }); }, };这个文件虽然短结构上已经把权限校验、数据库查询、错误处理都留出了扩展位。后面新增业务只需要加新的 if 分支或者拆成模块不要让一个 Worker 膨胀成分布式巨兽。3.3 第三步D1 R2 补齐数据和文件存储D1 支持标准 SQLite 语法先建库再建表。当年我用的命令是npx wrangler d1 create cloudflare-os-db npx wrangler d1 execute cloudflare-os-db --remote --file./schema.sqlschema.sql 里可以是几张简单的业务表比如CREATE TABLE IF NOT EXISTS notes ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, body TEXT, created_at INTEGER NOT NULL ); CREATE TABLE IF NOT EXISTS users ( id INTEGER PRIMARY KEY AUTOINCREMENT, email TEXT UNIQUE NOT NULL, nickname TEXT );建完库后在wrangler.toml里做绑定[[d1_databases]] binding DB database_name cloudflare-os-db database_id 你的数据库ID [[r2_buckets]] binding FILES bucket_name cloudflare-os-files之后 Worker 里可以直接通过env.DB和env.FILES访问它们。R2 桶里存放的是用户上传的图片和附件注意不要给桶开放公共读文件访问一律通过 Worker 校验身份后再取流或者生成带时效的签名 URL。3.4 第四步Cron Triggers 让系统自己“动”起来一个系统光有请求响应还不够还得有“定时任务”才像个系统。Workers 的 Cron 功能正好解决这个需求。比如每天凌晨三点清理 30 天前的过期记录在wrangler.toml里加[triggers] crons [0 3 * * *]然后在 Worker 里实现 scheduled handlerexport default { async scheduled(event, env, ctx) { const cutoff Date.now() - 30 * 24 * 60 * 60 * 1000; const result await env.DB.prepare( DELETE FROM notes WHERE created_at ? ).bind(cutoff).run(); console.log(cleanup done:, result.meta.changes); }, async fetch(request, env, ctx) { // ...原有的请求处理 }, };第一次跑通这些流程后一次真实的用户请求链路是这样的浏览器访问example.comDNS 解析到最近边缘节点Pages 返回静态页面前端 JS 再调example.com/api/notes请求进入 WorkerWorker 从 D1 查询数据并返回 JSON。静态资源在边缘被缓存API 结果按需穿回主数据区整体体验很快且稳定。这就是 cloudflare-os 的日常。4. 把私有服务安全接进来Tunnels 与 Access 的组合拳前几节讲的都建立在“业务全部跑在 Cloudflare 平台上”的假设上但现实里总有例外。比如我家里的 NAS、笔记本上的开发环境、内网的一个管理后台它们并不在 Cloudflare 的边缘节点上。想让这些本地服务也纳入 cloudflare-os 的管理范围别去开端口用 Tunnel 和 Access。4.1 本地服务如何纳入云上管理Tunnel 的原理是让本地机器主动外联 Cloudflare 边缘节点建立一个加密通道流量经 Cloudflare 边缘转发到本地服务。整个过程中公网永远无法直接探测到你的真实 IP更像你对 Cloudflare 说“帮我带个话”而不是把自家大门敞开后对外吆喝。安装并登录 cloudflared 后我当时的做法是cloudflared tunnel login cloudflared tunnel create home然后写一份 config.yml把某个域名映射到本地端口tunnel: 你的隧道ID credentials-file: /root/.cloudflared/证书路径 ingress: - hostname: nas.example.com service: http://localhost:8096 - service: http_status:404最后把域名路由到隧道并跑起来cloudflared tunnel route dns home nas.example.com cloudflared tunnel run home这样我家的媒体服务就获得了nas.example.com这个域名访问路径在全球绕了一圈之后落到内网。缺点是多了一跳延迟但好处是不再需要路由器的端口映射不用理会家庭宽带是否给了公网 IP也彻底断了被扫描器发现的可能。4.2 Access 策略让私密页面只对指定身份开放光有隧道还不够nas.example.com虽然隐藏了真实 IP但它终究是一个公网域名任何人访问都会被解析到隧道入口。这时 Zero Trust 里的 Access 就要出场了。在 Cloudflare Zero Trust 控制台新建一个 Self-hosted Application域名填nas.example.com。访问策略可以这样配只允许特定邮箱前缀或指定邮箱登录登录时需要额外通过一次性验证码校验。配置完成后所有访问在到达本地服务之前先经过 Access 认证未登录用户根本看不到背后的页面。这一步很多人会忽略但恰恰是“接入公网”和“等于裸奔”的分水岭。我的原则是任何通过 Tunnel 暴露的本地服务必须套一层 Access。哪怕只是自己用也要留着那层认证因为家庭网络环境远没有你想象的干净。4.3 域名架构、预览环境与灰度发布的思路既然是“操作系统”就要考虑多环境和版本迭代。Pages 天然支持分支预览每次 push 到非生产分支都会生成一个独立的预览 URL这相当于你的 staging 环境。生产环境走主分支稳定可控。Worker 发布也支持版本化操作可以先上传新版本在控制台按比例切流量观察日志没问题再全量上线。我通常会拿十分之一的请求到新版本跑上半小时没有异常再切剩下 90%出问题随时回滚到上一版本整个发布过程对用户无感。这套节奏以前在 VPS 上得靠 Docker 镜像加负载均衡才能实现现在平台原生就支持省心不少。5. 我在实际部署中踩过的坑与排查链路讲完全部流程必须把坑讲透。外面很多教程只展示“完美路径”但真实生产里你碰到的怪问题才是劝退人的部分。下面几条都是我真金白银踩出来的。5.1 KV 读慢了先别骂平台查缓存键设计有段时间我的 API 响应从 200ms 涨到 1.2s先怀疑是不是 D1 查询慢结果日志显示慢的是env.KV.get(key)。按常识KV 是边缘缓存应该快到飞起才对怎么反而成了瓶颈我打开wrangler tail看每次请求的实际耗时和键名发现一个问题我写代码时为了防止数据过期每次请求都在键后面拼上了当前时间戳。结果就是每个请求都在读一个全新的键缓存永远命中不了每次都穿透到底层存储速度自然慢。我把键改成稳定值再把有效期控制放进去P90 耗时直接回到 30ms 以内。这个排查过程让我牢牢记住一件事KV 是缓存型存储不是无限精确的数据库。它的性能优劣完全取决于缓存键设计键越稳定命中率越高。5.2 D1 的连接模式与并发限制刚开始从自建 Postgres 迁移到 D1 的时候我犯了“把 D1 当本地数据库”的毛病。某个页面对外的接口在高峰期同时来了三十几个查询请求结果日志里冒出一串 500 和 timeout。D1 的底层是分布式的 SQLite单次查询需要从边缘节点穿回主数据区域执行并发能力不是本地直连数据库那种规模。应对策略我列了三层对读多写少的表把数据镜像到 KV 缓存关键查询走 KV回源 D1 只在缓存过期时发生对写入路径做削峰把高频写操作丢到队列里异步执行避免瞬时请求量打满数据库尽量把 SQL 拆小一次操作别跨多个表做大范围扫描按分区按索引精准查询。我现在的习惯是先画数据流图分清哪些请求必须实时读数据库哪些可以容忍最终一致。容忍度越高的部分越往 KV 和缓存层放。5.3 Workers 体量限制逼出来的“瘦身”方案我第一次把带 Express 依赖的旧代码直接部署到 Worker 时部署直接报错提示压缩包超过限制。Workers 的运行环境不是完整 Node任何大依赖都会让发布失败。解决办法其实不神秘把重框架换成原生fetch路由不用的依赖全部拆掉静态资源一律移进 R2不在代码包里携带。业务逻辑上把一个 Worker 拆成多个职责单一的 Worker各管一摊不要图省事全塞进去。压完包之后我的代码量缩小到原来的十分之一不止部署速度也快了。这里可以做个对比参考错误做法正确做法效果引入完整 Express用原生 fetch 手写路由包体积大幅下降把几 MB 依赖打进代码依赖由平台内置或拆成独立 Worker部署成功率提升静态资源塞进代码图片等放 R2 再引代码纯逻辑化一个 Worker 管所有业务按边界拆成多个 Worker单个服务可独立发布5.4 免费额度“看起来很多撞墙才知道”曾经有一个公开的图片聚合站一天内被爬虫打了大几十万次 Workers 调用免费额度直接告警正常用户也跟着受影响。问题倒不在 Workers 的请求额度而是 KV 的写操作额度很小我当时把访问日志直接写进了 KV等于把日志收集器架在一个只适合存配置的热存储上不撞墙才怪。后来我做了三件事一是打开账单和用量提醒给邮箱设置告警用量达到一定比例就通知二是在 CDN 层加缓存规则对明显的爬虫流量直接拦截减少 Worker 调用三是日志类数据改走 R2 的批量写入或直接丢弃不重要明细KV 只保留对用户有实际价值的配置状态。内存和存储资源各有各的定位不要贪方便什么都往里塞。这个经验在传统服务器时代完全不存在因为你有磁盘有 CPU想怎么折腾都行。到了 Serverless 环境额度是硬约束代码写之前就必须先算清楚每个存储组件对应的是什么用量。最终折腾下来我现在对“服务器”这个概念的态度有了明显变化个人项目能不上 VPS 就不上cloudflare-os 这套模式把基础设施的复杂度降到了几乎不需要关注的程度。每次我拿到一个新点子都先问自己一句——我真的需要一台服务器吗只要答案是否我就按照这篇文章的模板往下走Pages 管壳子Workers 管逻辑D1 管结构化数据R2 管文件Tunnel 和 Access 管私有入口再用 Cron 让系统自己动起来。省下来的时间多写几行业务代码比什么基础设施都值。

没有主机的个人云：基于Cloudflare Workers的无服务器架构实践

相关推荐

4-20mA回路供电拓扑解析：两线制与四线制的本质区别与现场判断

深度学习与异步爬虫在金融舆情分析中的应用

S7-1200 PLC八段LED与交通红绿灯实验工程解析

更多资讯

JDK 1.8 + Tomcat 7 外网访问配置全指南

数字孪生技术路线分化与AI原生落地：选型、成本与最小闭环

100V转220V单相逆变电源Matlab/Simulink仿真与参数设计

gpmall.zip实战指南：Spring Cloud微服务教学项目启动避坑全解析

东钱湖春节主题活动：童话与财神文化的创新融合

罗德与施瓦茨FSW频谱仪SCPI远控稳定性实战指南

今日更新

微信个人号API开发案例：图片/语音/视频消息怎么下载解析存到本地？

Python股票自动交易系统源码解析：从行情获取到风控的完整链路

视酷酷信IM源码部署指南：Java 17+MySQL 8.0.33实战配置

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？