https://github.com/zq2599/blog_demos
内容:所有原创文章分类汇总及配套源码,涉及Java、Docker、Kubernetes、DevOPS等;
本文是《Spring Cloud Gateway实战》系列的第七篇,前面的文章咱们学习了各种内置过滤器,还在[《Spring Cloud Gateway的断路器(CircuitBreaker)功能》]一文深入研究了断路器类型的过滤器(理论&实战&源码分析皆有),相信聪明的您一定会有此疑问:内置的再多也无法覆盖全部场景,定制才是终极武器
所以今天咱们就来开发一个自己专属的过滤器,至于此过滤器的具体功能,其实[前文]已埋下伏笔,如下图:
简单来说,就是在一个有断路器的Spring Cloud Gateway应用中做个自定义过滤器,在处理每个请求时把断路器的状态打印出来,这样咱们就能明明白白清清楚楚知道断路器的状态啥时候改变,变成了啥样,也算补全了[《Spring Cloud Gateway的断路器(CircuitBreaker)功能》]的知识点
过滤器分为全局和局部两种,这里咱们选用局部的,原因很简单:咱们的过滤器是为了观察断路器,所以不需要全局生效,只要在使用断路器的路由中生效就够了;
以上就是自定义过滤器的基本套路了,可见还是非常简单的,接下来的实战也是按照这个套路来的
在编写自定义过滤器代码之前,还有个拦路虎等着我们,也就是咱们过滤器的基本功能:如何取得断路器的状态
这个问题当然难不倒聪明的您了,没错,用反射修改此方法的访问权限,稍后的代码中咱们就这么干
还剩最后一个问题:circuitBreakerRegistry是ReactiveResilience4JCircuitBreakerFactory的成员变量,这个ReactiveResilience4JCircuitBreakerFactory从哪获取?
如果您配置过断路器,对这个ReactiveResilience4JCircuitBreakerFactory就很熟悉了,设置该对像是配置断路器的基本操作,回顾一下前文的代码:
@Configuration public class CustomizeCircuitBreakerConfig { @Bean public ReactiveResilience4JCircuitBreakerFactory defaultCustomizer() { CircuitBreakerConfig circuitBreakerConfig = CircuitBreakerConfig.custom() // .slidingWindowType(CircuitBreakerConfig.SlidingWindowType.TIME_BASED) // 滑动窗口的类型为时间窗口 .slidingWindowSize(10) // 时间窗口的大小为60秒 .minimumNumberOfCalls(5) // 在单位时间窗口内最少需要5次调用才能开始进行统计计算 .failureRateThreshold(50) // 在单位时间窗口内调用失败率达到50%后会启动断路器 .enableAutomaticTransitionFromOpenToHalfOpen() // 允许断路器自动由打开状态转换为半开状态 .permittedNumberOfCallsInHalfOpenState(5) // 在半开状态下允许进行正常调用的次数 .waitDurationInOpenState(Duration.ofSeconds(5)) // 断路器打开状态转换为半开状态需要等待60秒 .recordExceptions(Throwable.class) // 所有异常都当作失败来处理 .build(); ReactiveResilience4JCircuitBreakerFactory factory = new ReactiveResilience4JCircuitBreakerFactory(); factory.configureDefault(id -> new Resilience4JConfigBuilder(id) .timeLimiterConfig(TimeLimiterConfig.custom().timeoutDuration(Duration.ofMillis(200)).build()) .circuitBreakerConfig(circuitBreakerConfig).build()); return factory; } }
既然ReactiveResilience4JCircuitBreakerFactory是spring的bean,那我们在StatePrinterGatewayFilterFactory类中用Autowired注解就能随意使用了
至此,理论分析已全部完成,问题都已经解决,开始编码
名称 | 链接 | 备注 |
---|---|---|
项目主页 | https://github.com/zq2599/blog_demos | 该项目在GitHub上的主页 |
git仓库地址(https) | https://github.com/zq2599/blog_demos.git | 该项目源码的仓库地址,https协议 |
git仓库地址(ssh) | git@github.com:zq2599/blog_demos.git | 该项目源码的仓库地址,ssh协议 |
前文创建了子工程circuitbreaker-gateway,此工程已添加了断路器,现在咱们的过滤器代码就写在这个工程中是最合适的了
接下来按照套路写代码,首先是StatePrinterGatewayFilter.java,代码中有详细注释就不再啰嗦了,要注意的是getOrder方法返回值是10,这表示过滤器的执行顺序:
package com.bolingcavalry.circuitbreakergateway.filter; import io.github.resilience4j.circuitbreaker.CircuitBreaker; import io.github.resilience4j.circuitbreaker.CircuitBreakerRegistry; import io.vavr.collection.Seq; import lombok.extern.slf4j.Slf4j; import org.springframework.cloud.circuitbreaker.resilience4j.ReactiveResilience4JCircuitBreakerFactory; import org.springframework.cloud.gateway.filter.GatewayFilter; import org.springframework.cloud.gateway.filter.GatewayFilterChain; import org.springframework.core.Ordered; import org.springframework.http.HttpStatus; import org.springframework.web.server.ServerWebExchange; import reactor.core.publisher.Mono; import java.lang.reflect.Method; public class StatePrinterGatewayFilter implements GatewayFilter, Ordered { private ReactiveResilience4JCircuitBreakerFactory reactiveResilience4JCircuitBreakerFactory; // 通过构造方法取得reactiveResilience4JCircuitBreakerFactory实例 public StatePrinterGatewayFilter(ReactiveResilience4JCircuitBreakerFactory reactiveResilience4JCircuitBreakerFactory) { this.reactiveResilience4JCircuitBreakerFactory = reactiveResilience4JCircuitBreakerFactory; } private CircuitBreaker circuitBreaker = null; @Override public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) { // 这里没有考虑并发的情况,如果是生产环境,请您自行添加上锁的逻辑 if (null==circuitBreaker) { CircuitBreakerRegistry circuitBreakerRegistry = null; try { Method method = reactiveResilience4JCircuitBreakerFactory.getClass().getDeclaredMethod("getCircuitBreakerRegistry",(Class[]) null); // 用反射将getCircuitBreakerRegistry方法设置为可访问 method.setAccessible(true); // 用反射执行getCircuitBreakerRegistry方法,得到circuitBreakerRegistry circuitBreakerRegistry = (CircuitBreakerRegistry)method.invoke(reactiveResilience4JCircuitBreakerFactory); } catch (Exception exception) { exception.printStackTrace(); } // 得到所有断路器实例 Seq<CircuitBreaker> seq = circuitBreakerRegistry.getAllCircuitBreakers(); // 用名字过滤,myCircuitBreaker来自路由配置中 circuitBreaker = seq.filter(breaker -> breaker.getName().equals("myCircuitBreaker")) .getOrNull(); } // 取断路器状态,再判空一次,因为上面的操作未必能取到circuitBreaker String state = (null==circuitBreaker) ? "unknown" : circuitBreaker.getState().name(); System.out.println("state : " + state); // 继续执行后面的逻辑 return chain.filter(exchange); } @Override public int getOrder() { return 10; } }
package com.bolingcavalry.circuitbreakergateway.filter; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.cloud.circuitbreaker.resilience4j.ReactiveResilience4JCircuitBreakerFactory; import org.springframework.cloud.gateway.filter.GatewayFilter; import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory; import org.springframework.stereotype.Component; @Component public class StatePrinterGatewayFilterFactory extends AbstractGatewayFilterFactory<Object> { @Autowired ReactiveResilience4JCircuitBreakerFactory reactiveResilience4JCircuitBreakerFactory; @Override public String name() { return "CircuitBreakerStatePrinter"; } @Override public GatewayFilter apply(Object config) { return new StatePrinterGatewayFilter(reactiveResilience4JCircuitBreakerFactory); } }
server: #服务端口 port: 8081 spring: application: name: circuitbreaker-gateway cloud: gateway: routes: - id: path_route uri: http://127.0.0.1:8082 predicates: - Path=/hello/** filters: - name: CircuitBreaker args: name: myCircuitBreaker - name: CircuitBreakerStatePrinter
有个很明显的问题,聪明睿智的您当然不会忽略:上图绿框中的连续四个响应,对应的断路器状态都没有打印出来,要知道,咱们的过滤器可是要处理每一个请求的,怎么会连续漏掉四个呢?
其实原因很容易推理出来:断路器CircuitBreaker的filter先执行,然后才是咱们的CircuitBreakerStatePrinter,而处于开启状态的断路器会直接返回错误给调用方,其后面的filter都不会执行了
那么问题来了:如何控制CircuitBreaker和CircuitBreakerStatePrinter这两个filter的顺序,让CircuitBreakerStatePrinter先执行?
CircuitBreakerStatePrinter是咱们自己写的代码,修改StatePrinterGatewayFilter.getOrder的返回值可以调整顺序,但CircuitBreaker不是咱自己的代码呀,这可如何是好?
老规矩,看看断路器的源码,前文已经分析过了,断路器最重要的代码是SpringCloudCircuitBreakerFilterFactory.apply方法,如下图红框,生成的filter是GatewayFilter接口的实现类:
回顾咱们的路由配置,CircuitBreaker在前,CircuitBreakerStatePrinter在后,所以,在添加CircuitBreaker的时候,i等于0,那么CircuitBreaker的order就等于i+1=1了
而CircuitBreakerStatePrinter实现了Ordered接口,因此不会走红框中的代码,其order等于咱们写在代码中的值,咱们写的是10
所以:CircuitBreaker的order等于1,CircuitBreakerStatePrinter等于10,当然是CircuitBreaker先执行了!
知道了原因,改起来就容易了,我的做法很简单:StatePrinterGatewayFilter不再实现Ordered,这样就和CircuitBreaker的filter一样,执行的是上图红框中的代码,这样,在配置文件中,谁放在前面谁就先执行
代码就不贴出来了,您自行删除StatePrinterGatewayFilter中和Ordered相关的部分即可
配置文件调整后如下:
server: #服务端口 port: 8081 spring: application: name: circuitbreaker-gateway cloud: gateway: routes: - id: path_route uri: http://127.0.0.1:8082 predicates: - Path=/hello/** filters: - name: CircuitBreakerStatePrinter - name: CircuitBreaker args: name: myCircuitBreaker
我是欣宸,期待与您一同畅游Java世界…
https://github.com/zq2599/blog_demos