从‘它怎么又挂了’到‘稳如泰山’：我是如何用Nginx + PM2守护我的Node.js后台服务的
从‘它怎么又挂了’到‘稳如泰山’：我是如何用Nginx + PM2守护我的Node.js后台服务的
记得第一次部署Node.js服务时，每次看到"502 Bad Gateway"的报错页面，我的血压就会瞬间飙升。服务总在深夜崩溃，而我不得不爬起来手动重启——这种噩梦持续了整整三个月。直到把PM2和Nginx这套组合拳打透，才真正体会到什么叫"睡到自然醒的运维幸福感"。今天就来分享这段从菜鸟到稳如老狗的实战历程。
1. 为什么你的Node.js服务总在深夜崩溃？
三年前我的个人博客项目上线时，根本没想到进程守护这么重要。直到某天早晨发现服务挂了7小时，评论区骂声一片，才意识到问题的严重性。经过排查，主要暴露出几个致命问题：
- 无状态丢失：普通
node app.js启动时，控制台关闭即服务终止 - 异常穿透：未捕获的Promise rejection会导致整个进程退出
- 内存泄漏：连续运行两周后内存占用突破1.5GB
- 日志黑洞：
console.log输出的日志随着进程死亡而消失
# 典型的内存泄漏检测方式 node --inspect=9229 app.js打开Chrome的chrome://inspect连接后，通过Memory面板可以抓取堆快照。我的案例中，一个全局存储的数组在不断增长却从未被清理。
提示：即使代码完善，第三方库也可能引发内存泄漏。定期重启是最后的防线。
2. PM2：从进程守护到性能调优
2.1 基础守护配置
安装PM2后的第一版启动命令看起来平平无奇：
pm2 start app.js --name "my-api"但很快发现这远远不够。当实现以下配置后，稳定性才真正提升：
// ecosystem.config.js module.exports = { apps: [{ name: "api-prod", script: "./app.js", instances: "max", // 根据CPU核心数自动扩展 exec_mode: "cluster", max_memory_restart: "800M", // 内存阈值 env: { NODE_ENV: "production" } }] }关键参数对比：
| 参数 | 默认值 | 生产推荐值 | 作用 |
|---|---|---|---|
| instances | 1 | max或具体数字 | 集群实例数 |
| exec_mode | fork | cluster | 集群模式 |
| max_memory_restart | 无限 | 系统内存的70% | 防止内存泄漏 |
2.2 日志管理实战
曾经为了找某个凌晨3点的错误日志，我不得不翻遍整个服务器。PM2的日志系统解决了这个痛点：
# 日志文件自动按日期分割 pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M pm2 set pm2-logrotate:retain 30现在通过以下命令就能快速定位问题：
# 实时查看日志 pm2 logs --lines 200 --timestamp "YYYY-MM-DD HH:mm:ss" # 根据错误关键词过滤 pm2 logs --grep "ECONNREFUSED"3. Nginx：不只是反向代理那么简单
3.1 基础代理配置
最初的Nginx配置简单到令人发指：
server { listen 80; server_name api.example.com; location / { proxy_pass http://localhost:3000; } }直到遭遇流量高峰时的连环502错误，才意识到需要更完善的配置：
upstream node_cluster { server 127.0.0.1:3000; server 127.0.0.1:3001; keepalive 64; // 保持长连接 } server { proxy_http_version 1.1; proxy_set_header Connection ""; location / { proxy_pass http://node_cluster; proxy_next_upstream error timeout http_502; } }3.2 性能调优参数
经过压力测试后，这些参数对性能提升显著：
# 文件描述符缓存 open_file_cache max=200000 inactive=20s; open_file_cache_valid 30s; # 缓冲区优化 proxy_buffers 16 32k; proxy_buffer_size 64k; # 超时控制 proxy_connect_timeout 5s; proxy_read_timeout 30s;4. 那些年我们遇到的经典故障
4.1 502 Bad Gateway排查指南
当Nginx返回502时，按照这个检查清单逐步排查：
PM2状态检查
pm2 list pm2 logs端口监听验证
netstat -tulnp | grep 3000Nginx错误日志
tail -n 50 /var/log/nginx/error.log系统资源监控
htop df -h
4.2 零停机部署方案
早期每次部署都需要停服30秒，直到实现这套流程：
# 1. 拉取最新代码 git pull origin main # 2. 安装依赖 npm install --production # 3. 优雅重启 pm2 reload all --update-env # 4. 健康检查 curl -I http://localhost:3000/health配合Nginx的max_fails和fail_timeout参数，用户完全感知不到重启过程。
5. 监控告警：防患于未然
5.1 基础监控配置
这套命令组合成了我的监控三板斧：
# 实时监控 pm2 monit # 自定义指标 pm2 describe 0 # 异常重启统计 pm2 reset all5.2 告警集成方案
将PM2的异常事件推送到钉钉机器人：
// pm2事件钩子配置 module.exports = { apps: [...], events: { restart: { command: "curl -X POST https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN -H 'Content-Type: application/json' -d '{\"msgtype\": \"text\",\"text\": {\"content\":\"PM2重启告警: "+process.env.name+"\"}}'" } } }现在当服务异常时，手机就会收到实时推送，再也不用半夜手动检查了。这套组合拳实施后，我的服务uptime从最初的70%提升到99.9%，终于可以安心睡觉了。