何时使用Serverless？
1) 先把"Serverless"说清楚（以免误用）
工程上大家说的 Serverless 通常指两件事一起用：
- FaaS（函数即服务） ：代码以"函数/事件"为单位运行，平台负责弹性伸缩、实例管理与高可用
例：AWS Lambda / 阿里云 FC / 腾讯云 SCF / Azure Functions ... - Serverless 托管服务（BaaS） ：数据库/队列/存储/消息/API网关等都尽量用托管、按量的版本（对象存储、Serverless DB、消息总线等）
关键点：你仍然在"做架构"，只是把"一直跑着的服务器/容器集群"换成"事件触发 + 自动伸缩 + 按实际使用计费"。
2) Serverless 在实际开发中是怎么"用起来"的（常见落地形态）
A. HTTP API 后端（最主流）
典型链路：
Client → API Gateway / HTTP触发器 → FaaS function →（用到就接）托管DB / Redis / 对象存储 / 消息队列适合做：
- CRUD API、BFF（Backend For Frontend）
- 鉴权/令牌校验、请求改写、限流熔断的轻中间件层
- 多租户 SaaS 里"按租户隔离"的小服务（每个功能拆成函数或函数组）
实践上往往不是"一个接口=一个函数永远"，而是按限界上下文分组：同一服务的接口放在同一个函数应用/同一个仓库+路由分发，减少碎片化。
B. 事件驱动 / 异步工作流（它真正的舒适区）
Serverless 最强的地方是"被事件触发、干完就走"：
- 对象存储事件：文件上传 → 触发 Function → 做图片/视频转码、病毒扫描、元数据提取、写 DB 索引
- 消息/队列/日志事件：下单写消息 → Function 做库存扣减、发通知、同步ES、清理缓存
- 定时任务（cron/Timer）：报表生成、对账、清理过期数据、轮询第三方状态（但要小心长时间跑）
这类场景天然"突发""不可预测流量"，Serverless 能把峰值成本从"预留资源"变成"按事件付钱"。
C. 数据流水线 / ETL / 批处理（小到中型规模）
例如：
- 每小时把 OSS/S3 里的日志文件汇总 → 清洗 → 写入 OLAP/数仓
- Webhook 进来 → 标准化 → 入队 → 消费写入 DB
若单次处理很长（几十分钟）、或需要大内存/大磁盘，Serverless 就会开始"别扭"（超时、成本、本地状态难放）。
D. 边缘/轻网关逻辑（扩展用法）
- 边缘函数（Edge Functions / CDN边缘脚本）：做 A/B 路由、地区重定向、Header 改写、轻鉴权、防爬策略
- 这类更强调"低延迟、短计算"，不跑重业务逻辑
3) 什么场景"特别适合"Serverless（判断清单）
你可以把它当成一张速查表：
| 场景特征 | 为什么适合 Serverless |
|---|---|
| 流量波动大 / 峰谷明显 / 难以预测（活动、营销、爆款） | 弹性自动顶住峰值；闲时几乎不花钱 |
| 事件驱动：由存储/消息/Webhook/定时触发 | 天然"被触发→算→停"，利用率高 |
| 无状态、可重试：每次执行可失败重试、幂等 | 匹配 FaaS 生命周期（可能冷启动、可能被重复投递） |
| 对运维人力敏感：希望少管 VM/K8s | 少管宿主机、扩缩容、补丁 |
| 新项目 / 试验功能 / 快速验证 | 上线快，失败成本低 |
最适合的典型例子
- 图片/视频上传后的异步处理
- Webhook 接收与转发（支付回调、第三方事件）
- API 网关后面的轻量业务 API（尤其流量不稳定）
- 定时报表、对账、数据清洗（中小规模）
- 工单/消息通知/推送/邮件短信这类"触发型任务"
4) 什么时候不太适合 / 你要提前踩刹车
Serverless 不是银弹，这些信号要警惕：
- 长耗时 + 重 CPU/GPU ：多数 FaaS 有超时（常见 15min/29min 之类）与资源上限；更适合 容器/VM job 或拆分（拆成"调度 function + 真正 worker 跑在容器里"）。
- 强依赖本地状态/大文件临时存储：函数实例随时回收；必须靠外部存储（对象存储/DB/Redis/共享卷），否则你会被坑。
- 稳定超大流量 + 可预测 ：如果 QPS 很高且平稳，长期看 专用容器/K8s 往往成本更可控（Serverless 也有单价溢价）。
- 复杂单体迁移硬上 Serverless：把"一个巨大单体"直接剁成几百个 function 会制造分布式泥潭------应先做领域拆分、事件化，再逐步让合适边界用 FaaS。
- 冷启动敏感路径：例如首屏必须超低延迟的"主路径"接口，可能需要预热、保活、或改成常驻容器/ECS/K8s。
5) 落地时的"工程化经验"（避免把 Serverless 用成 chaos）
- 按领域分组，而不是按接口盲目炸碎
一个 service = 一个 function app / 一个部署单元，内部用路由区分接口。 - 所有关键异步流都当"至少一次投递"来设计
- 幂等键（idempotency key）
- 消费成功才 ack / 出队；失败进 DLQ（死信队列）
- 外部依赖一定要连接池化/复用（如果在支持 runtime 复用的情况下）
但要注意：不能假设"上一毫秒那个实例还在"。 - 可观测性别省：结构化日志 + traceId + 指标 + 错误告警；否则排查像抓鬼。
- 成本模型要算 ：
成本 ≈ 调用次数 + 执行时长×内存 + 配套托管资源；很多团队第一次用容易忽略"高频调用 + 每次跑太久"。