微服务架构中，一次用户请求往往要串联多个下游依赖。当某个下游服务响应变慢或错误率飙升时，如果上游仍然持续发起调用，线程池和连接池会被逐渐占满，最终拖垮整个服务链路。熔断器模式通过在失败达到一定条件时主动切断调用，让系统快速失败并给下游喘息的机会。但熔断阈值该怎么设置，是静态固定值好，还是根据错误率与慢调用率动态计算更合理？本文围绕这个问题，用Ruby实现一个基于滑动窗口统计的动态熔断器。
熔断器的三种状态与阈值的意义
经典的熔断器模型包含三个状态：关闭、打开和半开。关闭状态下请求正常放行，同时持续统计调用结果；当统计指标突破阈值时切换到打开状态，此时所有请求直接被拒绝，不再真正打到下游；经过一段冷却时间后进入半开状态，放行少量探测请求，如果探测成功则恢复关闭，失败则重新打开。
阈值的意义在于回答一个核心问题：什么时候认定下游已经不可用。最简单的做法是连续失败N次就熔断，比如连续5次超时。这种方案实现简单，但在低流量场景下会误判，5次失败可能只是5个孤立请求恰好赶上网络抖动；而在高流量场景下又不够敏感，可能要等上千个请求失败后才触发，白白浪费了资源并放大了故障影响。
更合理的思路是基于比例而非次数做判断。错误率定义为失败请求数除以总请求数，慢调用率定义为耗时超过阈值的请求数除以总请求数。只要设置一个最小样本量门槛，比如窗口内至少20个请求才参与统计，就能有效避免低流量误判。同时慢调用率指标非常关键，因为下游过载时往往不是立刻报错，而是响应时间先恶化，慢调用堆积会逐渐占满上游资源，等到错误率上升时可能已经晚了。
用Ruby实现滑动窗口统计
动态熔断的基础是准确的统计数据。我们用一个固定长度的环形数组记录最近N次调用的结果，每次调用记录两个信息：是否成功、是否属于慢调用。为了保证线程安全，读写操作需要加锁。下面是一个简洁的滑动窗口实现。
require 'monitor'
class SlidingWindow
def initialize(size: 100, slow_threshold_ms: 800)
@size = size
@slow_threshold_ms = slow_threshold_ms
@records = Array.new(size)
@index = 0
@count = 0
@lock = Monitor.new
end
# 记录一次调用结果，duration_ms为本次耗时
def record(duration_ms:, success:)
@lock.synchronize do
@records[@index] = { duration: duration_ms, success: success }
@index = (@index + 1) % @size
@count += 1 unless @count == @size
end
end
def error_rate
stats[0]
end
def slow_call_rate
stats[1]
end
def total
@count
end
private
def stats
total_count = failures = slow_calls = 0
@lock.synchronize do
@records.first(@count).each do |r|
next unless r
total_count += 1
failures += 1 unless r[:success]
slow_calls += 1 if r[:duration] >= @slow_threshold_ms
end
end
return 0.0, 0.0 if total_count.zero?
[failures.to_f / total_count, slow_calls.to_f / total_count]
end
end这个实现把每次调用的耗时和成败都存进环形缓冲区，统计时一次性遍历计算两个比率。相比只记成功失败的做法，保留耗时数据的好处是后续可以灵活调整慢调用判定线，甚至画出响应时间的分布图，而不需要重新采集数据。如果并发量特别大，也可以按时间片聚合，比如每秒汇总一次，只保留最近60秒的聚合桶，把统计开销从O(N)降到O(桶数)。
基于双指标动态判断的熔断器
有了统计数据，熔断器的核心判断逻辑就清晰了：当样本量达到门槛，且错误率或慢调用率任一突破各自阈值时，就打开熔断。打开状态下拒绝请求并计数，冷却期结束后放行探测请求，根据探测结果决定恢复还是继续熔断。
class CircuitBreaker
STATES = [:closed, :open, :half_open].freeze
def initialize(window:,
error_rate_threshold: 0.5,
slow_rate_threshold: 0.8,
min_calls: 20,
open_duration: 30)
@window = window
@error_rate_threshold = error_rate_threshold
@slow_rate_threshold = slow_rate_threshold
@min_calls = min_calls
@open_duration = open_duration
@state = :closed
@opened_at = nil
@lock = Monitor.new
end
def call
@lock.synchronize do
check_state_transition
raise CircuitOpenError if @state == :open
end
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
begin
result = yield
duration = (Process.clock_gettime(Process::CLOCK_MONOTONIC) - start) * 1000
@window.record(duration_ms: duration, success: true)
result
rescue => e
duration = (Process.clock_gettime(Process::CLOCK_MONOTONIC) - start) * 1000
@window.record(duration_ms: duration, success: false)
raise e
end
end
private
def check_state_transition
case @state
when :open
# 冷却期结束，进入半开状态放行探测请求
if Time.now - @opened_at >= @open_duration
@state = :half_open
end
when :half_open
# 探测成功则关闭，失败则重新打开，简化为按窗口数据判断
if @window.total >= @min_calls &&
@window.error_rate <= @error_rate_threshold &&
@window.slow_call_rate <= @slow_rate_threshold
@state = :closed
end
when :closed
if @window.total >= @min_calls &&
(@window.error_rate > @error_rate_threshold ||
@window.slow_call_rate > @slow_rate_threshold)
@state = :open
@opened_at = Time.now
end
end
end
end
class CircuitOpenError < StandardError; end使用方式非常直接，把下游调用包在熔断器的block里即可。调用方可以捕获CircuitOpenError做降级处理，比如返回缓存的旧数据、走备用服务，或者直接给用户一个友好的失败提示。
breaker = CircuitBreaker.new(window: SlidingWindow.new(size: 100))
begin
response = breaker.call { Faraday.get('http://ipipp.com/api/orders') }
puts response.body
rescue CircuitOpenError
# 熔断打开，走降级逻辑
puts '使用本地缓存数据'
rescue Faraday::Error
puts '请求失败，提示用户稍后重试'
end阈值调优与生产环境建议
阈值设置没有万能公式，需要结合业务特性反复调整。错误率阈值一般设在30%到60%之间：设得太低，正常的偶发失败就会触发熔断，影响可用性；设得太高，故障已经蔓延才反应。慢调用率阈值通常可以设得更宽容一些，比如70%到90%，因为慢调用不一定意味着故障，可能只是下游在做批量任务。慢调用的耗时判定线要参考下游的正常P99响应时间，一般取正常P99的2到3倍比较稳妥，比如下游平时P99是300毫秒，慢调用线可以设在800毫秒左右。
窗口大小和最小样本量是另一对需要权衡的参数。窗口越大统计越平滑，但对突发故障的反应越迟钝；窗口太小则容易被抖动干扰。实践中常见的组合是最近100次调用或最近10秒，最小样本量取窗口的10%到20%。对于秒杀、大促这类流量突增场景，建议改用基于时间片聚合的窗口，并适当调低最小样本量，让熔断器能更快响应。
几个生产环境的补充建议：第一，熔断打开时一定要记录日志和告警，熔断本身是重要的可观测性信号，说明下游有问题，运维需要第一时间知道；第二，半开状态的探测请求最好控制在很小的比例，避免下游刚恢复就被探测流量再次打垮；第三，对不同的下游依赖使用独立的熔断器实例，互不影响，避免一个依赖的熔断状态污染其他依赖的统计；第四，注意熔断器自身的锁竞争，高并发下Monitor的同步开销不可忽略，可以考虑用原子操作或分片统计来优化。如果不想自己造轮子，也可以评估社区方案，比如集成了Resilience4j思想的Ruby移植库，或者在网关层用Envoy的熔断能力，把保护逻辑从应用代码中剥离出来。
总的来说，基于错误率与慢调用率的双指标动态熔断，比简单的连续失败计数更贴合真实故障的表现形态。慢调用率作为前置信号尤其有价值，它能在下游彻底崩溃之前就触发保护。结合滑动窗口统计、最小样本量过滤和半开探测恢复机制，Ruby实现的这套熔断器代码不到百行，完全可以直接嵌入现有项目，为服务调用链路加一道可靠的保险。