智汇 IT
城启新篇

Serverless冷启动优化 别被厂商零冷启动话术骗了

上次跟一个做电商中台的技术负责人在南京的老破小馆子里吃皮肚面,他扒着碗吐槽,说去年大促的时候压测跑了三轮,所有接口的响应时间都压在200ms以内,结果大促当天零点第一个进来的用户,点下单按钮转了2.3秒才跳成功。翻日志翻到后半夜才发现,是负责订单校验的Serverless函数刚好被云平台回收,第一次请求触发了完整的冷启动流程。

冷启动的账,根本不是厂商PPT里算的那样

很多人对冷启动的认知停留在“函数闲置太久,云厂商把资源收走,下次来请求要重新拉容器、初始化运行时、加载代码,所以慢”。

说白了,这个过程的耗时拆解开,拉镜像大概占四成,初始化语言运行时占三成,剩下的三成全是业务侧自己加的工作——全局变量初始化、数据库连接池建连、配置中心拉全量配置、甚至有人在启动逻辑里写了预热爬虫。

很多人优化了半天镜像大小,最后发现七成的冷启动耗时根本不在镜像层。之前帮一个做内容审核的团队调优,他们花了两周把Java函数的镜像从1.2G压到300M,算下来冷启动从8s降到5s,觉得占了大便宜。结果扒完链路日志才发现,光Spring容器初始化就花了3.2s,数据库连接池建连花了1.1s,拉镜像的环节才用了0.7s。

Serverless函数冷启动耗时拆解瀑布图
Serverless函数冷启动耗时拆解瀑布图

那些厂商吹得震天响的“零冷启动”,本质上就是预留实例。你花钱买固定的计算资源,平台一直给你留着,不管有没有请求都照常扣钱。麻烦在于,这个账算起来远没有看上去划算。比如你做的是工作日早9点到晚6点有稳定流量,其余时间几乎没有请求,那开20个预留实例兜底,一晚上8小时空跑,加上周末两天的闲置,大半时间的钱都打了水漂。更闹心的是,哪怕你开了预留实例,只要并发量打满了预留实例的承载上限,新进来的请求还是要走完整的冷启动流程。

真的见过有人为了把冷启动压到200ms以内,开了比日常峰值还多30%的预留实例,月底账单出来直接攥着计算器找老板认错,说之前的成本测算漏了这部分固定支出。

真要把冷启动压下来,得拆着每一秒抠

很多人一提到Serverless冷启动优化,第一反应就是把Java换成Node.js,说运行时轻、启动快。是快。但代价是什么?整个团队写了三年的Java业务逻辑,全量重写的人力成本,够你交两年的预留实例费用了。这事没那么玄。

你Java函数里,把启动时全量拉取的配置改成懒加载,把Spring自动装配里根本用不到的模块全关掉,光这两步就能把Java的冷启动从4s压到800ms以内,根本用不着推倒重来。

冷启动优化的第一优先级,永远是把启动阶段的非必要工作全删掉,而不是上来就换技术栈。太多人写函数的时候,一上来就在全局初始化逻辑里把所有下游连接全建好——数据库、缓存、消息队列、对象存储,哪怕这次请求根本碰不到这些资源,也挨个建一遍连接。光这部分冗余操作,就能占掉冷启动耗时的四成。

Serverless函数全局变量懒加载前后冷启动对比图
Serverless函数全局变量懒加载前后冷启动对比图

那些被吹得神乎其神的优化手段,其实都有不为人知的代价。比如快照恢复,平台把函数运行到稳定状态的内存存成快照,下次冷启动直接拉快照跳过初始化环节。好用是好用,但快照大小直接决定恢复速度——你要是函数运行时占了2G内存,拉快照的时间跟拉个小镜像也差不了多少。更别提大部分厂商的快照功能是单独收费的,按存储容量算钱,按恢复次数算钱,算下来不比开预留实例便宜多少。

还有那种定时预热的小插件,每隔一段时间发个空请求给函数,让它一直保持活跃。问题是你根本摸不准流量什么时候突然涨上来。预热间隔设成1分钟,函数刚被回收,预热请求还没到,第一个真实用户还是要等冷启动。间隔设成10秒,一天下来大半都是无效的预热请求,纯白花冤枉钱。

别追求绝对的零冷启动,算好用户体验的账

所有的Serverless冷启动优化,最后都要回到一个最朴素的问题:你的用户能接受多少的首请求延迟?

你做的是内部的运维平台,管理员点个按钮,等个2秒根本没人在意,那你花大价钱开一堆预留实例,纯纯是浪费钱。但你要是做面向C端的电商下单接口,用户点一下等个1秒就可能划走竞品页面,那你就得把核心链路的冷启动时间压到300ms以内,甚至更低。

真的见过离谱的事。有个团队给内部的报表导出函数,花了好几万做Serverless冷启动优化,把启动时间压到100ms以内。结果那个报表导出函数一周才被调用三次,每次导出全量数据要跑5分钟,用户根本不会在意开头那几百毫秒的启动时间。

真正成熟的Serverless落地团队,从来不会追求所有函数的零冷启动,只会给不同的链路匹配不同的优化策略。核心交易链路的函数,用预留实例加代码轻量化把冷启动压到可接受的范围;边缘的、低频的函数,哪怕冷启动1s也没关系,根本不需要额外投入成本优化。

之前跟某云Serverless团队的一线工程师聊天,他们内部统计过,大概八成的冷启动投诉,最后查下来都不是平台的问题,是用户自己的函数在初始化阶段写了太多没必要的逻辑——比如启动的时候去爬一遍全量的商品配置表,比如把本地的依赖文件全加载到内存里,哪怕这次请求根本用不到。你说这能怪谁?

前两天又收到那个吃皮肚面的技术负责人的消息,说他们现在把核心下单链路的函数做了分层:高峰期开3个预留实例兜底,启动逻辑里把没用的Spring模块全砍了,数据库连接改成按需创建,冷启动从之前的2.3s压到了180ms,这个月的Serverless账单还比之前少了12%。

挺实在的。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:Serverless冷启动优化 别被厂商零冷启动话术骗了
文章链接:https://www.itcdj.com/it/304.html