Serverless 成本模型是什么
函数类服务按调用次数与执行时长计费，时长通常与内存规格挂钩（按 GB-秒折算），另外还有出网流量、日志采集与上下游请求等附加成本。它的优势在低频、突发、事件驱动的负载：没有请求就不计费，也没有为峰值预留的常驻容量。反过来，高频长任务或稳态高并发负载常常比常驻服务更贵，因为每一毫秒都在计费，冷启动与并发限制还会影响用户体验，所以选型必须用实测数据而不是印象。
基本信息
| 计费 | 调用次数 + 执行时长（内存规格相关）+ 出网流量 |
|---|---|
| 优势 | 弹性快、无闲置成本、按秒级计费 |
| 注意 | 高频长任务与冷启动场景需实测对比 |
| 限制项 | 并发配额、单次执行超时、包体积与依赖规模 |
| 配套成本 | 日志与可观测采集量、死信与重试带来的额外调用 |
典型使用场景
- 低频后台任务（对账、报表、清理）替代常驻服务
- 事件驱动处理（对象存储事件、消息触发）按需执行
- 流量波动极大的接口，用弹性替代为峰值预留容量
- 新功能验证期快速上线，先跑通再评估是否常驻化
- 评估现有常驻服务中哪些模块可以函数化以省掉闲置成本
测算要点示例
测算要点示例
统计：日均调用量、平均执行时长、内存上限 # 三项决定计费基数，先测准再比价
对比：常驻服务月成本 vs 函数月成本 # 用同一负载模型跑，口径不一致就没意义
考虑：冷启动影响与并发限制（结合体验要求） # 延迟敏感链路要单独压测确认
附加：出网流量与日志采集量 # 常被漏算，量级起来后不可忽视
结论：给出适用边界而非绝对值 # 明确多大流量规模下函数才划算成本构成读法
| 成本项 | 计费方式 | 容易忽略的点 |
|---|---|---|
| 调用次数 | 按请求数计费 | 重试与轮询会成倍放大调用量 |
| 执行时长 | 按内存规格与耗时折算 | 内存调高可能更快但总费用反而上升 |
| 出网流量 | 按流量计费 | 跨区调用与回源会额外产生费用 |
| 日志与可观测 | 按采集量或存储计费 | 调试期全量打印日志极易失控 |
| 上下游请求 | 数据库、队列、对象存储按次计费 | 函数拆得越细，下游请求数增长越快 |
函数数量膨胀后会形成看不见的常驻成本：定时触发器、失败重试、日志全量采集和死信队列的调用都会持续计费，因此成本看板要按函数维度展示调用量与费用，而不是只看服务总额。