CircuitBreaker 断路器
服务熔断是为了保护我们的服务，比如当某个服务出现问题的时候，控制打向它的流量，让它有时间去恢复，或者限制一段时间只能有固定数量的请求打向这个服务。这些都是保护措施。我在实际工作中也确实遇到过，数据库出现问题了，进而导致Web服务出现问题了，导致不依赖数据库的服务也出现问题了，出现一连串问题。 这次学习《玩转 Spring 全家桶》，丁雪丰老师给了使用resilience4j的例子。 丁老师的例子是2019年的，这个框架已经修改了些方法，所以我自己也花了些时间来理解了它的用法。现将过程记录下来。
首先POM文件引入
<dependency>
<groupId>io.github.resilience4j</groupId>
<artifactId>resilience4j-spring-boot2</artifactId>
<version>2.0.2</version>
</dependency>
接着改造之前的Controller方法
@RestController
@RequestMapping("/customer")
@Slf4j
public class BookController {
@Autowired
private BookService bookService;
private CircuitBreaker circuitBreaker;
public BookController(CircuitBreakerRegistry registry) {
circuitBreaker = registry.circuitBreaker("menu");
}
@GetMapping("/menu")
public List<Book> readMenu() {
Supplier<List<Book>> supplier = () -> bookService.getAll();
circuitBreaker.getEventPublisher()
.onEvent(event -> log.info(event.toString()));
try{
return circuitBreaker.executeSupplier(supplier);
}
catch (Exception ex)
{
log.error(ex.getMessage());
return Collections.emptyList();
}
}
}
不同的地方就是引入了CircuitBreaker， 然后使用它将我们的方法“bookService.getAll()”包起来了。
然后在配置文件中添加如下的配置
resilience4j.circuitbreaker.backends.menu.failure-rate-threshold=50
resilience4j.circuitbreaker.backends.menu.wait-duration-in-open-state=60000
resilience4j.circuitbreaker.backends.menu.sliding-window-size=5
resilience4j.circuitbreaker.backends.menu.permitted-number-of-calls-in-half-open-state=2
resilience4j.circuitbreaker.backends.menu.minimum-number-of-calls=2
稍微解释一下这里的配置
failure-rate-threshold=50是说失败率超过50%就熔断，
wait-duration-in-open-state= 60000，是说熔断后等待60S才允许再次调用。
sliding-window-size =5 可以理解为5个请求统计一次，
permitted-number-of-calls-in-half-open-state = 2是说进入半开的状态的时候，还允许请求多少个。
minimum-number-of-calls=2是说最少有多少个请求才开始统计。 这里的参数都是我为了实验设置的，实际情况根据需要进行调整。参数比较多，具体可以参加官方文档
https://resilience4j.readme.io/docs/circuitbreaker
我们来看下实际的效果通过浏览器访问，
首先我们现打开BookService，让它有一次成功的请求，日志会输出
CircuitBreaker 'menu' recorded a successful call.
然后我们将BookService关闭，让它请求失败，日志会输出如下
CircuitBreaker 'menu' recorded an error: 'feign.RetryableException: Connection refused: no further information executing GET http://bookshop-service/book/getAll'. Elapsed time: 2050 ms
CircuitBreaker 'menu' exceeded failure rate threshold. Current failure rate: 50.0
CircuitBreaker 'menu' changed state from CLOSED to OPEN
可以看到断路器已经打开了，
接着我们继续访问会出现，
CircuitBreaker 'menu' recorded a call which was not permitted.
这个时候请求不会打到BookService上面了。就算这个时候我们的BookService恢复正常。
等待60s后进入半Open的状态
CircuitBreaker 'menu' changed state from OPEN to HALF_OPEN
这个时候恢复BookService正常，我们请求也会正常响应了
CircuitBreaker 'menu' recorded a successful call
多请求几次，断路器就从HALF_OPEN变成了CLOSED
CircuitBreaker 'menu' changed state from HALF_OPEN to CLOSED
这里给一个官方的状态图来说明
断路器有三个状态： CLOSED， OPEN， HALF_OPEN。
- CLOSED是最开始的状态，也就是关闭状态，流量可以正常通过，
- 当失败比率超过threshold后，断路器打开， 变成OPEN 打开后流量不可以通过；
- 等待一定的时间后，断路器进入半开状态 HALF_OPEN, 这个时候如果失败率低于阈值，断路器进入CLOSED状态，如果超过阈值，断路器继续保证OPEN，再等待，如此往复。
断路器现在还支持设置慢请求，使用起来还是比较方便。对于参数的设置如果不是很理解，可以通过单元测试的方法来加深对它的理解。这里参考https://github.com/eugenp/tutorials/bl