node进程管理集群

有人的地方就有江湖，有江湖的地方就有包工头
                   --尼古拉斯张三

单机进程管理的缺点

一个人的力量毕竟是有限的，单机进程管理像下图这样。

看这个图会发现两个问题：

1. 任务分发和进程管理两个服务放在一块耦合过于严重，一上线某一个功能就需要重启所有进程
2. 单机资源是有限的，随着进程增加，就会出现资源不够用的情况

进程管理集群

为了解决上面两个问题，应该引入集群思维，一个主机管理下面其他进程管理机器，这样主机上线不会影响 node 服务，而且集群资源是丰富的配合 docker 还是可以动态扩容的。

具体架构应该是这样的

• 启动

  • 当集群 B 的工作节点启动时候，会向任务分配节点注册机器信息，并按分钟发送心跳（机器信息）。
  • 集群 A 会保存这些节点信息，供后面任务分发使用。

• 启动服务

  • 当一个进程需要启动时候，会检查当前节点信息，分配给相对空闲的机器。
  • 此时将 node 进程和工作节点进行绑定，以供后续重启暂停操作。

• 上线管理节点

  • 上线管理节点时候我们无需重启 node 进程节点，各节点均可正常访问

• 上线工作节点

  • 工作节点会不再发送心跳，管理节点认为工作节点挂掉。
  • 并向新一轮的注册节点进行新一轮的任务分配，并重启对应 node 进程

这样就解决了单机实例的问题，并且服务高可用，工作职责明确。

node 进程高可用谁来管理？

也可整合到节点服务中，那么可能节点分配可能是这样的

可以看到每个工作节点都会存在进程 1，为什么有的进程是单个有的进程是多个节点都存在呢。

这部分是因为进程功能不相同

对于业务节点比如 ssr，node 测试服务可能只需要一个进程就够了。

但是对于想要把 gitlab runner 的能力也搞过来，就需要多个工作节点干一样的活了。

总结

单节点还是很脆弱的，集群与其对比优势展现的十分明显，不过需要维护节点信息，分发任务等细节的处理，实现起来相对复杂些。