背景与问题界定

Node.js 单线程事件循环的特性决定了单个进程只能利用一个 CPU 核心。在生产环境中，面对多核服务器（4C / 8C / 16C），直接启动单进程 Node.js 会导致 CPU 资源利用率极低。传统的解决方案是使用 cluster 模块启动多个 Worker 进程，由 Master 进程负责负载均衡。然而，cluster 在实际运维中暴露出不少问题：Worker 进程意外退出后 Master 的 fork 行为可能导致无限重启；优雅关闭时信号处理容易遗漏；进程间共享资源（数据库连接池、缓存）的管理没有标准方案。随着容器化和 Kubernetes 编排的普及，这些问题的解决路径也在发生变化——从进程级别的管理转向容器级别的编排。

目标拆解与工程约束

  • Worker 数量自适应：在裸机部署中，Worker 数应等于 CPU 核心数减 1（预留系统资源）；在容器部署中，应通过 cgroup 获取实际的 CPU 配额，避免在 1 核限制的容器中启动 4 个 Worker。
  • 优雅关闭与零停机重启：收到 SIGTERM 信号后，Worker 应停止接受新请求，等待正在处理的请求完成后退出，超时（默认 30s）未完成则强制退出。
  • 共享状态管理：进程间需要维护一个轻量级的共享状态（如内存缓存、节流计数器），通过共享内存或外部中间件实现，避免引入额外的网络依赖。
  • 健康检查与自愈：每个 Worker 对外暴露 /healthz 端点，Master 定期检测 Worker 的心跳，异常 Worker 被替换。

方案设计

cluster 模块的核心架构是 Master-Worker 模式。Master 进程负责监听端口、接收连接并通过 round-robin 或操作系统分派将连接分配给 Worker。Worker 进程是实际处理请求的应用实例。我们实现一个增强版的 cluster 管理器，覆盖常见的风险场景：

import cluster from 'cluster'
import { cpus } from 'os'
import { availableParallelism } from 'os'

const WORKER_COUNT = process.env.CLUSTER_CPU_COUNT
  ? parseInt(process.env.CLUSTER_CPU_COUNT)
  : availableParallelism?.() ?? cpus().length

const MAX_RESTART_RATE = 3  // 每分钟最多重启次数
const restartTimestamps: number[] = []

if (cluster.isPrimary) {
  console.log(`Primary ${process.pid} is running`)

  for (let i = 0; i < WORKER_COUNT; i++) {
    forkWorker()
  }

  cluster.on('exit', (worker, code, signal) => {
    console.log(`Worker ${worker.process.pid} died (${signal || code})`)
    if (isRestartAllowed()) {
      forkWorker()
    } else {
      console.error('Too many restarts, giving up')
      process.exit(1)
    }
  })

  // 健康检查 ping
  setInterval(() => {
    for (const id of Object.keys(cluster.workers)) {
      cluster.workers[id]?.send({ type: 'ping' })
    }
  }, 30000)
} else {
  // Worker: 启动应用并处理 ping
  process.on('message', (msg) => {
    if (msg.type === 'ping') { process.send?.({ type: 'pong' }) }
    if (msg.type === 'shutdown') { gracefulShutdown() }
  })
}

在容器化部署场景下，Kubernetes 的 ReplicaSet 替代了 cluster 的 Master 角色。此时不需要在应用内使用 cluster 模块——每个 Pod 运行单一的 Node.js 进程，K8s 的 Service 负责负载均衡。这样做的好处是：Pod 级别的故障隔离更加清晰，水平伸缩由 kubectl scale 或 HPA 控制，滚动更新由 Deployment 策略保障。我们只需要保证单个进程的优雅关闭（SIGTERM → HTTP server close() → 等待活跃连接 → 退出）。

在容器与 cluster 混用的混合模式下，我们在 K8s Pod 内使用 cluster 共享 Pod 内的多核，但需要正确配置 worker count 为 Pod 的 CPU limit 而非宿主机的核心数。通过读取 /sys/fs/cgroup/cpu.max 或通过 Downward API 注入环境变量来获取准确的 CPU 配额。

实施路径与关键决策

  • 裸机部署优先使用 PM2：PM2 封装了 cluster 的进程管理、日志轮转和自动重启，比手写 cluster 代码更稳定，仅当需要自定义进程间通信时引入 cluster 的增强实现。
  • 容器部署禁用 cluster：K8s 环境下每个 Pod 跑单进程，配合 HPA 实现水平伸缩，避免 Pod 内多进程的资源竞争和日志混乱。
  • 优雅关闭必须测试：编写集成测试，启动真实 HTTP 服务，发送 SIGTERM 后并发请求验证未断连。
  • 进程间通信限定场景：仅用于广播（如缓存刷新）和心跳检测，不用于 RPC，大量跨进程通信时应引入 Redis Pub/Sub 或消息队列。

验证指标与可持续迭代

滚动更新期间零请求失败（通过负载均衡器的 5xx 指标监控）；单 Worker 故障恢复时间 < 1s；CPU 利用率从单进程的 25% 提升到 85% 以上（4C 场景）。持续迭代方向包括：基于 worker_threads 的混合并行模型（IO 密集型用 cluster + 计算密集型转 worker_threads），以及基于自定义指标的 K8s HPA 自动扩缩容策略。

工程落地思考

从 cluster 到容器化编排的演进，反映了应用架构从"尽可能利用单机资源"到"分布式可伸缩"的范式转变。cluster 模块在现代 Node.js 应用中的角色越来越像一个过渡方案——它在裸机时代是必需品，在云原生时代变成了可选优化。团队在做技术选型时，优先级应该是：先考虑应用的部署目标环境，再决定是否使用 cluster。K8s 已经为我们提供了进程级故障恢复和负载均衡，不要在 K8s 之上重复实现同样的能力。