背景

分布式架构面临的问题：服务雪崩

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的"扇出"。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

比较经典的就是23年10.23号各大厂的生产故障：语雀、阿里云产品控制台、阿里系大部分产品（淘宝、咸鱼、阿里云盘）崩溃。

如何解决？

出现有问题的节点，快速熔断(快速返回失败处理或者返回默认兜底数据【服务降级】)。

"断路器"本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

相对应的措施就是：

• 服务熔断：类比保险丝，保险丝闭合状态(CLOSE)可以正常使用，当达到最大服务访问后，直接拒绝访问跳闸限电(PEN)，此刻调用方会接受服务降级的处理并返回友好提示
• 服务降级：服务器忙，请稍后再试。不让客户端等待并立刻返回一个友好提示，fallback
• 服务限流：秒杀高并发操作，限制速率
• 服务限时
• 服务预热：一开始放20、30个，后面慢慢增加量100个等等
• 接近实时的监控

以上功能现在市面上可用的是Hystrix，但Hystrix已经停止更新进入维护状态，官方给出最好替代是Resilience4j。

所以推荐使用Resilience4j！

CircuitBreaker

CircuitBreaker的目的是保护分布式系统免受故障和异常，提高系统的可用性和健壮性。

当一个组件或服务出现故障时，CircuitBreaker会迅速切换到开放OPEN状态(保险丝跳闸断电)，阻止请求发送到该组件或服务从而避免更多的请求发送到该组件或服务。这可以减少对该组件或服务的负载，防止该组件或服务进一步崩溃，并使整个系统能够继续正常运行。同时，CircuitBreaker还可以提高系统的可用性和健壮性，因为它可以在分布式系统的各个组件之间自动切换，从而避免单点故障的问题。

Circuit Breaker只是一套规范和接口，落地实现者是Resilience4J。

Resilience4j

Resilience4j 是一个专为函数式编程而设计的轻量级容错库。Resilience4j 提供高阶函数（装饰器），以增强任何功能接口、lambda 表达式或方法引用，包括断路器、速率限制器、重试或隔板。您可以在任何函数接口、lambda 表达式或方法引用上堆叠多个装饰器。优点是您可以选择所需的装饰器，而没有别的。
Resilience4j 2 需要 Java 17。

核心功能

• resilience4j-circuitbreaker：熔断
• resilience4j-ratelimiter：速率限制
• resilience4j-bulkhead： 舱壁
• resilience4j-retry：自动重试（同步和异步）
• resilience4j-timelimiter：超时处理
• resilience4j-cache：结果缓存

还有用于度量的附加模块、Feign、Kotlin、Spring、Ratpack、Vertx、RxJava2 等。

本文主要讲前三个核心功能，其他的功能可用其他组件替代，并不是王牌。

CircuitBreaker 服务熔断+服务降级

断路器有三个普通状态:关闭(CLOSED)、开启(OPEN)、半开(HALFOPEN)，还有两个特殊状态:禁用(DISABLED)、强制开启(FORCED OPEN)。

当熔断器关闭时，所有的请求都会通过熔断器。

• 如果失败率超过设定的阈值，熔断器就会从关闭状态转换到打开状态，这时所有的请求都会被拒绝
• 当经过一段时间后，熔断器会从打开状态转换到半开状态，这时仅有一定数量的请求会被放入，并重新计D算失败率
• 如果失败率超过阈值，则变为心开状态，如果失败率低于阅值，则变为关闭状态

断路器使用滑动窗口来存储和统计调用的结果。你可以选择基于调用数量的滑动窗口或者基于时间的滑动窗口。基于访问数量的滑动窗口统计了最近N次调用的返回结果。居于时间的滑动窗口统计了最近N秒的调用返回结果。

除此以外，熔断器还会有两种特殊状态:DISABLED(始终允许访问)和FORCEDOPEN(始终拒绝访问)。

• 这两个状态不会生成熔断器事件(除状态装换外)，并且不会记录事件的成功或者失败
• 退出这两个状态的唯一方法是触发状态转换或者重置熔断器.
  
  断路器使用滑动窗口来存储和统计调用的结果。你可以选择基于调用数量的滑动窗口或者基于时间的滑动窗口。基于访问数量的滑动窗口统计了最近N次调用的返回结果。居于时间的滑动窗口统计了最近N秒的调用返回结果。

这三个状态互相转换基于两个条件，基于访问数量的滑动窗口和基于时间的滑动窗口

• 访问数量：假设十次调用，有6次调用不成功，就是只有40%的通过率，那么就设定为服务异常，断路器打开，服务熔断，进入服务降级
• 时间：假设最近20s调用，其中有几次调用失败，超过阈值的失败率，就设定服务亚健康状态，断路器打开，服务熔断，进入服务降级

以上都可以通过配置去设定状态之间的转换规则

三种状态转换例子

绿色箭头类似于保险丝，关闭状态时正常使用，a服务请求都可以到b服务中去

打开状态时，保险丝断开，a服务请求无法到达b服务

在打开状态后，隔一段时间会变为半开状态，此时a服务会用几个请求去测试连接b服务，如果这几个请求在一定数量和一定时间内请求到b服务成功的话，就会从半开状态回复到关闭状态，如果是请求失败，那么就会变成打开状态。

参数配置

重点关注这几个属性

案例demo作业

• 6次访间中当执行方法的失败率达到50%时circuitBreaker将进入开启OPEN状态(保险丝跳闸断电)拒绝所有请求。
• 等待5秒后，CircuitBreaker 将自动从开启OPEN状态过渡到半开HALF_OPEN状态，允许一些请求通过以测试服务是否恢复正常
• 如还是异常circuitBreaker 将重新进入开启OPEN状态:如正常将进入关闭CLOSE闭合状态恢复正常处理请求。
  
  可以根据以上参数配置，完成这个demo的流程演示，当做一个小作业。
  代码中如何配置参数以及使用熔断和降级，本文不再赘述，可根据下文相关文献或者其他线上文档进行编码。

BulkHead隔离

Bulkhead(船的)舱壁/(飞机的)隔板
隔板来自造船行业，床仓内部一般会分成很多小隔舱，一旦一个隔舱漏水因为隔板的存在而不至于影响其它隔舱和整体船。

在这里可以理解为，BulkHead就相当于一个九宫格火锅，同时向一个服务发起多个请求，这多个请求就相当于每个格子的菜串串，当一个菜串串里面有虫子时，其他格子的菜品都是好的，不受影响。

特性

Resilience4j提供了两种隔离的实现方式，可以限制并发执行的数量。

SemaphoreBulkhead使用了信号量

信号量舱壁(SemaphoreBulkhead)原理当信号量有空闲时，进入系统的请求会直接获取信号量并开始业务处理。
当信号量全被占用时，接下来的请求将会进入阻塞状态，SemaphoreBukhead提供了一个阻塞计时器，如果阻塞状态的请求在阻塞计时内无法获取到信号量则系统会拒绝这些请求。
若请求在阻塞计时内获取到了信号量，那将直接获取信号量并执行相应的业务处理。

通俗理解：
信号量：相当于一个停车场，停车场只有三个停车位，这三个停车位就是信号量，车子就相当于请求，如果停车位被停满了，那么外面的车子就必须在外面等着，除非有空余停车位，外面车子才能进去。

FixedThreadPoolBulkhead使用了有界队列和固定大小线程池

FixedThreadPoolBukhead的功能与SemaphoreBukhead一样也是用于限制并发执行的次数的，但是二者的实现原理存在差别而且表现效果也存在细微的差别。

FixedThreadPoolBulkhead使用一个周定线程池和一个等待队列来实现舱壁。

当线程池中存在空闲时，则此时进入系统的请求将直接进入线程池开启新线程或使用空闲线程来处理请求。
当线程池中无空闲时时，接下来的请求将进入等待队列，若等待队列仍然无剩余空间时接下来的请求将直接被拒绝，在队列中的请求等待线程池出现空闲时，将进入线程池进行业务处理。
另外:ThreadPoolBulkhead只对CompletableFuture方法有效，所以我们必创建返回CompletableFuture类型的方法)

通俗理解：线程池参数有个最大线程池大小和核心线程池大小，那么可请求的数量就是两者之和，超过这个数量的请求进来，就会被直接拒绝掉。

限流

所谓限流，就是通过对并发访问/请求进行限，或者对一个时间窗口内的请求进行限速，以保护应用系统，一旦达到限制速率则可以拒绝服务、排队或等待、降级等处理。

常见限流算法

• 漏斗算法
  一个固定容量的漏桶，按照设定常量固定速率流出水滴，类似医院打吊针，不管你源头流量多大，我设定匀速流出。
  如果流入水滴超出了桶的容量，则流入的水滴将会溢出了(被丢弃)，而桶容量是不变的。
  缺陷是：面对突发性的流量，无法做出立刻响应，效率低
  

• 令牌桶算法（springcloud默认该算法）
  

• 滚动时间窗口算法
  允许固定数量的请求进入(比如1秒取4个数据相加，超过25值就over)超过数量就拒绝或者排队，等下一个时间段进入。由于是在一个时间间隔内进行限制。如果用户在上个时间间隔结束前请求(但没有超过限制)，同时在当前时间间隔刚开始请求(同样没超过限创)，在各自的时问问隔内，这些请求都是正常的。下图统计了3次。
  但是缺陷是：间隔临界的一段时间内的请求就会超过系统限制，可能导致系统被压垮
  

• 滑动时间窗口算法
  顾名思义，该时间窗口是滑动的。所以，从概念上讲，这里有两个方面的概念需要理解:
  窗口:需要定文窗口的大小
  滑动:需要定义在窗口中滑动的大小，但理论上讲滑动的大小不能超过窗口大小
  滑动窗口算法是把固定时间片进行划分并且随着时间移动，移动方式为开始时间点变为时间列表中的第2个时间点，结束时间点增加一个时间点。不断重复，通过这种方式可以巧妙的避开计数器的临界点的问题。下图统计了5次
  

参数配置

可在yml中配置好后，效果为，指定刷新周期内，限制请求进来的请求数量，超过后服务降级提醒

相关文献

CircuitBreaker官网：https://spring.io/projects/spring-cloud-circuitbreaker#overview
Resilience4j github：https://github.com/resilience4j/resilience4j#1-introduction
Resilience4j 官方文档：https://resilience4j.readme.io/docs/circuitbreaker
中文文档：https://github.com/lmhmhl/Resilience4j-Guides-Chinese/blob/main/index.md

$就先说到这$
$在下Apollo$
$一个爱分享Java、生活的小人物，$
$咱们来日方长，有缘江湖再见，告辞！$