在 CentOS 服务器上管理和启动 Node.js 应用是后端开发与运维工作中的常见任务，一个稳定、可靠的启动方案不仅关系到服务的可用性，也直接影响后续的维护和监控效率，本文将深入探讨在 CentOS 环境下启动 Node.js 应用的多种方式，从最基础的命令到适用于生产环境的高级方案，并分析其优劣,帮助您选择最适合您项目需求的策略。
基础启动方式及其局限性
最直接、最简单的启动方式是通过 Node.js 解释器直接运行应用脚本，假设您的应用入口文件是 app.js,在终端中执行以下命令即可启动服务：
node app.js
这种方式在开发和调试阶段非常便捷，可以立即看到控制台的输出和错误信息，如果直接将其用于生产环境,会暴露出诸多严重的局限性：
- 进程脆弱性：该启动方式将 Node.js 进程与当前终端会话绑定，一旦关闭 SSH 客户端或终端会话结束，Node.js 进程会随之终止,导致服务下线。
- 缺乏自动恢复：应用可能因为未捕获的异常或内存溢出等原因意外崩溃，基础启动命令无法在进程退出后自动重启，需要人工干预,无法保证服务的高可用性。
- 日志管理混乱：所有的日志（标准输出和标准错误）都直接打印在当前终端，难以进行持久化存储、检索和分析，随着时间推移,重要的调试信息可能会丢失。
- 无法利用多核性能：单个 Node.js 进程是单线程的，无法充分利用现代服务器的多核 CPU 资源。
正是由于这些局限性，在生产环境中，我们必须采用更专业的进程管理工具或系统服务来启动和管理 Node.js 应用。
使用进程管理器：PM2
PM2 是一个功能强大且广受欢迎的 Node.js 进程管理器，它内置了负载均衡、应用监控、日志管理和自动重启等功能，是 Node.js 应用的生产环境部署首选之一。
通过 npm 全局安装 PM2：
npm install pm2 -g
安装完成后,您可以使用一系列简单的命令来管理您的应用。
核心命令：
启动应用：
pm2 start app.js
PM2 会为您的应用分配一个唯一的
name（默认为文件名，不含扩展名）和id。查看进程列表：
pm2 list
此命令会显示所有由 PM2 管理的进程状态、CPU 和内存占用等信息。
停止、重启、删除应用：
pm2 stop app_name_or_id pm2 restart app_name_or_id pm2 delete app_name_or_id
查看实时日志：
pm2 logs
可以查看所有应用的实时日志,或指定应用名查看特定日志。
生产环境高级特性：
开启集群模式：利用
cluster模式，可以轻松创建多个子进程来充分利用服务器的多核 CPU。pm2 start app.js -i max
-i max表示根据 CPU 核心数创建相应数量的进程实例。设置开机自启：这是生产环境至关重要的一步,确保服务器重启后应用能自动恢复运行。
# 1. 生成开机自启所需的启动脚本 pm2 startup # 2. 保存当前进程列表 pm2 save
执行
pm2 startup后，PM2 会输出一条需要您使用sudo权限执行的命令,复制并执行即可。
使用系统服务：Systemd
对于 CentOS 7 及以上版本，systemd 是默认的初始化系统和服务管理器，将 Node.js 应用配置为一个 systemd 服务，可以实现与操作系统深度集成，无需安装额外的 Node.js 工具（如 PM2）。
您需要创建一个服务配置文件，在 /etc/systemd/system/ 目录下创建 myapp.service 文件：
sudo vim /etc/systemd/system/myapp.service
填入以下配置内容，请根据您的实际情况修改 User、Group、WorkingDirectory 和 ExecStart 等参数。
[Unit] Description=My Node.js Application After=network.target [Service] # 运行应用的用户和组 User=nodeuser Group=nodeuser # 应用的工作目录，即 package.json 所在目录 WorkingDirectory=/var/www/myapp # 启动命令，建议使用绝对路径 ExecStart=/usr/bin/node /var/www/myapp/app.js # 设置环境变量，例如生产环境 Environment=NODE_ENV=production # 重启策略：总是重启 Restart=always # 重启前的等待时间 RestartSec=10 # 标准输出和错误日志的输出方式 SyslogIdentifier=myapp StandardOutput=syslog StandardError=syslog [Install] WantedBy=multi-user.target
配置文件创建并保存后，使用 systemctl 命令来管理您的服务：
重新加载 systemd 配置：
sudo systemctl daemon-reload
启动服务：
sudo systemctl start myapp.service
设置开机自启：
sudo systemctl enable myapp.service
查看服务状态：
sudo systemctl status myapp.service
查看服务日志：
sudo journalctl -u myapp.service -f
-u指定服务单元，-f实时跟踪日志输出。
方案对比与选择
PM2 和 Systemd 都是优秀的生产环境解决方案，但各有侧重，下表对它们进行了对比,以帮助您做出决策。
| 特性 | PM2 | Systemd |
|---|---|---|
| 易用性 | 非常高，命令简单直观，对 Node.js 开发者友好 | 相对较低，需要理解和编写服务配置文件 |
| 功能丰富度 | 极高，内置集群、监控、内存刷新等 Node.js 特有功能 | 基础，主要关注进程的生命周期管理 |
| 系统集成度 | 较低，作为第三方应用运行 | 极高，与操作系统核心深度集成 |
| 资源占用 | 自身会占用少量内存和 CPU | 几乎无额外资源占用，是系统原生能力 |
| 适用场景 | 纯 Node.js 应用、需要快速部署和丰富监控功能的项目 | 将 Node.js 应用作为服务器整体服务的一部分、追求系统级统一管理的环境 |
相关问答FAQs
问题 1：我应该选择 PM2 还是 Systemd 来管理我的 Node.js 应用？
解答： 这取决于您的具体需求和运维环境。
- 选择 PM2：如果您是 Node.js 开发者，希望快速部署和管理应用，并且需要 PM2 提供的零停机重载、集群模式、内置监控面板等高级功能，PM2 是理想的选择，它让您能用 Node.js 的思维方式来管理应用。
- 选择 Systemd：如果您是系统管理员，或者服务器上运行着多种不同类型的服务（如 Nginx, MySQL, Redis 等），您可能更倾向于使用系统原生的服务管理工具来统一管理所有服务，Systemd 更加稳定，不依赖额外的 npm 包，与系统日志（journald）完美集成,适合追求系统级标准化和稳定性的场景。
问题 2：如何查看我的 Node.js 应用崩溃时的详细日志？
解答： 这取决于您使用的启动方式。
- 如果使用 PM2：您可以使用
pm2 logs命令查看所有被管理进程的实时日志，如果只想看某个应用的日志，可以使用pm2 logs app_name，PM2 默认会将日志文件存储在~/.pm2/logs/目录下，您也可以直接查看这些文件，tail -f ~/.pm2/logs/app-out.log和tail -f ~/.pm2/logs/app-error.log。 - 如果使用 Systemd：最佳方式是使用
journalctl命令，执行sudo journalctl -u myapp.service -f可以实时查看服务的日志输出，如果应用已经崩溃，您可以通过sudo journalctl -u myapp.service -n 100来查看最近 100 行日志，或者使用sudo journalctl -u myapp.service --since "1 hour ago"来查看过去一小时内的日志,以便定位崩溃原因。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复