稳定性不是零故障，而是”可恢复”。
场景与痛点
这篇文章面向2-5 人小团队，从稳定性视角深入拆解Node.js 服务稳定性。当前定位为「深挖」阶段，核心目标是规模化演进与成本优化。我们会从实际场景出发，结合具体代码示例，把关键知识点拆解为可落地的行动步骤。衡量标准：SLA/MTTR/错误率。
在微服务架构下，一个请求可能经过 5-10 个服务节点。任何一个节点的抖动都可能引发连锁反应：下游超时 → 上游线程堆积 → 整个链路雪崩。稳定性工程的核心不是”消灭故障”（这不现实），而是”控制故障的影响范围”和”缩短恢复时间”。超时、重试、熔断、降级是四个最基本的稳定性手段。
当团队规模是2-5 人小团队时，最大的挑战不是”不会做”，而是”做了但不可复用、不可追溯”。在已有系统的重构期的背景下，我们需要一套既轻量又可靠的方案。
核心原理
没有超时的外部调用就像一颗定时炸弹。当下游服务响应变慢时，如果调用方没有设置超时，请求会一直挂着，占用连接池和内存。随着堆积的请求越来越多，调用方自己也会变慢，最终整条链路瘫痪。这就是所谓的”级联故障”。超时是最基本的自我保护机制，重试是容错手段，熔断是快速失败策略，降级是保核心放非核心的取舍。
分步实施指南
超时设置的原则是：比下游的 P99 响应时间稍大，但不能太大。比如下游 P99 是 800ms，超时可以设 1.5s。太短会导致正常请求被误杀，太长起不到保护作用。
重试要有限制：最多重试 1-2 次，且只对可重试的错误（网络超时、5xx）重试，不要对 4xx 重试。重试间隔使用指数退避（exponential backoff）加随机抖动（jitter），避免重试风暴。
熔断器（Circuit Breaker）有三个状态：关闭（正常通行）、打开（快速失败）、半开（试探恢复）。当错误率超过阈值时熔断器打开，所有请求直接返回降级结果，不再调用下游。一段时间后进入半开状态，放少量请求试探，如果成功则恢复，否则继续熔断。
降级是业务层面的取舍：核心功能保证可用，非核心功能在压力大时主动关闭。比如商品详情页，价格和库存是核心，推荐和评论是非核心，可以在高峰期降级。
实战代码
以下代码片段经过简化，可以直接用于项目中：
// 带超时的 fetch 封装
async function fetchWithTimeout(url, options = {}, timeout = 3000) {
const controller = new AbortController();
const timer = setTimeout(() => controller.abort(), timeout);
try {
const res = await fetch(url, {
...options,
signal: controller.signal
});
return res;
} finally {
clearTimeout(timer);
}
}
// 带重试的调用（指数退避 + 抖动）
async function fetchWithRetry(url, maxRetries = 2) {
for (let i = 0; i <= maxRetries; i++) {
try {
return await fetchWithTimeout(url);
} catch (err) {
if (i === maxRetries) throw err;
const delay = Math.min(1000 * 2 ** i, 5000);
const jitter = delay * 0.2 * Math.random();
await new Promise(r => setTimeout(r, delay + jitter));
}
}
}进阶实践
Node.js 中可以用 AbortController 实现请求超时，用 p-retry 库做重试，用 opossum 库实现熔断器。建议为每个外部依赖（数据库、Redis、第三方 API）都配置独立的超时和熔断策略。监控方面，重点关注超时率、重试率、熔断触发次数，这些是系统健康度的先行指标。
踩坑记录
最危险的错误是没有设置超时——这在 Node.js 中尤其致命，因为单线程模型下一个慢请求就能阻塞整个事件循环。其次是无限重试，这会在下游故障时成倍放大流量，加速雪崩。还有一种常见问题是降级逻辑和正常逻辑耦合太深，导致降级本身也可能出错。
下一步行动
如果你正处于深挖阶段，建议先把核心链路的SLA/MTTR/错误率监控建立起来，然后按照上面的步骤逐项推进。记住，降低故障率并缩短恢复时间不是一蹴而就的，而是持续迭代的过程。每次改进后都要回看数据，确认效果符合预期。