[!info] related notes

• 所属 MOC: nextjs-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

Vercel Functions 与 Fluid Compute

核心模型

Next.js 部署到 Vercel 后，服务端代码通常运行在平台托管的 Functions 中。应用不再拥有一台“永远在线、由自己管理进程生命周期”的 VPS，而是把请求执行交给平台调度。

Browser
→ Vercel Edge / CDN
→ Vercel Function
→ database / API / service

Fluid Compute 是 Vercel 当前的函数执行模型之一：它保留按需扩缩容，同时允许一个函数实例处理更多并发请求，并在等待 I/O 时更有效复用计算资源。

与传统 VPS 的关键差异

VPS / long-lived server
→ 进程通常长期存在
→ 内存状态可能持续到进程重启
→ 连接池由应用长期管理

Managed Functions
→ 实例生命周期由平台决定
→ 可能创建、复用、挂起或回收实例
→ 不能把本机内存当 durable state
→ 数据库连接必须考虑并发实例与连接上限

因此模块级对象可以作为“当前实例内可复用资源”，但不能被当作跨实例唯一事实。

什么可以放内存，什么不可以

适合实例内缓存 / 复用：

• 数据库连接池对象
• SDK client
• 编译后的 schema / validator
• 无需跨实例一致的短期计算缓存

不应依赖实例内存作为权威状态：

• 用户 Session 的唯一记录
• Job 当前状态的唯一副本
• 全局计数器
• 唯一锁
• 未落盘的重要业务数据

这些应进入数据库、Redis、队列或真正 owning service。

Region 与数据位置

函数位置会影响：

Function ↔ Database latency
Function ↔ downstream service latency

因此部署 region 应尽量接近主要数据源，而不是只追求离浏览器最近。对数据库密集型应用，函数到数据库的 RTT 往往比前端 CDN 的几毫秒差异更重要。

Fluid Compute 不等于“没有 Serverless 问题”

Fluid Compute 改善了传统 serverless 中的一些冷启动、并发和连接复用问题，但仍应保留以下原则：

• 不假设实例永久存在
• 不假设只有一个实例
• 不用进程内状态表达分布式唯一事实
• 数据库连接数要有上限
• 外部调用必须有 timeout / cancellation / retry policy

最短判断

需要 durable / globally consistent state？
→ 外部持久化系统

只需要当前实例复用？
→ module-level client / pool 可以

部署后数据库连接暴涨？
→ 先检查实例并发 × pool size × database max connections

这部分是 Full Stack Open Part 14 从“本地 Next.js”走到“真实托管运行时”时最重要的新增心智模型。