Serverless踩坑后的落地真相

上个月帮杭州一个做宠物用品的小团队救大促的场。

之前他们用传统ECS搭的秒杀链路，去年大促崩了三次，运维小哥蹲在机房楼梯间哭的事我现在还记着。这次换了Serverless搭的链路，当天峰值12万QPS，整个团队除了运营在后台改库存，没人盯着服务器告警。

别再被Serverless的宣传稿骗了

很多宣传稿把Serverless吹得神乎其神，说什么‘零运维’‘零成本’。

哪有那么好的事。

上次那个团队刚上的时候，图省事把所有接口都塞函数里，结果冷启动延迟把用户卡到直接退单——就是那种点了提交订单转三秒圈，人直接跑去找别家买了。真的，那一周他们的客服后台全是骂‘点了付款没反应’的消息，运营盯着转化率掉了20%，脸都绿了。

后来拉着他们的技术负责人拆监控数据才发现，他们把需要常驻数据库连接的订单核心接口，全设成了按需触发的模式，每次冷启动要重建整个连接池，光初始化就要占300多毫秒，再加上函数本身的计算逻辑，整体接口延迟直接冲到了1.2秒，能不丢用户吗。

调了快一周才顺过来：核心的订单提交、库存扣减链路留了固定的常驻实例，非核心的比如优惠券计算、订单短信通知、用户行为埋点上报这些，全扔给按需触发的云函数。最后算下来，整个大促当天的资源成本，才花了两千三百多——之前他们光预留ECS实例一年就要掏12万，平时闲的时候资源利用率连10%都不到。

小团队用Serverless最爽的根本不是省钱

跟那个团队的后端聊，他说之前最烦的根本不是钱的事，是每次上新功能的流程太长了。

产品说要加个‘宠物生日提醒’的功能，先得申请服务器资源，配Java环境，搭Nginx转发规则，做压测防大流量冲垮，整个流程走下来至少三天，等功能上线，产品的热情都没了。

现在呢？

他写了个不到200行的云函数，配个每天凌晨两点跑的定时触发器，接个企业微信的消息模板，当天下午就上线了。根本不用管服务器在哪个可用区，出问题了直接在控制台看函数日志，连SSH都不用登。

之前那个天天处理告警的运维小哥，现在每天的工作就是扫一眼函数的调用量曲线，闲得在工位上撸公司养的橘猫。说真的，技术演进最实在的好处，不就是让大家少点无意义的机械劳动吗。

不过话说回来，别觉得上了Serverless就可以躺平。上次有个做内容社区的团队，上了Serverless之后半年没管过成本，后台账单拉出来一看，光日志服务的费用就花了九千多——原来他们写函数的时候没关debug日志，每次请求把全量的用户请求报文、甚至用户的cookie信息都打到日志里，存了快三个月，钱全交了日志存储费。

别把Serverless当万能解药

我见过太多团队，听了两场云厂商的发布会，回来就拍板要把整个业务全迁到Serverless上，最后踩得头破血流。

什么场景别硬凑Serverless的热闹？比如需要常驻长连接的直播推流服务，要跑持续几小时的离线大数据计算，或者对延迟要求到毫秒级的工业控制接口。之前有个做在线教育的朋友，把整个直播课的实时转码服务全迁到云函数上，结果函数的超时阈值设的15分钟，一节45分钟的课上到一半，函数直接超时断连，学生全在弹幕里刷‘卡成PPT’，校长在会议室脸都黑了。

说实话，别听那些销售给你画饼，说什么‘Serverless能覆盖所有业务场景’。他要是真能覆盖全场景，为啥他自己公司的核心交易系统还跑在传统虚拟机上啊？对吧。

真要落地，别上来就全量迁。先从那些非核心的、流量峰谷差特别大的、用完就走的业务开始试——比如临时的活动报名接口，定时发营销消息的任务，用户上传图片的压缩逻辑，这些东西就算出问题了，也不会把整个业务搞崩。核心链路留够弹性冗余，把冷启动的参数调合适，别为了省那点实例的钱，把用户体验搞没了。

前几天跟那个宠物团队的老板吃饭，他说现在终于不用在大促前一周就带着团队睡公司了。其实技术这东西，哪有什么银弹啊。能让你少熬夜出故障，少把时间花在无意义的服务器配置上，把精力放在真的给用户做有用的功能上，就是好技术。