跳到主要内容

SSR问题

服务端执行/客户端执行注意问题​

  • 1、注意在服务端渲染SSR时，window、dom对象不存在，如果在服务端环境，使用会报错
  • 2、相关生命周期方法也要注意，相关涉及到dom的生命周期方法也只能在客户端执行，比如onMount

SSR请求排查问题​

由于ssr 首屏渲染请求数据的时候，是走服务端渲染，相关请求是在服务端中，无法在浏览器看到请求，有时候需要经常排查问题，希望能看到请求参数和响应的数据

  • 输出到日志中
    • 可以把ssr请求相关，如请求参数，响应数据，请求到日志logs目录中
  • 输出到终端中打印

SSR并发请求服务器压力问题​

解决高并发、高流量场景保持用户体验和系统问题

  • SSR 在并发请求下会增加服务器压力
    • 因为是服务端渲染，在服务端请求数据，拼接数据，来生成HTML，这些数据是放在服务器内存中的，多并发情况下，就会导致内存被打爆
  • 配置ISR缓存问题
    • 配置了ISR，可以减少SSR并发请求的压力
      • 但不能解决缓存未命中、缓存击穿
    • 第一次访问和缓存过期时也是同样会有SSR压力问题
    • 比如播放页，每个播放页的URL都有自己单独的缓存，爬虫或者用户访问是大量不同的剧集，缓存命中率就会降低，每个URL都会触发一次SSR请求
    • 排查ISR缓存，比如多语言路径是否都配置了缓存、缓存时间
  • 排查SSR请求数据量过大的问题
  • 配置多实例node进程worker，来分担服务器压力

SSR服务504报错排查​

  • 504：网关/反向代理等待上游服务响应超时。
  • 当SSR高并发时、内存泄漏问题，可能会导致服务挂导致网关超时

报错排查定位链路​

  • 检查pm2
  • 检查node服务端口
  • 通过curl检查nuxt/next服务，比如如果 127.0.0.1:3000 本身都超时，就把问题定位到 Nuxt/Node 层
  • 检查nginx error日志

PM2 看进程 → ss 看端口 → curl localhost 看 Node 服务 → Nginx error 看 upstream -> 检查Nuxt SSR、代码内存泄漏问题

检查 PM2 进程状态​

  • pm2 list
  • 确认 Nuxt/Next 进程是否 online
  • 关注重启次数、CPU、内存是否异常
  • 注意：online 只代表进程活着，不代表服务一定能正常响应

检查 Node 服务端口​

  • ss -lntp | grep ':3000'
  • 确认 Node/Nuxt 是否正常监听端口
  • 没有监听 → 优先排查进程启动失败
  • 正常监听 → 继续检查 HTTP 服务是否正常

通过 curl 直接检查 Nuxt/Next 服务​

  • 如果 127.0.0.1:3000 本身都超时：

    基本可以把问题范围定位到 Nuxt/Next/Node 服务层

  • 继续排查 SSR 请求阻塞、后端 API 超时、Event Loop 阻塞、内存增长/OOM 等问题

  • 如果 127.0.0.1:3000 秒回 200，但外部访问 504 → 重点排查 Nginx/Tengine/CDN

text
curl -v --max-time 10 http://127.0.0.1:3000/

检查 Nginx error 日志​

  • upstream timed out → 上游响应太慢
  • connection refused → 上游服务/端口无法连接
  • prematurely closed connection → 上游处理中途断开
  • 重点确认日志里的 upstream 是否真的是 Nuxt 的 127.0.0.1:3000
text
tail -200 /var/log/nginx/error.log

监控502、503、504脚本重启应用​

需要保证504异常能够重启应用，到时候挂了也可以自动重启了，也不用每次都手动重启

  • 健康检查脚本作为兜底恢复服务
    • 如重点监控502、503、504
    • 502是服务没启动
      • 看进程、看端口是否启动
    • 503是服务不可用
    • 504是服务连接超时 （SSR 卡住，容易超出504）
      • 比如node服务、SSR等待后端慢接口
  • 作为企业级的SSR应用，都会做健康检查的监控服务，来作为兜底的机制
  • 可以连续 3 次检测失败/504 → 才执行 pm2 reload
    • 如果pm2 reload也卡住的话，使用systemctl restart pm2-vincent
      • systemctl restart pm2-vincent理解
        • 会重启整个pm2服务，影响所有pm2管理的应用
text
执行脚本
  ↓
检查站点
  ↓
正常 → 脚本退出

异常
  ↓
连续检查 3 次
  ↓
仍异常
  ↓
pm2 reload flextv
  ↓
reload 卡住/失败
  ↓
让 systemd 重启 pm2-vincent 这个系统服务
systemctl restart pm2-vincent

SSR 等待问题​

  • 给服务端业务请求设置明确超时，并控制重试次数，让请求在外层网关超时前结束。
  • SSR 优先获取首屏必需数据；用户状态等非必需数据改为客户端补齐。
  • 明确接口失败后的处理：核心数据失败返回受控错误，辅助数据失败允许降级；避免一直等待或把失败当成正常空数据。
  • 记录接口地址、耗时、错误类型和请求 ID，方便定位具体卡住的接口

问题分析

  • node服务卡住，但是进程没死
  • 大量慢请求积压，可能进一步耗尽内存、连接或 CPU
  • FD （文件描述符） 压力问题，导致文件描述符过多
    • 日志文件、HTTP连接、TCP socker都会涉及FD
  • 并发高时，只要 SSR 里某些接口变慢，就容易形成堆积
    • 堆积：请求还没处理完、还在等待中的 SSR 请求越来越多

降低重复渲染压力​

如果1000 个用户访问的是完全相同页面，服务器也可能做 1000 次 SSR

  • 缓存 SSR 结果
  • 接口数据缓存
  • CDN缓存

SSR接口请求的超时时间处理​

  • SSR 请求要有明确的等待上限超时处理，避免无限等待，导致SSR卡住
  • 来提高SSR 稳定性的基础能力

如何证明是SSR请求接口慢问题？

  • 证明 Node 进程还在
    • 比如pm2 status来查看node进程服务是否还在
    • 如果进程活着但请求没完成
  • 记录后端API的记录
    • 可以在Nginx中查看api的耗时