continuation-local-storage在Express中的负载承载能力及高CPU问题咨询

我之前在高并发Express场景下折腾过cls-hooked，遇到过几乎一模一样的CPU爆炸问题，刚好能给你点实际踩坑后的经验！

• Node 8的async_hooks性能短板：cls-hooked依赖Node的async_hooks API，但Node 8.x里这个API还处于实验性阶段，底层优化非常有限。每一次异步操作（哪怕是你觉得"轻量"的API调用、数据库查询）都会触发钩子的初始化、绑定、销毁流程，每分钟几百次请求叠加下来，这些额外的钩子调用会把CPU直接拉满——我当时测过，开启cls后单请求的CPU耗时直接翻了10倍以上。
• 上下文未及时销毁导致的堆积：如果没在请求结束后手动销毁cls命名空间的上下文，这些上下文会一直在内存里堆积，后续的请求会不断关联旧的上下文数据，CPU要处理的关联逻辑越来越多，最终直接崩盘。
• 隐性异步操作的无差别追踪：你说大多是同步计算，但很多看似同步的代码里其实暗藏微任务（比如Promise.resolve、process.nextTick），cls会无差别追踪所有异步操作，这些隐性的钩子触发会把开销放大N倍。

我当时处理的场景是每分钟约250次请求，最终把CPU降回了正常水平，试试这些：

• 手动管控上下文生命周期：别依赖cls自动销毁，在Express中间件里绑定请求结束事件，手动销毁上下文。示例代码：

  const cls = require('cls-hooked');
  const appNamespace = cls.createNamespace('my-app-context');
  
  app.use((req, res, next) => {
    appNamespace.run(() => {
      // 存入需要的上下文数据
      appNamespace.set('reqId', req.headers['x-request-id']);
      // 保存当前上下文引用，方便后续销毁
      appNamespace.set('currentContext', appNamespace.active);
      next();
    });
  
    // 请求结束后强制销毁上下文
    res.on('finish', () => {
      const activeContext = appNamespace.get('currentContext');
      if (activeContext) {
        appNamespace.destroy(activeContext);
      }
    });
  });
  

• 缩小上下文追踪范围：不要全局用cls包裹所有请求，只在真正需要跨异步操作传递上下文的代码块里用appNamespace.bind()或者appNamespace.run()。比如只有某个需要调用多个第三方API的路由需要上下文，就只在那个路由里初始化cls，其他请求完全不碰。
• 用req对象替代cls（优先推荐）：如果你的场景不需要跨非常复杂的异步链传递上下文，直接把数据挂载到Express的req对象上是最轻量化的方案——毕竟你的请求大多是同步或简单异步，后续中间件、路由里直接访问req.myContext就好，完全没有cls的额外开销。示例：

  app.use((req, res, next) => {
    req.myContext = {
      reqId: req.headers['x-request-id'],
      userId: req.query.userId || null
    };
    next();
  });
  
  // 在路由里直接使用
  app.get('/api/user/profile', (req, res) => {
    const { reqId, userId } = req.myContext;
    // 业务逻辑处理
  });
  

• 尽量升级Node版本（如果可行）：Node 8已经停止维护多年了，后续的Node 10+对async_hooks做了大量性能优化，我后来把项目升级到Node 12后，cls-hooked的CPU开销直接降了80%以上，基本不会出现飙升的情况。

一定要用压测工具（比如artillery）模拟真实的并发请求，本地开发环境请求量小，cls的开销根本体现不出来，只有在高并发下才能验证优化效果。

内容的提问来源于stack exchange，提问作者E Fleischman