1. 故障模式与弹性工程
1.1 分布式系统中的常见故障类型
在分布式系统中，故障不再是“是否会发生”的问题，而是“何时发生”以及“如何应对”的问题。与单体应用不同，分布式系统的任何节点、网络或资源都可能成为故障的引爆点。以下三类故障是弹性工程需要重点防御的核心场景：
| 故障类型 | 典型表现 | 根因示例 | 对系统的影响 |
|---|---|---|---|
| 网络延迟 | 请求响应时间从毫秒级飙升到秒级甚至超时 | 机房光缆中断、DNS 解析抖动、跨 AZ 带宽打满 | 线程池阻塞、连接池耗尽、调用链雪崩 |
| 服务过载 | CPU 使用率持续 95%+、请求排队、吞吐量骤降 | 突发流量（秒杀/热点）、慢 SQL 堆积、上游重试风暴 | 服务质量下降、级联超时、部分节点被熔断 |
| 资源耗尽 | 内存 OOM、文件句柄耗尽、连接池无可用连接 | 内存泄漏、未关闭的 HTTP 连接、线程泄漏 | 节点宕机、健康检查失败、集群容量收缩 |
关键认知： 上述三种故障往往不是孤立发生的。网络延迟会引发客户端重试，重试加剧服务过载，过载导致资源耗尽，最终形成典型的“雪崩效应”。弹性工程的目标就是在故障扩散路径上设置“断路器”。
1.2 弹性工程的核心思想
弹性工程（Resilience Engineering）并非追求“永不故障”，而是承认故障必然发生，并确保系统在故障发生时仍能提供可接受的服务质量。其核心思想可以概括为三个层次：
- 故障隔离（Bulkheading）： 将系统拆分为独立的资源池或舱壁，一个舱壁的故障不会扩散到其他舱壁。例如：为不同业务线分配独立的线程池。
- 快速失败（Fail Fast）： 当检测到下游服务不可用或响应过慢时，立即拒绝请求，而不是长时间等待。这能防止线程和连接资源被无效请求耗尽。
- 优雅降级（Graceful Degradation）： 在核心功能受损时，主动关闭非核心功能，优先保障主流程可用。例如：推荐系统不可用时，返回默认推荐列表而非报错。
实践原则： 弹性设计应遵循“防御性编程 + 运行时自适应”的组合策略。代码层面做好超时、重试限制和异常处理；运行时通过熔断器、限流器和舱壁模式动态调整行为。
1.3 Resilience Pattern 的引入背景
随着微服务架构和云原生技术的普及，服务间调用关系从简单的“请求-响应”演变为复杂的网状拓扑。传统的“重试+超时”策略在以下场景中暴露出严重不足：
- 重试风暴： 上游服务统一配置 3 次重试，下游故障时，重试流量放大 3 倍，直接压垮下游。
- 资源泄漏： 无限制等待超时导致线程池和连接池被僵尸请求占满。
- 级联故障： 一个服务的抖动通过调用链传导，导致整个调用链路瘫痪。
为了解决上述问题，业界从电路工程、交通工程等领域借鉴了成熟的控制模式，形成了一套可复用的 Resilience Pattern（弹性模式）。这些模式提供了标准化的故障处理策略，使开发人员无需从零设计容错逻辑。
1.4 核心模式概览
本课程将重点实战以下四种 Resilience Pattern，它们构成了分布式系统弹性设计的基石：
| 模式名称 | 核心职责 | 类比 | 适用场景 |
|---|---|---|---|
| 熔断器（Circuit Breaker） | 监控失败率，达到阈值后快速拒绝请求，避免资源浪费 | 家庭电路保险丝 | 下游服务持续超时或返回错误 |
| 降级（Degradation） | 在压力或故障下，主动关闭非核心功能，保障主流程 | 飞机降落后关闭机上娱乐系统 | 资源紧张、依赖服务不可用 |
| 限流（Rate Limiting） | 控制请求速率，防止系统被突发流量冲垮 | 高速公路收费站 | 秒杀、爬虫、DDoS 防护 |
| 舱壁（Bulkhead） | 隔离资源池，一个舱壁的故障不影响其他舱壁 | 船舶水密隔舱 | 多租户、混合负载、关键与非关键业务分离 |
常见误区： 不要将熔断和降级混为一谈。熔断是“停止调用”，降级是“提供替代响应”。两者通常配合使用：熔断触发后，调用方执行降级逻辑返回兜底数据。
1.5 本章小结
- 分布式系统的三大故障类型——网络延迟、服务过载、资源耗尽——是弹性工程的主要防御对象。
- 弹性工程的核心思想是故障隔离、快速失败和优雅降级，而非追求零故障。
- Resilience Pattern 提供了标准化的故障处理策略，避免了从零设计容错逻辑的重复劳动。
- 熔断器、降级、限流、舱壁是四种最基础且最实用的弹性模式，后续章节将逐一深入实战。