SpringCloud升级之路2020.0.x版-31. FeignClient 实现断路器以及线程隔离限流的思路

本系列代码地址：https://github.com/JoJoTec/spring-cloud-parent

在前面一节，我们实现了 FeignClient 粘合 resilience4j 的 Retry 实现重试。细心的读者可能会问，为何在这里的实现，不把断路器和线程限流一起加上呢：

@Bean
public FeignDecorators.Builder defaultBuilder(
        Environment environment,
        RetryRegistry retryRegistry
) {
    //获取微服务名称
    String name = environment.getProperty("feign.client.name");
    Retry retry = null;
    try {
        retry = retryRegistry.retry(name, name);
    } catch (ConfigurationNotFoundException e) {
        retry = retryRegistry.retry(name);
    }

    //覆盖其中的异常判断，只针对 feign.RetryableException 进行重试，所有需要重试的异常我们都在 DefaultErrorDecoder 以及 Resilience4jFeignClient 中封装成了 RetryableException
    retry = Retry.of(name, RetryConfig.from(retry.getRetryConfig()).retryOnException(throwable -> {
        return throwable instanceof feign.RetryableException;
    }).build());

    return FeignDecorators.builder().withRetry(
            retry
    );
}

主要原因是，这里增加断路器以及线程隔离，其粒度是微服务级别的，这样的坏处是：

• 微服务中只要有一个实例一直异常，整个微服务就会被断路
• 微服务只要有一个方法一直异常，整个微服务就会被断路
• 微服务的某个实例比较慢，其他实例正常，但是轮询的负载均衡模式导致线程池被这个实例的请求堵满。由于这一个慢实例，倒是整个微服务的请求都被拖慢

回顾我们想要实现的微服务重试、断路、线程隔离

请求重试

来看几个场景：

1.在线发布服务的时候，或者某个服务出现问题下线的时候，旧服务实例已经在注册中心下线并且实例已经关闭，但是其他微服务本地有服务实例缓存或者正在使用这个服务实例进行调用，这时候一般会因为无法建立 TCP 连接而抛出一个 java.io.IOException，不同框架使用的是这个异常的不同子异常，但是提示信息一般有 connect time out 或者 no route to host。这时候如果重试，并且重试的实例不是这个实例而是正常的实例，就能调用成功。如下图所示：

2.当调用一个微服务返回了非 2XX 的响应码：

a) 4XX：在发布接口更新的时候，可能调用方和被调用方都需要发布。假设新的接口参数发生变化，没有兼容老的调用的时候，就会有异常，一般是参数错误，即返回 4XX 的响应码。例如新的调用方调用老的被调用方。针对这种情况，重试可以解决。但是为了保险，我们对于这种请求已经发出的，只重试 GET 方法（即查询方法，或者明确标注可以重试的非 GET 方法），对于非 GET 请求我们不重试。如下图所示：

b) 5XX：当某个实例发生异常的时候，例如连不上数据库，JVM Stop-the-world 等等，就会有 5XX 的异常。针对这种情况，重试也可以解决。同样为了保险，我们对于这种请求已经发出的，只重试 GET 方法（即查询方法，或者明确标注可以重试的非 GET 方法），对于非 GET 请求我们不重试。如下图所示：

3.断路器打开的异常：后面我们会知道，我们的断路器是针对微服务某个实例某个方法级别的，如果抛出了断路器打开的异常，请求其实并没有发出去，我们可以直接重试。

4.限流异常：后面我们会知道，我们给调用每个微服务实例都做了单独的线程池隔离，如果线程池满了拒绝请求，会抛出限流异常，针对这种异常也需要直接重试。

这些场景在线上在线发布更新的时候，以及流量突然到来导致某些实例出现问题的时候，还是很常见的。如果没有重试，用户会经常看到异常页面，影响用户体验。所以这些场景下的重试还是很必要的。对于重试，我们使用 resilience4j 作为我们整个框架实现重试机制的核心。

微服务实例级别的线程隔离

再看下面一个场景：

微服务 A 通过同一个线程池调用微服务 B 的所有实例。如果有一个实例有问题，阻塞了请求，或者是响应非常慢。那么久而久之，这个线程池会被发送到这个异常实例的请求而占满，但是实际上微服务 B 是有正常工作的实例的。

为了防止这种情况，也为了限制调用每个微服务实例的并发（也就是限流），我们使用不同线程池调用不同的微服务的不同实例。这个也是通过 resilience4j 实现的。

微服务实例方法粒度的断路器

如果一个实例在一段时间内压力过大导致请求慢，或者实例正在关闭，以及实例有问题导致请求响应大多是 500，那么即使我们有重试机制，如果很多请求都是按照请求到有问题的实例 -> 失败 -> 重试其他实例，这样效率也是很低的。这就需要使用断路器。

在实际应用中我们发现，大部分异常情况下，是某个微服务的某些实例的某些接口有异常，而这些问题实例上的其他接口往往是可用的。所以我们的断路器不能直接将这个实例整个断路，更不能将整个微服务断路。所以，我们使用 resilience4j 实现的是微服务实例方法级别的断路器（即不同微服务，不同实例的不同方法是不同的断路器）

使用 resilience4j 的断路器和线程限流器

下面我们先来看下断路器的相关配置，来理解下 resilience4j 断路器的原理:

CircuitBreakerConfig.java

//判断一个异常是否记录为断路器失败，默认所有异常都是失败，这个相当于黑名单
private Predicate recordExceptionPredicate = throwable -> true;
//判断一个返回对象是否记录为断路器失败，默认只要正常返回对象就不认为是失败
private transient Predicate