Edge 部署与全球分发

传统的 Web 应用部署在某个数据中心（比如美东 us-east-1），全球用户都要跨越物理距离访问这个单一节点。Edge 计算将代码推到离用户最近的边缘节点执行——从"一个中心服务所有人"变成"在每个用户身边部署一个服务"。本章深入解析 Next.js 的 Edge Runtime、边缘缓存策略、全球分发架构和区域化部署的技术细节。

1. 理解 Edge 计算

1.1 Edge 计算的本质

传统模式：
  东京用户 ──[180ms]──→ 美东服务器 ──[180ms]──→ 东京用户
  总延迟：~360ms

Edge 模式：
  东京用户 ──[5ms]──→ 东京边缘节点 ──[5ms]──→ 东京用户
  总延迟：~10ms

物理距离决定延迟下限。光在光纤中的速度约为真空光速的 2/3，从东京到美东的单程光延迟约 67ms，加上路由跳转，实际往返延迟约 180-250ms。这是物理定律限制，无法通过优化代码解决——唯一的办法是把代码搬到离用户更近的地方。

1.2 Edge vs Serverless vs Server

1.3 Edge 的能力边界

Edge 运行时是 V8 引擎的精简版本（类似 Web Worker），不是完整的 Node.js：

✅ Edge 可以做的事：

• 读写 Cookie
• 重写/重定向 URL
• 设置 Headers
• 读取环境变量
• 调用外部 API（fetch）
• 简单的数据转换和逻辑
• KV 存储读写

❌ Edge 不能做的事：

• 使用 Node.js 原生模块（fs、path、crypto 的部分 API）
• 直接连接数据库（TCP 连接）
• 使用大量内存的操作
• 长时间运行的任务
• 使用依赖 Node.js API 的 npm 包

这个限制是刻意的——精简运行时才能实现毫秒级冷启动和全球部署。

2. Next.js 的 Edge Runtime

2.1 两种运行时

Next.js 提供两种运行时，可以按路由级别选择：

2.2 哪些 Next.js 功能可以运行在 Edge

2.3 Middleware：天然的 Edge 计算

Middleware 是 Next.js 中唯一默认运行在 Edge 上的功能——它在请求到达你的页面之前执行：

用户请求
    ↓
边缘节点接收
    ↓
Middleware 执行（Edge Runtime）
├── 重定向？ → 302 重定向
├── 重写？ → 内部路由到不同页面
├── 修改 Headers？ → 添加/修改响应头
├── 身份验证？ → 检查 Cookie/Token
└── 放行 → 请求继续到 Server Component
    ↓
Server Component 执行（Node.js 或 Edge）
    ↓
返回 HTML

Middleware 的典型用途：

2.4 何时选择 Edge Runtime

选择 Edge Runtime 的场景：

不适合 Edge Runtime 的场景：

3. 边缘数据库与存储

3.1 数据库连接的边缘难题

传统数据库（PostgreSQL、MySQL）使用 TCP 长连接。Edge Functions 的问题：

1. 无法建立 TCP 连接——Edge Runtime 不支持 net 模块
2. 连接池无法复用——每个边缘节点是独立的，连接池碎片化
3. 延迟问题——即使能连接，数据库在单一区域，边缘到数据库的延迟抵消了 Edge 的优势

3.2 边缘数据方案

3.3 HTTP 数据库访问模式

解决 Edge 环境下数据库连接的核心思路：用 HTTP 替代 TCP。

传统模式（Node.js）：
  应用 ──[TCP 连接]──→ PostgreSQL

Edge 模式：
  Edge 应用 ──[HTTP/fetch]──→ 数据库 HTTP 代理 ──[TCP]──→ PostgreSQL

这就是 Neon、PlanetScale、Supabase 等提供 HTTP API 的原因——让 Edge Functions 可以通过 fetch 查询数据库。

权衡：HTTP API 比 TCP 直连慢（每次查询需要 HTTP 握手），但在 Edge 环境下这是唯一的选择。对于读密集的场景，配合边缘缓存可以大幅减少数据库查询次数。

3.4 边缘缓存策略

用户请求
    ↓
Edge 节点
    ↓ 检查本地缓存
├── 缓存命中 → 直接返回（< 5ms）
└── 缓存未命中
    ↓ 查询数据库（HTTP API）
    ↓ 写入本地缓存
    ↓ 返回数据

缓存层级：

4. ISR 与边缘缓存

4.1 ISR 的边缘增强

ISR（Incremental Static Regeneration）在边缘环境下变得更加强大：

首次请求（缓存冷）：
  用户 → Edge 节点 → Origin 服务器渲染 → 缓存到 Edge → 返回 HTML

后续请求（缓存热）：
  用户 → Edge 节点 → 直接返回缓存的 HTML（< 10ms）

缓存过期（Stale-While-Revalidate）：
  用户 → Edge 节点 → 返回旧缓存（立即）
                    → 后台异步从 Origin 获取新版本
                    → 更新 Edge 缓存

4.2 按需重验证 + 全球缓存

CMS 发布新文章
    ↓
Webhook → Next.js revalidation API
    ↓
通知所有 Edge 节点清除该页面缓存
    ↓
下次请求该页面时重新生成

关键问题：全球缓存一致性

当你调用 revalidatePath('/blog/hello') 时，Vercel 需要通知全球 300+ 个边缘节点清除这个路径的缓存。这不是瞬时的——有几秒钟的传播延迟。

对于大部分内容场景（博客、文档、产品页），这个延迟是完全可接受的。但对于实时性要求极高的场景（股票价格、实时比分），不应该使用 ISR。

4.3 Cache-Control 与 CDN 行为

s-maxage vs max-age：

• max-age：浏览器缓存时间
• s-maxage：CDN/代理缓存时间（覆盖 max-age）
• 常见模式：s-maxage=3600, max-age=0（CDN 缓存 1 小时，浏览器不缓存）

5. 全球分发架构

5.1 Vercel 的全球架构

用户请求
    ↓
Anycast DNS → 路由到最近的边缘节点
    ↓
Edge Network（300+ 节点）
├── 静态资源 → 直接从 Edge 返回
├── Middleware → Edge 执行
├── ISR 页面 → Edge 缓存 / 回源重生成
└── 动态页面 → 路由到 Serverless Region
    ↓
Serverless Functions（特定区域）
    ↓
数据库（特定区域）

5.2 区域选择策略

5.3 多区域部署架构

对于真正的全球应用，需要多区域部署：

                          全球 DNS（GeoDNS / Anycast）
                              ↓
        ┌──────────────────────┼──────────────────────┐
        ↓                      ↓                      ↓
   美东区域                 欧洲区域                亚太区域
   Next.js + DB            Next.js + DB            Next.js + DB
   (us-east-1)             (eu-west-1)             (ap-northeast-1)

多区域的核心挑战：数据同步

实际建议：大部分应用不需要多区域部署——单区域 + CDN 边缘缓存已经能覆盖全球用户。只有当你的用户群真正分布在多个大洲，且对写操作延迟敏感时，才考虑多区域。

6. 边缘计算的实际应用

6.1 地理位置个性化

Edge 运行时可以获取用户的地理信息（IP → 国家/城市），实现：

6.2 A/B 测试

Edge 是实现 A/B 测试的理想位置——在请求到达服务器之前就完成分组：

用户请求 → Edge Middleware
    ↓
检查 Cookie 是否已有分组
├── 有 → 根据分组路由到对应版本
└── 没有 → 随机分组 → 设置 Cookie → 路由到对应版本

优势：

• 零闪烁：在服务端完成分组，用户不会看到页面切换
• SEO 友好：同一 URL 返回不同内容，搜索引擎看到默认版本
• 统计可靠：分组在 Edge 完成，不依赖客户端 JS

6.3 Feature Flags

Edge + Feature Flags 的组合非常强大——可以在毫秒内决定用户看到什么功能，且不增加服务端负载。

7. 性能优化策略

7.1 边缘缓存命中率优化

7.2 全球延迟优化

7.3 TTFB 优化对照表

8. Edge 部署的陷阱

8.1 常见问题

8.2 何时不用 Edge

• 业务逻辑复杂：超过 100 行的处理逻辑，用 Node.js Runtime
• 需要大量数据库交互：多次查询的事务，用 Node.js Runtime
• 依赖不兼容：核心依赖用了 Node.js API，无法替换
• 调试优先：开发初期用 Node.js Runtime，稳定后再迁移到 Edge

本章小结

• Edge 本质：将代码部署到全球 300+ 节点，通过物理距离优势减少延迟
• Edge Runtime 限制：不是完整 Node.js，不支持 TCP 连接、fs 模块、Node.js 原生 API
• Middleware：Next.js 唯一默认运行在 Edge 的功能，适合路由、认证、A/B 测试
• 边缘数据库：用 HTTP API 替代 TCP（Neon、PlanetScale、Turso），配合 KV 缓存
• ISR + Edge：静态页面在边缘缓存，stale-while-revalidate 实现零感知延迟
• 全球分发：大部分应用"单区域 + CDN"够用，多区域部署的核心挑战是数据同步
• 实际应用：地理个性化、A/B 测试、Feature Flags 是 Edge 的最佳场景
• 务实建议：默认用 Node.js Runtime，只在有明确收益的路由上启用 Edge