无服务器部署与 CI CD 自动化
11.2 Vercel部署架构选择
Tip
Vercel 之于前端，就像 iPhone 之于手机。虽然你失去了部分 DIY 的自由，但你获得的是极致的流畅与省心。
1. 为什么要学这个?
新手常问："为什么不把 Next.js 部署在 $5/月的 Digital Ocean 或阿里云轻量服务器上？" 答案是：你自己运维的精细度，永远比不上 Vercel。
- 全球加速：AWS CloudFront 配置极其复杂，Vercel 默认帮你配好了全球 100+ 个边缘节点。
- 预览环境：Vercel 会为你的每一个 PR 自动生成一个
https://project-git-feature-xxx.vercel.app。这一项功能，自己搭需要一个 DevOps 团队干一周。
Vercel 不是服务器，它是"前端云" (Frontend Cloud)。
2. 核心概念：Edge Network (边缘网络)
什么是边缘？
地球是圆的，光速是有限的。 如果你把服务器放在美国纽约，上海用户访问会有 300ms 的物理延迟（光纤来回）。 边缘 (Edge) 就是把静态资源（甚至计算逻辑）推送到离用户最近的节点（比如 Vercel 香港节点）。
Vercel 的魔法架构
- Static (静态资源): 图片、CSS、JS 自动推送到全球边缘。
- Function (动态逻辑): 默认在区域中心（如美东），但可以通过 Region 配置改到新加坡或日本。
- Edge Middleware: 运行在边缘的轻量脚本，拦截全球请求（如做 IP 封禁、A/B 测试）。
3. 解决方案 (HOW)
Vercel 内部工作流
当你执行 git push 时：
graph TD
Code["Git Push"] --> Build["Vercel 构建系统"]
Build --"1. 识别框架"--> Next["Next.js Build"]
Next --"2. 提取静态资源"--> CDN["全球 CDN (32个区域)"]
Next --"3. 提取 API"--> Lambda["AWS Lambda (Serverless)"]
Next --"4. 提取中间件"--> Edge["Edge Workers (Cloudflare/AWS)"]
CDN & Lambda & Edge --> URL["生成预览链接 (Preview URL)"]
style CDN fill:#fff9c4,stroke:#fbc02d
style Lambda fill:#e1bee7,stroke:#8e24aa
两种 Runtime 选择
1. Node.js Runtime (默认 & 推荐)
- 全能：支持所有 Node.js API (fs, net...)。
- 生态：可以使用所有 npm 包。
- 位置：单区域 (Region) 部署。
- 适用：绝大多数业务 API，尤其是需要连接数据库的 API。
2. Edge Runtime
- 极速：0ms 冷启动，全球分布。
- 阉割：不支持 Node.js API，只支持 Web Standard API (
fetch,Request)。 - 适用：简单的重定向、验证 Token、读取 Cookies。
4. 真实案例
Story
那个"绕地球两圈"的慢速请求
某国内开发者把 Next.js 部署在 Vercel（默认美东节点），但他买的 MySQL 数据库在阿里云（北京节点）。 灾难链路：
- 上海用户发起请求 -> 200ms -> Vercel 美东。
- Vercel 美东查询数据库 -> 200ms -> 阿里云北京。
- 阿里云北京返回数据 -> 200ms -> Vercel 美东。
- Vercel 美东返回响应 -> 200ms -> 上海用户。
仅仅是光速带来的物理延迟（RTT）就接近 1 秒，用户感觉网页卡顿。 修正：要么数据库买 AWS 的（离 Vercel 近），要么把 Vercel 区域切到新加坡（离中国近）。
Vibe 心法： 物理定律不可违背。Compute (计算) 必须靠近 Data (数据)。 如果你的数据库在国内，请慎用 Vercel 的 Serverless Function（除非你能接受跨洋延迟）。
5. 本章小结
- 预览部署：Vercel 最杀手级的功能，没有之一。
- 默认最优：默认的配置已经击败了 99% 的手动运维。
- 数据引力：部署区域的选择，取决于你的数据库在哪里，而不是用户在哪里（对于动态请求）。