我们平时在开发部署 Node.js 应用的过程中,对于应用进程启动的耗时很少有人会关注,大多数的应用 5 分钟左右就可以启动完成,这个过程中会涉及到和集团很多系统的交互,这个耗时看起来也没有什么问题。
目前,集团 Serverless 大潮已至,Node.js serverless-runtime 作为前端新研发模式的基石,也发展的如火如荼。Serverless 的优势在于弹性、高效、经济,如果我们的 Node.js FaaS 还像应用一样,一次部署耗时在分钟级,无法快速、有效地响应请求,甚至在脉冲请求时引发资源雪崩,那么一切的优势都将变成灾难。
所有提供 Node.js FaaS 能力的平台,都在绞尽脑汁的把冷/热启动的时间缩短,这里面除了在流程、资源分配等底层基建的优化外,作为其中提供服务的关键一环 —— Node.js 函数,本身也应该参与到这场时间攻坚战中。
Faas平台从接到请求到启动业务容器并能够响应请求的这个时间必须足够短,当前的总目标是 500ms,那么分解到函数运行时的目标是 100ms。这 100ms 包括了 Node.js 运行时、函数运行时、函数框架启动到能够响应请求的时间。巧的是,人类反应速度的极限目前科学界公认为 100ms。
Node.js 有多快
在我们印象中 Node.js 是比较快的,敲一段代码,马上就可以执行出结果。那么到底有多快呢?
以最简单的 console.log 为例(例一),代码如下:
// console.js
console.log(process.uptime() * 1000);
在 Node.js 最新 LTS 版本 v10.16.0 上,在我们个人工作电脑上:
node console.js
// 平均时间为 86ms
time node console.js
// node console.js 0.08s user 0.03s system 92% cpu 0.114 total
看起来,在 100ms 的目标下,留给后面代码加载的时间不多了。。。
在来看看目前函数平台提供的容器里的执行情况:
node console.js
// 平均时间在 170ms
time node console.js
// real 0m0.177s
// user 0m0.051s
// sys 0m0.009s
Emmm… 情况看起来更糟了。
我们在引入一个模块看看,以 serverless-runtime 为例(例二):
<