PM2 源码分析

近期有需求须要了解 PM2 一些功能的实现方式，因此趁势看了一下 PM2 的源码，也算是用了这么多年的 PM2，第一次进入内部进行一些探索。
PM2 是一个 基于 node.js 的进程管理工具，自己 node.js 是一个单进程的语言，可是 PM2 能够实现多进程的运行及管理（固然仍是基于 node 的 API），还提供程序系统信息的展现，包括 内存、CPU 等数据。

PM2 的核心功能概览

源码位置
官方网站

PM2 的功能、插件很是的丰富，但比较核心的功能其实很少：

1. 多进程管理
2. 系统信息监控
3. 日志管理

其余的一些功能就都是基于 PM2 之上的辅助功能了。

项目结构

PM2 的项目结构算是比较简洁的了，主要的源码都在 lib 目录下， God 目录为核心功能多进程管理的实现，以及 API 目录则是提供了各类能力，包括 日志管理、面板查看系统信息以及各类辅助功能，最后就是 Sysinfo 目录下关于如何采集系统信息的实现了。

# 删除了多个不相干的文件、文件夹
lib
├── API     # 日志管理、GUI 等辅助功能
├── God     # 多进程管理逻辑实现位置
└── Sysinfo # 系统信息采集

几个比较关键的文件做用：

• Daemon.js

  • 守护进程的主要逻辑实现，包括 rpc server，以及各类守护进程的能力

• God.js

  • 业务进程的包裹层，负责与守护进程创建链接，以及注入一些操做，咱们编写的代码最终是由这里执行的

• Client.js

  • 执行 PM2 命令的主要逻辑实现，包括与守护进程创建 rpc 链接，以及各类请求守护进程的操做

• API.js

  • 各类功能性的实现，包括启动、关闭项目、展现列表、展现系统信息等操做，会调用 Client 的各类函数

• binaries/CLI.js

  • 执行 pm2 命令时候触发的入口文件

守护进程与 Client 进程通信方式

看源码后会知道，PM2 与 Client 进程（也就是咱们 pm2 start XXX 时对应的进程），是经过 RPC 进行通信的，这样就能保证全部的 Client 进程能够与守护进程进行通信，上报一些信息，以及从守护进程层面执行一些操做。

PM2 启动程序的方式

PM2 并非简单的使用 node XXX 来启动咱们的程序，就像前边所提到了守护进程与 Client 进程的通信方式，Client 进程会将启动业务进程所须要的配置，经过 rpc 传递给守护进程，由守护进程去启动程序。
这样，在 PM2 start 命令执行完成之后业务进程也在后台运行起来了，而后等到咱们后续想再针对业务进程进行一些操做的时候，就能够经过列表查看对应的 pid、name 来进行对应的操做，一样是经过 Client 触发 rpc 请求到守护进程，实现逻辑。

固然，咱们其实不多会有单独启动守护进程的操做，守护进程的启动其实被写在了 Client 启动的逻辑中，在 Client 启动的时候会检查是否有存活的守护进程，若是没有的话，会尝试启动一个新的守护进程用于后续的使用。
具体方式就是经过 spawn + detached: true 来实现的，建立一个单独的进程，这样即使是咱们的 Client 做为父进程退出了，守护进程依然是能够独立运行在后台的。

P.S. 在使用 PM2 的时候应该有时也会看到有些这样的输出，这个其实就是 Client 运行时监测到守护进程尚未启动，主动启动了守护进程：

> [PM2] Spawning PM2 daemon with pm2_home=/Users/jiashunming/.pm2
> [PM2] PM2 Successfully daemonized

多进程管理

通常使用 PM2 实现多进程管理主要的目的是为了可以让咱们的 node 程序能够运行在多核 CPU 上，好比四核机器，咱们就但愿可以存在四个进程在运行，以便更高效的支持服务。
在进程管理上，PM2 提供了一个你们常常会用到的参数： exec_mode，它的取值只有两个，cluster和fork，fork 是一个比较常规的模式，至关于就是执行了屡次的 node XXX.js。
可是这样去运行 node 程序就会有一个问题，若是是一个 HTTP 服务的话，很容易就会出现端口冲突的问题：

const http = require('http')

http.createServer(() => {}).listen(8000)

好比咱们有这样的一个 PM2 配置文件，那么执行的时候你就会发现，报错了，提示端口冲突：

module.exports = {
  apps: [
    {
      // 设置启动实例个数
      "instances": 2,
      // 设置运行模式
      "exec_mode": "fork",
      // 入口文件
      "script": "./test-create-server.js"
    }
  ]
}

这是由于在 PM2 的实现中， fork 模式下就是简单的经过 spawn 执行入口文件罢了。

实现位置： lib/God/ForkMode.js

而当咱们把 exec_mode 改成 cluster 以后，你会发现程序能够正常运行了，并不会出现端口占用的错误。
这是由于 PM2 使用了 node 官方提供的 cluster 模块来运行程序。

cluster 是一个 master-slave 模型的运行方式（_最近 ms 这个说法貌似变得不政治正确了。。_），首先须要有一个 master 进程来负责建立一些工做进程，或者叫作 worker 吧。
而后在 worker 进程中执行 createServer 监听对应的端口号便可。

const http = require('http')
const cluster = require('cluster')

if (cluster.isMaster) {
  let limit = 2
  while (limit--) {
    cluster.fork()
  }
} else {
  http.createServer((req, res) => {
    res.write(String(process.pid))
    res.end()
  }).listen(8000)
}

详情能够参考 node.js 中 TCP 模块关于 listen 的实现：lib/net.js
在内部实现逻辑大体为， master 进程负责监听端口号，并经过 round_robin 算法来进行请求的分发，master 进程与 worker 进程之间会经过基于 EventEmitter 的消息进行通信。

具体的逻辑实现都在这里 lib/internal/cluster 由于是 node 的逻辑，并非 PM2 的逻辑，因此就不太多说了。

而后回到 PM2 关于 cluster 的实现，实际上是设置了 N 多的默认参数，而后添加了一些与进程之间的 ipc 通信逻辑，在进程启动成功、出现异常等特殊状况时，进行对应的操做。
由于前边也提到了，PM2 是由守护进程维护管理全部的业务进程的，因此守护进程会维护与全部服务的链接。
process 对象是继承自 EventEmitter 的，因此咱们只是监听了一些特定的事件，包括 uncaughtException、unhandledRejection 等。
在进程重启的实现方式中，就是由子进程监听到异常事件，向守护进程发送异常日志的信息，而后发送 disconnect 表示进程即将退出，最后触发自身的 exit 函数终止掉进程。
同时守护进程在接收到消息之后，也会从新建立新的进程，从而完成了进程自动重启的逻辑。

实现业务进程的主要逻辑在 lib/ProcessContainer 中，它是咱们实际代码执行的载体。

系统信息监控

系统信息监控这块，在看源码以前觉得是用什么 addon 来作的，或者是某些黑科技。
可是真的循着源码看下去，发现了就是用了 pidusage 这个包来作的- -
只关心 unix 系统的话，内部实际上就是ps -p XXX这么一个简单的命令。

至于在使用 pm2 monit、pm2 ls --watch 命令时，实际上就是定时器在循环调用上述的获取系统信息方法了。

具体实现逻辑：
getMonitorData
dashboard
list

后边就是如何使用基于终端的 UI 库展示数据的逻辑了。

日志管理

日志在 PM2 中的实现分了两块。
一个是业务进程的日志、还有一个是 PM2 守护进程自身的日志。

守护进程的日志实现方式是经过 hack 了 console 相关 API 实现的，在原有的输出逻辑基础上添加了一个基于 axon 的消息传递，是一个 pub/sub 模型的，主要是用于 Client 得到日志，例如 pm2 attach、pm2 dashboard 等命令。
业务进程的日志实现方式则是经过覆盖了 process.stdout、process.stderr 对象上的方法（console API 基于它实现），在接收到日志之后会写入文件，同时调用 process.send 将日志进行转发，而守护进程监听对应的数据，也会使用上述守护进程建立的 socket 服务将日志数据进行转发，这样业务进程与守护进程就有了统一的能够获取的位置，经过 Client 就能够创建 socket 链接来实现日志的输出了。

hack console 的位置： lib/Utility.js
hack stdout/stderr write 的位置： lib/Utility.js
建立文件可写流用于子进程写入文件： lib/Utility.js
子进程接收到输出后写入文件并发送消息到守护进程： lib/ProcessContainer.js
守护进程监听子进程消息并转发： lib/God/ClusterMode.js
守护进程将事件经过 socket 广播： lib/Daemon.js
Client 读取并展现日志： lib/API/Extra.js

查看日志的流程中有一个小细节，就是业务日志， PM2 会先去读取文件最后的几行进行展现，而后才是依据 socket 服务返回的数据进行刷新终端展现数据。

后记

PM2 比较核心的也就是这几块了，由于经过 Client 能够与守护进程进行交互，而守护进程与业务进程之间也存在着联系，能够执行一些操做。
因此咱们就能够很方便的对业务进程进行管理，剩下的逻辑基本就是基于这之上的一些辅助功能，以及还有就是 UI 展现上的逻辑处理了。

PM2 是一个纯 JavaScript 编写的工具，在第一次看的时候仍是会以为略显复杂，处处绕来绕去的比较晕，我推荐的一个阅读源码的方式是，经过找一些入口文件来下手，能够采用 调试 or 加日志的方式，一步步的来看代码的执行顺序。 最终就会有一个较为清晰的概念。