去年帮苏州一个做小众家居的电商团队扛618大促。之前他们每次大促都要提前两周囤8台云服务器，光配置监控、压测、调带宽就要耗掉后端组一半的人力，结果去年换了Serverless的方案，整个大促峰值跑下来，后端组连半夜的告警电话都没接到。我当时去他们公司做方案的时候，还看到运维的电脑桌面贴了张便签，上面写着”大促不炸就是赢”，去年大促结束，他直接把那张便签撕了，说现在再也不用盯着监控屏熬大夜了。
那些被吹得神乎其神的好处，真不是画饼
别一上来就觉得所有技术宣传都是智商税。他们之前的库存同步接口，跑在固定配置的ECS上，平时一天也就几百次调用，资源利用率不到10%，大促的时候一秒钟能冲上来2000多次请求。之前的做法很简单，提前把实例数拉到最高，哪怕平时闲得发慌，钱也照付。
换了方案之后，这个接口的实例数会跟着实时请求量自动伸缩，流量来了自动扩容，流量退了自动缩容到零，连闲置的资源成本都省了。之前那个负责运维的小伙子，每次大促都要在公司打地铺，电脑开着监控面板，靠在折叠椅上眯两小时。去年直接提前休了年假，去舟山看海了。
当然，零运维的噱头听听就好。哪有那么好的事？至少你得自己写函数逻辑，得配好触发规则，得把冷启动的时间压到用户感知不到的区间。一开始他们把商品详情页的渲染全扔给函数，结果用户点进去要等1.2秒才出图，查了半天才发现是冷启动的时候Node.js的依赖包太大，每次初始化就要占800毫秒，用户当然会觉得卡。
很多人踩的坑，本质上是把它当万能银弹
我见过太多团队，刚接触Serverless就恨不得把整个系统全迁上去，最后摔得鼻青脸肿。
之前有个做即时通讯的创业团队，把整个用户系统的长连接聊天功能全迁到Serverless上，结果跑了不到半个月就崩了。为啥？函数实例是有执行时长限制的，最长也就十几分钟，长连接这种需要持续保持会话的场景，根本就不适合扔给Serverless。
长连接、常驻类的核心服务根本不适合Serverless。反过来，那种需要长时间跑的批处理任务，比如每月跑一次的账单统计，之前要单独开一台服务器跑一整夜，换Serverless的话，跑完全程自动销毁，算下来成本能降70%都不止。我见过最离谱的操作，是有团队把自己的核心数据库连接池全塞在函数的全局变量里，结果实例数上来之后，连接数直接把数据库打挂了，排查了整整两天才找到问题。
说真的，Serverless从来不是让你把所有老代码原封不动搬上去就完事的。你得顺着它的运行逻辑调整代码写法，比如别在函数里存需要长期保存的状态，所有状态都扔到外部存储里，不然哪天实例被回收了，你写的那些临时数据说没就没。
真要落地，别一上来就全量迁移
真的别犯傻。
很多人刚接触一个新技术，就想着把所有系统全换一遍，最后折腾得全团队疲惫不堪，还没拿到实际收益。正确的打开方式很简单，先从那些零散的、之前没人愿意维护的边角功能入手——比如用户上传图片之后的压缩处理，比如订单支付成功之后的短信通知，比如每天凌晨跑的库存同步脚本。这些功能之前散落在各个服务器上，没人愿意专门花精力维护，扔给Serverless跑，根本出不了什么大问题。
那个苏州的家居电商团队，第一次迁的就是用户上传晒单图片的压缩逻辑。之前这个功能跑在一台老服务器上，上个月刚因为磁盘满崩过一次，迁完之后根本不用管，图片传上来自动压缩成三个尺寸，存到对象存储里，每个月的调用费才12块钱，比之前单独开一台服务器一个月几百块的成本划算太多了。
别听那些人说Serverless会取代所有传统服务器。扯淡的。你要是做那种需要低延迟、长期驻留的核心服务，比如交易的核心链路，老老实实用容器或者固定实例就好。Serverless就适合那些流量波动大、逻辑相对独立的零散功能，把这些功能从原来的服务器上拆出来，能帮你省掉好多无意义的运维成本。
前阵子跟那个运维的小伙子吃饭，他说现在团队的后端人力终于能腾出来做新功能了，不用每个月花一半时间调服务器参数、处理突发的资源告警。
其实技术从来没有什么绝对的好坏。适合自己业务节奏的，就是最好的。别为了追技术热点硬上，也别因为听别人说有坑就完全拒绝。你先拿个小功能试两周，算一下成本，测一下性能，觉得合适再慢慢扩，比看一百篇厂商的通稿都管用。