当前位置:首页 > 科研成果库

Serverless冷启动:那个让你白等三秒的隐形坑,到底能不能填?

2026-10-02 05:21:10小研科研成果库13

上周翻自己三年前写的个人笔记小程序,周末闲了点开搜点东西,转啊转转了三秒才出内容。我站在地铁里刷卡刷不出来,网也不差,差点把手机扔了。一开始以为是小程序框架更新把我代码搞崩了,查了半小时才反应过来——哦,又是Serverless冷启动搞的鬼。

冷启动到底在「启」什么?

很多人刚接触Serverless,只知道「不用买服务器,按调用次数收钱,太香了」,很少会提前想到冷启动这回事。

Serverless的函数计算,本质上就是云厂商给你在共享集群里挤个地方放你的代码,没人调用的时候,不会给你留着运行环境。占资源啊,人家要把资源腾给别人用,才能多赚钱,也才能给你便宜的单价,对吧?

多久不用会被回收?不同厂商不一样,有的十几分钟,有的几十分钟,反正只要断了请求,大概率会被干掉。下次再来请求,就得从头来一遍:从镜像仓库拉你的代码镜像,分配CPU内存,启动容器,运行你写的初始化代码,全部跑完才能处理请求。

这一顿操作花掉的时间,就是大家说的冷启动耗时。

Serverless函数冷启动执行流程图Serverless函数冷启动执行流程图

说直白点,就像你去巷口的裁缝店做衣服,裁缝平时不把你的布料放操作台,只有你来了才从仓库翻出来,摆开缝纫机,找线头找剪刀——你等的那十分钟,就是你的冷启动。如果裁缝一直给你摆在操作台上,那就是一直跑着的热实例,来了就能做,不用等,那就是热启动。

哪些场景会被冷启动坑得睡不着?

哪些场景会被冷启动坑得睡不着?哪些场景会被冷启动坑得睡不着?

不是所有场景都怕冷启动。我后台跑个每天凌晨生成周报的任务,晚启动十秒,谁能发现?钱省了,爽得很。

怕的是用户刚好在等的场景。比如小程序首页请求,个人博客的访问接口,APP的登录验证,用户点完屏幕,超过两秒没反应,转身就走了,根本不会给你等冷启动的时间。

之前帮一个做手工银饰的朋友改小程序,他图便宜把所有后端接口都扔在了Serverless上,店铺本来流量就少,一天才几十个访问,两次访问间隔远远超过实例回收时间,所以每个新进来的用户,都得等三秒的冷启动。他跟我吐槽了半个月说为什么留不住客,我一抓包,光是冷启动就花了2.8秒,换你你走不走?

还有突发流量的场景。比如你发了一篇爆文,链接挂在文章里,突然一千个用户同时点进来,原来的一两个实例根本扛不住,云厂商就得给你开几百个新实例,每个新实例都得冷启动,最后就是大部分用户都卡在那,等半天出不来,流量白来。

说多了都是泪。

还有那种端内的轻量小程序插件,每次打开都要重新调函数,冷启动概率高得吓人,用户体验差到极点,运营还以为是产品做的烂,找谁说理去。

网上说的那些优化办法,真的有用吗?

现在确实有不少优化的路子,没有一个是完美的,各有各的取舍,别听营销号瞎吹全解决。

第一个就是预留实例,说白了就是你出钱,让云厂商给你一直留着运行实例,不回收。那肯定不会冷启动啊,问题是,你用Serverless不就是为了不用给闲置时间付钱吗?这下好了,你包了实例,和自己买个云服务器有啥区别?钱没省多少,事还多了。

第二个是定时预热,就是写个定时脚本,每隔十分钟八分钟给你的函数发个空请求,把实例唤醒,保持实例不被回收。这个办法成本低,适合流量不大、但是每次请求都要快的小服务,我自己的博客搜索接口就用了这个,一年下来也花不了几块钱。但是问题也明显,万一你的定时任务挂了,或者半夜断了,第二天起来全凉了,用户访问全卡在冷启动,你都不知道。还有突发流量的时候,原来预热好的实例不够用,新开的还是要冷启动,该卡还是卡。

第三个,也是最实用、零额外成本的,就是自己优化代码,把不必要的东西从启动阶段挪走。很多人写代码,一启动就把所有能加载的库都加载了,所有数据库链接都建好了,其实百分之八十的请求根本用不到这些东西。把这些改成懒加载,用的时候再初始化,一下子就能省好几百毫秒,积少成多,有时候就能把三秒的冷启动砍到一秒以内,用户根本感知不到。

Serverless冷启动优化方案优缺点对比Serverless冷启动优化方案优缺点对比

现在还有不少新技术,比如轻量容器启动,把冷启动耗时从原来的几秒降到几百毫秒,还有边缘Serverless,把代码放到离用户更近的节点,拉镜像的时间短了,也能快个几百毫秒。但本质上都是优化,没有办法完全消除冷启动,只要是按需回收实例的模式,冷启动就不可能完全消失。

说实话,很多人对冷启动的误解太深了。有人一提到冷启动就骂Serverless不好,其实很多时候冷启动慢都是自己造的孽。我见过有人把一个上百M的AI模型直接放到函数初始化里加载,一启动就十几秒,那能不慢吗?这种活本来就不该放在按需启动的Serverless函数里啊。还有人说冷启动必须解决,不解决就不能用Serverless,其实完全不是这么回事,选对场景就行。

不过话说回来,我用Serverless快五年了,冷启动遇过无数次,踩过的坑能凑一桌麻将。本来就是拿一点潜在的等待时间,换不用运维服务器、按调用付费的省心,哪有十全十美的事。你做一个用户量不大的个人项目,做后台异步任务,做对延迟不敏感的后端API,那冷启动根本不是事,省下来的钱和时间香多了。你要是做对延迟要求极高的核心入口,那要么花钱预留实例,要么就别往Serverless扔,绕开这个坑就是了。

下次你点开某个小网站,卡了个一两秒才出来,别着急骂运营商,说不定人家的Serverless实例,刚刚才从仓库里被喊出来干活呢。