容灾、高可用与混沌工程全景知识图谱

4.1 多活架构

同城双活：两个机房在同一城市（延迟 < 2ms），数据同步写入。适合金融等对 RPO=0 有要求的场景，但无法防御城市级灾难。

异地多活：多个地域独立服务用户，数据异步同步。核心挑战是数据冲突解决和跨地域一致性。常见方案：按用户分片（单元化）、按业务分片、最终一致性。

单元化架构：将用户按规则（如 UID 取模）路由到固定单元，单元内闭环处理。跨单元调用走中心路由。阿里、蚂蚁的 LDC 架构是典型实现。

工程判断：异地多活的复杂度和成本是同城双活的 5-10 倍。先评估业务是否真的需要跨地域容灾，大多数系统同城双活 + 异地冷备就够了。

4.2 RTO / RPO 设计

RPO（Recovery Point Objective）：能容忍丢失多少数据。RPO=0 需要同步复制（性能代价大），RPO=分钟级可以用异步复制 + WAL。

RTO（Recovery Time Objective）：能容忍多长时间不可用。RTO=秒级需要热备自动切换，RTO=分钟级可以用温备手动切换。

业务分级：不是所有服务都需要最高等级的 RTO/RPO。核心交易链路（P0）要求秒级恢复，内部管理系统（P3）小时级恢复即可。分级是成本控制的关键。

切换自动化：手动切换的 RTO 下限是"人被叫醒 + 判断 + 操作"的时间（通常 10-30 分钟）。要做到分钟级 RTO，必须自动化切换 + 自动化验证。

4.3 降级 / 熔断 / 限流

服务降级：非核心功能在压力下主动关闭，保护核心链路。需要预先定义降级策略和开关，不能临时决定。

熔断：下游服务异常时快速失败，避免请求堆积拖垮调用方。Sentinel / Resilience4j 是主流实现。熔断阈值和恢复策略需要根据实际流量调优。

限流：保护系统不被超出容量的流量击穿。入口限流（网关层）+ 服务限流（单机/集群）。限流后的用户体验（排队/降级页/重试提示）同样重要。

隔离：线程池隔离、信号量隔离、进程隔离、机房隔离。粒度越细保护越强但资源利用率越低。核心链路建议至少做到线程池隔离。

4.4 混沌工程实践

核心流程：定义稳态假设 → 设计实验（注入故障）→ 控制爆炸半径 → 执行并观察 → 分析结果 → 修复薄弱点。

故障注入类型：网络（延迟/丢包/分区）、进程（Kill/CPU 满载/内存溢出）、存储（磁盘满/IO 延迟）、依赖（下游超时/错误响应）。

爆炸半径控制：从最小范围开始（单实例 → 单 AZ → 单 Region）。必须有紧急停止按钮和自动回滚机制。生产环境演练需要值班人员在场。

常态化演练：从"偶尔做一次"到"每周/每月固定演练"。GameDay 制度化，演练结果纳入 SRE 指标。目标是让团队对故障"脱敏"而非"恐惧"。

4.5 容量规划与压测

容量模型：基于历史流量 + 业务增长预测 + 大促峰值倍数，计算各服务所需资源。模型需要定期校准，业务变化会让旧模型失效。

全链路压测：在生产环境用影子流量或标记流量模拟真实峰值。关键挑战：数据隔离（压测数据不污染真实数据）、流量构造（模拟真实分布）、瓶颈定位。

弹性伸缩验证：压测不仅验证"当前容量够不够"，还要验证"扩容速度够不够快"。如果扩容需要 10 分钟但流量在 1 分钟内涌入，弹性就是假的。