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

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

java开源商城零碎

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

1. 为什么须要断路器

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

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

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

2. Hystrix

2.1什么是Hystrix

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

2.2 Hystrix简略案例

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

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

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

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

2.2.3 在 TestProductController中退出断路逻辑

@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";    }

2.3 总结

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

3. Resilience4j

3.1 简介

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

3.2 模块形成

Resilience4j提供了几个外围模块：

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

3.3 设置Maven

引入依赖

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

3.4 断路器（CircuitBreaker）

请留神，应用此性能，咱们须要引入上文的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事件
自定义谓词，用于评估异样是否为失败，从而进步失败率

3.5 限流器

此性能须要应用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。

咱们能够配置如下参数：

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

3.6 舱壁隔离

这里须要引入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();

咱们能够配置以下设置：

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

3.7 重试

须要引入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));}

咱们还能够配置：

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

3.8 缓存

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

javax.cache.Cache cache = ...; // Use appropriate cache hereCache<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类型。

3.9 限时器

对于此模块，咱们须要引入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);

3.10 附加模块

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

一些比拟常见的集成是：

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

3.11 总结

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

4. Sentinel

4.1 什么是Sentinel?

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

4.2 Sentinel 具备以下个性:

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

4.3 工作机制：

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

4.4 Sentinel总结：

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

5.总结

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

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

java开源商城零碎