上个月在南京徐庄软件园的咖啡馆碰着老周。
他脸都熬绿了。
去年中秋大促的阴影还没散。他团队做的是南京本地的盐水鸭预制菜电商，当时提前一周压测了八台配置拉满的ECS，刚开卖十分钟就被涌进来的秒单流量冲垮了，运维小哥抱着监控屏在机房蹲了整整三天，换了三波临时扩容的服务器，最后还是因为接口超时丢了快两百万的订单，老板在复盘会上骂到整个部门抬不起头。
不是所有崩掉的服务都要堆服务器救
之前他们碰到流量涨的第一反应永远是加服务器。算下来账其实根本不划算：一年十二个月，只有大促那十几天的流量能把服务器跑满，剩下的大半年时间，那些服务器空跑的资源，每个月的云账单都够发半个月的团队奖金。
真正让他们对Serverless改观的，是个没人当回事的小功能。去年国庆做活动报名通道，本来还是准备开两台ECS扛流量，结果运维小哥临时赶项目没时间搭环境，图省事直接把报名接口的代码扔到云函数里，配了个HTTP触发就上线了。
那天通道开了之后，瞬间涌进来五千多个报名请求，函数稳稳扛住了，连个报错都没出。等活动结束看账单的时候，三个人凑在屏幕前数了半天——总共八块三毛二。
老周说当时以为云厂商算错了，反复核对了三遍账单明细，真的是八块多，连买杯冰美式都不够。
别被厂商的宣传PPT骗了Serverless不是万能药
不过话说回来，我之前也被云厂商的销售拉去参加过好几次Serverless的专场沙龙，台上的讲师把这东西吹得好像能把整个IT团队裁得只剩两个写代码的，结果下来问了几个已经落地的同行，全是踩了一屁股坑才摸出来的门道。
老周他们一开始就踩了个大坑：听了几场分享就头脑发热，把核心的订单支付逻辑直接迁到了Serverless上。结果上线第一周就碰到了最常见的问题——冷启动延迟：函数长时间没有请求进来的时候，云厂商会把闲置的计算实例回收，第一次请求触发的时候要重新拉取代码包、初始化运行环境，整个过程大概有两三百毫秒的延迟，对支付这种要求毫秒级响应的核心链路来说，用户点了付款按钮盯着加载圈等半秒，十个人里有三个会直接退出去，算下来的流失损失，比省下来的那点服务器钱高太多了。
折腾了半个月他们才摸清楚边界：像活动页面生成、用户上传图片压缩、大促临时报名通道、日志初步清洗这类非核心、流量波动极大、不需要长连接的功能，用Serverless真的香，靠自动扩缩容和按量计费两个特性，不管流量怎么涨都不用慌，没流量的时候一分钱不花。但核心的订单数据库、支付通道、需要长连接的客服IM系统，还是老老实实放在原来的ECS或者容器集群里，别瞎折腾。
真要落地Serverless别一上来就全量迁移
很多团队一提到要上Serverless，第一反应就是要把整个系统拆成细碎的函数，搞全量的云原生转型，最后折腾半年啥效果没有，还把原来稳定跑的系统搞出一堆问题。
老周他们的落地节奏就很实在：先把那些最适合Serverless的定时任务迁过去——比如每天凌晨的订单对账、用户消费积分统计，这些之前要专门留一台服务器24小时跑的任务，直接改成定时触发的云函数，第一个月账单就省了六千多。当然一开始也不是顺顺利利的，第一次迁任务的时候，没注意控制台的触发时间设置，把本来应该凌晨两点跑一次的对账任务，不小心选成了每十分钟触发一次，连续跑了整整三天，最后看账单的时候差点跳起来——那三天的函数调用费居然比之前跑这任务的服务器月费还高，折腾了半天才把设置改回来，说起来都是泪。
之后再把那些一年只用十几天的活动类功能迁过去，比如中秋月饼券秒杀、国庆到店自提预约通道，这些场景要是单独买服务器，一年下来成本得好几万，用Serverless的话，大促那几天的费用加起来可能都不到一千块。
写函数的时候也别搞那种一个函数扛所有逻辑的骚操作，单函数的代码量尽量控制在几百行以内，异常捕获、日志输出、监控告警一样都不能少——别觉得Serverless就不用管运维了，上次老周他们那个图片压缩函数，因为没写异常捕获，用户传了个损坏的图片直接卡死，连续报错三个小时才被用户反馈发现，之前配好的监控面板，居然没人设置告警通知，白瞎了云厂商送的免费监控额度。
说白了。
Serverless从来不是什么要把传统架构全部推翻的革命。
就是给你手里多了一把趁手的螺丝刀。
拧小螺丝的时候别硬扛着用大铁锤，也别拿着螺丝刀去拧钢筋。
对了，老周他们这个月的云账单，比去年同期少了快四成。
运维小哥现在每天六点准时下班，再也不用在机房蹲大促了。