Node 应用优化、进程守护与运维
适用人群:Node 站点已上线、要做性能优化与稳定运维的开发者。
核心概念
稳定性优先
Node 是单进程事件循环,一旦崩溃或内存泄漏会导致服务不可用。用 PM2/systemd 守护、开启多实例(PM2 cluster)利用多核、监控内存并设置异常自动重启,是运维重点。
加速
把静态资源(打包后的 JS/CSS/图片)交给 Nginx 直接服务或走 CDN,减少 Node 负担;页面/接口按需加缓存。
部署更新
更新代码时先构建、再重启进程;PM2 的 reload 可做到零停机滚动重启,避免用户请求中断。
操作步骤
步骤 1多实例利用多核
用 PM2 cluster 模式起多个实例(如 pm2 start -i max),充分利用多核 CPU。
步骤 2静态资源交给 Nginx/CDN
打包后的静态资源用 Nginx 直接服务或接 CDN,境内 CDN 需域名已备案。
步骤 3监控内存与可用性
监控进程内存、CPU 和网站可用性,设置内存超限自动重启。
步骤 4零停机更新
更新时先 npm ci + build,再 pm2 reload 滚动重启,避免请求中断。
步骤 5备份与日志
备份应用数据与配置,集中管理 PM2/应用日志便于排障。
实际示例
# PM2 集群模式 + 零停机重启
pm2 start .output/server/index.mjs -i max --name myapp
# 更新代码后:
npm ci && npm run build && pm2 reload myapp
# 内存超限自动重启(如超过 500M)
pm2 start app.js --name myapp --max-memory-restart 500M
常见错误
- ⚠️单实例跑在多核机器上,CPU 利用不充分(可用 PM2 cluster)
- ⚠️用 pm2 restart 而非 reload 更新,造成短暂请求中断
- ⚠️静态资源也让 Node 处理,白白增加负载(应交给 Nginx/CDN)
- ⚠️没监控内存,内存泄漏累积到 OOM 才发现
对应工具
常见问题
Node 应用怎么更新不影响用户?
Node 应用怎么防崩溃?
相关教程
相关文章
网站上线后怎么做运维监控?可用性、SSL 到期与掉备案预警
网站上线不是终点。服务器宕机、证书过期、域名忘续费、备案被注销,任何一项都会让网站突然打不开。做好运维监控,就是在这些问题影响用户之前先收到预警。本文讲清该监控什么、怎么设告警。 要监控哪些项 | 监控项 | 关注什么 | 出问题的后果 | |---|---|---| | 可用性/Uptime | 网站是否能正常访问…
网站上线前怎么测试?测试环境、预发布与上线前检查清单
直接把没测过的网站推到线上,很容易上线即翻车:页面报错、链接失效、证书没配好,甚至因为空白页被判备案不合格。正式上线前做一轮测试和逐项检查,能把问题挡在用户之前。本文讲清测试环境怎么搭、备案期间怎么合规地测,以及上线前该核对什么。 为什么要先测 功能验证:注册、表单、支付、接口等关键流程能不能跑通; 展示验证:各页面…
备案接入商变更(转入转出)全流程与运维要点
什么是备案接入商变更 备案里的"接入商",指为你的域名提供服务器与网络接入、并在管局系统里代为提交"接入备案"的服务商(如各家云厂商)。当你把网站从一家云迁到另一家、或换到不属于原接入商的 IP 时,备案的接入信息就与实际不符了,需要通过"转入转出"把接入关系迁到新服务商名下。 转入:在新接入商处发起接入申请,把已有…
备案站点的分库分表架构与运维实践
加索引救不了的问题,分库分表也未必救得了 单表数据量涨到几千万甚至上亿行时,慢查询定位和索引优化的边际收益会急剧下降——不是索引没建对,是这张表本身已经超出了单机数据库能舒服处理的规模。这时候团队往往会条件反射地想到分库分表,但分片是一次架构级别的重构,代价远高于加一个索引,动手前必须想清楚三件事:真的是数据量问题,…
备案站点的多租户隔离架构与运维
多租户系统最贵的两类事故,都不是宕机 单租户系统的故障边界很清楚:挂了就是挂了,所有用户一起受影响,运维和用户对此都有心理预期。多租户系统的可怕之处在于故障可能只发生在一个租户身上,却悄无声息:一次查询没加租户过滤条件,导致 A 租户看到了 B 租户的数据;一个租户的异常流量把共享资源打满,拖累了同一实例上所有其他租…
官方资料来源