谁偷走了我的500ms：聊聊Serverless冷启动那点破事
上个月9月23号在南京江北的软件园，跟做小程序创业的朋友蹲在楼下瑞幸门口抽烟，他对着屏幕骂娘。说自己花了一周把后台全迁Serverless，账单从每个月三千降到三百，结果用户投诉打开卡一秒，留存掉了快十个点。
“明明说好用Serverless省事儿又省钱，怎么就出这破事？”
问题出在哪？就是所有人都会碰到的Serverless冷启动。
Serverless冷启动热启动耗时对比图
很多人说冷启动是Serverless的天生缺陷，其实不对。它是Serverless设计思路带来的必然结果，你拿了它省钱的好处，就得接受这个取舍。
Serverless冷启动全流程时序图
说实话，冷启动的耗时波动其实很大，跟你的代码大小、依赖多少、用的开发语言都有关系。Go这种编译型语言，编译成单个二进制之后，启动一般只要几十毫秒，而Java这种重型语言，动辄好几秒，差距就是这么大。
我们真的需要彻底消灭冷启动吗
现在网上一搜Serverless冷启动，全是各种“零冷启动优化方案”，说得好像不消灭冷启动你就不配用Serverless一样。
我就想问一句，消灭冷启动的代价你付得起吗？
比如最常见的预留实例方案，就是你花钱一直保留几个实例在线，不管有没有请求都要付钱。那这不就是变向租了一台服务器？原来用Serverless就是为了闲置省钱，结果你为了消灭冷启动，花的钱比买ECS还多，这不是丢了西瓜捡芝麻吗？
还有定时预热方案，就是每隔几分钟发一个空请求唤醒函数，让平台不回收实例。这种方法确实能减少冷启动的概率，但是如果你有几十个函数，流量波动又大，白天流量高不需要预热，晚上没流量还一直跑，照样浪费钱。
当然，也有没成本的优化方案，这些我是举双手赞成的。比如把大函数拆成小函数，每个函数只做一件事，代码包小了，拉代码启动自然就快了。再比如把初始化逻辑懒加载，不需要启动的时候加载的依赖，放到第一次请求用到的时候再加载，一下子就能省出一两百毫秒。还有选启动快的语言做对延迟敏感的函数，这些都是实打实的优化，没有额外代价。
不过话说回来，冷启动本来就不是所有场景都不能接受。
你做个定时爬数据的任务，一天跑一次，晚启动几秒有什么关系？你做个图片转码的后端任务，用户上传完本来就要等，多等几百毫秒根本没人在乎。你做个内网的工具接口，一天没几个人用，冷启动省下来的钱，香得很。
只有面向C端用户的核心路径请求，比如小程序启动接口、首页渲染、商品搜索接口这种，用户能直接感知到延迟的场景，冷启动才是需要解决的问题。
我那个南京的朋友后来怎么解决的？他把核心的用户启动接口抽了出来，留了两个预留实例，每个月多花几十块钱，剩下的所有非核心接口，包括订单回调、后台管理、图片处理这些，全用按需实例，最后每个月账单才四百多，比原来三千块钱省了一大半，用户也再也没投诉过卡顿。
哪有什么完美的技术？从来都是你选你最在乎的，接受你必须付出的。冷启动不是Serverless的bug，是它的特性。选对场景，做该做的优化，用起来照样舒服。
对不对？
你碰到的那一秒卡顿，其实就是冷启动
你有没有过这种经历？自己搭的个人博客，用了Serverless函数做渲染，隔了一周没人访问，你自己点进去，白屏转半天，刷新一下就快得飞起。 那多出来的几百毫秒，就是冷启动花掉的时间。 很多刚接触Serverless的开发者，只会盯着“按需付费”“免运维”的优点，转头就把冷启动这个事忘得一干二净，等线上用户投诉了才拍大腿，骂自己为什么不提前做功课。 实话讲，500ms的可见延迟，对C端用户来说就是天差地别——一秒以内的加载，用户觉得正常，超过一秒，一半的用户可能直接关掉页面走人。Serverless冷启动热启动耗时对比图
很多人说冷启动是Serverless的天生缺陷，其实不对。它是Serverless设计思路带来的必然结果，你拿了它省钱的好处，就得接受这个取舍。
冷启动到底是哪一步在拖慢你的请求
要解决问题，先得搞清楚，冷启动到底慢在哪？ Serverless和传统服务器最大的区别，就是按需伸缩，闲置时实例会缩容到0。什么叫缩容到0？就是你的代码进程直接被平台杀掉，占用的CPU内存全收走，分给别人用——这样你才不用为闲置的资源付钱，这才是按需付费的核心。 那当很久没有请求之后，第一个请求过来的时候，平台要从头帮你把运行环境搭起来： 第一步，得调度资源，给你找一台空闲的物理机，分配好CPU内存这些资源。第二步，拉取你的代码包，如果是容器部署，还要从镜像仓库拉对应的镜像。第三步，启动代码运行需要的运行时，比如Java要启动JVM，Node要启动Node进程。第四步，跑你写的初始化逻辑，加载配置、建立数据库连接、加载各种第三方依赖。 一整套流程走下来，少则两三百毫秒，多则好几秒。你说用户能不觉得卡吗？ 我见过最夸张的案例，有人把整个Spring Boot项目直接打包扔到Serverless上，光JVM启动加初始化就要三四秒，用户根本不可能等。 那为什么第二次访问就快了？因为第一个请求处理完之后，平台不会立刻杀掉已经启动好的实例，会保留几分钟。下一个请求过来，直接用现成的实例处理就好，也就是热启动，耗时一般只有几毫秒，跟传统服务器没任何区别。Serverless冷启动全流程时序图
说实话，冷启动的耗时波动其实很大，跟你的代码大小、依赖多少、用的开发语言都有关系。Go这种编译型语言，编译成单个二进制之后，启动一般只要几十毫秒，而Java这种重型语言，动辄好几秒，差距就是这么大。
我们真的需要彻底消灭冷启动吗
我们真的需要彻底消灭冷启动吗
现在网上一搜Serverless冷启动，全是各种“零冷启动优化方案”，说得好像不消灭冷启动你就不配用Serverless一样。
我就想问一句，消灭冷启动的代价你付得起吗？
比如最常见的预留实例方案，就是你花钱一直保留几个实例在线，不管有没有请求都要付钱。那这不就是变向租了一台服务器？原来用Serverless就是为了闲置省钱，结果你为了消灭冷启动，花的钱比买ECS还多，这不是丢了西瓜捡芝麻吗？
还有定时预热方案，就是每隔几分钟发一个空请求唤醒函数，让平台不回收实例。这种方法确实能减少冷启动的概率，但是如果你有几十个函数，流量波动又大，白天流量高不需要预热，晚上没流量还一直跑，照样浪费钱。
当然，也有没成本的优化方案，这些我是举双手赞成的。比如把大函数拆成小函数，每个函数只做一件事，代码包小了，拉代码启动自然就快了。再比如把初始化逻辑懒加载，不需要启动的时候加载的依赖，放到第一次请求用到的时候再加载，一下子就能省出一两百毫秒。还有选启动快的语言做对延迟敏感的函数，这些都是实打实的优化，没有额外代价。
不过话说回来，冷启动本来就不是所有场景都不能接受。
你做个定时爬数据的任务，一天跑一次，晚启动几秒有什么关系？你做个图片转码的后端任务，用户上传完本来就要等，多等几百毫秒根本没人在乎。你做个内网的工具接口，一天没几个人用，冷启动省下来的钱，香得很。
只有面向C端用户的核心路径请求，比如小程序启动接口、首页渲染、商品搜索接口这种，用户能直接感知到延迟的场景，冷启动才是需要解决的问题。
我那个南京的朋友后来怎么解决的？他把核心的用户启动接口抽了出来，留了两个预留实例，每个月多花几十块钱，剩下的所有非核心接口，包括订单回调、后台管理、图片处理这些，全用按需实例，最后每个月账单才四百多，比原来三千块钱省了一大半，用户也再也没投诉过卡顿。
哪有什么完美的技术？从来都是你选你最在乎的，接受你必须付出的。冷启动不是Serverless的bug，是它的特性。选对场景，做该做的优化，用起来照样舒服。
对不对？