10. Next.js 在 Cloudflare 上的部署挑战

在前面的章节中为了解决Page Functions单请求不能长时间执行的问题。我尝试用Cloudflare Queue去处理大批量任务和长时间执行的情况，但发现任务没有消费和通知机制。

于是我就开始查找答案，最终的解法是采用Cloudflare Workers解决，而不是用Cloudflare Pages进行部署。

但要理解这个问题，得从起源Serverless架构说起了。

Serverless 架构的演进与本质

Serverless 计算代表了云计算的一次范式转变，从根本上改变了应用程序的构建和部署方式。

Serverless 的核心哲学可以概括为"关注业务逻辑，而非基础设施"。这种思想源于云计算发展的必然趋势：

1. 计算单元的演进：从物理服务器 → 虚拟机 → 容器 → 函数

2. 抽象级别的提升：从硬件管理 → 操作系统管理 → 运行时管理 → 纯代码逻辑

3. 资源分配模式的变革：从静态分配 → 动态扩缩容 → 按需执行

这种演进反映了一个核心趋势：计算资源的消费正在从"预留"模式转向"即用即付"模式，类似于电力供应的公共设施模型。

从技术角度看，Serverless 架构建立在几个关键概念之上：

1. 事件驱动执行：代码仅在响应特定事件时执行，而非持续运行

2. 执行环境的临时性：计算环境可能在每次调用之间创建和销毁

3. 状态外部化：应用状态必须存储在专门的持久化服务中

4. 分布式执行：代码可以在地理分布的多个位置执行

5. 微粒度计费：按实际执行的计算资源（毫秒级）计费

这些特性共同定义了 Serverless 的技术边界，也决定了其优势和局限性。

显然各大厂商都有 Serverless 的布局，但Cloudflare更便宜、更成熟。

Cloudflare 提供了两种主要的 Serverless 部署方案：Workers 和 Pages。

Workers 是 Cloudflare 的核心计算平台，具有完全不同的架构设计：

1. 架构特点：


*   基于 V8 引擎的隔离执行环境（Isolates）

*   直接在 Cloudflare 的边缘网络节点上执行

*   完整的请求-响应生命周期控制

*   支持自定义路由和中间件模式

2. 技术能力：


*   更高的 CPU 和内存限额

*   完整访问 Cloudflare 平台 API

*   支持 WebAssembly 执行

3. 部署模型：


*   独立部署单元，不依赖构建系统

*   支持增量部署和版本控制

Cloudflare Pages 最初设计为静态网站托管服务，后来通过 Pages Functions 扩展了服务端能力：

1. 架构特点：


*   基于构建系统（Build System）和静态资产分发

*   Pages Functions 作为附加功能集成到静态资产服务中

*   使用 `_routes.json` 文件定义路由规则和函数映射