记录一次修改 PNPM 版本，部署 NextJs 服务时导致服务器崩溃的问题

最近在使用 NextJs 开发 DocFlow 协同编辑这个项目，运行了很久都没有问题，最近终于在部署方面出现了问题了，早上的时候发现 ssh 连不上了，一开始并没有太在意，但后来打开京东云控制台，好家伙真的好家伙：

真的小母牛坐飞机牛逼上天了！原来是 CPU 爆了，怪不得连接不上了，当然网站也 502 了：

那是什么原因呢，接下来就要开始慢慢排查了，既然 vscode 连不上，那我们就在官方提供的 ssh 来连接:

输入命令 htop ，罪魁祸首马上出现：

原来是 next-server 和 node （运行在 /home/DocFlow-Server/dist/main.js ）占用了基本全部的 CPU ，那这个原因就很清楚了，那么接下来就可以排查了这个问题的原因了。

首先，可以明确的一点是，之前一直都是同样的方式部署的，没有出现问题，但是为什么今天就一直出现这个问题呢，那肯定是在运行的进程出现了问题。

我项目使用的是 pm2 部署的，那打个日志看看咯：

问题找到了，原来是 pm2 一直在重启，把内存全部占用了，具体是什么原因的已经不好查了，有可能是安装了一些依赖。我这个部署脚本是基本没问题的，至少能跑，现在查看这两天的 commit ，想起来有一个这样的操作：

那基本就可以确定是这个问题了。

其他部署方案

PM2 是一种流行的进程管理工具，适用于 Node.js 应用，尤其在小型项目和单机部署时很有效。然而，PM2 的部署流程存在一些局限性：

依赖管理和版本控制：PM2 需要手动确保服务器上安装正确的 Node.js 和 pnpm 版本。每次代码更新后，你还需要在服务器上重新构建项目（执行 pnpm run build），这可能会导致生产环境与开发环境之间的不一致，并增加了维护工作。
服务中断问题：每次代码更新时，PM2 需要重启应用来使新版本生效。如果没有正确配置或管理，应用在重启过程中可能会停机一段时间，这对于高可用性要求较高的生产环境来说是个问题。

与 PM2 相比，Docker 自动化部署通过容器化解决了这些问题，提供了更简洁、更一致的部署流程，特别适用于云端和多环境部署。主要优势包括：

无需依赖管理和环境配置：Docker 将应用及其所有依赖、环境变量、构建过程封装在 Docker 镜像中。这样，服务器上无需安装特定版本的 Node.js 或 pnpm ，避免了手动配置和版本不一致的问题。你只需要在构建镜像时配置好所有的依赖和环境，部署时无需再进行任何安装或构建操作。
代码问题不会影响运行：如果代码有问题，Docker 使得应用不会受到当前部署的影响。因为 Docker 镜像已经包含了所有必要的依赖，部署失败时，原先的镜像仍然可以继续运行，确保生产环境不受影响。而在 PM2 部署时，更新代码后需要重启应用，如果代码有问题，应用会直接停机，导致服务中断。
无缝的 CI/CD 集成：Docker 完美集成 CI/CD 流程。例如，使用 GitHub Actions ，你可以自动构建 Docker 镜像并推送到仓库。服务器只需要拉取最新镜像，并启动新的容器。如果部署失败，不会影响当前运行的容器，你可以迅速恢复服务，且无需手动修复。相反，PM2 需要重新启动应用，且服务停机时需要手动修复代码。
快速回滚：由于 Docker 镜像的版本化机制，你可以轻松回滚到之前的稳定版本。即便遇到部署失败的情况，只需要拉取旧版本的镜像，应用立即恢复，不需要手动操作，这为应用提供了更高的可靠性。

PM2 部署中，如果代码有问题，必须手动修复并重启应用，这可能会导致服务中断，并影响用户体验。而且每次更新都需要在服务器上重新构建项目，这可能导致环境不一致，增加了部署的复杂性。

Docker 部署则通过容器化确保应用和环境的一致性，部署失败时不会影响生产环境的运行，原有容器仍可继续工作，且通过 CI/CD 流程可以自动恢复和快速回滚，不需要人工干预。即使代码存在问题，原有的容器仍可保持正常服务，确保应用的高可用性。

因此，对于生产环境，Docker 提供了比 PM2 更稳定、高效、自动化的部署方式，尤其适合大规模、高可用的应用部署。

最后看到的问题是启动 PM2 一次性给我开了 3 个进程，资源相互抢占，导致服务器崩溃的，最后直接换成了 Docker 部署了