Skip to content

Latest commit

 

History

History
319 lines (260 loc) · 10.8 KB

6.2 async_hooks.md

File metadata and controls

319 lines (260 loc) · 10.8 KB

上一小节讲解了 koa-await-breakpoint 的用法,但 koa-await-breakpoint 仍然有一个很大的缺憾,即无法记录除 routes/controllers 外的函数的执行时间(因为获取不到当前请求的 ctx)。举个通俗的例子:在一个路由的 controller 里面调用了 A ,A 调用了其他文件的 B ,B 又调用了其他文件的 C...这是非常常见的用法,但之前使用 koa-await-breakpoint 只能获取 A 的执行时间,无法获取 B 和 C 的执行时间。

根本原因在于:无法知道函数之间的调用关系,即 B 不知道是 A 调用的它,即便知道也不知道是哪次请求到来时执行的 A 调用的它。

但是,node@8.1 引入了一个黑魔法——Async Hooks。

6.2.1 Async Hooks

我们先看看 async_hooks 是什么。Node.js 官网对 async_hooks 的介绍为:

The async_hooks module provides an API to register callbacks tracking the lifetime of asynchronous resources created inside a Node.js application.

一句话概括:async_hooks 用来追踪 Node.js 中异步资源的生命周期。

我们来看段测试代码:

const fs = require('fs')
const async_hooks = require('async_hooks')

async_hooks.createHook({
  init (asyncId, type, triggerAsyncId, resource) {
    fs.writeSync(1, `${type}(${asyncId}): trigger: ${triggerAsyncId}\n`)
  },
  destroy (asyncId) {
    fs.writeSync(1, `destroy: ${asyncId}\n`);
  }
}).enable()

async function A () {
  fs.writeSync(1, `A -> ${async_hooks.executionAsyncId()}\n`)
  setTimeout(() => {
    fs.writeSync(1, `A in setTimeout -> ${async_hooks.executionAsyncId()}\n`)
    B()
  })
}

async function B () {
  fs.writeSync(1, `B -> ${async_hooks.executionAsyncId()}\n`)
  process.nextTick(() => {
    fs.writeSync(1, `B in process.nextTick -> ${async_hooks.executionAsyncId()}\n`)
    C()
    C()
  })
}

function C () {
  fs.writeSync(1, `C -> ${async_hooks.executionAsyncId()}\n`)
  Promise.resolve().then(() => {
    fs.writeSync(1, `C in promise.then -> ${async_hooks.executionAsyncId()}\n`)
  })
}

fs.writeSync(1, `top level -> ${async_hooks.executionAsyncId()}\n`)
A()

async_hooks.createHook 可以注册 4 个方法来跟踪所有异步资源的初始化(init)、回调之前(before)、回调之后(after)、销毁后(destroy)事件,并通过调用 .enable() 启用,调用 .disable() 关闭。

这里我们只关心异步资源的初始化和销毁的事件,并使用 fs.writeSync(1, msg) 打印到标准输出,writeSync 的第 1 个参数接收文件描述符,1 表示标准输出。为什么不使用 console.log 呢?因为 console.log 是一个异步操作,如果在 init、before、after 和 destroy 事件处理函数中出现,就会导致无限循环,同理也不能使用任何其他的异步操作。

运行该程序,打印如下:

top level -> 1
PROMISE(6): trigger: 1
A -> 1
Timeout(7): trigger: 1
TIMERWRAP(8): trigger: 1
A in setTimeout -> 7
PROMISE(9): trigger: 7
B -> 7
TickObject(10): trigger: 7
B in process.nextTick -> 10
C -> 10
PROMISE(11): trigger: 10
PROMISE(12): trigger: 11
C -> 10
PROMISE(13): trigger: 10
PROMISE(14): trigger: 13
C in promise.then -> 12
C in promise.then -> 14
destroy: 7
destroy: 10
destroy: 8

这段程序的打印结果包含了很多信息,下面逐一进行解释:

  1. 为了实现对异步资源的跟踪,Node.js 对每一个函数(不论异步还是同步)提供了一个 async scope,我们可以通过调用 async_hooks.executionAsyncId() 来获取函数当前的 async scope 的 id(称为 asyncId),通过调用 async_hooks.triggerAsyncId() 来获取当前函数调用者的 asyncId。
  2. 异步资源在创建时触发 init 事件函数,init 函数中的第 1 个参数代表该异步资源的 asyncId,type 表示异步资源的类型(例如 TCPWRAP、PROMISE、Timeout、Immediate、TickObject 等等),triggerAsyncId 表示该异步资源的调用者的 asyncId。异步资源在销毁时触发 destroy 事件函数,该函数只接收一个参数,即该异步资源的 asyncId。
  3. 函数调用关系明确。我们通过上面的打印结果可以很容易地看出(从下往上看) :C(asyncId: 10)被 B(asyncId: 7)调用,B(asyncId: 7)被 A(asyncId: 1)调用。而且 C 的 promise.then 里面的 asyncId(值为 12/14)也可以通过 12/14 -> 11/13 -> 10 定位到 C 的 asyncId(值为 10)。
  4. 同步函数每次调用的 asyncId 都一样,如上所示,C 调用了两次,都打印了 C -> 10,与调用方的作用域的 asyncId 一致,即如上所示打印的 B in process.nextTick -> 10。异步函数每次调用的 asyncId 都不一样,即如上所示打印的 C in promise.then -> 12 和 C in promise.then -> 14。
  5. 最外层作用域的 asyncId 总是 1,每个异步资源在创建时 asyncId 全局递增。

上面 5 条结论非常重要。接下来我们看看如何使用 async_hooks 改造 koa-await-breakpoint。

6.2.2 改造 koa-await-breakpoint

我们通过前面的结论已经知道,使用 async_hooks 时可以通过 asyncId 串起函数的调用关系,但是如何将这些函数的调用链与 koa 接收的每个请求关联起来呢?

首先,定义一个全局 Map,存储函数的调用关系:

const async_hooks = require('async_hooks')
const asyncIdMap = new Map()

async_hooks.createHook({
  init (asyncId, type, triggerAsyncId) {
    const ctx = getCtx(triggerAsyncId)
    if (ctx) {
      asyncIdMap.set(asyncId, ctx)
    } else {
      asyncIdMap.set(asyncId, triggerAsyncId)
    }
  },
  destroy (asyncId) {
    asyncIdMap.delete(asyncId)
  }
}).enable()

function getCtx (asyncId) {
  if (!asyncId) {
    return
  }
  if (typeof asyncId === 'object' && asyncId.app) {
    return asyncId
  }
  return getCtx(asyncIdMap.get(asyncId))
}

有以下三点需要解释:

  1. 定义了一个全局 Map 来存储函数的调用关系,在适当的地方(下面会讲到)将当前请求的 ctx 存储到 Map 中,key 是 asyncId。
  2. 每个异步资源在初始化时,会尝试通过 asyncId 向上寻找祖先的 value 是否是 ctx(koa 应用中每个请求的 ctx),如果有,则直接将 value 设置为 ctx,否则将 value 设置为调用者的 asyncId(即 triggerAsyncId)。
  3. 在 destroy 事件函数里直接删除调用关系,保证了不会引起内存泄漏,即杜绝引用了 ctx 但没有释放的情况。

然后,修改 global[loggerName] 如下:

global[loggerName] = async function (ctx, fn, fnStr, filename) {
  const originalContext = ctx
  let requestId = _getRequestId()

  const asyncId = async_hooks.executionAsyncId()
  if (!requestId) {
    const _ctx = getCtx(asyncId)
    if (_ctx) {
      ctx = _ctx
      requestId = _getRequestId()
    }
  } else {
    asyncIdMap.set(asyncId, ctx)
  }

  if (requestId) {
    _logger('beforeAwait')
  }
  const result = await fn.call(originalContext)
  if (requestId) {
    _logger('afterAwait', result)
  }
  return result

  function _getRequestId () {
    return ctx && ctx.app && _.get(ctx, requestIdPath)
  }

  function _logger (type, result) {
    ...
  }
}

有以下两点需要解释:

  1. logger 函数传入的第 1 个参数 ctx,之前是每个请求的 ctx,现在可能是当前执行上下文的 this,所以先将 ctx 赋值给 originalContext,然后通过 await fn.call(originalContext) 让函数在执行时有正确的上下文。
  2. 如果传入的 ctx 是来自请求的 ctx 且能拿到 requestId,那么将当前 asyncId 和 ctx 写入 Map,如果不是来自请求的 ctx,则尝试从 Map 里向上寻找祖先的 value 是否是 ctx,如果找到,则覆盖当前的 ctx 并拿到 requestId。

至此,koa-await-breakpoint 全部改造完毕。接下来我们通过一个例子验证下升级后的 koa-await-breakpoint:

app.js

const koaAwaitBreakpoint = require('koa-await-breakpoint')({
  files: ['./routes/*.js']
})

const Paloma = require('paloma')
const app = new Paloma()

app.use(koaAwaitBreakpoint)
app.route({ method: 'POST', path: '/users', controller: require('./routes/user').createUser })

app.listen(3000)

routes/users.js

const Mongolass = require('mongolass')
const mongolass = new Mongolass('mongodb://localhost:27017/test')
const User = mongolass.model('User')
const Post = mongolass.model('Post')
const Comment = mongolass.model('Comment')

exports.createUser = async function (ctx) {
  const name = ctx.query.name || 'default'
  const age = +ctx.query.age || 18
  await createUser(name, age)
  ctx.status = 204
}

async function createUser (name, age) {
  const user = (await User.create({
    name,
    age
  })).ops[0]
  await createPost(user)
}

async function createPost (user) {
  const post = (await Post.create({
    uid: user._id,
    title: 'post',
    content: 'post'
  })).ops[0]

  await createComment(user, post)
}

async function createComment (user, post) {
  await Comment.create({
    userId: user._id,
    postId: post._id,
    content: 'comment'
  })
}

这段代码的意思是:在访问创建用户接口时,调用 createUser,createUser 里面又调用了 createPost,createPost 里面又调用了 createComment。运行:

$ curl -XPOST localhost:3000/users

打印如下:

{ type: 'start',
  step: 1,
  take: 0 ... }
{ type: 'beforeAwait',
  step: 2,
  fn: 'createUser(name, age)',
  take: 1 ... }
{ type: 'beforeAwait',
  step: 3,
  fn: 'User.create(...)',
  take: 1 ... }
{ type: 'afterAwait',
  step: 4,
  fn: 'User.create(...)',
  take: 36 ... }
{ type: 'beforeAwait',
  step: 5,
  fn: 'createPost(user)',
  take: 1 ... }
{ type: 'beforeAwait',
  step: 6,
  fn: 'Post.create(...)',
  take: 0 ... }
{ type: 'afterAwait',
  step: 7,
  fn: 'Post.create(...)',
  take: 3 ... }
{ type: 'beforeAwait',
  step: 8,
  fn: 'createComment(user, post)',
  take: 1 ... }
{ type: 'beforeAwait',
  step: 9,
  fn: 'Comment.create(...)',
  take: 0 ... }
{ type: 'afterAwait',
  step: 10,
  fn: 'Comment.create(...)',
  take: 1 ... }
{ type: 'afterAwait',
  step: 11,
  fn: 'createComment(user, post)',
  take: 1 ... }
{ type: 'afterAwait',
  step: 12,
  fn: 'createPost(user)',
  take: 6 ... }
{ type: 'afterAwait',
  step: 13,
  fn: 'createUser(name, age)',
  take: 44 ... }
{ type: 'end',
  step: 14,
  take: 0 ... }

至此,一个全链路、无侵入、强大的日志打点工具就完成了。

注意:使用 async_hooks 在目前有较严重的性能损耗,见 https://github.com/bmeurer/async-hooks-performance-impact,请慎重在生产环境中使用。

6.2.3 参考链接

上一节:6.1 koa-await-breakpoint

下一节:6.3 ELK