凌晨三点，手机震了。
是 PagerDuty。某条队列的消费者函数一直在报错，然后重试……再报错，再重试。等早上打开账单，那条函数跑了将近四百万次，费用直接跳了两个量级。
说实话，那次之后我彻底改变了对 Serverless 的认知。
不是因为什么冷启动或者供应商锁定的问题——那些当然也要命，但真正让我觉得这个东西需要重新理解的，是一张账单。它比任何架构评审都直白。你写多少代码，代码里藏着多少循环和重试，最后都会变成数字，赤裸裸地摆在那里。
先说那个被忽视的问题
很多团队上 Serverless 的动机，其实和当年上 Docker 一样——看起来“先进”，招聘时能写在 JD 里，团队负责人可以在周会上说“我们已经在用云原生了”。但真正落到业务上，很多人根本没想清楚：哪些负载适合按请求计费，哪些不适合？
比如一个需要保持长连接的 WebSocket 聊天服务，你把它塞进 FaaS，每几秒一次心跳，每次心跳都触发一次计费。听上去单价不高，但累积起来，还不如租一台常驻的机器。可如果反过来，是那种每天只跑几次的定时任务、或者图片上传后的缩略图生成，Serverless 几乎是碾压级优势——你不需要为了那几个请求养一台机器，也不用在半夜被叫起来扩容。
这里面有一个很核心的概念，叫做“计费粒度”。
传统服务器是按时间租用，你花的是“存在成本”；Serverless 是按调用次数和运行时间计费，你花的是“行为成本”。这两个东西的底层逻辑完全不同。一旦你没把“行为”设计好——比如重试逻辑写得太激进，或者一个函数里做了本不该它做的事——成本就会像雪崩一样滚起来。
Serverless 到底改变了什么
我觉得最重要的是“责任边界”的转移。
以前运维要操心服务器、内核、运行时、容量规划。现在这些事情全部被推到了云厂商那边。你只需要写好函数代码。听上去很爽，对吧？但问题也恰恰出在这里——你只“看见”了函数，看不见下面的容器、网络和调度。
函数之间的通信，函数冷启动的延迟，并发限制，状态管理……这些东西不会因为你“看不见”就不存在。它们只是从“你能直接控制的变量”变成了“你必须绕开的约束”。
比如冷启动。Java 函数的冷启动可以轻松跑到几百毫秒甚至一两秒，而 Node.js 或 Go 通常要快得多。如果你的接口对延迟敏感，又要用 JVM 生态，那就得考虑预置并发或者 Provisioned Concurrency。但这些都不是免费的。
再比如状态。Serverless 函数天生无状态。你没法在函数实例里存任何东西——下一次调用很可能就是另一台机器了。所以你需要外部存储：Redis、DynamoDB、S3……这些东西的选择和调用方式，直接决定了你的架构好不好用。
我见过一个团队，把 Session 存在函数实例的 /tmp 目录里。本地测试完全没问题，因为请求少，同一个实例被反复调用。一上线，流量上来后，用户开始莫名其妙掉登录状态。排查了半天才发现问题。
落地的时候应该怎么开始
我一般建议从三个维度来筛选第一批 Serverless 场景：
第一，看调用频率。低频触发、突发性强的任务最适合。比如每天晚上跑一次的报表生成、用户上传文件后触发的转码、订单状态变更后的通知推送。
第二，看执行时长。Serverless 函数有超时限制，通常几分钟。如果你的任务是批处理、大数据运算，或者需要长时间维持连接，那就别硬塞进去。用容器或者专门的批处理服务更合适。
第三，看依赖复杂度。如果你需要大量本地库、或者对文件系统有强依赖，Serverless 会比较别扭。它的运行环境是临时且隔离的，每次调用都是一个全新的世界。
除了场景筛选，还有几个工程习惯，早做早省心。
一个是监控先行。不要等出了事才去查。函数的调用次数、错误率、持续时间、冷启动比例，这些指标要提前接入告警。尤其是调用次数——它跟你的钱包直接挂钩。我们后来设置了一条规则：任意函数的单日调用量超过基线三倍，立即告警。那条半夜重试的规则，后来再也没出现过。
另一个是死信队列。异步调用失败后，默认重试行为可能让你崩溃。一定要配置死信队列或者失败目标，把“处理不了的消息”捕获起来，而不是让它无限重试。
还有一个是本地模拟和集成测试。Serverless 的本地开发体验一直是个槽点。但可以通过 SAM CLI、Serverless Framework 的 offline 插件、或者 LocalStack 来搭建接近真实的本地环境。别等到部署上去才发现 IAM 权限不够。
最后，关于供应商锁定。我觉得这个话题被讨论得有点过度了。
Serverless 确实和云厂商深度绑定——IAM、触发器、日志、监控，全都是平台特有的。但话说回来，你用了 AWS 的 S3，用了 DynamoDB，用了 CloudFront，你本来就是在做一个技术选择，而不是在追求“可移植性最大化”。真正重要的是：你的业务逻辑能不能和基础设施解耦？函数代码里的核心逻辑是否足够干净、足够独立？
如果哪天真的要迁，你能把业务逻辑抽出来，重新接上另一套触发器，那就够了。
Serverless 不是银弹。它是一把很锋利的刀，用得好能切菜，用不好会切手。
而账单，就是那把刀的另一面。
它不会跟你讲道理，不会听你解释“这是个预期之外的流量高峰”。它只会告诉你：你的代码在这个平台上真实跑了多少次，花了多少钱。
从这个角度来说，它比任何架构评审都诚实。