断路器模式——云计算架构常用设计模式

背景

    在一个分布式系统当中，一个应用程序在云中对远程资源和服务进行访问时，可能会由于瞬时故障而引起操作失败，如网络连接缓慢、超时、资源被过度访问或临时不可用。但是，这些故障都可以在短时间内得到修复，因此可以使用重试模式来处理它们。
    同时，也会存在一些很难预见的突发事件而需要更长时间来恢复的情形。如果采用重试模式去完成一个不大可能成功的操作是毫无意义的。另外，如果一个服务非常繁忙，可能会导致系统其他部分的级联故障，因此，最好的方式是引入超时机制，让某些操作立即失败，仅去执行那些可能成功的服务。

目的

    当连接一个远程服务或资源时，修复故障可能会消耗大量时间。使用这种模式可以提高应用程序的稳定性和伸缩性。

方案建议

使用代理实现模仿电路断路器的功能，具体如下：
关闭状态：将一个应用程序的请求路由到一个操作，代理对最近失败的次数进行监控。如果操作失败，则增加失败次数。如果失败次数超过指定失败次数的阈值，代理被设置为打开状态。同时，代理开启一个定时器，当定时器过期时，代理状态变为半打开状态。
打开状态：从应用程序接收到的请求立即失败并返回给应用程序一个异常信息。
半打开状态：允许通过应用程序的部分请求并调用操作方法。如果请求处理成功，就假定之前的故障问题已经被修复，并将断路器的状态置为关闭状态，同时将保存失败次数的计数器重置；如果请求处理失败，则认为故障仍然存在，将断路器恢复为打开状态，然后重启定时器，并设定更长的时间来让系统进行修复异常。

考虑因素

• 异常分类及处理：当一个请求因各种原因失败时，其中的一些类型可能比其他故障更严重，有必要对异常进行分类。另外，当请求失败时，系统可以根据异常的分类来辨识故障恢复可能需要的时间长短，是否能够恢复等信息，同时，系统也可以将对应的故障信息返回给客户，提供更加友好的交互性；
• 日志：断路器可以记录所有的失败及成功请求，供管理员进行监控系统的健康状况；
• 重试操作：当断路器打开的状态下，除了通过一个定时器来决定什么时候切换至半打开状态，可以周期性的ping远程服务或资源来觉得是否已经恢复使用，也可以专门提供用于测试服务健康状态的方式；
• 手动覆盖：需要提供一个可供管理员手动重置的选项，用于强制关闭或启动断路器；
• 并发性：保证断路器可以被大量的并发实例访问，实现方式不能阻塞并发请求，或者增加请求的开销；
• 资源分化：当某类型的资源需要多个提供者时，那么应用一个单独的断路器需要格外小心，避免部分资源可用而部分资源不可用的情况。

适用情况

适用：为阻止一个应用程序尝试执行一个很有可能会失败的操作，如调用远程服务或访问资源。
不适用：处理本地私有资源，可能会增加系统开销，也不适合代理程序的业务逻辑来处理异常。