4. 健康检查指标：响应时间、状态码、负载等
健康检查到底查什么？说白了，就是问三个问题：快不快？对不对？扛不扛得住？
这三个问题分别对应三个核心指标：响应时间、状态码、负载。我做了这么多年接口运维，踩过的坑大多跟这三个指标没设好有关。今天咱们一个一个说透。
4.1 响应时间——接口的“心跳”
响应时间，就是从发起请求到收到完整响应所花的时间。我习惯把它拆成三段看：
- 网络延迟：数据在链路上跑的时间。跨机房、跨区域时尤其明显。
- 处理时间：服务端真正干活的时间。业务逻辑、数据库查询、外部调用都算在内。
- 传输时间：响应体从服务器回到客户端的时间。返回数据量越大，这个值越吓人。
我在项目中遇到过一件事。有个密码验证接口，响应时间偶尔飙到 5 秒以上。一开始以为是业务代码慢，查了一圈才发现，是返回的加密证书序列化后太大，挤占了带宽。你看，不同阶段的瓶颈，表现可能完全一样，但根因截然不同。
4.2 状态码——接口的“表情”
状态码是服务端给客户端的表情信号。但我发现很多人只看 200 和 500，中间那一大片“灰色地带”全忽略了。
我一般把状态码分成四个等级来判断健康度：
| 等级 | 状态码范围 | 健康判定 | 我的处理方式 |
|---|---|---|---|
| 健康 | 2xx | ✅ 正常 | 计数通过，不做额外动作 |
| 警告 | 3xx, 4xx（除 429） | ⚠️ 轻微异常 | 记录日志，不触发切换；连续 N 次才告警 |
| 过载 | 429, 503 | 🔶 限流或超载 | 立即标记为“风险”，降低权重但不摘除 |
| 故障 | 5xx（除 503） | ❌ 服务不可用 | 立即摘除，触发故障转移 |
曾经我负责的一个支付密码接口，连续返回了 6 次 502。按当时的策略，直接摘除并切到了备用集群。结果发现是网关层临时配置错误，业务本身完全正常。那次之后我加了一个规则：状态码异常必须结合连续次数和响应时间一起判断，单一条件太容易误伤了。
4.3 负载指标——接口的“承重墙”
响应时间和状态码反映的是“现在怎么样”，而负载指标告诉你“还能撑多久”。
我通常关注以下四个负载维度：
- 并发连接数：当前正在处理的请求量。超过线程池上限就开始排队了。
- CPU 使用率：计算密集型接口（比如加解密）这个值很敏感。我见过一个 RSA 验签接口，并发一上来 CPU 直接飙到 95%。
- 内存占用：尤其注意 GC 频率和堆内存压力。频繁 Full GC 比 CPU 高更危险。
- 排队深度：请求在队列里等待的数量。这个值一旦上涨，响应时间会跟着剧烈抖动。
核心原则：负载指标不做“值判断”，而是做趋势判断。CPU 到 80% 不一定有问题，但从 40% 在 30 秒内直线升到 80%，这才是警报信号。
我个人习惯把负载指标和响应时间做交叉对比。举个例子，有一次某个密码重置接口的响应时间从 150ms 涨到 800ms，但 CPU 和内存都很平稳。最后查出来是下游的短信通道变慢了。如果只看负载指标，根本发现不了问题。
4.4 综合评分与阈值设定
单一指标不足以做故障转移决策。我一般用一个综合健康评分来算：
健康分 = w₁ × 响应时间分 + w₂ × 状态码分 + w₃ × 负载分
三个维度的分数都是 0–100，权重 w₁、w₂、w₃ 根据业务场景调整。举个例子，密码接口对响应时间敏感，我会给 w₁ 设 0.5，w₂ 设 0.3，w₃ 设 0.2。
阈值怎么定？我的经验是分两档：
- 警告阈值：健康分 < 70，记录日志，通知值班人员，但不做切换。
- 切换阈值：健康分 < 40，持续 10 秒以上，立即触发故障转移。
下面是我画的一张综合决策流程图，把三个指标的关系串起来了：
上图中，三个维度的分数先加权融合，然后进入决策分支。这里有个细节我要强调：不要连续两次都做切换决策。我见过一个系统，每次检查发现分低就立刻切，结果两个集群之间来回倒腾，比不切换还糟糕。我的做法是：连续 3 次检查都低于 40 分，才真正执行切换。