Node.js 8

编者：本文作者孝达，经作者允许，刊载于 Alinode 团队博客。未经允许，不得转载。

端午节结束了。虽然接下来的四个月都没有节假日，但笔者一点都不烦恼。因为 Node.js 8 在端午后第一个工作日就正式发布，这足以让我与 Node.js 的激情燃烧一个夏天！本文挑选了笔者认为 Node.js 8 最令人兴奋的四大新功能，与大家分享。

async/await 与 util.promisify

Node.js 一直以来的关键设计就是把用户关在一个“异步编程的监狱”里，以换取非阻塞 I/O 的高性能，让用户轻易开发出高度可扩展的网络服务器。这从 Node.js 的 API 设计上就可见一斑，很多API——如 fs.open(path, flags[, mode], callback)——要求用户必须把该操作执行成功后的逻辑放在最后参数里，作为函数传递进去；而 fs.open 本身是立即返回的，用户不能把依赖于 fs.open 结果的逻辑与 fs.open 本身线性地串联起来。

在这座“异步编程的监狱”里，不掌握异步编程就寸步难行。而我们习惯性地使用线性思维去思考业务问题，却在实现的时候，被迫把业务逻辑被切成很多小片段去书写，就是一件很痛苦的事情了。为了减轻异步编程的痛苦，几年间我们见证了数个解决方案的出现：从深度嵌套的回调金字塔，到带有长长的 then() 链条的 Promise 设计模式，再到 Generator 函数，到如今 Node.js 8 的 async/await 操作符。笔者认为，所有这些解决方案中，async/await 操作符是最接近命令式编程风格的，使用起来最为自然的。

例如我们想先创建一个文件，再读取、输出它的大小，只需三行代码：

await writeFile('a_new_file.txt', 'hello');
let result = await stat('a_new_file.txt');
console.log(result.size);

这简直是最简单的异步编程了！我们用自然、流畅的代码表达了线性业务逻辑，同时还得到了 Node.js 非阻塞 I/O 带来的高性能，简直是兼得了鱼和熊掌。

但别着急，这段代码不是立即就可以执行的，细心的读者肯定会问：例子中的 writeFile 和 stat 分别是什么？其实它们就是标准库的 fs.writeFile 和 fs.stat，但又不完全是。这是因为 async 和 await 本质上是对 Promise 设计模式的封装，一般情况下 await 的参数应是一个返回 Promise 对象的函数。而 fs.writeFile 和 fs.stat 这些标准库 API 没有返回值（返回 undefined），需要一个方法把他们包装成返回 Promise 对象的函数。

但总不能一个一个包装去吧，这样工作量堪比重写标准库了。幸好，我们观察到所有这些标准库 API 基本都满足一个共同特征：它们都是用最后一个参数来接受一个类似“ (err, value) => ... ”的回调函数。于是我们就可以用一个 API 把几乎所有标准库 API 都转换为返回 Promise 对象的函数。这就是 util.promisify。利用 util.promisify，我们可以添加以下代码：

const util = require('util');
const fs = require('fs');
const writeFile = util.promisify(fs.writeFile);
const stat = util.promisify(fs.stat);

若没有 util.promisify，async/await 是很难用的，因为它们需要配合 Promise 一起使用，而之前很多库函数又不返回 Promise。笔者认为 async/await 运算符和 util.promisify 的绝配，是 Node.js 8 最大的亮点。

以上示例的完整代码如下：

const util = require('util');
const fs = require('fs');
const writeFile = util.promisify(fs.writeFile);
const stat = util.promisify(fs.stat);

(async function () {
  await writeFile('a_new_file.txt', 'hello');
  let result = await stat('a_new_file.txt');
  console.log(result.size);
})();

Async Hooks

调试过 Node.js 的小伙伴都知道，Node.js 一个很大的弱点就是——出错时调用栈不完整。这也是“异步编程的监狱”的设计带来的另一个缺点，因为在异步编程下，我们的代码被切成了无数个小片段，报错时只能得到一个小片段的调用栈，而全局的来龙去脉却看不到，用户只能推测是何处代码触发了何种事件导致执行了小片段，再不断往前推演。

举一个简单的例子：

function IWantFullCallbacks() {
  setTimeout(function() {
    const localStack = new Error();
    console.log(localStack.stack);
  }, 1000);
}

IWantFullCallbacks();

在这个例子中，我们模拟了 setTimeout 内出错时打印调用栈的情景。将它存为 1.js 并执行，我们期望，如果调用栈能包含外层的 IWantFullCallbacks()，并打印其行号 8，定是极好的，因为那样对我们排查错误很有帮助。但现实中却并非如此，调用栈只有四行，行号顶多打印到了第 3 行的报错本身，我们根本看不出来是第 8 行触发了这个错误。因为第 8 行作为异步调用成功地结束了，它才不关心“后事如何”。

Error
    at Timeout._onTimeout (/Users/pmq20/1.js:3:24)
    at ontimeout (timers.js:488:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:283:5)

而 Node.js 8 中新增的 Async Hooks 功能就可以解决这个问题。Node.js 8 中添加了四种 Async Hooks 回调，它们可以跟踪 Node.js 的所有异步资源的生命周期。这里所谓的资源是指 Node.js 底层 libuv 中的各类短期请求和长期句柄，如本例中的定时器，就是这样一个异步资源。这四种回调分别涵盖了这些异步资源的创建、回调前、回调后、销毁这四个生命阶段。

通过自定义这四种回调函数，我们就可以跨调用栈来做事件追踪，我们可以先做一个 Map 容器放在回调函数的闭包里，用来作为异步资源 ID 到调试信息的映射，并在异步资源的创建时进行调试信息的累积。闭包里再声明一个 currentUid 表示目前正在执行的异步资源 ID，于回调前、回调后两个生命阶段的时机进行记录。这样下来，第 8 行执行 IWantFullCallbacks() 的时候创建的异步资源的 ID，与后期定时器到期自行回调的异步资源的 ID，是同一个 ID，因而可以起到跨调用栈累积调试信息的作用。我们通过 Node.js 8 的 async_hooks 的 createHook API 来创建回调，并通过 enable() 方法注册并执行，代码如下：

const stack = new Map();
stack.set(-1, '');
let currentUid = -1;

function init(id, type, triggerId, resource) {
  const localStack = (new Error()).stack.split('\n').slice(1).join('\n');
  const extraStack = stack.get(triggerId || currentUid);
  stack.set(id, localStack + '\n' + extraStack);
}
function before(uid) {
  currentUid = uid;
}
function after(uid) {
  currentUid = -1;
}
function destroy(uid) {
  stack.delete(uid);
}

const async_hooks = require('async_hooks');
const hook = async_hooks.createHook({init, before, after, destroy});
hook.enable();

最后我们修改定时器的回调内容，让它输出 Map 中累积的调试信息：

function IWantFullCallbacks() {
  setTimeout(function() {
    const localStack = new Error();
    console.log(localStack.stack);
    console.log('---');
    console.log(stack.get(currentUid));
  }, 1000);
}

这次的效果如下：

Error
    at Timeout._onTimeout (/Users/pmq20/2.js:26:24)
    at ontimeout (timers.js:488:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:283:5)
---
    at init (/Users/pmq20/2.js:6:23)
    at runInitCallback (async_hooks.js:459:5)
    at emitInitS (async_hooks.js:327:7)
    at new Timeout (timers.js:592:5)
    at createSingleTimeout (timers.js:472:15)
    at setTimeout (timers.js:456:10)
    at IWantFullCallbacks (/Users/pmq20/2.js:25:3)
    at Object.<anonymous> (/Users/pmq20/2.js:33:1)
    at Module._compile (module.js:569:30)
    at Object.Module._extensions..js (module.js:580:10)

可见，我们以同一个异步资源的 ID 为线索，把两次的调用栈都完整保留了。

但这只是 Node.js 8 的 Async Hooks 的用途之一，有了这个功能，我们甚至可以来测量一些事件各个阶段所花费的时间。只要我们有异步资源 ID 这枚钥匙，配合回调函数，就可以在事件循环的多个周期那看似毫无头绪的执行过程中，筛选出有用的信息。

Node.js API (N-API)

经历过 Node.js 大版本升级的同学肯定会发现，每次升级后我们都得重新编译像 node-sass 这种用 C++ 写的扩展模块，否则会遇到下面这样的报错，

Error: The module 'node-sass'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 51. This version of Node.js requires
NODE_MODULE_VERSION 55. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).

NODE_MODULE_VERSION 是每一个 Node.js 版本内人为设定的数值，意思为 ABI 的版本号。一旦这个号码与已经编译好的二进制模块的号码不符，便判断为 ABI 不兼容，需要用户重新编译。

这其实是一个工程难题，亦即 Node.js 上游的代码变化如何最小地降低对 C++ 模块的影响，从而维持一个良好的向下兼容的模块生态系统。最坏的情况下，每次发布 Node.js 新版本，因为 API 的变化，C++ 模块的作者都要修改它们的源代码，而那些不再有人维护或作者失联的老模块就会无法继续使用，在作者修改代码之前社区就失去了这些模块的可用性。其次坏的情况是，每次发布 Node.js 新版本，虽然 API 保持兼容使得 C++ 模块的作者不需要修改他们的代码，但 ABI 的变化导致必须这些模块必须重新编译。而最好的情况就是，Node.js 新版本发布后，所有已编译的 C++ 模块可以继续正常工作，完全不需要任何人工干预。

Node.js Compiler 也面临同样的问题，之前 nodec 强制用户编译环境中的 Node.js 版本与编译器的内置 Node.js 版本一致，就是为了消除编译时与运行时 C++ 模块的版本不兼容问题，但这也给用户带来了使用的不便。见： https://github.com/pmq20/node-compiler/issues/27 如果能做到上述最好的情况，那么这个问题也就完美解决了。

Node.js 8 的 Node.js API (N-API) 就是为了解决这个问题，做到上述最好的情况，为 Node.js 模块生态系统的长期发展铺平道路。N-API 追求以下目标：

1. 有稳定的 ABI
2. 抽象消除 Node.js 版本之间的接口差异
3. 抽象消除 V8 版本之间的接口差异
4. 抽象消除 V8 与其他 JS 引擎（如 ChakraCore）之间的接口差异

笔者观察到，N-API 采取以下手段达到上述目标：

1. 采用 C 语言头文件而不是 C++，消除 Name Mangling 以便最小化一个稳定的 ABI 接口
2. 不使用 V8 的任何数据类型，所有 JavaScript 数据类型变成了不透明的 napi_value
3. 重新设计了异常管理 API，所有 N-API 都返回 napi_status，通过统一的手段处理异常
4. 重新了设计对象的生命周期 API，通过 napi_open_handle_scope 等 API 替代了 v8 的 Scope 设计

N-API 目前在 Node.js 8 仍是实验阶段的功能，需要配合命令行参数 --napi-modules 使用。

TurboFan 与 Ignition (TF+I)

Node.js 8 得益于将 v8 升级到了 5.8，引入了 TurboFan 与 Ignition 的支持。关于 Ignition 的详细介绍，请见 https://yq.aliyun.com/articles/77964

前面已经提到，如今借助 Node.js 8 我们可以用 await/async 书写程序，但并未提到异常处理，其实 await/async 的异常处理多借助 try/catch 配合使用。而在以前的 Node.js 版本中，try/catch 是个昂贵的操作，性能并不高。这主要是由于 v8 内老的 Crankshaft 不易优化这些 ES5 的新语法。但随着 TF+I 新架构的引入，try/catch 的写法也可以得到优化，作为用户就可以高枕无忧的使用 await/async + try/catch 了。

目前 Node.js 8 内的 v8 版本仅更新到了 5.8，TF+I 需要配合命令行参数 --turbo --ignition 使用。一旦升级到 v8 5.9，TF+I 将会默认开启。