FaaS 执行模型

Function as a Service 的核心契约：你提交 Handler，平台在事件到来时拉起运行时、传入 payload、执行、返回（或异步 ack）。理解生命周期、并发与超时，才能解释冷启动、账单项和「为什么我的函数被杀了」。

学习目标

• 描述一次 invocation 从调度到回收的阶段
• 区分同步调用、异步调用与事件源映射
• 掌握并发、超时、内存—CPU 配比等平台限制

生命周期（简化）

事件到达 → 调度器选实例（新建 or 复用 warm）
        → 加载 Handler / 初始化运行时（冷启动成本）
        → 执行 user code（受 timeout 约束）
        → 返回结果 or 写入 DLQ
        → 实例保留一段时间（warm）或销毁

Warm 实例 复用同一进程：全局变量可跨调用保留——这既可以是 连接池缓存 的优化，也可能是 脏状态 的陷阱。

并发与隔离

概念	含义	设计影响
并发执行数	同一函数同时跑多少 invocation	账户/函数有上限，需申请提额
Reserved / Provisioned	预留 warm 容量	换稳定延迟，见 srv-cold-start
隔离	通常一 invocation 一隔离环境	不要假设多线程共享可变全局状态

与 scale-load 不同：FaaS 自动水平扩，你写的是 幂等、短、无阻塞 的逻辑，而不是自己调 replicas。

超时与资源

• Timeout：硬上限（如 Lambda 最大 15 分钟），超时被强杀
• Memory：不仅影响 RAM，还关联 CPU 份额——加内存有时 缩短总耗时、反而省钱
• Payload 大小：API 同步请求有 body 上限；大文件走 S3 事件而非直传

// 反模式：在 Handler 里同步调用慢外部 API 且无 timeout
// 正模式：短 Handler + 写队列，重活给下游消费者（见 kafka-intro）

与消息队列的对照

长任务、削峰填谷更适合 队列 + 消费者：kafka-intro 讲日志型 broker；AWS 上常见 SQS 触发 Lambda。FaaS 擅长 单条消息的快速处理，不擅长 长时间流式计算。

练习

• 画时序图：API Gateway 同步调用 Lambda 成功与 timeout 两种路径
• 说明为何「全局静态 DB 连接」在 warm 实例上可能有效，在本地单测却不够
• 查 AWS Lambda 文档，记录默认 timeout 与最大 memory

小结

FaaS = 事件调度 + 短生命周期 + 平台管扩缩。 下一课落到 AWS Lambda：Handler 签名、IAM 与部署包结构。