上个月帮朋友排查线上故障。
他公司把核心订单服务全迁去了Serverless，结果大促当天冷启动超时，直接卡了二十分钟，损失小十万。我看完他的监控曲线，半天没说话。这已经是我今年遇到的第三起Serverless踩大坑的案例了。
那些被吹上天的好处
很多人被云厂商的销售话术绕晕，觉得Serverless就是免运维、按用量付费、自动扩容，买了就等于捡了大便宜。
我第一次接触Serverless是2021年，当时给公司公众号做个签到活动，流量峰谷差极大——平时每天只有几百个调用，大促的时候能涨十万倍。要是按之前的套路，得提前一周申请ECS实例，压测、配负载均衡、盯监控，活动结束还要花两天清理资源，算下来人力成本比服务器成本高十倍都不止。
当时试了下Serverless函数，不用配服务器，直接上传代码就能跑，自动扩容到几百个实例都没掉链子。活动结束直接停掉，花的钱还不到之前的十分之一。真的香。
哪些场景真的能用
不过话说回来，Serverless不是什么场景都能套的。我自己用了这三年，总结下来只有两类场景真的合适。
一类是流量峰谷差极大的临时业务，比如抽奖活动、临时营销页、公众号签到接口。这类业务平时没人用，大促的时候流量爆涨，用传统服务器的话平时要浪费99%的资源，用Serverless刚好按调用量付费，不用管扩容缩容，活动结束直接不用管。
另一类是定时触发的轻量任务，比如每天凌晨跑的财务对账、用户数据报表生成、定时发推送。之前这类任务都是用Crontab挂在ECS上，万一ECS宕机，任务跑失败都没人知道。用Serverless的定时触发器，到点就自动执行，根本不用管服务器状态，我们把财务的对账任务迁过去之后，半年没出过一次问题。
反过来，那种需要长连接的即时通讯服务，或者要常驻内存加载几个G大模型的推理接口，就别碰Serverless。冷启动一次十几秒，用户早就跑光了，纯纯找罪受。
踩过才知道的实坑
最先栽的跟头就是冷启动。所谓冷启动，就是函数长时间没流量的时候，云厂商会把闲置实例回收，下次请求过来的时候要重新拉代码、装依赖、初始化运行环境，整个过程要花几百到几千毫秒不等。
我们之前的签到服务刚上线的时候，凌晨几乎没流量，早上八点大家上班集中签到，第一波请求全部冷启动，平均超时1.2秒。用户点了没反应，以为是页面卡了，反复点，导致请求量又翻了一倍，差点把函数的调用配额打满。后来没办法，只能配了个定时预热任务，每天七点半自动发几个测试请求，把实例热起来，才解决问题。说真的，那阵子我见人就吐槽云厂商的冷启动优化。
第二个坑是权限配置。之前图省事，给函数绑了个全权限的角色，结果某次测试的时候代码写错了，把对象存储里存的用户身份证照片全删了。现在想起来还后背发凉。后来我们严格按最小权限配置，每个函数只能访问自己需要的存储桶和数据库表，才敢放心往上面放核心业务。
还有调试的麻烦。本地跑的时候好好的，上传到云上就报错，因为本地的运行环境和云上的不完全一致，有的系统依赖本地有，云上的运行时没装。后来我们干脆用云厂商提供的本地调试工具，先在本地模拟云上的环境跑通，再上传，省了好多来回排查的时间。
上周和某云的技术朋友吃饭，他说现在遇到最多的客户需求，就是上来就要全量迁Serverless，听着就头大。
哪有什么万能的技术。
适合自己业务的，才是最好的。