10.3 Resilience4j 结合微服务
Retry、CircuitBreaker、RateLimiter
10.3.1 Retry
- (1)创建一个 Spring Boot 项目 resilience4j-2 作为 module,添加 web 、eureka client discovery 依赖
- (2)手动添加 Resilience4j 依赖
- (3)把原来的 application.properties 文件删除,新建 application.yml 文件来配置 retry 重试,配置注册到 Eureka
- (4)在 provider 服务中,设置本身会抛异常的接口:
- (5)resilience4j-2 服务中,创建 RestTemplate 请求模板 bean对象,创建 HelloService 和 HelloController 类
在 HelloService 中的 @Retry(name = "retryA")
注解的属性 retryA
是在 application.yml
中配置自定义的策略名;
- (6)启动 Eureka 服务端、provider 服务和 resilience4j-2 服务,访问 http://localhost:5000/hello 地址:
前端报错
-(7)查看 provider 控制台日志,看接口中被访问情况:
hello 1113 被打印了5次,说明接口被访问5次,就是说 resilience4j-2 的 retry 重试功能起作用了,重试了 5次。
10.3.2 CircuitBreaker 断路器
- (1)继续在 application.yml中配置断路器
- (2)在 HelloServie 类上加上
@CircuitBreaker
注解,并配置fallbackMethod
属性
注意 error 方法的参数要加上Throwable
参数,否则会报错,继续访问 hello 接口,返回 error ,说明服务降级了
- 在 provider 中,我们依然能看见 控制台打印 5次 hello 1113,证明 retry 也在起作用
- (3)retry 和 circuitbreker 一起使用
在 provider 中更改接口,使请求重试在第二次成功,
然后重启provider ,继续访问 hello 接口:
前端结果成功
provider 服务控制台日志
打印了两次,说明 retry 的第二次成功了,服务不进行降级。成功返回了结果 hello 1114
10.3.3 RateLimiter
可以在请求端,也可以在被请求端使用,主要在被请求端使用,保护服务端的接口
- (1)在 provider 中添加 Resilience4j 依赖
- (2)在 application.properties 中配置限流
就是一秒处理两个请求
- (3)修改 provider 中的 hello 接口,打印时间,方便观察限流效果
@RateLimiter(name = "rlA")
注解的 rlA
是 application.properties
中配置的自定义限流策略名称。
- (4)在 resilience4j-2 中修改 HelloService 方法, 多次调用 provider 中的接口
- (5)重启 provider 和 resilience4j-2 服务,再次调用 http:///localhost:5000/hello,观察 provider 控制台打印情况:
如果修改application.properties
每秒处理一个请求
再次查看 provider 的控制台
一秒处理一个请求也起了作用,这就是限流的简单应用