serverless-development

用途

本技能覆盖在无服务器计算平台上构建应用，这类平台将基础设施管理抽象化。它面向需要构建 API、Webhook、后台处理、定时任务，或任何受益于自动扩缩容、按用量计费和零基础设施管理的工作负载的场景。

主要能力

覆盖 AWS Lambda（Node.js、Python、Go 运行时）、Vercel Edge Functions 与 Serverless Functions、Cloudflare Workers。
冷启动优化。
无服务器设计模式（扇出、Step Functions、事件驱动）。
数据库连接管理。
使用 SAM/SST/Serverless Framework 部署。
监控与成本优化。

核心原则

为无状态而设计：每次函数调用都是独立的。不要在调用之间把状态存放在全局变量中（但可以复用连接）。使用外部状态存储（数据库、缓存、队列）做持久化。
最小化冷启动：冷启动会在首次调用时增加 100ms 到 10s 的延迟。保持打包体积小，使用轻量运行时，对延迟敏感的路径考虑预置并发。
连接管理至关重要：无服务器函数可能产生数千个并发实例，每个都打开自己的数据库连接会耗尽连接池。使用连接池（RDS Proxy、Prisma Data Proxy、PgBouncer）。
按调用付费思维：你为执行时间和内存付费。优化热路径，选择合适的 memory 大小（更多内存 = 更多 CPU = 可能更快 = 有时更便宜），并尽可能批量处理。
拥抱约束：函数超时、负载限制和并发限制是特性而非缺陷。围绕它们设计：长任务用队列，大负载用 S3，复杂编排用 Step Functions。

关键模式

模式 1：使用 TypeScript 的 AWS Lambda

适用场景： AWS 上的后端 API、事件处理、定时任务。

实现要点：使用模块级变量复用数据库连接（如 PrismaClient），在 API Gateway 处理器中设置 context.callbackWaitsForEmptyEventLoop = false；SQS 处理器支持部分批次失败上报（batchItemFailures），只重试失败消息；定时任务处理器执行清理等操作。配套 AWS SAM 模板定义函数、HttpApi 事件、SQS 事件（BatchSize 10、ReportBatchItemFailures）、Schedule 事件（rate(1 hour)）、处理队列与死信队列（DLQ）。

理由： AWS Lambda 配合 SAM 提供基础设施即代码、本地测试（sam local invoke）和自动化部署。通过模块级变量复用连接可避免每次调用重连的冷启动代价。SQS 的部分批次失败上报确保只重试失败消息。

模式 2：Vercel Edge Functions

适用场景： 需要贴近全球用户运行的低延迟 API 路由和中间件。

实现要点：在路由中设置 export const runtime = "edge"，读取 x-vercel-ip-country、x-vercel-ip-city 等地理信息头，使用边缘兼容的 KV 存储做缓存并设置 Cache-Control。中间件（middleware.ts）可用于边缘鉴权、重定向和 A/B 测试，通过 config.matcher 指定匹配路径，使用 NextResponse.redirect、NextResponse.rewrite 和 cookie 设置。

理由： Edge Functions 运行在 30 多个全球位置，冷启动为亚毫秒级（V8 隔离，而非容器）。它们非常适合鉴权检查、地理路由、A/B 测试和受益于贴近用户的 API 响应。代价是运行时受限（无 Node.js API、无原生模块、内存更小）。

模式 3：冷启动优化

适用场景： 延迟敏感端点出现不可接受的冷启动时间时。

实现要点：

用 esbuild 做 tree-shaking 最小化打包体积，将 @aws-sdk/* 设为 external（Lambda 中已可用），开启 minify、sourcemap。
懒加载重型依赖（如 sharp），仅在真正需要时动态 import。
对关键路径使用预置并发（ProvisionedConcurrencyConfig）。
使用定时预热（比预置并发便宜），通过 CloudWatch 规则 rate(5 minutes) 触发，处理器检测到 warming 事件时提前返回。

理由： 冷启动是无服务器的主要延迟问题。更小的打包初始化更快。懒加载把重型导入成本推迟到真正需要时。预置并发为关键路径完全消除冷启动（有成本）。预热调用让函数实例保持热态而无需支付预置并发费用。

模式 4：数据库连接池

适用场景： 任何连接关系型数据库的无服务器函数。

实现要点：Prisma schema 中区分直连（用于迁移）与池化连接（用于无服务器运行时）。AWS Lambda 使用 RDS Proxy；Vercel/Cloudflare 使用 Neon serverless 驱动或 Prisma Accelerate，配合 @neondatabase/serverless、@prisma/adapter-neon 和 ws（Node.js 环境需要设置 neonConfig.webSocketConstructor = ws）。使用模块级变量复用客户端。

理由： 每次 Lambda 调用都可能创建新的数据库连接。数千个并发调用会耗尽数据库连接上限（托管数据库通常为 100-500）。连接池（RDS Proxy、PgBouncer、Neon serverless、Prisma Accelerate）将大量无服务器连接多路复用为较少的数据库连接。

成本优化参考

策略	节省	代价
合理设置内存	20-40%	需要基准测试
ARM64（Graviton）	20%	少量兼容性顾虑
预置并发（对比过度配置的常开服务器）	对比常开节省 50-70%	扩容时延迟更高
预留并发	防止成本失控	限制吞吐量
批处理（SQS 批大小）	50-80%	延迟更高
分层存储（S3 生命周期）	30-60%	冷层访问延迟

反模式

反模式	为何不好	更好的做法
每次调用打开数据库连接	耗尽连接池	模块级连接复用 + RDS Proxy
打包整个 `node_modules`	冷启动巨大（5-10s）	用 esbuild tree-shake，external AWS SDK
在全局变量中存状态	调用间丢失（不可靠）	用 DynamoDB、Redis 或 S3 存状态
API 处理器 15 分钟超时	用户要等 15 分钟？	API 用 30s，长任务用 Step Functions
无并发限制	成本失控、下游过载	为每个函数设置预留并发
同步扇出	慢、有超时风险	用 SQS/SNS 扇出，异步处理
无结构的 `console.log`	CloudWatch 中无法搜索	带关联 ID 的结构化 JSON 日志

检查清单

[ ] 打包体积已最小化（esbuild tree-shaking，external AWS SDK）
[ ] 数据库连接已池化（RDS Proxy、Neon、Prisma Accelerate）
[ ] 冷启动已测量且对用例可接受
[ ] 延迟敏感路径已配置预置并发
[ ] 内存大小已基准测试并合理设置
[ ] 已启用 SQS 部分批次失败上报
[ ] 异步事件源已配置死信队列
[ ] 已设置预留并发以防止成本失控
[ ] 带请求/关联 ID 的结构化日志
[ ] 超时设置合理（API 30s，批处理更长）
[ ] 所有配置使用环境变量（无硬编码值）
[ ] 选择 ARM64/Graviton 运行时以节省成本

限制

资料未提供该技能的具体安装命令、收费与价格信息、支持的平台范围细节，以及除上述内容外的其他使用步骤。

技能介绍

用途