[AOP] 7. 一些自定义的Aspect - Circuit Breaker

Circuit Breaker(断路器)模式

关于断路器模式是在微服务架构/远程调用环境下经常被使用到的一个模式。它的作用一言以蔽之就是提高系统的可用性，在出现的问题通过服务降级的手段来保证系统的整体可用，而不至于因为部分问题导致整个系统不可用。

用下面这张图可以很好的说明它能够解决的问题：

图片引用自参考资料1。

其中从client和supplier可以分别理解成调用者和远程方法。在没有Circuit Breaker这个组件之前，两者是直接发生交互的，因此当远程方法不可用时，调用者这边可能会阻塞或者失败。由于在微服务架构/远程调用环境下，方法调用之间往往都有依赖性，因此当本次方法调动失败后有可能会影响到后续的业务，从而层层失败(Cascading Failures)导致整个系统的不可用。

通过引入断路器模式(即图中的Circuit Breaker组件)，让它负责Client和远程资源的调用和协调。当调用正常的时候，并不会感觉到断路器的存在，然而当调用发生异常，比如连续性的Timeouts，这个时候断路器会被触发(也就是图中的trip)，被触发后的断路器处于打开(Open)的状态，此时由Client发起的调用请求会被断路器拒绝，完成服务的降级。

降级后的返回值因应用场景而异，如果能够有默认值的情况可以返回给调用方默认值。比如在一个购物网站中，会根据用户的浏览记录动态地推荐相关产品，如果这个动态推荐的服务暂时不可用，那么可以考虑推荐一些默认的畅销产品，这些结果一般会存放在缓存中，因此也不需要消耗什么计算资源。如果没有的话可以提示调用者流量过大，请稍后重试。就像每逢双11零点的时候经常会被各大购物网站拒绝访问一样。

希望通过以上的解释，能够大概说明Circuit Breaker模式的意图。更多信息可以查看参考资料的1和2。同时，在业界也有一些厂商针对这个模式有一些开源工具，比如Netflix的Hystrix项目，这个项目也被Spring整合到其Spring Cloud微服务技术栈中。

和Retry的区别

在上一篇文章中我们讨论了如何使用Retry机制来处理调用中可能出现的失败，Retry和Circuit Breaker尤其共通之处：

• 都涉及到对于目标方法的多次调用
• 都有阈值的概念(重试次数vs断路前的失败次数)

但是Retry机制尤其自身的问题，比如：

• 当服务不可用时容易堆积大量调用
• 服务再次可用的时候容易被大量的堆积请求再次弄崩
• 策略上不够灵活

以上问题的症结在于重试机制没有办法去区分服务是暂时不可用(随机性的网络异常)还是真的不可用(服务挂了)，也许通过区分异常类型可以判断，但是多个调用线程的重试是彼此独立的，并没有一个统一的管控方(比如Circuit Breaker)进行协调。这就导致在服务确实不可用的时候，调用还是会发起请求，哪怕重试的次数因为异常类型的缘故不那么多。

而使用断路器时，它能够根据情况服务状况调整请求数量，比如在服务不可用的时候能够大量地减少请求数量。并且断路器本身会根据业务性质实现一些恢复策略，比如断路器开启30秒后进行重试，如果调用成功则关闭断路器等等。

下面，我们就来看看如何通过AOP实现Circuit Breaker模式。

Aspect实现

目标业务方法(可以考虑成远程调用)

@Service
@Scope("prototype")
public class CircuitBreakerService {
   

  private int counter = 0;

  @CircuitBreaker
  public int service() {
    if (counter++ < 1) {
      throw new RuntimeException("服务不可用");
    }

    return 1;
  }

}

以上的service方法便是目标业务方法了，里面一般会包含远程调用。这里为了模拟远程调用出现的问题，在初次调用的时候会抛出RuntimeException，第二次调用的时候返回正常结果。

标记注解

@CircuitBreaker注解用来标注业务方法作为Pointcut的定位方式，目前注解只是一个Marker Annotation：

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface CircuitBreaker {
   

}

Aspect

@Component
@Scope("prototype")
@Aspect("perthis(com.rxjiang.aop.