4. 主流熔断框架对比：Hystrix、Resilience4j、Sentinel 核心特性对比表

在金融压力测试场景中，选择正确的熔断框架直接决定了系统的弹性边界与运维复杂度。本节从线程模型、隔离策略、实时统计、规则配置、运维集成五个维度，对 Hystrix、Resilience4j、Sentinel 三大主流框架进行横向对比，帮助架构师在选型时做出精准决策。

4.1 核心特性对比总表

4.2 线程模型与隔离机制对比

线程隔离是熔断框架的核心设计决策，直接影响金融系统的资源利用率与延迟稳定性。

• Hystrix 线程池隔离：每个依赖对应一个独立线程池，请求通过线程池切换执行。优点是隔离彻底，缺点是线程上下文切换开销大，在金融高频交易场景中容易造成 CPU 资源浪费。
• Resilience4j 信号量隔离：所有请求在调用线程中执行，仅通过信号量控制并发数。优点是零线程切换开销，适合低延迟、高吞吐的金融核心链路。
• Sentinel 双模式：默认使用信号量隔离，同时支持线程池模式。在金融场景中推荐信号量模式，配合 QPS 限流与热点参数限流，实现更精细的资源控制。

4.3 实时统计与滑动窗口机制

熔断决策依赖实时统计数据，滑动窗口的精度与性能直接影响熔断的及时性与误判率。

4.4 熔断状态机与恢复策略

三个框架均采用经典的三态熔断模型，但在恢复策略上存在差异。

4.5 监控与运维集成能力

金融系统对可观测性要求极高，熔断框架的监控集成能力直接影响故障定位效率。

• Hystrix：提供 Hystrix Dashboard 与 Turbine 聚合，但 Dashboard 已停止更新，且不支持实时规则调整。在金融生产环境中，建议尽快迁移。
• Resilience4j：无内置 Dashboard，通过 Micrometer 指标暴露给 Prometheus + Grafana。优点是标准化程度高，适合已有 Prometheus 基础设施的金融团队。
• Sentinel：内置控制台，支持实时监控、规则推送、集群限流管理。控制台可直接查看每台机器的 QPS、RT、错误率，并支持动态修改熔断阈值，无需重启应用。

4.6 选型决策矩阵

4.7 代码示例：Resilience4j 与 Sentinel 配置对比

以下展示两个框架在金融场景中的典型配置方式，体现规则定义的差异。

Resilience4j 熔断配置（application.yml）：

resilience4j.circuitbreaker:
  configs:
    default:
      slidingWindowSize: 10
      minimumNumberOfCalls: 5
      failureRateThreshold: 50
      waitDurationInOpenState: 10s
      permittedNumberOfCallsInHalfOpenState: 3
      automaticTransitionFromOpenToHalfOpenEnabled: true
  instances:
    paymentService:
      baseConfig: default
      failureRateThreshold: 30
      waitDurationInOpenState: 5s

Sentinel 熔断规则（Java 代码动态配置）：

// 定义熔断规则
DegradeRule rule = new DegradeRule("paymentService")
    .setGrade(RuleConstant.DEGRADE_GRADE_RT)   // 按 RT 熔断
    .setCount(200)                              // 平均 RT > 200ms
    .setTimeWindow(10)                          // 熔断时长 10s
    .setMinRequestAmount(5)                     // 最小请求数
    .setStatIntervalMs(1000);                   // 统计窗口 1s

DegradeRuleManager.loadRules(Collections.singletonList(rule));