早高峰挤不上电梯：聊聊Serverless冷启动的那些事

上次帮发小做一个线下活动的报名小站，图省事直接用Serverless搭，不用买服务器不用运维，成本按调用算，想着怎么也亏不了。结果链接刚发出去预热，第一批点进来的用户直接炸锅——刷新完白屏等了快五秒才出内容，发小隔着电话都能闻见火药味。

为啥会这样？说白了就是踩了冷启动的坑。

说人话：冷启动就是便利店等第一个客人上门的那五分钟

很多人听Serverless觉得玄乎，其实核心逻辑特别简单：不用的时候，你的代码不跑，不用给钱；有人访问了，云厂商临时给你腾地方运行代码，跑完就撤。

冷启动是什么？就是你的代码已经被停了很久，下一次请求过来，云厂商得从零开始给你准备运行环境，这一整套准备的时间，就是冷启动耗时。

类比就是你家楼下只做白天生意的便利店，晚上没人就锁门关灯，所有设备都关掉省电。第二天早上第一个客人推门进来，老板得开门、开卷闸门、开收银机、接通冰柜电源、整理好货柜，这一套折腾下来，客人得等，这就是冷启动。

要是客人赶时间买个早餐，等五分钟肯定转身就走。换成网页，用户等三秒还出不来，九成九会关掉，你说这个坑大不大？

本质上，冷启动就是Serverless「按需付费、闲置不花钱」这个核心优势带来的副作用。想要省钱，就得接受闲置的时候销毁实例，那自然就会有从零启动的开销。天底下哪有既不花钱又一直待命的好事，对吧？

拖慢冷启动的凶手，大多是你自己埋下的

很多人一遇到冷启动就骂云厂商，其实大部分情况，问题出在自己的代码里。

我见过最离谱的，一个做静态页面转化的函数，把整个node_modules全打包进去，代码包快两百M，光云厂商拉代码就要一分钟，那不冷启动等五分钟才怪。

还有人喜欢把所有东西都放在启动阶段初始化：启动的时候连三个数据库，拉一份全量配置，还同步一遍缓存数据，这些加起来，一两秒就没了。

弹性扩缩容时新增的实例，同样会触发冷启动——这个很多新手不知道，流量突然涨上来，原来的实例扛不住，云厂商自动新建十个实例，每个新实例都要走一遍冷启动流程，运气不好前几个请求全撞上，用户体验直接垮掉。

不同语言天生冷启动速度差得也多。Go编译成单个二进制，依赖少，启动一般几百毫秒就搞定；Java的传统SpringBoot项目，光启动就要好几秒，要是再带一堆依赖，慢到你怀疑人生。这不是语言好坏，是天生的特性，选的时候就得想清楚。

当然云厂商的调度也会有影响，比如刚好节点资源被占满，调度慢个几百毫秒也正常，但大多时候，这都是可接受范围，主要问题还是在自己这边。

那些优化方案，哪些真有用哪些是坑

说实话，网上一堆优化方案，很多都是站着说话不腰疼，我踩过几个坑，给你们捋捋。

第一个说的最多的就是预置并发，说白了就是提前留几个实例一直跑着，不用销毁，这样请求过来直接就能处理，不会有冷启动。这个确实有用，但是要钱啊！你一直留着实例，那不就和传统租服务器按时间付费一模一样了？Serverless省成本的优势直接没了。

我见过新手上来就开二十个预置实例，说解决冷启动，结果活动结束一看账单，比租个一年的服务器还贵，图啥？正确用法是你知道九点要发活动，提前半小时开几个预置，活动结束降下来，这样既解决了高峰期冷启动，又不浪费钱。

第二个，代码优化，这个是真的零成本见效快。缩小编译包大小，去掉无用依赖，用树摇砍掉没用的代码，我之前把那个一百八十多M的包缩到二十M，冷启动直接砍了三分之二，香得不行。还有把不必要的启动初始化改成懒加载，用到的时候再加载，能一下子少掉快一秒的耗时，这个真的谁做谁知道。

第三个，预热，就是定时发个请求唤醒实例，不让它被销毁。这个适合低流量的场景，比如一天也就几十个请求，你每分钟发个空请求唤醒，成本也没多少，还能避免偶尔的冷启动，挺好。但是要是遇到云厂商例行资源调度，实例还是会被销毁，该冷还是得冷，只能缓解，不能根治。

不过话说回来，不是所有冷启动都需要优化。你的接口是后台内部用的，一天没几个人调用，等个两秒怎么了？省下来的钱买杯奶茶不好吗？只有面向C端的入口请求，用户对延迟敏感，才需要花力气优化。

没有银弹，只有trade-off。Serverless冷启动从根上来说，就是省成本和低延迟之间的取舍，你不可能既要一分钱不花，又要永远零延迟，那是不可能的。

现在各大厂商都在做优化，从轻量虚拟机到镜像预热，冷启动速度比三四年前快太多了，大部分场景下，只要你代码不瞎写，几百毫秒就能搞定，用户根本感知不到。我那个报名小站，优化完冷启动也就三百多毫秒，活动结束一算账单，总共才两块七，比买瓶矿泉水还便宜，这不香吗？

用技术本来就是这样，哪有完美的方案，摸清楚它的脾气，知道什么时候该忍，什么时候该治，选适合自己场景的就行。我现在做小项目，能上Serverless还是优先上，冷启动这点事，玩顺了，根本不算个问题。