熔断器模式中，半开状态是整个恢复流程的转折点。关闭状态下所有请求正常放行，打开状态下请求直接快速失败，而半开状态则允许少量试探请求通过，通过观察这些试探请求的结果来决定是彻底恢复还是继续熔断。半开试探的成功判定方法直接影响系统能否安全地重新接入下游服务，因此需要单独设计并实现。
熔断器状态流转与半开试探的触发条件
熔断器通常包含关闭、打开、半开三种状态。在关闭状态时，系统正常累计失败次数，一旦失败次数达到预设阈值，状态切换为打开。打开状态会持续一段时间，这段时间内所有请求都会被直接拒绝，避免对故障服务造成更大压力。当打开状态的持续时间超过预设的恢复超时时间后，熔断器进入半开状态。
半开状态的核心限制是只允许极少数请求通过，通常是一个或两个。这些请求被称为试探请求，它们真实地调用下游依赖服务，但数量被严格控制。试探请求的结果将成为状态切换的依据：如果判定为成功，熔断器认为服务已经恢复，切换回关闭状态并重置失败计数；如果判定为失败，则立即切回打开状态，重新开始冷却计时。
成功判定方法在半开状态中扮演着守门人的角色。它不能只看网络请求是否返回，还需要区分HTTP状态码、业务错误码、响应时间等多种因素。如果判定过松，可能在一个尚未完全恢复的服务上重新放开全部流量；如果判定过严，则会导致服务恢复过程被拉长，影响整体可用性。因此在Ruby实现中，应当将判定逻辑抽象出来，并允许按实际场景配置。
Ruby实现半开试探成功判定方法
下面先实现一个基础的熔断器类，负责状态管理和失败计数。这个类使用Mutex来保证多线程环境下的状态一致性，避免并发请求同时修改状态导致竞态条件。
class CircuitBreaker
attr_reader :state
def initialize(failure_threshold: 5, recovery_timeout: 60, half_open_max: 1)
@state = :closed
@failure_count = 0
@failure_threshold = failure_threshold
@recovery_timeout = recovery_timeout
@half_open_max = half_open_max
@half_open_trials = 0
@last_failure_time = nil
@mutex = Mutex.new
end
def allow_request?
@mutex.synchronize do
case @state
when :closed
true
when :open
if Time.now - @last_failure_time >= @recovery_timeout
@state = :half_open
@half_open_trials = 0
true
else
false
end
when :half_open
if @half_open_trials < @half_open_max
@half_open_trials += 1
true
else
false
end
end
end
end
def record_success
@mutex.synchronize do
if @state == :half_open
@state = :closed
@failure_count = 0
@half_open_trials = 0
elsif @state == :closed
@failure_count = 0
end
end
end
def record_failure
@mutex.synchronize do
@failure_count += 1
@last_failure_time = Time.now
if @state == :half_open || @failure_count >= @failure_threshold
@state = :open
@half_open_trials = 0
end
end
end
end
在allow_request?方法中，半开状态会判断当前已经放行的试探请求数量是否小于half_open_max，只有未达到上限时才放行新的请求，否则直接返回false。这样可以在不彻底拒绝的情况下，精确控制对下游服务的探测压力。当试探请求成功后调用record_success，只有在半开状态下成功才会将状态切回关闭，并清空失败计数。如果处于关闭状态，则只是将失败计数归零，不会产生副作用。
接下来需要单独实现一个成功判定模块，用来根据响应结果判断试探请求是否成功。这个模块可以独立于熔断器类，方便替换不同判定策略。
module SuccessJudge
# 可配置的HTTP状态码上限
MAX_HTTP_STATUS = 499
# 配置业务错误码集合
BUSINESS_ERROR_CODES = %w[E001 E002 E003]
def self.success?(response)
return false if response.nil?
status = response.status.to_i
# HTTP 5xx 一律视为失败
return false if status >= 500
# HTTP 4xx 需要结合业务判断，这里默认视为失败
return false if status >= 400
# 解析响应体中的业务错误码
body = parse_body(response.body)
error_code = body.fetch('error_code', nil)
return false if BUSINESS_ERROR_CODES.include?(error_code)
true
end
def self.parse_body(raw_body)
# 简化解析，实际项目中可替换为JSON解析
raw_body || {}
end
end
这个判定模块将成功标准拆分为三个层次：响应对象是否为空、HTTP状态码是否在可接受范围内、业务错误码是否属于已知故障集合。在真实的Ruby服务中，响应对象通常来自HTTP客户端库，例如Faraday或Net::HTTP。解析响应体时可以使用JSON.parse替换掉parse_body中的占位实现。将判定逻辑独立出来后，不同服务可以拥有不同的SuccessJudge实现，而熔断器本身无需改动。
把熔断器和成功判定结合使用时，调用流程如下：请求前先执行allow_request?，如果返回false则直接短路；如果返回true则发起真实请求，拿到响应后根据SuccessJudge.success?的结果调用record_success或record_failure。整个过程清晰可测，也便于后续扩展。
判定策略的边界条件与并发控制
半开状态下最需要警惕的是并发试探请求数量失控。如果多个线程同时进入半开状态，而half_open_max设置得不够严格，就可能同时发出多个探测请求，变相增加下游压力。在上面的实现中，allow_request?使用@mutex.synchronize保证了计数器的原子性，每个线程在修改@half_open_trials之前都必须获得锁，从而避免了超发问题。
仅靠单次试探成功就恢复关闭状态，有时并不够稳妥。如果下游服务处于间歇性故障中，一次成功可能只是运气，紧接着的请求又会失败。为了应对这种情况，可以给半开状态增加连续成功次数要求。例如设置required_success_count = 2，只有连续两次试探都成功后才切换回关闭状态。
class CircuitBreaker
def initialize(failure_threshold: 5, recovery_timeout: 60, half_open_max: 1, required_success_count: 2)
# 其他初始化代码保持不变，这里省略重复部分
@required_success_count = required_success_count
@half_open_success_count = 0
end
def record_success
@mutex.synchronize do
if @state == :half_open
@half_open_success_count += 1
if @half_open_success_count >= @required_success_count
@state = :closed
@failure_count = 0
@half_open_trials = 0
@half_open_success_count = 0
end
elsif @state == :closed
@failure_count = 0
end
end
end
def record_failure
@mutex.synchronize do
@failure_count += 1
@last_failure_time = Time.now
if @state == :half_open
@state = :open
@half_open_trials = 0
@half_open_success_count = 0
elsif @failure_count >= @failure_threshold
@state = :open
end
end
end
end
这段代码对record_success进行了增强：在半开状态下每次成功递增half_open_success_count，只有达到required_success_count时才真正关闭熔断器。同时record_failure在半开状态下会立即重新打开，并且重置连续成功计数，确保一个失败就能阻断不稳定的恢复过程。
另一个容易忽略的边界条件是响应时间。即使HTTP状态码为200，如果响应耗时严重超过正常范围，说明下游服务可能处于过载状态，此时不应判定为成功。可以在SuccessJudge中增加耗时检测，记录请求开始和结束的时间差，如果超过预设阈值则将结果标记为失败。Ruby中可以借助Process.clock_gettime或Time.now计算耗时，逻辑与状态码判断并列即可。
在真实网络服务依赖中的集成建议
将熔断器接入现有HTTP客户端调用时，推荐封装一个中间层。例如在使用Faraday时，编写一个自定义中间件，在call方法中先执行allow_request?，如果返回false则抛出或返回一个预定义的熔断异常；如果返回true则继续调用下游，并在on_complete回调中根据响应调用record_success或record_failure。这样上层业务代码几乎无感知，熔断逻辑被完全隔离。
测试熔断器行为时，可以使用RSpec配合时间模拟工具，例如timecop，固定当前时间来验证打开状态是否在恢复超时后正确进入半开。对于半开成功判定，可以构造不同状态码和业务错误码的假响应对象，断言熔断器状态切换是否符合预期。此外，针对并发场景，可以用多线程压测半开试探数量，确保不会超过half_open_max的限制。
总体而言，半开试探的成功判定不是单一布尔条件，而是一组可配置策略的集合。Ruby的动态特性和丰富的标准库支持让这套逻辑实现起来非常直观。开发者可以根据下游服务的特点调整HTTP状态码范围、业务错误码列表、连续成功次数以及响应时间阈值，把熔断器打磨成真正可靠的容错组件。