Cloudflare 边缘架构

边缘的真正含义

"Edge Computing"被用得太泛。Cloudflare 的边缘非常具体:全球 330+ 城市的 PoP,每个 PoP 都能运行你的代码、读你的数据库、缓存你的对象。不是"有几个节点加速",是一整套运行时。

V8 Isolate:不是容器,也不是 FaaS

Lambda/Vercel Functions 等 FaaS 用容器或 microVM 隔离,每次冷启动要启一个进程,耗时 100-500ms。Workers 用的是 V8 的 Isolate——一个进程里装上千个相互隔离的 JS 环境。

Anycast 路由

你部署一次 Worker,Cloudflare 自动把它推到所有 PoP。用户请求通过 Anycast IP 到达最近的 PoP,由那个 PoP 执行。不需要你配置区域、不需要负载均衡——路由是 BGP 级别的事。

用户(上海)  ──DNS──>  cloudflare.com
                              │
                       BGP Anycast
                              │
            ┌─────────────────┼─────────────────┐
            ▼                 ▼                 ▼
       上海 PoP          东京 PoP           法兰克福 PoP
       (被路由到)       (未被选)           (未被选)

Cloudflare 产品矩阵

计算模型的三个关键约束

1. CPU 时间,不是 wall-clock

Workers 按 CPU 时间计费(Free 10ms、Paid 30s)。await fetch() 等 IO 的时间不算 CPU。这是它能便宜的原因——十万个请求同时在 await,都只算一个 Worker 在"存在"。

export default {
  async fetch(req) {
    // fetch() 的等待不算 CPU 时间
    const [a, b] = await Promise.all([
      fetch('https://api.a.com'),
      fetch('https://api.b.com'),
    ]);
    return new Response('ok');
  },
};

2. 无文件系统、无长连接

Worker 是请求作用域的。每次请求起一个 Isolate(或复用现有的),请求结束后状态可能消失。任何"全局缓存""连接池"想法要重新思考——答案通常是 KV 或 Durable Object。

3. 子请求数量有限

一个请求内最多 50 个子 fetch()(Paid 1000)。这强迫你把逻辑想清楚,别在一个请求里循环调 100 次外部 API。

什么场景适合 Cloudflare

免费额度(2026)

对个人项目、Demo、初创,这套免费额度已经能跑到"被媒体报道"的量级。

一个心智模型

把 Cloudflare 想成一个分布式操作系统:

这一章理解完,后面每一章都是在"这个操作系统上"装一个系统级能力。

本章小结