Spring Cloud gateway - CircuitBreaker GatewayFilte

前面学习Spring cloud gateway的时候，做测试的过程中我们发现，Spring Cloud Gateway不需要做多少配置就可以使用Spring Cloud LoadBalance的功能，比如：

spring:application:name: spring-gatewaycloud:gateway:routes:- id: path_routeuri: lb://orderservicepredicates:- Path=/order/*
eureka:client:service-url: # eureka servicedefaultZone: http://127.0.0.1:10086/eureka/
server:port: 9095

就实现了通过Eureka注册中心进行路由、并自动启用了负载均衡。

其实这个功能是通过Gateway的过滤器实现的。

我们已经知道，Spring Cloud Gateway内置n多过滤器，我们今天就学习其中两个过滤器：

The CircuitBreaker GatewayFilter
The ReactiveLoadBalancerClientFilter

The ReactiveLoadBalancerClientFilter

该Filter原理非常简单，就是上面说过的配置项uri中有 lb 标记，比如上例中的 lb://orderservice 。

ReactiveLoadBalancerClientFilter会查找uri配置中如果包含 lb 的话，会使用Spring Cloud ReactorLoadBalancer解析uri为实际的host和port。

所以只要在配置文件中uri指定lb标记，就会启用Spring Cloud LoadBalancer，简直就是，不要太方便。

ReactiveLoadBalancerClientFilter是Spring Cloud Gateway的全局过滤器，因此你不需要做特殊配置，自动全局生效。

The CircuitBreaker GatewayFilter

CircuitBreaker GatewayFilter是路由过滤器，所以，如果想要其生效，必须在路由下进行配置，比如：

spring:cloud:gateway:routes:- id: circuitbreaker_routeuri: https://example.orgfilters:- CircuitBreaker=myCircuitBreaker

断路器基础

我们前面学习过Hystrix，了解了断路器的作用以及基本原理，知道断路开关有闭合、打开、半开半闭三个状态，以下是Hystrix的断路开关状态描述：

闭合：默认为闭合状态，可以对服务正常调用。
打开：服务调用失败达到设定的阈值后打开，一定时间范围（MTTR 平均故障处理时间）内不会调用服务。打开时长达到MTTR设置的时间后，切换到半熔断状态（半开半闭）。
半开半闭：半熔断状态，此状态下允许请求访问服务一次，如果访问成功则关闭断路器，否则再次打开断路器。

不同的断路器实现都会遵循在以上三个状态下工作的基础原理，只不过开关打开条件、半开半闭状态下变更为开、闭状态的条件可能会有所不同。

CircuitBreaker GatewayFilter

我们今天要学习的是Spring Cloud Gateway的断路过滤器，而不是Spring Cloud CircuitBreaker。

关于CircuitBreaker GatewayFilter，官网描述：

The Spring Cloud CircuitBreaker GatewayFilter factory uses the Spring Cloud CircuitBreaker APIs to wrap Gateway routes in a circuit breaker. Spring Cloud CircuitBreaker supports multiple libraries that can be used with Spring Cloud Gateway. Spring Cloud supports Resilience4J out of the box.

CircuitBreaker GatewayFilter工厂采用Spring Cloud断路器的接口将网关路由包装在Spring Cloud断路器中。Spring Cloud CircuitBreaker 支持众多可用于Spring Cloud网关的库。其中Resilience4J 对于Spring Cloud来说是开箱即用的。

意思除了Resilience4J 之外，Spring Cloud还应该支持其他类型的断路器。但是具体还有哪些，官网并没有说。

Spring Cloud CircuitBreaker

Spring Cloud CircuitBreaker 我们后面会专门进行学习研究，今天的主要目标是Spring Cloud Gateway的CircuitBreaker GatewayFilter。不过既然CircuitBreaker GatewayFilter 官网说Spring Cloud CircuitBreaker支持多个断路器，那我们就大概看一下Spring Cloud CircuitBreaker，简单了解一下官网所说的Spring Cloud CircuitBreaker支持多个断路器的libraries具体是什么意思。

还是看官网，找到Spring Cloud CircuitBreaker的官网介绍：

在这里插入图片描述
Spring Cloud CircuitBreaker提供了一个对不同断路器实现的抽象，为应用提供了一组API，使得你（猿类们啊…)可以在自己应用中轻松选择适合你自己应用的断路器实现。

支持的断路器实现包括：

Resilience4J
Sentinel
Spring Retry

官网文档并没有提到Hystrix，Hystrix是属于Netflix的组件，并不属于Spring Cloud CircuitBreaker，所以Spring有了自己的断路器，Hystrix就会被他主动抛弃（并不是说不支持了，只不过是，不亲了啊…)。

所以，概念梳理清楚了，Spring Cloud CircuitBreaker是一个对各断路器实现的抽象，可以灵活支持Resilience4J、Sentinel以及Spring Retry。而CircuitBreaker GatewayFilter 是Spring Cloud网关的一个断路器过滤器，该过滤器内部封装了Spring Cloud CircuitBreaker，可以支持Spring Cloud CircuitBreaker的各实现库包括Resilience4J、Sentinel及Spring Retry。

CircuitBreaker GatewayFilter官网提到Resilience4J是开箱即用的，所以，Resilience4J应该是CircuitBreaker GatewayFilter中断路器的默认实现。

CircuitBreaker GatewayFilter 应用

模块gateway的pom文件中引入Resilience4J:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>springCloud</artifactId><groupId>com.example</groupId><version>0.0.1-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>springgateway</artifactId><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-client</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-circuitbreaker-reactor-resilience4j</artifactId></dependency></dependencies><properties><maven.compiler.source>17</maven.compiler.source><maven.compiler.target>17</maven.compiler.target></properties></project>

模块gateway的配置文件

spring:application:name: spring-gatewaycloud:gateway:routes:- id: path_route
#          uri: http://127.0.0.1:9090uri: lb://orderservicepredicates:- Path=/order/*filters:- name: Myargs:name: My own pre-filter- name: CircuitBreakerargs:name: myCircuitBreakerfallbackUri: forward:/fallbackstatusCodes: 500- id: orderfallback_routeuri: lb://orderservicepredicates:- Path=/fallback
eureka:client:service-url: # eureka servicedefaultZone: http://127.0.0.1:10086/eureka/
server:port: 9095

增加CircuitBreaker的配置，调用发生错误的话、或者返回的status code是500的话，则出发fallback。

fallback也可以通过路由配置到指定位置，比如我们案例中指向orderservice的fallback路径。

orderservice模块增加fallback请求的相应

增加一个controller：

package com.example.controller;import lombok.extern.slf4j.Slf4j;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;@RestController
@Slf4j
public class FallbackController {@GetMapping("/fallback")public String fallback(){return "this is fallback from orderservice...";}
}

orderservice模块增加一个失败请求

修改orderservice，模拟一个失败请求，以及一个返回500的请求，以便测试：

    @GetMapping("/orderCount")public String orderCount(@RequestParam int count, HttpServletRequest request, HttpServletResponse response){log.info("Come here to get Order....123===");if(count==500 || count==404){response.setStatus(count);}return "10/count:"+10/count+" from:"+serverPort;}

增加一个orderCount方法，判断请求参数后做返回，返回信息中包含了一个除法运算 10/count，这样我们请求参数count如果是500的话，会返回status code 500，请求参数count如果是0的话，将会触发服务端的 / by zero异常。

测试

启动Eureak模块、gateway模块、以及orderservice模块。

在这里插入图片描述
前端访问，首先送入count=0，触发服务端除零错误后，路由的fallback：

然后传入count=500，触发gateway的statusCode=500的fallback路由：

最后送入一个正常的count=1的值，获取到正常的返回：

OK，Spring Cloud gateway的CircuitBreaker GatewayFilte就到这里了，源码没有研究，还有，Spring Cloud的CircuitBreaker 也没有深入研究，下次。