用Serverless扛住大促流量的真实细节

去年双11,我们7个人的小团队在软件谷旁边的办公楼里,蹲了快一个月做本地文旅小程序的大促版本。本来预案都做好了:租三台弹性ECS,拉上带宽,安排两个同事轮班值通宵,就怕预约接口被瞬间冲垮。结果临上线前一周,技术负责人拍板,把核心的预约接口全迁到Serverless上。

真的爽。

最后大促那三天,我们几个核心成员直接躲到公司楼下的茶社喝雨花茶,从下午坐到傍晚,钉钉里连一条报警消息都没收到。月底算账单的时候更惊了:所有函数调用加起来,总费用才1762块。之前预估的一万八的服务器成本,连零头都没花到。

那些被厂商吹过头的Serverless神话

刚接触Serverless的时候,我也被厂商的宣传页忽悠过。说什么”零运维””无限弹性””零成本启动”,听着跟白捡的便宜一样。真用起来才知道,哪有这么好的事。

上次有个新来的同事写预约接口的函数,没设数据库连接的复用逻辑,流量峰值的时候,每一次函数调用都新建一个数据库连接,没十分钟就把我们的MySQL连接数打满了。排查了俩小时才找到问题,那时候已经有几十个用户提交的预约请求因为数据库超时失败,还是我们一个个手动给用户回电话解释的。

还有人说Serverless能扛无限流量。拉倒吧。

我们第一次压测的时候就碰到冷启动的问题。就是服务闲了快半小时,没人请求,云厂商就把实例给收回去了,等下一个用户请求过来,要重新拉镜像、初始化运行环境,整个过程要个两三百毫秒。我们第一次碰到这情况的时候,还以为是代码写崩了,翻了半小时日志才反应过来。

Serverless函数冷启动延迟监控曲线图
Serverless函数冷启动延迟监控曲线图

别小看这两三百毫秒。我们做的是景区预约接口,用户点一下提交按钮,等个半秒才反应,早就觉得卡得要死,划走了。就跟你在楼下买鸡蛋饼,老板临时去隔壁拿鸡蛋,等个两分钟才回来摊饼,你早就走到下一个摊子了。

说白了,Serverless从来不是什么银弹。它就是个工具,吹得再神,该踩的坑一个都不会少。

哪些业务真的适合上Serverless

用了快两年Serverless,我们现在已经摸出规律了,不是所有业务都值得迁上去。

最适合的,就是那种流量波动极大、平时访问量极低、偶尔会冲一波高峰的接口。比如我们的景区预约接口,平时一天也就两三百个请求,大促的时候瞬间能冲到每秒上千请求。这种用ECS的话,你得按峰值的配置买机器,闲的时候机器空转,纯纯浪费钱。用Serverless的话,闲的时候根本不产生费用,流量冲上来的时候自动扩缩容,按实际调用次数算钱,算下来能省个七八成的成本。

还有那种触发逻辑特别简单的任务。比如公众号的用户消息回调,之前我们是在ECS上跑了个Node服务,隔三差五就内存泄漏挂掉,一个月得重启三四次。现在换成云函数,用户发消息的时候云厂商自动触发函数处理,没消息的时候啥资源都不占,快一年了我们都没管过这个服务,一次问题都没出过。还有那个每天早上8点要跑的用户报表,之前是写在ECS的crontab里,有时候机器重启了,定时任务没起来,报表就断更,现在用函数的定时触发器,从来没掉过链子。

小团队Serverless业务适配场景对照表
小团队Serverless业务适配场景对照表

反过来,有些业务真的别硬凑。比如我们之前有个视频转码的任务,要跑三四十分钟,结果云函数的最大超时时间就15分钟,根本跑不完,最后还是乖乖放回ECS上。还有那种对延迟要求到毫秒级的实时对战游戏,冷启动那几百毫秒的延迟,玩家早就退出去给差评了。

说实话,别听那些大公司的架构师说什么未来所有服务都要跑在Serverless上。我们这种小团队,本来就没几个专职运维,能少接半夜的报警电话,能省点预算给团队加奶茶,就够了。

上Serverless之前必须做的几个准备

踩了这么多坑,我们也总结了几个实打实的经验,准备上Serverless的团队,真的可以照着做。

头一件事,别上来就把所有核心服务都迁过去。先找那种非核心的、出点问题也不影响大局的服务试个两三个月,算下实际成本,摸清楚它的脾气,再慢慢迁核心业务。我们当初就是先迁了公众号的回调接口,跑了俩月没问题,才敢把预约接口迁上去的。

再就是,一定要把监控和日志配全。之前我们踩过一个大坑,云函数的日志默认只存7天,结果有一次函数报错,过了半个月才被用户反馈,那时候日志早就被清没了,连报错原因都找不到。现在我们直接把所有函数的日志实时导到自己的日志存储里,存够半年,出问题随时能查。还有成本预警一定要开,之前有个同事写的函数死循环,跑了一晚上,调用了12万次,扣了80多块钱,虽然钱不多,但是这种无意义的消耗真的闹心。现在我们设了阈值,单天成本超过50块就发钉钉提醒,比啥都强。

还有个最容易被忽略的点,别被云厂商绑死。虽然各家的Serverless函数语法都差不多,但是那些触发器、网关、权限的配置,全是跟特定云厂商绑定的,万一哪天要换厂商,迁起来能要半条命。最好把核心的业务逻辑全抽出来,跟触发器那层解耦,就算要换,也就是改几行配置的事。

哦对,还有冷启动的问题。对延迟要求高的接口,记得配个常驻实例,哪怕就留一个,也比用户进来等半秒强。那点常驻实例的成本,跟因为卡顿流失的用户比起来,真的不值一提。

上周我们跟旁边团队的技术负责人聊天,他说他们最近也开始用Serverless了,之前每个月在服务器上要花小两万,现在省了快一半,每天下班到点就走,根本不用留值班的人。

其实技术哪有什么绝对的好坏。

能帮小团队少花点钱,少加点班,少接半夜的报警电话,就是好技术。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:用Serverless扛住大促流量的真实细节
文章链接:https://www.itcdj.com/it/175.html