本篇要回答的问题：在 24h 不间断服务下，软硬件环境故障是一种必然。那么一个经典 API 请求沿途有哪些故障点（故障域）？每个故障点又该如何做故障预案，避免单点故障影响用户？
承接前面发布（49）与监控（50）。本讲聚焦三大故障来源中的第二类——软硬件环境故障：通过逐个排查请求链路上的故障点，建立"切流量优先、最小切量"的故障预案体系。
三类故障与本讲重点
| 故障类型 | 性质 | 本讲处理 |
|---|---|---|
| 软硬件升级/配置变更（发布） | 过程型故障，主动变更引起 | 灰度可规避大部分，但灰度发现不了所有风险（如长潜伏期故障）→靠白盒审查+测试覆盖 |
| 软硬件环境故障 | 规模化下的必然事件 | 本讲重点 |
| 终端用户请求（过载） | 见第 53 讲 | —— |
关键判断：1 块盘按 3 年寿命算每 1000 天坏一次，1000 块盘就平均每天坏一块——故障从偶然变必然。
用源码画请求链路：故障点是一棵 IO 树
关键洞见：IO 之外的普通业务代码不太会出"环境故障"；故障点主要在 IO（磁盘 IO、网络 IO）。请求链路可画成一棵树，每个节点是一次 IO 操作。
为什么写业务代码可以"心宽"、不必处处做异常恢复？因为前端有负载均衡：任何异常返回 5XX，LB 发现出错就把请求转给其他业务服务器重试，从而解决业务架构的单点问题。
逐个故障点的预案
| 故障点 | 风险 | 故障预案 |
|---|---|---|
| 网络链路 | 用户端网络（个例损失小）/ 运营商区域故障（影响大但自身难解） | 服务端侧准备多条链路：多域名，由客户端选择与重试 |
| DNS | 权威服务/递归服务单点 | 权威服务配多个且分散机房；递归服务给 OS 配多个（含公共 8.8.8.8 等，服务端侧则自建高可用 DNS） |
| 机房 | 断电/断网 | 偏静态读多用 2AZ，通用业务建议 3AZ（每 AZ 只需扛 1/2 体量，总成本 1.5 倍而非 2 倍，且利于 DB 选主） |
| 机架 | 整排同时断电断网 | 同类服务/同数据多副本分散到不同机架 |
| 交换机 | 大范围机器下线 | 两交换机热备，走 HSRP（热备份路由协议） |
| 负载均衡 | 1 个实例故障=1/N 用户受影响 | LB 用 VIP（虚 IP），主实例故障即把流量打到其他实例（不走 DNS，因 DNS 生效慢） |
| 业务服务本身 | 相对容易 | 坚持业务服务器无状态，任一台故障都不影响用户 |
| 缓存/数据库/存储 | 有状态，最难容灾 | 见下方专项 |
机房故障与 DNS 生效慢
机房故障要在 DNS 中下线一批 IP，但 DNS 生效周期长（受 TTL 影响，有的递归服务还忽略 TTL）。解法：客户端引入 HTTP DNS（基于 HTTP 协议提供解析，绕过传统 DNS）+ 客户端缓存。
有状态服务：缓存与数据库
| 组件 | 特征 | 预案 |
|---|---|---|
| 缓存 | 通常单副本（一致性哈希分片） | 少量挂掉只是命中率短降；挂太多→后端 DB 压力大→雪崩，需在 DB 层做过载保护，或 SRE 让 LB 扔掉部分请求；雪崩已发生则先扔够多请求让 DB 恢复，再逐步回放 |
| 数据库/存储 | 有状态、必多实例 | 有主（Master）有从（Slave），主挂触发选举；老式一主一备 Stand-by 已过时不推荐 |
故障恢复：切流量优先 + 最小切量
关键判断：大部分故障优先用切流量消除，并遵循最小切量原则——能细粒度切就不粗粒度切。
| 流量切换控制点 |
|---|
| 负载均衡 |
| 负载均衡实例的 VIP 入口 |
| DNS 解析 |
但若根因是有状态服务（DB/存储），很难靠切量消除——此时应用过载保护机制降级（按比例丢请求）；扩容也是缓解 DB/存储压力的常规思路（第 53 讲展开）。
总结
可导致故障的因素分三类，本讲重点是"软硬件环境故障"。方法是沿请求链路把所有故障点画成一棵 IO 树，逐点设计预案；负载均衡 + 无状态业务服务器极大降低了业务架构的心智负担，而真正的难点永远是有状态的数据库与存储的容灾。
先把"是什么"回答清楚
| 概念 | 一句话说明 |
|---|---|
| 故障域 | 请求链路上可能出故障的各个点 |
| 请求链路树 | 以每次 IO 操作为节点画出的故障点树 |
| 2AZ / 3AZ | 双/三机房容灾；3AZ 利于选主，总成本可仅 1.5 倍 |
| VIP | 负载均衡用的虚 IP，主实例故障即漂移流量 |
| HTTP DNS | 基于 HTTP 的解析，绕过传统 DNS 解决生效慢 |
| 无状态 | 业务服务器不存状态，任一台故障不影响用户 |
| 最小切量原则 | 能细粒度切流量消除故障就不粗粒度切 |
一句话速记
规模化让环境故障从偶然变必然；沿请求链路把每个 IO 故障点（网络/DNS/机房/机架/交换机/LB/业务/存储）逐一做预案，无状态服务靠切流量救，有状态存储只能靠过载保护与多副本选主。
几条值得记住的判断
- 1000 块盘平均每天坏一块——故障必然化。
- 负载均衡 + 无状态业务服务器让业务架构容错心智负担骤降。
- 3AZ 不一定比 2AZ 贵（每 AZ 只扛 1/2 体量），且利于 DB 选主。
- 故障恢复优先切流量、最小切量；有状态服务靠过载保护降级。
思考题
文中说有了负载均衡，写业务代码可以"心宽"。但对你系统里那些有状态的环节（缓存、DB、存储），这种心宽就失效了。试着画出你某个核心 API 的请求链路树，标出每一个 IO 节点：哪些靠切流量就能救？哪些一旦故障只能靠多副本选主或过载保护？
