关于分布式:分布式系统的三个断路器框架的原理和实践

springboot 实战电商我的项目 mall4j（https://gitee.com/gz-yami/mall4j）

java 开源商城零碎

随着微服务的风行，熔断作为其中一项很重要的技术也广为人知。当微服务的运行品质低于某个临界值时，启动熔断机制，暂停微服务调用一段时间，以保障后端的微服务不会因为继续过负荷而宕机。本文介绍了 Hystrix、新一代熔断器 Resilience4j 以及阿里开源的 Sentinel 如何应用。如有谬误欢送指出。

断路器模式源于 Martin Fowler 的 Circuit Breaker 一文。“断路器”自身是一种开关安装，用于在电路上爱护线路过载，当线路中有电器产生短路时，“断路器”可能及时切断故障电路，避免产生过载、发热甚至起火等严重后果。

在分布式架构中，断路器模式的作用也是相似的，当某个服务单元产生故障 (相似用电器产生短路) 之后，通过断路器的故障监控(相似熔断保险丝)，向调用方返回一个谬误响应，而不是长时间的期待。这样就不会使得线程因调用故障服务被长时间占用不开释, 防止了故障在分布式系统中的蔓延。

针对上述问题，断路器是进行实现了断路、线程隔离、流量管制等一系列服务爱护性能的框架。零碎、服务和第三方库的节点，从而对提早和故障提供更弱小的容错能力。

Hystrix 是一款 Netfix 开源的框架，具备依赖隔离，零碎容错降级等性能，这也是其最重要的两种用处，还有申请合并等性能。

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

@EnableCircuitBreaker
public class TestApplication extends SpringBootServletInitializer{public static void main(String[] args) {SpringApplication.run(ApiApplication.class, args);
   }
}

@RequestMapping("/get/{id}")
    @HystrixCommand(fallbackMethod="errorCallBack")   // 测试没有这个数据时，服务降级
  public Object get(@PathVariable("id") long id){Product p= productService.findById(id);
        if(p==null){throw new RuntimeException("查无此商品");
        }
        return p;
    }

    // 指定一个降级的办法
    public Object errorCallBack(@PathVariable("id") long id   ){return id+"不存在,error";}

简略介绍了 Hystrix 工作原理以及简略案例，不过 Hystrix 官网曾经进行开发，就不深刻介绍了。

在 Hystrix 官网曾经进行开发后，Hystrix 官网举荐应用新一代熔断器为 Resilience4j。Resilience4j 是一款轻量级，易于应用的容错库，其灵感来自于 Netflix Hystrix，然而专为 Java 8 和函数式编程而设计。因为库只应用了 Vavr（以前称为 Javaslang），它没有任何其余内部依赖下。相比之下，Netflix Hystrix 对 Archaius 具备编译依赖性，Archaius 具备更多的内部库依赖性，例如 Guava 和 Apache Commons Configuration，如果须要应用 Resilience4j，也无需引入所有依赖，只需抉择你须要的功能模块即可。

Resilience4j 提供了几个外围模块：

 resilience4j-circuitbreaker：电路断开
 resilience4j-ratelimiter：速率限度
 resilience4j-bulkhead：隔板
 resilience4j-retry：主动重试（同步和异步）resilience4j-timelimiter：超时解决
 resilience4j-cache：后果缓存

引入依赖

  <dependency>
         <groupId>io.github.resilience4j</groupId>
         <artifactId>resilience4j-circuitbreaker</artifactId>
         <version>0.13.2</version>
  </dependency>

请留神，应用此性能，咱们须要引入上文的 resilience4j-circuitbreaker 依赖。

该熔断器模式下能够帮忙咱们在近程服务出故障时避免故障级联。

在屡次申请失败后，咱们就认为服务不可用 / 超载，并且对之后的所有申请进行短路解决，这样咱们就能节约系统资源。让咱们看看如何通过 Resilience4j 实现这一指标。

首先，咱们须要定义要应用的设置。最简略的办法是应用默认设置：

CircuitBreakerRegistry circuitBreakerRegistry  = CircuitBreakerRegistry.ofDefaults();

同样也能够应用自定义参数：

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
  .failureRateThreshold(20)
  .ringBufferSizeInClosedState(5)
  .build();

在这里，咱们将 ratethreshold 设置为 20%，并且起码重试 5 次。

而后，咱们创立一个 CircuitBreaker对象，并通过它调用近程服务：

interface RemoteService {int process(int i);
}

CircuitBreakerRegistry registry = CircuitBreakerRegistry.of(config);
CircuitBreaker circuitBreaker = registry.circuitBreaker("my");
Function<Integer, Integer> decorated = CircuitBreaker
  .decorateFunction(circuitBreaker, service::process);

最初，让咱们看看它如何通过 JUnit 测试。

咱们调用服务 10 次。能够验证服务至多调用 5 次，如果有 20% 的失败的状况下，会进行调用。

when(service.process(any(Integer.class))).thenThrow(new RuntimeException());

for (int i = 0; i < 10; i++) {
    try {decorated.apply(i);
    } catch (Exception ignore) {}}

verify(service, times(5)).process(any(Integer.class));

断路器的三种状态：

敞开— 服务失常，不波及短路
关上— 近程服务宕机，所有申请都短路
半开— 进入关上状态一段时间 (依据已配置的工夫量) 后，熔断器容许查看近程服务是否复原

咱们能够配置以下设置：

故障率阈值，高于该阈值时CircuitBreaker 关上
等待时间，用于定义 CircuitBreaker 切换为半开状态之前应放弃关上状态的工夫
当 CircuitBreaker 半开或闭合时，环形缓冲区的大小
解决自定义事件的的监听器 CircuitBreakerEventListener，它解决CircuitBreaker 事件
自定义谓词，用于评估异样是否为失败，从而进步失败率

此性能须要应用 resilience4j-ratelimiter 依赖性。

简略示例：

RateLimiterConfig config = RateLimiterConfig.custom().limitForPeriod(2).build();
RateLimiterRegistry registry = RateLimiterRegistry.of(config);
RateLimiter rateLimiter = registry.rateLimiter("my");
Function<Integer, Integer> decorated
  = RateLimiter.decorateFunction(rateLimiter, service::process);

当初所有对 decorateFunction 的调用都合乎 rate limiter。

咱们能够配置如下参数：

极限刷新工夫
刷新期间的权限限度
默认期待许可期限

这里须要引入 resilience4j-bulkhead 依赖，能够限度对特定服务的并发调用数。

让咱们看一个应用 Bulkhead API 配置并发调用的示例：

BulkheadConfig config = BulkheadConfig.custom().maxConcurrentCalls(1).build();
BulkheadRegistry registry = BulkheadRegistry.of(config);
Bulkhead bulkhead = registry.bulkhead("my");
Function<Integer, Integer> decorated
  = Bulkhead.decorateFunction(bulkhead, service::process);

为了测试，咱们能够调用一个 mock 服务的办法。这种状况下，咱们就确保 Bulkhead 不容许其余任何调用：

CountDownLatch latch = new CountDownLatch(1);
when(service.process(anyInt())).thenAnswer(invocation -> {latch.countDown();
    Thread.currentThread().join();
    return null;
});

ForkJoinTask<?> task = ForkJoinPool.commonPool().submit(() -> {
    try {decorated.apply(1);
    } finally {bulkhead.onComplete();
    }
});
latch.await();
assertThat(bulkhead.isCallPermitted()).isFalse();

咱们能够配置以下设置：

容许的最大并行数
进入饱和舱壁时线程将期待的最大工夫

须要引入 resilience4j-retry 库。能够应用 Retry 调用失败后主动重试：

RetryConfig config = RetryConfig.custom().maxAttempts(2).build();
RetryRegistry registry = RetryRegistry.of(config);
Retry retry = registry.retry("my");
Function<Integer, Void> decorated
  = Retry.decorateFunction(retry, (Integer s) -> {service.process(s);
        return null;
    });

当初，让咱们模仿在近程服务调用期间引发异样的状况，并确保库主动重试失败的调用：

when(service.process(anyInt())).thenThrow(new RuntimeException());
try {decorated.apply(1);
    fail("Expected an exception to be thrown if all retries failed");
} catch (Exception e) {verify(service, times(2)).process(any(Integer.class));
}

咱们还能够配置：

最大尝试次数
重试前的等待时间
自定义函数，用于批改失败后的期待距离
自定义谓词，用于评估异样是否会导致重试调用

cache 模块须要引入 resilience4j-cache 依赖。初始化代码如下：

javax.cache.Cache cache = ...; // Use appropriate cache here
Cache<Integer, Integer> cacheContext = Cache.of(cache);
Function<Integer, Integer> decorated
  = Cache.decorateSupplier(cacheContext, () -> service.process(1));

这里的缓存是通过 JSR-107 Cache 实现实现的，Resilience4j 提供了操作缓存的办法。

请留神，没有用于装璜办法的 API（例如 Cache.decorateFunction（Function）），该 API 仅反对 Supplier 和Callable类型。

对于此模块，咱们须要引入 resilience4j-timelimiter 依赖，能够限度应用 TimeLimiter调用近程服务所破费的工夫。

咱们设置一个TimeLimiter，配置的超时工夫为 1 毫秒以不便测试：

long ttl = 1;
TimeLimiterConfig config
  = TimeLimiterConfig.custom().timeoutDuration(Duration.ofMillis(ttl)).build();
TimeLimiter timeLimiter = TimeLimiter.of(config);

接下来，让咱们调用 Future.get（） 验证 Resilience4j 是否如预期超时：

Future futureMock = mock(Future.class);
Callable restrictedCall
  = TimeLimiter.decorateFutureSupplier(timeLimiter, () -> futureMock);
restrictedCall.call();

verify(futureMock).get(ttl, TimeUnit.MILLISECONDS);

咱们也能够将其与断路器（CircuitBreaker）联合应用：

Callable chainedCallable
  = CircuitBreaker.decorateCallable(circuitBreaker, restrictedCall);

Resilience4j 还提供了许多附加的功能模块，可简化其与风行框架和库的集成。

一些比拟常见的集成是：

Spring Boot – resilience4j-spring-boot模块
Ratpack – Resilience4j-ratpack模块
Retrofit – resilience4j-Retrofit 模块
Vertx – Resilience4j-vertx模块
Dropwizard – Resilience4j-metrics模块
Prometheus – resilience4j-prometheus模块

通过上文咱们理解了 Resilience4j 库的各个方面的简略应用，以及如何应用它来解决服务器间通信中的各种容错问题。Resilience4j 的源码能够在 GitHub 上找到。

Sentinel 是面向分布式服务架构的轻量级流量管制组件，由阿里开源，次要以流量为切入点，从限流、流量整形、熔断降级、零碎负载爱护等多个维度来保障微服务的稳定性。

丰盛的利用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的外围场景，例如秒杀（即突发流量管制在零碎容量能够接受的范畴）、音讯削峰填谷、集群流量管制、实时熔断上游不可用利用等。
齐备的实时监控：Sentinel 同时提供实时的监控性能。您能够在控制台中看到接入利用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运行状况。
宽泛的开源生态：Sentinel 提供开箱即用的与其它开源框架 / 库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只须要引入相应的依赖并进行简略的配置即可疾速地接入 Sentinel。
欠缺的 SPI 扩大点：Sentinel 提供简略易用、欠缺的 SPI 扩大接口。您能够通过实现扩大接口来疾速地定制逻辑。例如定制规定治理、适配动静数据源等。

对支流框架提供适配或者显示的 API，来定义须要爱护的资源，并提供设施对资源进行实时统计和调用链路剖析。
依据预设的规定，联合对资源的实时统计信息，对流量进行管制。同时，Sentinel 提供凋谢的接口，不便您定义及扭转规定。
Sentinel 提供实时的监控零碎，不便您疾速理解目前零碎的状态。

Sentinel 是面向分布式服务架构的高可用流量防护组件，作为阿里的熔断中间件，Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的外围场景，对于流量防护的高可用、稳定性方面是很突出的。

三种支流熔断中间件的性能比照，如表所示：

springboot 实战电商我的项目 mall4j（https://gitee.com/gz-yami/mall4j）

java 开源商城零碎

关于分布式:分布式系统的三个断路器框架的原理和实践

分布式系统的三个断路器框架的原理和实际

1. 为什么须要断路器

2. Hystrix

2.1 什么是 Hystrix

2.2 Hystrix 简略案例

2.2.1 新建一个 hystrix 工程引入依赖

2.2.2 在启动类的上加上注解 @EnableCircuitBreaker // 启用断路器

2.2.3 在 TestProductController 中退出断路逻辑

2.3 总结

3. Resilience4j

3.1 简介

3.2 模块形成

3.3 设置 Maven

3.4 断路器（CircuitBreaker）

3.5 限流器

3.6 舱壁隔离

3.7 重试

3.8 缓存

3.9 限时器

3.10 附加模块

3.11 总结

4. Sentinel

4.1 什么是 Sentinel?

4.2 Sentinel 具备以下个性:

4.3 工作机制：

4.4 Sentinel 总结：

5. 总结