1 cluster多进程

cluster经过好几代的发展，现在已经比较好使了。利用cluster，可以自动完成子进程worker分配request的事情，就不再需要自己写代码在master进程中robin式给每个worker分配任务了。

const cluster = require('cluster');
const http = require('http');
const numcpus = require('os').cpus().length;

if (cluster.ismaster) {
  @H_618_28@// Fork workers.
  for (var i = 0; i < numcpus; i++) {
    cluster.fork();
  }

  cluster.on('exit',(worker,code,signal) => {
    console.log(`worker ${worker.process.piD} died`);
  });
} else {
   Workers can share any TCP connection
   In this case it is an http server
  http.createServer((req,res) => {
    res.writeHead(200);
    res.end('Hello world\n');
  }).listen(80);
}

上述简单的代码，就实现了根据cpu个数，创建多个worker。至于实际项目中，是正好一个核对应一个worker呢，还是一个核对应2、3个worker呢，就视情况而定了。如果项目中，等待其他服务器（例如数据库）响应特别长时间，设置2个以上worker应该会更好。

不过一般而言，一个cpu对一个worker就挺好的了。

那么，整个架构就类似这样：

Master进程，需要做的就是监控worker的生命周期，如果发现worker挂掉了，就重启worker，并做好相应的log。

整个架构没有太大的难点，重点就是做好一些细节处理，例如重启、日志、5秒心跳包等。

多进程的架构，相对原始的单进程+pm2重启好处肯定多很多，整个node服务会更稳定，不会突然彻底挂了。

另外，对比pm2多进程，也有优势，主要是master的逻辑掌握在开发自己手中，可以做好自定义的log和邮件、短信告警。

为了整个nodejs服务管理方便，在master进程中，我们一般开启管理端口的监听，例如12701，通过命令行curl 127.0.0.1:12701:xxx发起一个简单的http get请求，轻松管理。

例如xxx传入reload，可以作为服务器重启的指令。

2 负载均衡

说到多进程，目的肯定是尽可能利用多核cpu，提高单机的负载能力。

但往往在实际项目中，受到业务逻辑的处理时间长短和系统cpu调度影响，导致实际上所有进程的负载并不是理想的彻底均衡。

官方也说了：

In practice however,diStribution tends to be very unbalanced due to operating system scheduler vagaries. Loads have been observed where over 70% of all connections ended up in just two processes,out of a @R_847_10586@l of eight.

翻译一下：70%的请求最终都落到2个worker身上，而这2个worker占用更多的cpu资源。

那么在实际项目部署，我们可以尝试更进一步的措施：绑定cpu。4核cpu，我们fork出4个worker，每个worker分别绑定到#1-#4 cpu。

node并没有给我们提供现成的接口，不过我们可以使用linux的命令：taskset

在Node中，我们可以使用child_process执行sHell。