这个简单的断路器避免了在电路打开时进行调用，但是当一切恢复正常时需要外部干预来重置它。对于建筑物中的断路器，这是一种合理的方法，但是对于软件中断路器，我们可以让断路器本身检测底层调用是否可以继续。我们可以通过在适当的间隔之后再次尝试被保护调用来实现这种自重置行为，成功时则重置断路器。

创建这种断路器意味着需要为重置尝试添加一个阈值，并设置一个变量来保存上次错误时间。

class ResetCircuitBreaker．．．

def initialize ＆block

＠circuit ＝ block

＠invocation＿timeout ＝ 0．01

＠failure＿threshold ＝ 5

＠monitor ＝ BreakerMonitor．new

＠reset＿timeout ＝ 0．1

reset

end

def reset

＠failure＿count ＝ 0

＠last＿failure＿time ＝ nil

＠monitor．alert ：reset＿circuit

end

现在出现了第三种状态—半开放状态—这意味着线路已经准备好进行试验性的真实调用，看看问题是否已经修复。

class ResetCircuitBreaker．．．

def state

case

when （＠failure＿count ＞＝ ＠failure＿threshold） ＆＆

（Time．now － ＠last＿failure＿time） ＞ ＠reset＿timeout

：half＿open

when （＠failure＿count ＞＝ ＠failure＿threshold）

：open

else

：closed

end

end

在半打开状态下的试验性调用，如果成功，将重置断路器；如果失败，将重启超时设置。

class ResetCircuitBreaker．．．

def call args

case state

when ：closed， ：half＿open

begin

do＿call args

rescue Timeout：：Error

record＿failure

raise ＄！

end

when ：open

raise CircuitBreaker：：Open

else

raise ＂Unreachable＂

end

end

def record＿failure

＠failure＿count ＋＝ 1

＠last＿failure＿time ＝ Time．now

＠monitor．alert（：open＿circuit） if ：open ＝＝ state

end

这个例子很简单，在实践中断路器提供了更多的特性和参数化设置。它们通常会防止受保护调用可能引发的一系列错误，比如网络连接失败。并不是所有的错误都应该跳闸，有些是反映正常的故障，需要作为常规逻辑的一部分进行处理。

由于流量很大，您可能会遇到大量调用等待超时的问题。由于远程调用通常很慢，所以最好将每个调用放在不同的线程上，使用future或promise来处理返回的结果。从线程池中提取这些线程，在线程池耗尽时安排线路断开。

这个例子展示了一种简单的方法来跳闸—在成功调用时重置计数。一种更复杂的方法可能是查看错误的频率，比如，一旦达到50％的失败率，就会跳闸。您还可以为不同的错误设置不同的阈值，例如超时阈值为10，连接失败阈值为3。

我所展示的示例是用于同步调用的断路器，但是断路器对于异步通信也很有用。这里的一种常见技术是将所有请求放在一个队列中，服务提供者以一定速度消费该队列—这是一种避免服务器过载的有用技术。在这种情况下，当队列被填满时，线路就会断开。

就其本身而言，断路器有助于减少在可能失败的操作中占用资源。您可以避免客户端的超时等待，而断开的线路也可以避免给处于困境的服务器增加负载。我在这里讨论的是远程调用，这是使用断路器的常见情况，但是它们可以用于任何需要保护系统部件免受其他部件故障影响的情况。

断路器是一个有价值的监测点。断路器中状态的任何更改都应该被记录，断路器应该显示其状态的详细信息，以便进行更深入的监控。断路器的行为通常是一个很好的来源，来警告环境中更深层次的问题。操作人员应该能够跳闸或复位断路器。

断路器本身是有价值的，但使用断路器的客户端需要对断路器故障做出反应。与任何远程调用一样，您需要考虑在发生故障时应该做什么。它是否会使你正在进行的操作失败，或者是否还有其他的解决办法？比如信用卡授权可以放在队列中稍后处理；通过显示一些可以接受的旧数据来缓解无法获取某些数据的问题。