集群

背景与问题界定 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 管理器，覆盖常见的风险场景： ...