高可用架构与故障容错

系统可用性是衡量架构质量的首要指标。本文从可用性量化指标出发，系统讲解容灾架构设计（主备、主从、多活）、故障检测机制、自动故障转移、优雅降级策略，以及如何通过混沌工程验证系统韧性。

1. 可用性度量

1.1 可用性百分比与停机时间

1.2 MTBF / MTTR

可用性 = MTBF / (MTBF + MTTR)

MTBF（Mean Time Between Failures）：平均故障间隔时间
MTTR（Mean Time To Repair）：平均故障修复时间

提升可用性的两条路径：
1. 增加 MTBF → 减少故障发生的概率（更好的硬件、更健壮的代码）
2. 缩短 MTTR → 故障发生后更快恢复（自动化、良好的可观测性）

实践证明：降低 MTTR 比提升 MTBF 更加可行且效果显著。通过自动化故障检测和恢复，可将 MTTR 从小时级压缩到秒级。

2. 高可用架构模式

2.1 主备模式（Active-Standby）

        流量
          ↓
    ┌──────┴──────┐
    │    VIP      │  ← 虚拟 IP，由 Keepalived/HAProxy 管理
    └──────┬──────┘
           │
    ┌──────┴──────┐
    │             │
 [主节点]        [备节点]  ← 实时监控主节点心跳
  Active      Standby      主节点故障时，VIP 漂移到备节点
    │             │
    └──────┬──────┘
        共享存储

2.2 主从模式（Active-Active / 读写分离）

         写请求 ──→ [主库] ──→ 异步复制 ──→ [从库 A]
                               ──→ 异步复制 ──→ [从库 B]
         读请求 ──→ [负载均衡器] ──→ 从库 A / 从库 B

特点：

• 主库负责写，从库负责读
• 存在复制延迟（Replication Lag）
• 适用于读多写少场景
• 从库故障不影响写，但读能力降级

2.3 双活/多活架构

┌──────────┐         ┌──────────┐
│  地域 A   │←──同步──→│  地域 B   │
│ [应用]    │  复制    │ [应用]    │
│ [数据库]  │←───────→│ [数据库]  │
└──────────┘         └──────────┘
     │                    │
     └────── 全局 LB ──────┘
            （按地域/用户路由）

RPO（Recovery Point Objective）：灾难发生后允许丢失的最大数据量。RTO（Recovery Time Objective）：恢复业务所需的最大时间。

2.4 去中心化架构

传统中心化：            去中心化：

  ┌──────┐              ┌──┐  ┌──┐  ┌──┐
  │中心节点│              │N1│  │N2│  │N3│
  └──┬───┘              └┬┘  └┬┘  └┬┘
     │                   │    │    │
   / | \                 └───┤────┘
 ┌┐ ┌┐ ┌┐                     │
 所有数据/决策            数据/决策分散在各节点
 集中在单点              （Raft/Paxos 共识）

代表系统：Cassandra、DynamoDB、区块链（PoW/PoS 共识）。

3. 故障检测与自动切换

3.1 心跳检测机制

# 简化的健康检查逻辑
class HealthChecker:
    def __init__(self, timeout=5, retries=3):
        self.timeout = timeout
        self.retries = retries
        self.failure_count = {}

    async def check(self, endpoint):
        try:
            response = await asyncio.wait_for(
                http_get(endpoint + "/health"),
                timeout=self.timeout
            )
            if response.status == 200:
                self.failure_count[endpoint] = 0
                return True
        except (TimeoutError, ConnectionError):
            pass
        
        self.failure_count[endpoint] = self.failure_count.get(endpoint, 0) + 1
        if self.failure_count[endpoint] >= self.retries:
            return False  # 标记为不可用
        return True

3.2 脑裂问题与解决

脑裂（Split-Brain）：

  网络分区后，两边都认为对方挂了，各自选举出主节点
  
  分区前：        分区后：
  ┌───┐            ┌───┐     ┌───┐
  │ M │──────┬     │ M │     │ M │  ← 两个主节点！
  └───┘      │     └───┘     └───┘
  ┌───┐     ┌┴┐    数据不一致风险
  │ S │     │网络│
  └───┘     └┬┘
  
解决方案：
1. 法定人数（Quorum）：n/2 + 1 节点同意才能当选
2. 仲裁机制：引入外部仲裁节点（Witness）
3.  fencing/STONITH：强制关闭怀疑节点（Shoot The Other Node In The Head）

3.3 常用高可用组件

4. 容错设计策略

4.1 重试与熔断

调用链：
服务 A ──→ [断路器] ──→ 服务 B
              │
              ├── 正常时：直接转发请求
              ├── 失败次数 < 阈值：记录失败，继续转发
              └── 失败次数 ≥ 阈值：打开断路器，快速失败

半开状态：定时尝试放行少量请求，成功后恢复关闭状态

4.2 优雅降级（Graceful Degradation）

全量功能：                  降级后：

[首页]                      [首页]
  ├ 推荐商品（实时算法）        ├ 推荐商品（缓存数据）
  ├ 用户评论（实时聚合）   →    ├ 用户评论（暂不可见）
  ├ 实时库存                  ├ 实时库存（显示"有货/无货"）
  └ 个性化 banner              └ 默认 banner

降级触发条件：
- 依赖服务超时/不可用
- 系统负载超过阈值（CPU > 80%，QPS 超过容量）
- 数据库连接池耗尽

4.3 限流与隔离

5. 灾备与演练

5.1 灾备等级

5.2 混沌工程（Chaos Engineering）

在生产环境有控制地注入故障，验证系统的容错能力。

混沌工程原则：
1. 建立稳态假设：定义"正常"的行为指标
2. 模拟真实事件：网络延迟、节点宕机、服务超时
3. 在生产环境实验：最接近真实场景
4. 持续自动化：将混沌实验纳入 CI/CD

常用工具：
- Netflix Chaos Monkey：随机终止实例
- Chaos Mesh（Kubernetes）：Pod 故障、网络故障、磁盘故障
- Gremlin：企业级混沌工程平台
- Litmus：云原生混沌工程

5.3 灾难演练清单

□ 数据库主库宕机：从库是否自动提升？数据是否丢失？
□ 缓存全部失效：数据库能否承受流量？
□ 依赖服务超时：是否触发熔断？降级是否生效？
□ 网络分区：是否产生脑裂？数据一致性是否破坏？
□ 机房级故障：异地容灾是否有效切换？
□ 全链路压测：容量上限是多少？瓶颈在哪个环节？

6. 总结

高可用不是"不出故障"，而是"故障后快速恢复"。

核心公式：
  可用性 = MTBF / (MTBF + MTTR)
  
  → 降低 MTTR 的 ROI 远高于提升 MTBF

架构层次演进：
  单点 → 主备 → 主从 → 双活 → 多活 → 去中心化
  
  每升一级，可用性提升一个 9，但复杂度指数级增长
  
  选择适合业务阶段的方案，不要过度设计