明明接口没挂，为什么系统还是越来越慢？

做服务端的人，迟早会遇到一种非常恶心的问题：

监控里 CPU 不一定高，数据库也不一定挂，接口不是全部 500，甚至很多请求还能成功返回，但系统就是越来越慢，最后整站雪崩。

最要命的是，这类问题往往不是某一门语言独有的。你用 Node.js、PHP、Java，甚至 Go、Python，都可能中招。

一、这类事故为什么特别难排查

因为它不是那种一看就坏了的故障，更像是慢性中毒。

常见的表现是：

• 刚开始只有个别接口偶尔超时
• 然后调用链上游开始变慢
• 接着更多请求排队
• 连接池被占满
• 线程池被耗尽
• 重试放大流量
• 最后整个系统进入雪崩状态

你看到的往往只是最后结果：

• Node.js 进程卡顿
• PHP-FPM worker 被耗尽
• Java Tomcat / Spring Boot 请求线程打满
• MySQL 连接数飙升
• Redis 响应变慢
• Nginx upstream timeout

但真正的起点，可能只是一个：

• 下游接口慢了 300ms
• 某个 SQL 忽然变慢
• 某个第三方服务偶发抖动
• 某段代码没设超时
• 某个客户端把重试次数写大了

二、最典型的雪崩链路长什么样

这是线上最常见的一条死亡链路：

注意，这里最可怕的不是某个点挂了，而是：

系统在还没完全挂的状态下，被自己放大流量、放大等待、放大阻塞，最后拖死自己。

三、Node.js、PHP、Java 为什么都会中招

虽然三种技术栈的运行模型不同，但踩坑方式非常像。

1. Node.js 的痛点：你以为是异步，其实照样会堵

很多人误以为 Node.js 是异步模型，所以不怕阻塞。错。

Node.js 只是单线程事件循环 + 异步 IO 模型，不代表资源无限。你照样会遇到：

• 数据库连接池耗尽
• HTTP keep-alive 连接堆积
• 外部接口无超时导致 Promise 长时间悬挂
• 大量慢请求堆在事件循环外部资源上
• 某些 CPU 密集逻辑阻塞主线程
• 大量等待中的请求把内存拖高

尤其是下面这种情况最危险：

const results = await Promise.all(tasks.map(task => callService(task)));

看上去很优雅，实际上如果 tasks 很大，你可能一口气把下游服务、数据库连接池、第三方 API 全打爆。

异步不是免死金牌。无控制的并发，本质上仍然是洪水。

2. PHP 的痛点：请求结束不代表系统没堆死

PHP 最大的误区是：很多人以为 PHP 请求处理完就释放了，一次请求一个 worker，很安全。

但线上真实情况是：

• PHP-FPM worker 数有限
• MySQL 连接数有限
• Nginx 等待 PHP 返回的时间有限
• 慢请求一多，worker 就被占满
• 新请求进不来，只能排队
• 队列一长，超时更多
• 上游继续重试，系统更死

典型场景：

• 某个接口里做了多个串行远程调用
• 某个接口里查了一个慢 SQL
• 某个文件上传请求卡在下游存储
• 某个支付回调接口被第三方反复重试

最后不是 PHP 代码本身报了多漂亮的错，而是：

• PHP-FPM max_children 打满
• Nginx 返回 502 / 504
• 数据库连接数暴涨
• 整站变慢

PHP 的问题不是不会死，而是它死的时候，经常是 worker 被慢请求一个个占死。

3. Java 的痛点：池太多，最容易池池相扣

Java 服务端最经典的坑，就是各种池：

• Tomcat / Undertow 请求线程池
• 业务线程池
• 数据库连接池
• HTTP 客户端连接池
• Redis 连接池
• MQ 消费线程池

单独看每个池都没问题，组合起来就容易出大事。

举个非常典型的事故：

Java 最容易出现的问题不是没池，而是：池太多，但每个池的容量、等待时间、超时策略、拒绝策略根本没有协调。

四、真正的根因，不是慢，而是等待失控

你要记住一句非常重要的话：

大部分线上雪崩，不是因为计算本身太重，而是因为等待太多、等待太久、等待没有边界。

服务端最危险的不是一个请求执行 50ms 还是 500ms，而是：

• 这个请求会不会无限等
• 会不会把连接一直占着
• 会不会把线程一直占着
• 会不会被上游重复打
• 会不会把慢传播给全链路

所以真正要盯的不是单个接口快不快，而是下面这几个等待资源：

• 请求线程
• 数据库连接
• HTTP 连接
• Redis 连接
• MQ 消费能力
• PHP-FPM worker
• Node.js 进程内 pending promise 数
• 网关 / 负载均衡的等待队列

五、最危险的四个坑

1. 没有超时

这是所有事故的起点。

你只要有任何一个外部调用没设超时，迟早出事。

比如：

• 调数据库没超时
• 调 Redis 没超时
• 调 HTTP 接口没超时
• 调第三方支付 / 短信 / OCR / AI 接口没超时

没有超时的后果是：

• 请求一直挂着
• 连接一直不释放
• 线程 / worker 一直被占着
• 上游继续等
• 系统资源越来越少

最愚蠢、也最常见的代码，就是：

// Node.js
const res = await axios.get(url);

// PHP
$response = file_get_contents($url);

// Java
RestTemplate restTemplate = new RestTemplate();
String result = restTemplate.getForObject(url, String.class);

这些代码不是不能跑，而是如果你没显式配置连接超时和读取超时，线上迟早被坑。

2. 无脑重试

很多人以为重试是容错。其实在生产环境里，错误的重试是放大器。

下游本来已经慢了，你再来三次重试，就等于：

• 一个请求变三个
• 十个请求变三十个
• 一百个请求变三百个

如果整个系统都在这么干，流量会被瞬间放大到原来的几倍。

最可怕的是多层重试：

• 前端超时重试一次
• 网关又重试一次
• 服务 A 调 B 再重试三次
• B 调第三方又重试两次

最后你表面上只有一个用户点击，背后可能已经发出十几次请求了。

真正正确的原则是：

• 不是所有错误都能重试
• 不是所有接口都该重试
• 重试一定要限次数
• 重试一定要有退避
• 重试一定要考虑幂等性

3. 连接池配置拍脑袋

很多线上事故都来自一句话：

我把连接池调大一点不就好了？

结果通常更惨。

比如数据库最多只允许 200 个连接，你有 5 个服务实例，每个实例数据库连接池都配成 100，那理论最大连接就是 500。

你服务还没起量，数据库先被你配置打死了。

连接池不是越大越好。它本质上是有限资源的闸门，不是性能药水。

你真正要考虑的是：

• 下游最大承载量是多少
• 你有多少实例
• 每个实例最大并发是多少
• 单个请求平均占连接多久
• 是否有长事务、慢 SQL、慢查询
• 连接不够时，是排队还是快速失败

如果这些没想清楚，池越大，死得越快。

4. 同步等待太多

很多人写服务端代码时，逻辑上特别自然：

每一步都没错。错的是：它们全都在主请求链路里同步串行执行。

最后就会出现：

• 一个下游慢一点，整个接口就慢
• 一个下游抖一下，整个接口就抖
• 某个非核心动作卡住，主流程也卡住
• 所有请求都在等待同一堆下游

服务端一旦把太多动作塞进同步主链路，系统就变得极度脆弱。

六、怎么判断你的系统已经在雪崩边缘

如果你线上出现下面这些信号，就已经非常危险了：

1. 成功率没有完全掉，但 TP99 明显拉高 —— 说明系统不是彻底挂，而是在大量排队
2. 错误主要是 timeout，而不是代码异常 —— 说明大概率不是逻辑 bug，而是资源等待失控
3. 数据库连接数、线程数、worker 数接近上限 —— 说明你的系统在撑，不是在跑
4. 请求量没涨多少，但机器负载、响应时间突然恶化 —— 通常意味着某个慢点触发了连锁阻塞
5. 重启应用后暂时恢复，过一会儿又坏 —— 这类问题基本不是重启就好了，而是你把堆积清空了，但根因还在

七、服务端真正该怎么设计

1. 所有外部调用必须有超时

包括：数据库、Redis、HTTP、RPC、第三方 API、文件存储、消息队列。

而且超时要分两层：连接超时 和 读取 / 响应超时。

Node.js 示例：

const axios = require('axios');
const client = axios.create({ timeout: 3000 });

async function fetchUser() {
  const res = await client.get('http://user-service/api/user');
  return res.data;
}

Java 示例：

SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
factory.setConnectTimeout(1000);
factory.setReadTimeout(3000);
RestTemplate restTemplate = new RestTemplate(factory);

PHP 示例：

$ch = curl_init('https://api.example.com/data');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, 3);
$response = curl_exec($ch);
curl_close($ch);

2. 给并发加闸门，不要放任洪水冲下游

尤其是 Node.js，很容易一不小心把并发打爆。

错误示例：

const results = await Promise.all(ids.map(id => fetchDetail(id)));

更稳的方式，限制并发数：

const pLimit = require('p-limit');
const limit = pLimit(5);

const tasks = ids.map(id => limit(() => fetchDetail(id)));
const results = await Promise.all(tasks);

核心思想不是越快越好，而是：宁可稳一点，也不要把下游瞬间打死。

3. 重试要克制，而且必须带退避

错误的重试：立即重试、无限重试、多层同时重试、不分错误类型全部重试。

正确的重试至少要满足：

• 只对可恢复错误重试
• 限制次数
• 带随机退避
• 幂等接口才允许重试

例如伪代码：

而不是 0ms 连续三连击把下游狠狠干穿。

4. 非核心动作异步化

主链路只保留真正关键的步骤。

例如这些动作，很多时候不应该阻塞主请求：

• 写操作日志
• 发通知
• 刷搜索索引
• 发短信 / 邮件
• 埋点
• 推送 BI 数据
• 同步非核心系统

能进 MQ 的进 MQ，能异步任务的异步任务，别全堆在一个 HTTP 请求里同步做完。

5. 池的配置要按全链路算，不要单点拍脑袋

比如你要配数据库连接池，至少要先想：

• 数据库最大连接是多少
• 一共有几个应用实例
• 每个实例连接池上限多少
• 峰值时每秒多少请求
• 每个请求是否都需要数据库连接
• 一个连接平均占用多久

同理，线程池也一样。你不能只看本服务舒服不舒服，你得看整个链路会不会被你配崩。

6. 快速失败，比死扛更重要

很多人最怕失败。但线上真实世界里，快速失败往往比慢慢拖死全站更高级。

比如：

• 连接池满了，直接拒绝
• 线程池满了，快速返回降级结果
• 下游超时了，直接走兜底逻辑
• 非核心能力熔断，不拖主流程

你要保护的不是单个请求一定成功，而是整个系统别一起死。

八、一个典型事故案例

假设有这样一个下单接口：

某天第三方优惠接口变慢，从 100ms 变成 3 秒。接下来会发生什么？

1. PHP worker 被慢请求占住
2. MySQL 连接占用时间变长
3. Node.js 等 PHP 返回
4. Node.js 请求堆积
5. Java 网关线程等 Node.js
6. 上游 Nginx 499、504 增多
7. 开发觉得可能网络抖动，加了重试
8. 第三方接口被打得更狠
9. 雪崩正式开始

这里最关键的一点是：真正的问题不是第三方慢，而是你没有把第三方慢限制在局部。

如果你当时做了这些事情，事故会小很多：

• 第三方接口设置 800ms 超时
• 优惠计算失败直接降级
• 库存和下单主链路不要依赖优惠接口成功
• 对第三方调用限并发
• 禁止多层重试
• 非核心逻辑异步化

九、最该监控的不是接口报错，而是这些指标

很多团队监控只盯：QPS、平均响应时间、错误率。这远远不够。

真正该重点盯的是：

• TP95 / TP99
• 请求超时数
• 数据库连接池使用率
• HTTP 客户端连接池使用率
• PHP-FPM active processes
• Java 线程池活跃线程数与队列长度
• Node.js event loop delay
• 下游调用耗时分布
• 重试次数
• 熔断 / 降级次数
• 被拒绝的请求数

平均值会骗你，尾延迟和资源池状态不会。

十、总结

服务端最难排查、最容易跨语言复现的痛点，不是某个接口挂了，而是：

系统看起来没完全坏，但内部的等待、堆积、重试、阻塞，已经把整条链路拖进雪崩。

不管你用的是 Node.js、PHP、Java，还是别的服务端语言，最后都逃不过这几个基本规律：

1. 外部调用必须有超时
2. 并发必须有限流
3. 重试必须克制
4. 池的配置必须按全链路设计
5. 非核心逻辑必须异步化
6. 快速失败比死扛更重要

你只要记住一句最值钱的话：

线上系统不是死于报错，而是死于等待失控。

这才是服务端真正的高难度痛点。