技术

用 Cloudflare Workers 搭建
自己的边缘计算节点

2026年4月约 1000 字阅读需 5 分钟
本文目录

不需要服务器,不需要运维,不需要为流量峰值担心——Cloudflare Workers 让你用一段 JavaScript 代码,就能把服务部署到全球 300 多个城市的边缘节点。这不是营销话术,而是我实际用了两年后的真实感受。

这篇文章不是官方文档的翻译,而是我踩坑之后提炼出的最短路径:从零到一个真正跑在全球边缘的服务,你需要理解什么、做什么、避开什么。

为什么是 Workers,而不是传统服务器?

传统的服务器部署逻辑是:买一台机器(或云主机),把代码跑在上面,用 Nginx 做反向代理,配 SSL,配域名,然后祈祷流量不要突然暴增。整套流程走下来,光是环境配置就能耗掉你半天。

Workers 的逻辑完全不同。你写一个函数,Cloudflare 负责把它运行在离用户最近的节点上。你不管机器,不管扩容,不管网络,只管业务逻辑。免费套餐每天有 10 万次请求,对个人项目来说绰绰有余。

「Workers 的本质是:把你的代码变成基础设施的一部分,而不是跑在基础设施上面的应用。」

五步上手,从代码到上线

一个最简单的 Worker 长这样:

export default { async fetch(request, env, ctx) { // 获取请求的 URL const url = new URL(request.url); // 根据路径返回不同内容 if (url.pathname === '/api/hello') { return new Response( JSON.stringify({ message: '来自边缘节点的问候' }), { headers: { 'Content-Type': 'application/json' } } ); } return new Response('Not Found', { status: 404 }); } };
· 进阶能力 ·

真正让 Workers 变强的三个组合拳

KV Storage:键值数据库,全球复制,读取延迟极低。适合存配置、缓存、用户 session。写操作最终一致,不适合高频写入场景,这点要注意。

D1 Database:基于 SQLite 的关系型数据库,直接在 Worker 里跑 SQL 查询。对于中小型应用来说,D1 + Workers 的组合已经能覆盖 80% 的后端需求,而且免费套餐相当慷慨。

R2 Storage:对象存储,兼容 S3 API,但没有出站流量费用。这一条就让很多人从 AWS S3 迁过来了——存图片、存文件,再也不用担心流量账单。

我踩过的坑,你不必再踩

Workers 有一个隐藏限制:单次请求的 CPU 时间上限是 10ms(免费版)。这不是网络时间,是纯计算时间。大多数请求根本用不到,但如果你想在 Worker 里跑复杂的加密算法或图像处理,就会撞墙。付费版可以提升到 30 秒,但那已经是另一个量级的应用场景了。

另一个常见误区是把 Workers 当传统服务器用,试图在里面维护内存状态。Workers 是无状态的,每次请求都是全新的执行环境,想要持久化状态必须借助 KV 或 D1。

「不要对抗平台的设计哲学,顺着它走,你会发现很多问题根本不需要解决。」

最后说一点:Cloudflare Workers 最适合的场景是轻量、高频、对延迟敏感的服务——API 网关、A/B 测试、请求路由、实时数据处理。它不是万能的,但在它擅长的领域,几乎没有竞争对手。

下次你想搭一个小工具、写一个 webhook、做一个简单的 API,先想想 Workers 能不能搞定——大概率可以,而且比你想象的简单。

评论