Node节点集群如何实现负载均衡

Node 节点集群的负载均衡实现

一、架构总览

• 单机多进程：在单台机器上用 Node.js cluster 启动多个 worker，主进程（master）监听端口并按策略分发连接，充分利用多核 CPU。适合提升单机吞吐与可靠性。
• 多机多实例：在每台机器上同样启用多个 worker，前面再加一层 反向代理/负载均衡器（如 Nginx、HAProxy）做服务发现与健康检查，实现跨机器的流量分发与高可用。
• 进程管理：生产环境常用 PM2 的 cluster mode 一键起多进程、做零停机部署与监控，底层仍基于 cluster。

二、单机多进程的负载均衡

• 核心机制：master 进程创建 TCP 监听 socket，收到新连接后按策略分发给 worker；worker 共享该监听端口，由操作系统/运行时完成连接转发。Node 默认采用 Round Robin（轮询） 分发连接，均衡简单可靠。
• 基本示例：

// cluster.js
const cluster = require('cluster');
const http = require('http');
const os = require('os');

if (cluster.isMaster) {
  const n = os.cpus().length;
  console.log(`Master ${process.pid} fork ${n} workers`);
  for (let i = 0; i < n; i++) cluster.fork();
  cluster.on('exit', (w, code, sig) => {
    console.warn(`Worker ${w.process.pid} died, restarting...`);
    cluster.fork();
  });
} else {
  http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end(`Hello from worker ${process.pid}\n`);
  }).listen(8000, () => {
    console.log(`Worker ${process.pid} listening on 8000`);
  });
}

• 策略与调度：可通过环境变量 NODE_CLUSTER_SCHED_POLICY 或 cluster.schedulingPolicy 切换策略，常见为 cluster.SCHED_RR（轮询） 与 cluster.SCHED_NONE（由操作系统调度/共享套接字）。
• 进程管理要点：监听 ‘exit’ 事件自动重启异常退出的 worker，保证容量稳定。

三、多机部署与反向代理

• 拓扑结构：多台机器各运行多个 worker（如每台 4 个），前面统一接入 Nginx/HAProxy，对外暴露 80/443，对内按权重/健康检查分发到各实例。
• Nginx 示例（轮询）：

http {
  upstream backend {
    server 10.0.0.11:3000 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 weight=1 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:3000 weight=1 max_fails=3 fail_timeout=30s;
  }
  server {
    listen 80;
    location / {
      proxy_pass http://backend;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
  }
}

• HAProxy 示例（HTTP 模式 + 健康检查）：

frontend http_in bind *:80
  default_backend node_app

backend node_app
  balance roundrobin
  server node1 10.0.0.11:3000 check
  server node2 10.0.0.12:3000 check
  server node3 10.0.0.13:3000 check

• 适用场景：跨节点横向扩展、容灾与灰度发布；健康检查与权重机制可提升整体稳定性与资源利用率。

四、会话保持与状态管理

• 何时需要：有 粘性会话（Session Affinity） 诉求（如未做无状态设计、依赖本地内存会话）时，同一客户端请求应尽量落到同一 worker。
• 实现方式：
  • 应用层使用 Redis/Memcached 等集中式会话存储，彻底无状态，天然适配轮询与扩缩容。
  • 入口层做 IP 哈希/会话粘滞（如使用 sticky-session 等中间件），将同一来源 IP 固定到同一 worker。示例思路：

// 示意：基于 IP 的简单取模粘滞（生产请用成熟中间件）
const sticky = require('sticky-session');
const server = http.createServer(app);
sticky.listen(server, 8000, {
  workerIndex: (ip, workers) => {
    // 简化示例：将 IP 数字求和后取模
    const s = ip.replace(/\D/g, '');
    return Number(s) % workers.length;
  }
});
for (let i = 0; i < os.cpus().length; i++) cluster.fork();

• 建议优先选择“无状态 + 外部会话存储”，减少粘滞带来的热点与扩容限制。

五、生产实践与运维要点

• 进程数建议：通常设为 CPU 核心数 起步，结合 内存/事件循环阻塞 与 压测 调整；使用 PM2 cluster mode 的 instances=max 可快速按核心数起进程。
• 健康检查与自动恢复：反向代理配置 主动/被动健康检查 与 失败重试；Node 侧监听 worker ‘exit’ 事件自动拉起新进程，缩短故障恢复时间。
• 优雅停机与滚动升级：先摘除节点或停止接收新连接，等待 in-flight 请求 处理完成后再退出 worker；配合 PM2 零停机部署 或 Nginx/HAProxy 的 drain/weight 调整 实现平滑升级。
• 可观测性：输出 进程/实例 ID、请求耗时、错误率 等关键指标，结合日志与链路追踪定位热点与瓶颈。