Serverless 与函数计算
函数计算以事件触发的函数为部署单元，平台负责伸缩与计费，开发者只交付代码。它适合突发流量、胶水集成与低频任务，前提是接受冷启动延迟、执行时长限制，以及必须把状态全部外置到对象存储、数据库或缓存中。
什么时候不该用
长时程批处理、长连接服务、依赖本地状态或本地文件的工作负载都不适合直接放进函数。另一个常见陷阱是函数直连数据库：突发流量下每个实例各占一条连接，很快打满数据库连接上限，需要通过连接池代理或缓存层收敛。
基本信息
| 伸缩 | 按请求自动伸缩，无需容量规划 |
|---|---|
| 限制 | 执行时长、内存、并发配额与冷启动延迟 |
| 状态 | 无状态，状态放对象存储、数据库或缓存 |
| 计费 | 请求次数、执行时长与出网流量分别计费 |
适用与规避
- 适合：事件驱动胶水、突发流量接口、低频定时任务
- 不适合：长时程批处理、长连接、依赖本地状态的服务
- 冷启动缓解：预留并发、精简依赖包、优化初始化路径
- 状态外置：中间结果放对象存储，会话放外部缓存
- 连接收敛：函数经连接池代理访问数据库，避免连接数打满
- 本地调试：SAM CLI、Functions Framework、Functions Core Tools 等模拟器
冷启动为什么重要
函数实例在闲置后被回收，下一次调用需要重新拉起运行环境并初始化依赖。这个过程在简单运行时可能只有几十毫秒，但依赖较多的运行时加上框架初始化会达到数百毫秒甚至更长。对延迟敏感的接口，常用做法是预留并发让实例常驻，或者把初始化工作从处理逻辑中剥离，只保留必要的执行路径。
成本与治理
- 按请求次数与执行时长计费，空转不花钱，但高频小函数的总成本可能高于常驻服务
- 并发配额是硬上限，突发流量到顶后请求会被拒绝或排队
- 版本与别名配合灰度发布，回滚时把别名切回之前的版本
- 函数权限按最小原则授予，避免一个函数持有全量云资源权限
函数之间的同步调用链过长会放大冷启动与超时风险；函数适合短小、边界清晰的任务，把编排交给专门的工作流服务。