2. 熔断器基础概念：三种状态详解与状态机转换图

熔断器（Circuit Breaker）是分布式系统容错设计中的核心模式，其本质是一个有限状态机。它通过监控对下游服务（如数据库、API、缓存）的调用失败率，在系统出现故障时主动切断流量，防止故障级联扩散（即“雪崩效应”）。

熔断器维护三个关键状态：Closed（关闭）、Open（打开） 和 Half-Open（半开）。理解这三个状态及其转换条件是掌握熔断器配置的基础，也是后续使用 Terraform 编排云原生熔断策略的前提。

2.1 三种状态核心定义

状态 图标 含义 流量行为 典型触发条件
Closed 🔒 熔断器关闭，链路正常 请求正常通过，计数器实时统计失败率 初始状态；失败率低于阈值
Open 🔓 熔断器打开，链路切断 请求快速失败（返回降级响应），不发起真实调用 失败率超过阈值（如 50%）且达到最小请求数
Half-Open 🔐 熔断器半开，试探性恢复 允许少量探测请求通过，其余仍快速失败 Open 状态持续超时（如 60s）后自动进入
关键指标： 熔断器决策依赖三个核心参数——failure_threshold（失败阈值百分比）、request_volume_threshold（最小请求数）、sleep_window（Open 到 Half-Open 的等待时间）。在 Terraform 中，这些参数通常映射为 circuit_breaker 块中的属性。

2.2 状态机转换流程

熔断器的状态转换遵循严格的时序逻辑，不允许状态跳跃。下图展示了完整的转换路径及每个转换的触发条件。

熔断器状态机转换图 Closed （关闭） Open （打开） Half-Open （半开） 失败率 ≥ 阈值 且请求数达标 等待超时 （sleep_window） 探测请求成功 探测请求失败 状态转换规则说明 • Closed → Open：失败率超过 failure_threshold（如 50%），且请求量 ≥ request_volume_threshold。 • Open → Half-Open：经过 sleep_window 时间（如 60s）后自动进入。 • Half-Open → Closed / Open：根据探测请求的成功/失败结果决定。

2.3 状态转换的详细条件

每个转换背后都有明确的计数器和时间窗口逻辑。在基础设施即代码（IaC）场景下，这些条件直接对应 Terraform 配置中的参数。

  • Closed → Open（熔断触发）
    • 条件：在滑动时间窗口（如 10s）内，失败率 ≥ failure_threshold（默认 50%）。
    • 前置检查：窗口内总请求数 ≥ request_volume_threshold（默认 20），避免低流量误判。
    • 动作：立即切换到 Open 状态，后续请求直接返回降级响应（如 HTTP 503）。
  • Open → Half-Open（恢复试探）
    • 条件：熔断器处于 Open 状态的时间 ≥ sleep_window（默认 60s）。
    • 动作：允许通过 1 个探测请求（部分实现允许 N 个），其余请求仍快速失败。
    • 注意：sleep_window 不宜过短，否则可能导致频繁抖动。
  • Half-Open → Closed（恢复成功）
    • 条件：探测请求成功（如 HTTP 200），且响应时间在正常范围内。
    • 动作：重置失败计数器，熔断器回到 Closed 状态，恢复正常流量。
  • Half-Open → Open（恢复失败）
    • 条件：探测请求失败（如超时、HTTP 5xx）。
    • 动作：立即回到 Open 状态，并重置 sleep_window 计时器，等待下一次试探。
避坑提示： 在 Terraform 中配置熔断器时，sleep_window 和 failure_threshold 的取值需要结合下游服务的平均恢复时间（MTTR）来设定。如果 sleep_window 设置过小（如 5s），熔断器会在下游尚未恢复时频繁进入 Half-Open，导致“熔断-试探-再熔断”的震荡循环，反而增加系统负载。

2.4 状态机与滑动窗口的关系

熔断器的 Closed 状态依赖滑动窗口（Sliding Window）来统计失败率。常见的实现方式有两种：

窗口类型 实现原理 优点 缺点
计数滑动窗口 固定桶数（如 10 桶），每桶记录 1s 内的请求结果，过期桶自动丢弃 内存占用稳定，实现简单 窗口边界处统计精度略低
时间滑动窗口 记录每个请求的时间戳和结果，实时计算窗口内失败率 统计精度高，无边界误差 内存占用随请求量线性增长

在 Terraform 编排熔断器时（如 AWS App Mesh、Consul、Envoy 的熔断配置），通常只需指定窗口大小和阈值，底层实现由平台决定。但理解滑动窗口机制有助于排查“为什么熔断器没有按预期触发”的问题。

滑动窗口与状态转换时序示意 时间 T0 T1 T2 T3 T4 Closed Open Half-Open Closed 时序说明 • T0-T1：系统正常，熔断器处于 Closed 状态，滑动窗口统计失败率。 • T1：失败率超过阈值，熔断器跳转为 Open，所有请求快速失败。 • T2：sleep_window 超时，进入 Half-Open，发送探测请求；探测成功则回到 Closed。

2.5 状态机在 Terraform 中的映射

在 Terraform 中，熔断器配置通常以嵌套块的形式出现在服务网格、API 网关或负载均衡器的资源定义中。以下是一个基于 AWS App Mesh 的虚拟节点熔断器配置示例，展示了三种状态参数如何映射到 IaC 代码：

resource "aws_appmesh_virtual_node" "example" {
  name                = "service-b"
  mesh_name           = aws_appmesh_mesh.simple.id

  spec {
    backend = []

    listener {
      port_mapping {
        port     = 8080
        protocol = "http"
      }

      # 熔断器配置块
      connection_pool {
        http {
          max_connections      = 100
          max_pending_requests = 10
        }
      }

      outlier_detection {
        # 对应 Closed → Open 条件
        base_ejection_duration {
          unit  = "ms"
          value = 30000  # 30s 熔断持续时间（sleep_window）
        }
        interval {
          unit  = "ms"
          value = 10000  # 10s 滑动窗口大小
        }
        max_ejection_percent = 50  # 最大熔断比例
        max_server_errors    = 5   # 连续 5 次 5xx 触发熔断
      }
    }
  }
}
实践要点： 上述配置中 base_ejection_duration 对应 Open 状态的持续时间（即 sleep_window），interval 对应滑动窗口大小，max_server_errors 是触发熔断的失败计数阈值。在 Terraform 中，这些参数直接决定了熔断器的行为，建议在测试环境通过 terraform plan 验证参数组合的合理性。
← 上一章 📖 返回目录 下一章 →