看了pm2的源码后,发现了集群模式下无法切换node版本的奥秘

使用 pm2 管理的项目多了时,难免有更新node版本或者不同应用运行在不同版本的需求,网上许多人遇到了 pm2 的集群模式无法切换 node 版本的情况,不出意外,我也遇到了,今天这篇文章把这个事为什么,怎么解决说明白,希望能帮到大家伙。

解决问题过程

各种搜,无果

看着最靠谱的答案,pm2 开发者亲自下场给出方案,大概思路是 copy 一个pm2 的可执行文件,把其中的 #!/usr/bin/env node 改为指定版本如 #!/home/ubuntu/.nvm/versions/node/v13.14.0/bin node,怎么样,看着是不是及其靠谱?

结果经过小半天的尝试之后,宣告失败,我觉得可能是问题描述没到位,大佬没理解关键点。

大家感兴趣可以去看看这个 issue:github.com/Unitech/pm2...

看源码,有果

往往网上搜不着答案的时候,就是时候祭出大杀器了,看源码!

不看不知道啊,一看吓一跳,我算是见识到了什么叫做真正的"回调地狱",拿出一小段,大家感受一下:

从一个方法开始,一层一层的找,看的我感觉自己快升仙了,直接给我血压低的老毛病整犯了,所幸,我找到了这篇文章,juejin.cn/post/708527...,在这里感谢作者救了我的老命。

具体源码就不带大家分析了,这篇文章已经分析的非常好,咱们直接说结论。

分析后的结论

守护进程是啥

要理解后面的问题,必须先搞懂守护进程这个概念。

PM2的核心模块包括Client.js和Daemon.js。Client.js负责建立工作进程,而Daemon.js则是守护进程,负责创建守护进程以及RPC服务。

当你启动一个应用时,PM2客户端会通过RPC向Daemon发送信息,Daemon则负责创建进程。这样,进程不是由客户端创建的,而是由Daemon创建的。因此,即使客户端退出,应用也不会受到影响,这就是为什么PM2启动的应用可以在后台运行的原因。

注意:守护进程是pm2实例首次启动时创建的,之后执行一些操作时不会重新创建,除非把守护进程杀掉。

为啥 fork 模式下支持设置 interpreter 来切换 node 版本?

fork 模式下,PM2会使用Node.js的 child_process.spawn API来创建一个新的进程。

child_process.spawn 用于创建子进程执行任何可执行文件,例如外部命令、脚本文件等,而不仅仅是 Node.js 脚本。

用法:

javascript 复制代码
const { spawn } = require('child_process');

// spawn方法接受的参数依次为命令、参数、环境变量
const child = spawn('command', ['arg1', 'arg2'], {
  cwd: '/usr/local',
  env: { /* environment variables */ },
  stdio: [/* stdin, stdout, stderr */],
});

const child = spawn('ls', ['-l', '-a']); // 启动一个新的进程执行 "ls -l -a" 命令
const child = spawn('xxx/bin/node', ['a.js']); // 启动一个新的进程执行 node a.js 命令

spawn是可以指定脚本解释器的,例如node,所以,PM2 会取我们设置的interpreter值来作为spawn方法的第一个参数,如果没传的话就用当前终端激活的node版本,如果传入none的话,pm2会去取pm_exec_path中的内容,就是你首次启动pm2实例时守护进程运行的node版本。

源码可以很清晰看到:

为什么 fork 模式切换node版本后,直接启动应用版本并没有切换,需要删除应用才可以

上面说了 fork 模式会使用 child_process.spawn 创建一个新进程,前提是当前应用不存在,你原来的进程还存在的话当然不会创建新进程,只会重用之前的进程id,所以要么删除进程,要么换个应用名字

为什么 cluster 模式不支持配置 interpreter 切换版本

cluster 模式 pm2 使用 node 的 cluster 模块实现,cluster 模块使用的是 child_process.fork 方法来创建子进程,而不是 spawn 方法。

child_process.fork 用于创建一个新的 Node.js 子进程,该子进程执行指定的 JavaScript 文件,通常用于并行执行 js 代码。

用法:

javascript 复制代码
const { fork } = require('child_process');
const child = fork('child.js'); // 启动一个新的 Node.js 子进程执行 child.js

与 spawn 方法的区别:

  • child_process.fork 用于执行 Node.js 脚本,通常用于并行执行 JavaScript 代码。

  • child_process.spawn 用于执行外部可执行文件,包括系统命令、脚本文件等。

  • child_process.fork 具有内置的消息传递机制,可以方便地在主进程和子进程之间发送和接收消息。

  • child_process.spawn 不具备内置的消息传递机制,需要手动设置通信方式。

child_process.fork 使用与主进程相同的 Node.js 版本来执行 js 文件,子进程间要进行通讯而且要保证一致性,所以子进程不能指定版本。

回到pm2,因为是守护进程调用的 cluster 模块创建的应用,所以cluster模块会使用守护进程运行的node版本。

与 fork 模式不同的是,即使你删除应用,切换版本后重新启动应用node版本也不会更新,因为守护进程的版本并没有改变。

调用 pm2 kill 或者通过其他方式杀死守护进程后,再切换版本启动应用,守护进程会重新启动,这时才会使用最新的版本创建集群模式的应用。

创建多个守护进程是不是就能解决集群模式的版本问题?

既然守护进程的版本不会轻易改变,而守护进程又起着绝对性作用,那创建多个守护进程是不是就能解决集群模式的版本问题?

答案是肯定的,顺着这个思路,我也确实找到了解决方案,大家继续往下看啦。

解决方案

fork 模式

  1. 设置 interpreter
bash 复制代码
pm2 start app.js --interpreter=/usr/bin/node

如果启动的是配置文件,则在配置文件里设置

json 复制代码
// ecosystem.config.js
{
  interpreter: '/Users/yululiu/.nvm/versions/node/v14.21.3/bin/node',
}
bash 复制代码
pm2 start ./ecosystem.config.js

优点:

  • 简单,快速,安全,可立即生效,
  • 可以定制化单个应用使用任意已安装版本

缺点:

  • 需要手动配置node路径
  • 可能线上和测试环境的node二进制文件路径不一样,需要区分环境配置不同路径

推荐使用。

  1. delete项目,切换node版本,重新启动
bash 复制代码
pm2 delete app
nvm use 14
pm2 start ./ecosystem.config.js

优点:

  • 使用 nvm 自动切换 node 版本
  • 可以定制化单个应用使用任意已安装版本

缺点:

  • 应用会被短暂终止

使用 pm2 delete 停止进程并清理相关配置和缓存后切换版本重新启动,会短暂终止应用,不推荐使用

cluster 模式

需要终止pm2守护程序,切换node环境,然后再恢复

bash 复制代码
nvm use 14 # 先切换版本
pm2 save # 保存程序列表 (此时会记录切换激活后的node版本)
pm2 kill # 该操作会杀掉守护进程以及所有pm2已启动应用
pm2 resurrect # 恢复程序列表并启动 (所有应用都将统一使用切换后的版本)

优点:

  • 适合统一切换版本的场景

缺点:

  • 不能个别应用定制化版本
  • 操作麻烦,成本高,有一定风险

单项目切换时不推荐使用。

启动多个 pm2 实例,分别使用不同node版本

先使用 nvm 或 export 变量 等方式切换到目标 node 版本

bash 复制代码
nvm use 14

export PATH=/usr/node/v14.19.0/bin:$PATH

执行此命令前确保已切换到正确的版本

bash 复制代码
# 使用新 pm2 实例启动应用
PM2_HOME="$HOME/.pm2_14" pm2 start ./ecosystem.config.js

"$HOME/.pm2_14"表示将实例的配置文件存储到用户主目录的.pm2_14目录下,这样14版本的实例只创建一个,避免创建过多实例占用过多内存,文件夹名字可以自由定义,如果设置为".pm2_14",则会在应用下创建,这样会创建过多实例,没有必要。

pm2_14表示 pm2 node14版本的实例,你可以使用 ls -a ~ 查看主目录下的文件,一般情况下,原pm2的配置文件也在该目录下,名字为 .pm2

指定 PM2_HOME 后,pm2将在新目录下保存应用状态,pm2 实例之间是隔离的,不会影响原有的 pm2 实例。

后续对新实例下的应用进行操作需要把所有 pm2 的命令都替换为 PM2_HOME="$HOME/.pm2_14" pm2,注意不要搞错,以免误操作了别的实例的应用

bash 复制代码
PM2_HOME="$HOME/.pm2_14" pm2 show "$APP_NAME"
PM2_HOME="$HOME/.pm2_14" pm2 list
...

如果你觉得这个命令太长,可以设置一个简短的别名:

bash 复制代码
alias pm14='PM2_HOME="$HOME/.pm2_14" pm2'

这样设置仅临时shell窗口有效,想要永久有效的话加到 ~/.bashrc 或 ~/.zshrc 中即可。

bash 复制代码
# 查看你现在使用的终端
echo $0

# 如果是bash,配置文件就是~/.bashrc,zsh则是~/.zshrc
# 把别名设置加进去
vim ~/.bashrc

# source 执行一下配置文件
source  ~/.bashrc

之后就可以使用更短的命令了,例如: pm14 list

优点:

  • 可以定制化单个应用使用任意已安装版本
  • 简单,安全

缺点:

  • 旧应用如果还在其他 pm2 实例中运行,则需要把旧实例中的该应用删除,使用pm2 delete,不然端口号被旧实例占用,新实例里的应用无法启动

旧的已运行应用切换版本时,可以挑在访问量最小的时间点操作。

集群场景下推荐使用该方案。

总结

以上就是 pm2 进行 node 版本升级的一些解决方案了,为什么以及如何做基本比较清晰明了,大家可以去尝试一下了。

这种问题其实挺考验一个人的能力的,同时解决了之后对自身会有很大的提升,尤其在其他同事研究了很久之后给出结论:"pm2 集群模式没法单个项目切node版本,只能先停掉所有再重启",并且又拿不出有力证据时,这证明这个问题价值更高,看到这种问题要像在沙漠看到水一样兴奋、好奇,然后扑上去把它解决掉,类似别人解决不了的问题你解决的多了,你与别人的差距也就慢慢拉开了。

相关推荐
Dragon Wu2 分钟前
前端 Canvas 绘画 总结
前端
CodeToGym6 分钟前
Webpack性能优化指南:从构建到部署的全方位策略
前端·webpack·性能优化
~甲壳虫7 分钟前
说说webpack中常见的Loader?解决了什么问题?
前端·webpack·node.js
~甲壳虫11 分钟前
说说webpack proxy工作原理?为什么能解决跨域
前端·webpack·node.js
Cwhat13 分钟前
前端性能优化2
前端
一ge科研小菜鸡35 分钟前
React前端框架:现代网页开发的基石(附带构建简单任务管理应用案例代码)
前端框架
熊的猫1 小时前
JS 中的类型 & 类型判断 & 类型转换
前端·javascript·vue.js·chrome·react.js·前端框架·node.js
瑶琴AI前端1 小时前
uniapp组件实现省市区三级联动选择
java·前端·uni-app
会发光的猪。2 小时前
如何在vscode中安装git详细新手教程
前端·ide·git·vscode
我要洋人死3 小时前
导航栏及下拉菜单的实现
前端·css·css3