Part IV · 分布式系统 · 第 12 章
12
伸缩与韧性
云服务不追求永不失败，而追求失败时不扩散、负载变化时不崩溃、成本增长时不失控。
0先把地图摊开
云服务不追求永不失败，而追求失败时不扩散、负载变化时不崩溃、成本增长时不失控。 本章不会把概念排成术语表，而是沿着一条真实系统路径走：先看它解决什么痛点，再看 OS/云平台怎样实现，最后回到工程取舍。
自动扩缩容根据指标自动增加或减少资源。
背压下游扛不住时，主动让上游减速或失败得更早。
熔断发现下游持续失败后短时间停止调用，避免雪崩。
SLO用户体验层面的可靠性目标，例如 99.9% 请求 < 300ms。
12.1伸缩先问瓶颈在哪里
加机器不是万能药。CPU-bound 可以横向扩，数据库锁竞争不一定行；内存泄漏会被复制，网络瓶颈会转移。伸缩之前先找资源曲线和排队点。
12.2自动扩缩容是滞后的控制系统
HPA 看指标、做决定、等 Pod 启动、等流量重新分配。这条链有延迟。突发流量到来时，系统必须靠余量、队列或降级撑过反应时间。
12.3重试既是止痛药也是毒药
一次超时后重试可能救回请求，也可能把已经过载的下游打得更死。没有超时、退避、幂等和预算的重试，是雪崩制造机。
12.4背压承认系统容量有限
当队列变长、延迟升高，正确系统应该限流、降级或快速失败，而不是无限接单。云服务的成熟标志，是知道什么时候说“不”。
12.5可靠性和成本是一张账
多副本、跨区、预留容量、冷备热备都要钱。好的架构不是“最可靠”，而是在业务价值、SLO 和成本之间找到清晰边界。
↔云与 OS 的桥
这一章不是孤立知识点。下面这张表把它和前后章节接起来：你会看到，同一个机制在单机、云平台和 AI 基建里会换名字，但问题结构没变。
| 本章机制 | 云上形态 | 为什么重要 |
|---|---|---|
| Autoscaling | Kubernetes HPA、serverless concurrency | 控制系统有延迟，容量规划仍然重要。 |
| Backpressure | 队列、限流、429 | 主动拒绝是保护整体系统的正当动作。 |
| SLO/Error Budget | 可靠性工程 | 让可靠性从情绪变成可讨论的预算。 |
深潜 读完本章后，怎么确认自己真的懂了？›
不要只背定义。你应该能把一个线上现象翻译回机制：慢在哪里、谁在排队、哪个抽象漏了、哪个资源被过度承诺。下面三个检查点可以当成小作业。
本章收束 · 你现在握住了什么
- 伸缩要先定位瓶颈，盲目加机器会移动问题。
- 自动扩缩容是滞后的控制系统，必须处理反应窗口。
- 重试需要预算、退避、幂等，否则会放大故障。
- 可靠性是业务价值、用户体验和成本之间的工程选择。
接下来机器会继续消失：Serverless 把服务器抽象到几乎不可见，但底层代价仍然存在。