Node.js Event Loop 阻塞导致 23 分钟雪崩的完整复盘:从 1.4 秒同步 JSON.parse 到 8 条工程纪律

2025 年三月一个周二上午,我们的一个核心 Node.js 服务突然开始大面积超时:正常 P99 50ms 的接口飙到 8 秒,/health 健康检查也超时,Kubernetes 开始疯狂重启 Pod,流量进一步集中到剩下的副本,雪崩 5 分钟内蔓延到所有 20 个副本。最终持续了 23 分钟,影响了大约 18 万用户的下单流程,损失估算超过 40 万人民币。事后根因分析非常打脸:就是一段看似无害的 JSON.parse 同步代码,在收到一个 12MB 的恶意请求后阻塞了 event loop 1.4 秒,刚好命中健康检查超时阈值,触发了连锁反应。这篇把整个雪崩过程、Node.js event loop 的工作原理、CPU profiling 工具、5 种修法、以及我们后来建立的"event loop 保护体系"完整记录一遍。

服务背景和事故现场

事故服务是我们电商平台的订单聚合 API,Node.js 20 LTS + Fastify 4.x + TypeScript,部署在 K8s,20 个副本,每个副本 2 vCPU + 4GB 内存。主要职责是接收前端的下单请求,聚合用户信息、商品库存、优惠券、支付方式等数据,返回订单创建结果。日常 QPS 约 5000,P99 50ms,P999 200ms,运行了一年多一直很稳定,这次突然炸了让所有人措手不及。

第一轮排查:CPU 和内存看起来都正常

事故初期最让人困惑的是常规监控指标看起来"很健康":CPU 平均 40%(没有飙高)、内存 1.8GB(远低于 limit)、GC 时间正常、外部依赖(MySQL/Redis)延迟也正常。但服务就是慢,P99 八秒。我们第一反应是网络问题,查了 K8s 网络、Service Mesh、上游 LB,全都没异常。这种"指标都正常但服务就是慢"是 Node.js 事故最典型的特征,因为Node.js 的单线程 event loop 阻塞,在传统 CPU/内存监控里完全看不出来。

# 我们最初看的指标 (都正常)
$ kubectl top pod | grep order-api
order-api-7d8f4-x9mw2   847m   1834Mi
order-api-7d8f4-yp3k1   923m   1798Mi
# CPU 0.8-1.0 core, 内存 1.8GB, 都在合理范围

# 但 P99 监控完全炸了
$ curl prometheus/api/v1/query?query='histogram_quantile(0.99,...)'
{"value": [1746000000, "8.234"]}  # 8.2 秒

转机出现在我们想起一年前内部分享过的一个工具:event loop lag 监控。Node.js 的 perf_hooks 模块可以测量 event loop 的延迟,正常情况下应该 1ms 以内,如果飙到几百毫秒就说明有同步代码在阻塞。我们紧急在一个副本上跑了这个监控:

// 紧急加的 event loop lag 监控
const { monitorEventLoopDelay } = require('perf_hooks');

const histogram = monitorEventLoopDelay({ resolution: 20 });
histogram.enable();

setInterval(() => {
  const stats = {
    min: histogram.min / 1e6,        // 转 ms
    mean: histogram.mean / 1e6,
    max: histogram.max / 1e6,
    p50: histogram.percentile(50) / 1e6,
    p99: histogram.percentile(99) / 1e6,
    stddev: histogram.stddev / 1e6,
  };
  console.log('event_loop_lag', stats);
  histogram.reset();
}, 5000);

跑起来之后日志立刻给出真相:

event_loop_lag { min: 0.02, mean: 12.4, max: 1413.6, p50: 0.2, p99: 893.1 }
event_loop_lag { min: 0.02, mean: 18.7, max: 1402.9, p50: 0.3, p99: 1208.4 }

P99 event loop lag 接近 1.2 秒,max 1.4 秒,这就是雪崩的直接原因:某些请求触发了长达 1.4 秒的同步代码,期间整个 event loop 完全冻结,所有其他请求(包括健康检查)排队等待。CPU 监控之所以正常,是因为这段同步代码"很高效",100% 占用单核但没飙满,从外部看 CPU 利用率不高。这是 Node.js 监控最容易被忽视的盲区。

真凶定位:一段 JSON.parse 同步代码

找到 event loop lag 之后,下一步是定位哪段代码阻塞了 event loop。我们用 clinic.js 的 doctor 模式做了一次现场 profiling,生成的火焰图非常清楚:80% 的阻塞集中在一个文件的 JSON.parse 调用上。深入代码发现是这样的:

// 出问题的代码 (简化)
import fastify from 'fastify';

const app = fastify({
  bodyLimit: 50 * 1024 * 1024,  // ← 50MB! 历史遗留, 当初为了支持上传场景
});

app.post('/orders', async (req, reply) => {
  // Fastify 默认会用 JSON.parse 解析 body
  const orderData = req.body as OrderRequest;

  // 对 orderData 做一些处理 (我们以为 body 不会太大)
  const result = await processOrder(orderData);
  return result;
});

问题根因有两个叠加。第一,bodyLimit 设到了 50MB,这是历史遗留(早期为了支持图片上传保留下来的);第二,Fastify 的默认 JSON parser 是同步的,大 body 会同步解析阻塞 event loop。攻击者发了一个 12MB 的 JSON(深嵌套结构),Fastify 用 JSON.parse 解析这玩意花了 1.4 秒,期间所有其他请求堆积,然后健康检查超时,Pod 被重启,流量重分配,新 Pod 又遇到同样问题,雪崩成立。

Node.js event loop 的工作原理

Node.js 的核心是单线程 event loop,所有 JavaScript 代码都在这一个线程上运行(Worker Threads 例外)。event loop 在多个 phase 之间轮转,每个 phase 处理对应类型的回调。如果某个回调里执行了长时间的同步代码,整个 event loop 就被阻塞,期间没有任何其他回调能执行,包括接收新连接、读取 socket、定时器触发等等。这就是为什么 Node.js 工程师必须把"避免阻塞 event loop"当成生死线。

修法 1:减小 body limit 并快速失败

事故后我们立刻做的第一件事是把 bodyLimit 降下来。正常订单请求 body 不会超过 100KB,我们把 limit 降到 1MB(留点 buffer),超出直接 413 拒绝,不进入 parse 流程。这一步把非法大请求挡在最前线,即使没有其他优化,光这一项就能避免 99% 的类似攻击。

// 修法 1: 大幅降低 bodyLimit
const app = fastify({
  bodyLimit: 1 * 1024 * 1024,  // 1MB, 超出立刻 413
});

// 不同路由可以差异化设置
app.post('/orders', {
  bodyLimit: 100 * 1024,  // 订单只允许 100KB
  handler: async (req, reply) => {
    const orderData = req.body as OrderRequest;
    return await processOrder(orderData);
  }
});

// 上传场景单独提供路由, 走 multipart 流式处理, 不用 JSON
app.register(require('@fastify/multipart'), {
  limits: { fileSize: 50 * 1024 * 1024 }
});
app.post('/upload', async (req, reply) => {
  const data = await req.file();
  // 流式处理, 不一次性 load 到内存
  await pipeline(data.file, fs.createWriteStream('/tmp/' + data.filename));
  return { ok: true };
});

这里有个关键设计:不同路由设置不同的 bodyLimit。订单接口 100KB 够用,上传接口 50MB 但走 multipart 流式处理避免一次性 load。这种"按场景细粒度限流"比全局一刀切更合理,既保证安全又不影响合法业务。Fastify 的 bodyLimit 配置非常灵活,值得每个 Node.js 项目都做这种细粒度控制。

修法 2:用 stream JSON parser 处理大数据

如果业务确实需要处理大 JSON(比如批量导入接口),不能简单拒绝,这时候要用stream JSON parser。流式解析不需要把整个 JSON load 到内存再解析,而是边读边解析,既节省内存又不阻塞 event loop(I/O 是异步的,parse 也是分块的,事件循环可以在 chunk 之间处理其他请求)。

import { parser } from 'stream-json';
import StreamArray from 'stream-json/streamers/StreamArray';
import { pipeline } from 'stream/promises';

app.post('/orders/batch', {
  bodyLimit: 100 * 1024 * 1024,  // 批量接口允许 100MB
  handler: async (req, reply) => {
    // 不要用 req.body (会一次性 parse), 用 req.raw 拿 stream
    const stream = req.raw;
    const results: any[] = [];

    await pipeline(
      stream,
      parser(),
      StreamArray.streamArray(),
      async function* (source) {
        for await (const { value } of source) {
          // 每次处理一个订单, 不会一次性 load 全部
          const result = await processOrder(value);
          results.push(result);
          // 关键: 每处理 10 个让出 event loop
          if (results.length % 10 === 0) {
            await new Promise(r => setImmediate(r));
          }
          yield result;
        }
      }
    );

    return { processed: results.length, results };
  }
});

这段代码的关键是setImmediate 让出 event loop。即使是流式 parse,如果你不主动 yield,长时间循环还是会阻塞。await new Promise(r => setImmediate(r)) 这个写法相当于告诉 event loop "我处理完一批了,你可以去处理其他事情,处理完再回来找我"。这是 Node.js 长循环必备的优化手段。

修法 3:把 CPU 密集任务移到 Worker Threads

有些任务天生是 CPU 密集型,比如大 JSON 处理、加密、图像处理、复杂算法,这些没办法"流式化",只能搬到 Worker Threads。Worker Threads 是 Node.js 10+ 提供的真线程,可以在独立的 V8 实例里跑 JS 代码,不阻塞主 event loop。

// worker.js - 独立线程跑 CPU 密集任务
const { parentPort, workerData } = require('worker_threads');

function heavyJsonProcess(jsonString) {
  const data = JSON.parse(jsonString);  // 在 worker 里 parse, 不影响主线程
  // 假设要做一些复杂计算
  const result = data.items.map(item => {
    return {
      ...item,
      hash: complexHashFunction(item),
      score: complexScoring(item),
    };
  });
  return result;
}

parentPort.on('message', ({ jsonString, taskId }) => {
  try {
    const result = heavyJsonProcess(jsonString);
    parentPort.postMessage({ taskId, ok: true, result });
  } catch (e) {
    parentPort.postMessage({ taskId, ok: false, error: e.message });
  }
});

// main.js - 主线程用 worker pool
const { Worker } = require('worker_threads');

class WorkerPool {
  constructor(size, workerPath) {
    this.workers = Array.from({ length: size }, () => new Worker(workerPath));
    this.queue = [];
    this.idle = [...this.workers];
    this.workers.forEach((w, i) => {
      w.on('message', msg => this._handleMessage(w, msg));
    });
  }

  run(jsonString) {
    return new Promise((resolve, reject) => {
      const task = { jsonString, taskId: Math.random(), resolve, reject };
      if (this.idle.length > 0) {
        this._dispatch(this.idle.pop(), task);
      } else {
        this.queue.push(task);
      }
    });
  }

  _dispatch(worker, task) {
    worker._currentTask = task;
    worker.postMessage({ jsonString: task.jsonString, taskId: task.taskId });
  }

  _handleMessage(worker, msg) {
    const task = worker._currentTask;
    if (msg.ok) task.resolve(msg.result);
    else task.reject(new Error(msg.error));
    if (this.queue.length > 0) {
      this._dispatch(worker, this.queue.shift());
    } else {
      this.idle.push(worker);
    }
  }
}

const pool = new WorkerPool(4, './worker.js');

app.post('/heavy', async (req, reply) => {
  const result = await pool.run(JSON.stringify(req.body));
  return result;
});

Worker Threads 的开销不小(进程间通信、序列化、worker 启动等),所以不要为小任务用 worker。一般原则是超过 50ms 的 CPU 任务才值得放 worker,小于 50ms 直接在主线程跑可能反而快。Worker pool 的大小通常设为 CPU 核心数,不要太多否则上下文切换开销大。

修法 4:event loop lag 监控 + 自我保护

除了修复具体阻塞点,我们也加了持续的 event loop lag 监控和自我保护机制:每秒检测 event loop lag,如果超过阈值(比如 100ms)就主动拒绝新请求,优先处理排队中的请求,避免雪崩。这种"过载保护"的思路在 Netflix 的 ConcurrencyLimiter、Linkerd 等系统都有,Node.js 自己实现也不复杂。

import { monitorEventLoopDelay } from 'perf_hooks';

const lagHistogram = monitorEventLoopDelay({ resolution: 20 });
lagHistogram.enable();

let currentP99Lag = 0;
setInterval(() => {
  currentP99Lag = lagHistogram.percentile(99) / 1e6;  // ms
  lagHistogram.reset();
  // 上报 Prometheus
  eventLoopLagGauge.set(currentP99Lag);
}, 1000);

const SHED_THRESHOLD_MS = 100;

// 全局 hook: 高 lag 时拒绝新请求
app.addHook('onRequest', async (req, reply) => {
  // 健康检查永远不限
  if (req.url === '/health' || req.url === '/ready') return;

  if (currentP99Lag > SHED_THRESHOLD_MS) {
    // 主动 shedding, 返回 503 让客户端重试
    reply.code(503).send({
      error: 'service_overloaded',
      retry_after_ms: 200,
    });
    return reply;
  }
});

这种自我保护机制的精髓是"承认自己也会过载, 主动拒绝部分请求, 保护核心能力"。看似拒绝了一些请求,实际上避免了"全员拥堵导致全员失败"的雪崩。健康检查不限制确保 K8s 不会误杀 Pod,业务请求超载就 503,客户端重试或降级,这是云原生时代的标准过载保护模式。

修法 5:CPU profiling 工具链建设

事故让我们意识到 Node.js 的 CPU profiling 工具链必须建好。我们现在的工具组合包括 clinic.js(开发/测试环境用,生成可视化报告)、0x(性能分析专用,flame graph 直观)、--inspect + Chrome DevTools(在线 profiling),以及 v8-profiler-next(代码内嵌动态触发 profile)。每个工具有自己的最佳使用场景。

# clinic.js 完整套件 (开发环境)
npm install -g clinic
clinic doctor -- node app.js     # 通用诊断, 给出问题方向
clinic flame -- node app.js      # CPU flame graph
clinic bubbleprof -- node app.js # 异步操作可视化
clinic heapprofiler -- node app.js  # 内存分析

# 0x 单独看 flame graph (轻量)
npm install -g 0x
0x app.js   # 跑完按 Ctrl+C 自动打开 flame graph

# 生产环境: --inspect 远程 attach
node --inspect=0.0.0.0:9229 app.js
# Chrome 打开 chrome://inspect, 点 inspect, 切到 Performance tab 录制

# 生产环境: 通过 API 动态触发 profile (推荐)
import inspector from 'inspector';
import fs from 'fs';

app.get('/__debug__/cpu-profile', async (req, reply) => {
  const session = new inspector.Session();
  session.connect();
  await new Promise(r => session.post('Profiler.enable', r));
  await new Promise(r => session.post('Profiler.start', r));

  // 录 30 秒
  await new Promise(r => setTimeout(r, 30000));

  const { profile } = await new Promise(r =>
    session.post('Profiler.stop', (e, p) => r(p)));
  session.disconnect();

  const file = `/tmp/cpu-${Date.now()}.cpuprofile`;
  fs.writeFileSync(file, JSON.stringify(profile));
  return { file };
});

把 /__debug__/cpu-profile 端点加到生产服务(带 auth 保护),需要排查时随时触发一次 30 秒 profile,下载到本地用 Chrome DevTools 打开看 flame graph。这种"按需 profile"的模式比"持续开 profile"开销小得多,生产可用。我们一年大概用了五六次,每次都能在 10 分钟内定位到性能热点。

HTTP server 层的并发控制

除了应用层的修法,我们也在 HTTP server 层做了一些并发控制,作为最外层的保护。Node.js 的 http.Server 可以设置 maxConnections、headersTimeout、requestTimeout 等参数,合理配置能挡掉一批异常请求。事故之前我们这些参数都是默认值(很多默认值不合理),事故后系统性调整了一遍。

// 完整的 server 安全配置
import { createServer } from 'http';

const server = createServer(app);

// 单个连接超时
server.headersTimeout = 5000;    // 5s 内必须收到完整 headers
server.requestTimeout = 30000;   // 整个请求 30s 内必须完成
server.keepAliveTimeout = 5000;  // keep-alive 连接 5s 无活动关闭
server.maxRequestsPerSocket = 100;  // 单连接最多 100 个请求 (防 keep-alive 滥用)

// 全局连接数限制
server.maxConnections = 1000;    // 总连接数上限

// 优雅关闭 (SIGTERM 时)
process.on('SIGTERM', async () => {
  console.log('SIGTERM received, draining');
  // 1. 停止接收新请求 (返回 503 给 LB)
  app.addHook('onRequest', async (req, reply) => {
    if (req.url !== '/health') {
      reply.code(503).send('shutting_down');
    }
  });
  // 2. 等待 in-flight 请求完成 (最多 30s)
  await new Promise(r => setTimeout(r, 30000));
  // 3. 关闭 server
  server.close();
  process.exit(0);
});

这些 server 层配置看似细节但非常重要。比如 headersTimeout 默认 60 秒,这意味着攻击者可以建大量"半连接"(只发 headers 慢慢发或者根本不发)消耗 server 资源,这就是经典的 Slowloris 攻击。把 headersTimeout 调到 5 秒就能挡掉绝大多数 Slowloris,代价几乎为零。这种"调整默认配置"的优化往往是性价比最高的。

横向对比:同步代码阻塞 vs 内存泄漏 vs 死锁

事故复盘:链式失败的多个环节

这次雪崩不是单点失败,而是链式失败:配置不当(bodyLimit 50MB)→ 同步 parse 大 JSON → event loop 阻塞 1.4s → 健康检查超时 → Pod 被重启 → 流量重分配到其他 Pod → 其他 Pod 也接到大请求 → 全员阻塞。任何一个环节断掉就不会成雪崩,但所有环节都没做好,小问题变成大灾难。

从这次事故我们学到的核心教训是:分布式系统的鲁棒性来自多层独立的防御机制。bodyLimit 是第一层、stream parser 是第二层、worker thread 是第三层、event loop 监控是第四层、过载保护是第五层。任何一层都不能保证万无一失,但五层叠加可以让单点失败的概率降到几乎为零。这种"纵深防御"的思路是云原生时代每个服务都应该具备的。

团队立的 8 条 Node.js event loop 纪律

1. 所有 sync 函数都是嫌疑犯:JSON.parse / JSON.stringify / crypto.*Sync / fs.*Sync / zlib.*Sync 等大数据上必慢, code review 必看。
2. bodyLimit 按路由细粒度配置:不要用全局大 limit, 每个接口按业务实际需求设。
3. 大数据用 stream:JSON 用 stream-json, CSV 用 fast-csv, 文件用 fs.createReadStream, 永远不一次性 load。
4. CPU 密集任务用 Worker Threads:超过 50ms 的同步任务必须移出主线程。
5. 长循环必须 yield:每 N 次迭代用 setImmediate 让出 event loop。
6. 必有 event loop lag 监控:perf_hooks 持续监控, 阈值 100ms 报警。
7. 必有过载保护:lag 超阈值主动 shedding, 保护核心能力。
8. 必有 CPU profiling 端点:/__debug__/cpu-profile 随时按需 profile。

把 Node.js 限制讲清楚的内部分享

事故复盘的另一个产出是把 Node.js 的 event loop 限制做成内部技术分享,在公司内部所有用 Node.js 的团队都讲一遍。分享内容包括:event loop 的 6 个 phase、libuv 线程池的作用、Worker Threads 和 Cluster 的区别、所有 sync API 的清单、常见性能陷阱、监控和过载保护的最佳实践。这次分享后,各团队主动开始审视自己的代码,我们大约收到 30 多个内部反馈,涉及类似问题的代码大部分都修了。

这种"借事故推动全公司能力提升"的做法非常有效。很多团队平时没有动力去深入学 event loop,但一次事故让大家意识到必要性,主动学习的效果比强制培训好得多。我个人也更深入地学习了 V8 和 libuv 的内部实现,对 Node.js 的理解上了一个台阶。事故是糟糕的体验,但能从事故里提炼出系统性的能力提升,就是工程师成长的最快路径。

异步代码的"隐形阻塞"陷阱

除了显式的同步代码,还有些异步代码看起来非阻塞,实际上隐藏阻塞。比如大数组的 forEach + 同步操作、没有 await 的 Promise 链造成的 unhandled rejection、正则表达式回溯爆炸(ReDoS)等,这些都会阻塞 event loop 但更难定位。

// 隐形阻塞 1: forEach 看似异步实际同步
function processItems(items) {
  items.forEach(item => {
    // 这里同步处理 100 万个 item, 阻塞 event loop
    item.hash = computeHash(item);
  });
}

// 修法: 分批 + yield
async function processItemsAsync(items) {
  const BATCH = 1000;
  for (let i = 0; i < items.length; i += BATCH) {
    items.slice(i, i + BATCH).forEach(item => {
      item.hash = computeHash(item);
    });
    await new Promise(r => setImmediate(r));  // yield
  }
}

// 隐形阻塞 2: ReDoS - 正则回溯爆炸
const RE = /^(a+)+$/;  // 邪恶正则
const malicious = 'a'.repeat(30) + '!';
RE.test(malicious);  // 在 V8 上可能跑几秒, 阻塞 event loop

// 修法: 用 safe-regex 检查, 或限制正则复杂度
import safeRegex from 'safe-regex';
if (!safeRegex(userProvidedRegex)) {
  throw new Error('unsafe regex');
}
// 或用 RE2 库 (不支持反向引用但永远线性时间)
import RE2 from 're2';
const safe = new RE2('^(a+)+$');  // RE2 在恶意输入下也不会爆炸

ReDoS 是 Node.js 服务一个被严重低估的攻击面。任何接受用户提供正则的接口都是潜在风险点,即使是固定的正则,如果输入失控也可能触发回溯爆炸。我们在事故后系统性扫描了所有正则使用,用 safe-regex 标出了 12 个潜在 ReDoS 点,逐个改写或加入长度限制,从根本上消除了这类风险。

给 Node.js 工程师的几条建议

第一条建议是把"不阻塞 event loop"刻在 DNA 里。这是 Node.js 性能的命脉,任何写 Node 代码的工程师都应该养成"这段代码会不会阻塞 event loop"的本能反应。看到 JSON.parse 想到大对象、看到 forEach 想到长循环、看到 sync 后缀想到同步 I/O,这种警觉性能避免 90% 的性能问题。

第二条建议是建立 event loop lag 监控作为基础设施。这不是可选项,而是必备。lag 监控的成本极低(几 KB 内存 + 微秒级 CPU),但提供的洞察价值巨大。每个 Node.js 服务上线第一天就应该有 lag 监控,出现问题第一时间能定位是不是 event loop 阻塞。

第三条建议是不要害怕 Worker Threads。很多 Node.js 工程师对 Worker Threads 不熟,遇到 CPU 任务就硬扛。其实 Worker Threads 已经非常成熟,piscina 这种 worker pool 库封装得很好,几行代码就能把 CPU 任务搬过去。能用 worker 解决的就别在主线程硬撑。

第四条建议是过载保护比性能优化更重要。一个能在高负载下"保持降级运行"的服务,比一个"平时很快但过载即雪崩"的服务可靠得多。优雅降级、主动 shedding、限流、熔断这些机制比"再优化 10ms"的价值大十倍,但很多团队的优先级搞反了。

常见误诊和坑

排查 Node.js 性能问题时也容易误诊,分享几个我们踩过的坑。第一个误诊是把 GC 暂停误当成 event loop 阻塞。V8 的 GC 偶尔会有几十毫秒的 stop-the-world 暂停,这个看起来和同步代码阻塞很像,但根因完全不同,修法也不一样(GC 调优 vs 重构代码)。区分方法是看 --trace-gc 日志,看是不是 GC 期间发生的延迟尖峰。

第二个误诊是把网络延迟当成 event loop 问题。下游依赖慢导致的请求堆积,在监控里也表现为 P99 飙高,但 event loop lag 是正常的。区分方法是同时监控 event loop lag 和下游 RT,如果 RT 飙高但 lag 正常,问题在下游;如果 lag 也飙高,问题才在本服务。

第三个误诊是过度归因 Node.js 版本。事故发生后总有人说"是不是 Node 版本太老,升级一下吧",但绝大多数性能问题和 Node 版本无关,是代码层面的问题。先彻查代码,再考虑升级。我们事故后保持 Node 20 LTS 不动,所有问题都通过代码修复解决,稳定性很好。

第四个误诊是误信第三方库的性能宣传。"X 比 Y 快 10 倍" 的 benchmark 经常在特定场景下,实际生产可能差异很小甚至更慢。换库之前一定要在自己的业务场景跑压测,不要轻信营销宣传。我们之前为了"性能"换过一个 JSON 库,结果生产数据下反而慢 5%,又换回来,浪费了一周时间。

事故后我们做的 SOAK 测试

事故复盘的一个重要产出是把异常输入的 SOAK 测试加进 CI。我们专门设计了几类恶意输入模拟攻击:深嵌套 JSON、超大数组、长字符串、邪恶正则触发的输入、超长 URL 参数等等,每个 PR 都要跑一遍,任何一个让 event loop lag 超过 50ms 就阻断合并。这种"主动模拟攻击"的测试比常规功能测试更能挡住性能炸弹。

// soak/malicious-inputs.test.js
import { test, expect } from 'vitest';
import autocannon from 'autocannon';
import { monitorEventLoopDelay } from 'perf_hooks';

test('深嵌套 JSON 不会阻塞 event loop', async () => {
  const hist = monitorEventLoopDelay({ resolution: 20 });
  hist.enable();

  // 构造深嵌套 JSON (1MB 数据, 嵌套 500 层)
  let payload = { value: 1 };
  for (let i = 0; i < 500; i++) payload = { nested: payload };

  await autocannon({
    url: 'http://localhost:3000/orders',
    method: 'POST',
    body: JSON.stringify(payload),
    headers: { 'content-type': 'application/json' },
    duration: 10,
    connections: 50,
  });

  const p99lag = hist.percentile(99) / 1e6;
  hist.disable();
  expect(p99lag).toBeLessThan(50);  // P99 lag 不超过 50ms
});

test('1MB body 不会阻塞', async () => {
  const big = { items: Array(10000).fill({ name: 'x'.repeat(100) }) };
  // ... 同样的测试
});

test('ReDoS 输入不会阻塞', async () => {
  const malicious = 'a'.repeat(35) + '!';
  // 测试所有暴露给用户的接口对恶意正则输入的容忍度
});

这套 SOAK 测试在 CI 里只跑 5 分钟,但每周都会挡住 1-2 个性能问题 PR。常见的捕获模式是:开发者新加了一个 JSON 处理代码,没意识到大输入会阻塞,SOAK 测试一跑就暴露。这种"用恶意输入测试自己代码"的思路非常实用,推荐每个 Node.js 项目都做。

同步 API 在哪些场景仍然合理

讲了这么多反对同步 API,要不要全面禁止?其实不是。Node.js 的同步 API 在启动阶段(读配置、加载证书、初始化资源)是完全合理的,因为这时候还没开始接请求,阻塞无所谓。在 CLI 工具、build 脚本、单次性任务里同步 API 也是首选,因为没有并发需求。只有在请求处理路径上同步 API 才是禁忌。

// OK: 启动时用 sync 读配置
const config = JSON.parse(fs.readFileSync('./config.json', 'utf-8'));
const cert = fs.readFileSync('./cert.pem');

// 启动后请求处理路径只用 async
const server = https.createServer({ cert, key }, async (req, res) => {
  // 请求处理路径上禁止 sync
});

// CLI 工具用 sync 没问题
#!/usr/bin/env node
const data = fs.readFileSync(process.argv[2], 'utf-8');
const result = processSomething(data);
fs.writeFileSync(process.argv[3], result);
console.log('done');

分清"启动阶段"和"运行阶段"的不同要求,是 Node.js 工程的基本素养。死板地"一切都要 async"反而会让启动代码变复杂、可读性变差。理解 event loop 的工作原理才能做出正确的取舍。

Fastify / Express / Koa 在性能上的差异

这次事故之后我们也重新评估了 Node.js Web 框架的选择。Fastify 的优势是内置 schema validation 和高性能 JSON 处理,Express 简单但中间件链可能引入隐式同步,Koa 异步模型最干净但生态相对小。我们对三个框架的核心场景做了压测,结果分享出来给大家参考。

性能差异主要来自中间件实现方式和JSON parser。Fastify 用了 fast-json-stringify 做 schema 编译,比 Express 默认 body-parser 快 2-3 倍;hono 是新兴框架,在 Bun / Deno / Node 上都能跑,性能也很好。但框架选择不是只看性能,生态、团队熟悉度、长期维护性都要考虑。我们最终决定保留 Fastify,因为团队已经在用而且性能已经够好。

过载保护的具体阈值怎么定

有同行问 event loop lag 的过载阈值怎么定?我的经验是从生产数据出发,留 2-3 倍 buffer。先观察正常负载下的 P99 lag,如果平时 P99 是 20ms,过载阈值就设到 60-100ms;如果平时 P99 是 5ms,过载阈值可以设到 30-50ms。不要直接照抄别人的阈值,因为不同业务的 lag 特征差异很大,内存计算密集型的服务平时 lag 就高一些,纯 I/O 服务平时 lag 几乎是 0。

另一个建议是shedding 比例要渐进。lag 刚超阈值时只拒绝 10% 请求,继续涨拒绝 30%、50%,这种"渐进 shedding"比"全拒绝"更平滑,用户体验更好。netflix 的 Concurrency Limiter 算法就是这个思路,实现起来也不复杂,值得借鉴。

多 Node.js 进程的协同

事故之后我们也优化了 Node.js 进程的部署方式。原来是每个 K8s Pod 跑一个 Node.js 进程,只能用 1 个核;改成每个 Pod 跑 N 个进程(N = vCPU 数),通过 cluster 模式共享端口或者 Pod 给 N 个副本,可以充分利用多核。两种方式各有优劣:cluster 模式部署简单但共享内存有限制,多副本部署灵活但配置复杂一些。我们最终选择了多副本,搭配 K8s HPA 自动伸缩,运维和工程师都觉得顺手。

// cluster 模式示例 (单 Pod 多进程)
const cluster = require('cluster');
const os = require('os');

if (cluster.isPrimary) {
  const numCpu = os.availableParallelism();  // Node 19+
  console.log(`Master forking ${numCpu} workers`);
  for (let i = 0; i < numCpu; i++) cluster.fork();
  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died, forking new one`);
    cluster.fork();
  });
} else {
  // worker 进程跑实际服务
  require('./app');
}

// 或用 pm2 管理 (更成熟)
// pm2 start app.js -i max  // 自动按 CPU 核心数 fork

多进程之后还有一些细节要注意。第一,每个进程独立监控,event loop lag、内存、CPU 都按进程汇报,不能只看 Pod 总量;第二,状态不能放进程内存(比如 in-memory cache),要用 Redis 等共享存储;第三,sticky session 谨慎使用,会破坏负载均衡。这些都是从 cluster 模式踩过坑后总结的。

libuv 线程池和 CPU 密集任务的真实选择

事故复盘到后期,我们专门花了一周时间梳理 Node.js 里所有"看起来异步、其实可能阻塞"的 API,这部分知识对每个 Node.js 工程师都很重要。Node.js 的异步模型分两层:一层是 V8 主线程的 event loop,负责执行 JavaScript 代码和管理回调;另一层是 libuv 提供的固定大小线程池(默认 4 个线程),用来跑那些没法异步化的系统调用,比如文件 I/O、DNS 解析(getaddrinfo)、部分 crypto 操作(pbkdf2、scrypt、randomBytes 大数据量)、zlib 压缩等。

这个线程池的坑在于,它的大小默认只有 4,而且对所有这些任务共享。如果你的服务高并发用了 crypto.pbkdf2 算密码哈希,那 4 个线程很快被占满,后续的 DNS 解析、文件读取都会排队等待,表现就是明明 event loop lag 不高,但接口响应慢。我们在另一个服务上踩过这个坑:登录接口 P99 突然从 100ms 飙到 2 秒,排查了一周才发现是 pbkdf2 把线程池占满了。

// 调整 libuv 线程池大小 (启动前设置环境变量)
// UV_THREADPOOL_SIZE=16 node app.js

// 或者代码里设置 (必须在任何 fs / crypto / dns 调用之前)
process.env.UV_THREADPOOL_SIZE = '16';

// 验证线程池被打满的方法
const { performance } = require('perf_hooks');
const crypto = require('crypto');

async function probe() {
  const start = performance.now();
  await new Promise((resolve, reject) => {
    crypto.pbkdf2('test', 'salt', 1, 32, 'sha256', (err) => {
      err ? reject(err) : resolve();
    });
  });
  return performance.now() - start;
}

// 正常情况 < 1ms; 如果排队会变成几十甚至几百 ms
setInterval(async () => {
  const t = await probe();
  if (t > 10) console.warn(`Thread pool slow: ${t.toFixed(2)}ms`);
}, 1000);

我们最终把线程池调到了 16,刚好和 Pod 的 2 vCPU * 8 倍超分匹配。注意线程池调大不是越大越好,超过 vCPU 数的 4-8 倍后,线程切换开销会反噬,反而变慢。另外 crypto 密集型场景应该优先考虑用专用的密码哈希服务或者迁移到 argon2(有专门的 native 模块,不走 libuv 线程池),从根上摆脱这个瓶颈。

HTTP server 超时配置的安全清单

事故的根因虽然是 JSON.parse 阻塞,但事后我们也审视了 HTTP 层的超时配置,发现一堆默认值都不合理,容易给 Slowloris 这类慢速攻击留口子。Node.js 的 http.Server 有几个超时参数,但默认值都偏宽松,生产环境必须显式收紧。下表是我们这次复盘后定下的标准配置。

// Fastify 安全的超时配置 (我们的生产模板)
const fastify = require('fastify')({
  logger: true,
  bodyLimit: 1024 * 1024,  // 1MB, 之前是 50MB
  connectionTimeout: 30000,
  keepAliveTimeout: 15000,
  http: {
    headersTimeout: 10000,
    requestTimeout: 30000,
    maxHeaderSize: 8192,
  }
});

// 错误处理: 超时记录
fastify.setErrorHandler((error, request, reply) => {
  if (error.statusCode === 408 || error.code === 'FST_ERR_CTP_BODY_TOO_LARGE') {
    request.log.warn({ip: request.ip, url: request.url, err: error.message}, 'Suspicious request');
  }
  reply.send(error);
});

// 速率限制 (按 IP 每秒 100 请求)
await fastify.register(require('@fastify/rate-limit'), {
  max: 100,
  timeWindow: '1 minute',
  ban: 3,  // 连续 3 次超限封 60 秒
});

除了超时,我们还加了一层速率限制(用 @fastify/rate-limit 插件),按 IP 限制每分钟 100 请求,连续触发限速 3 次封禁 60 秒。这些都是基础的 HTTP 防护,但出事前我们一个都没配,完全裸奔。事故后这套配置已经成为团队所有 Node.js 服务的默认模板,新服务初始化就带上,不用再"等出事再加"。

总结

这次 23 分钟雪崩的核心教训是"看似无害的同步代码 + 不合理的配置 = 雪崩"。Node.js 单线程 event loop 的优势在 I/O 密集场景, 但任何 CPU 密集或大数据同步操作都是定时炸弹。这次事故让我们补齐了 event loop 监控、过载保护、CPU profiling 等基础设施, 也建立了 8 条工程纪律, 之后类似事故再没发生过。这种系统性的能力升级,远比"修一个 bug"的价值更大,值得每个团队在事故后认真投入。

给所有 Node.js 工程师一个建议:不要等到雪崩才学 event loop。这是 Node.js 性能的根本,平时多花时间理解 event loop 的工作原理、熟悉 perf_hooks / clinic.js 等工具、养成"避免阻塞"的编码习惯,这些投资在关键时刻能让你少加无数次班。希望这篇分享的工具链、修法、纪律能帮到正在搞 Node.js 服务的同行,提前把 event loop 这道生死线守住。

—— 别看了 · 2026