前提

在微服务架构中，下游依赖出现问题如果上游调用方不做请求降级处理，下游的异常依赖没有被隔离，很有可能出现因为一两个服务或者小到一两个接口异常导致上游所有服务不可用，甚至影响整个业务线。请求降级处理目前比较主流的依然是Netfilx出品的Hystrix。Hystrix的工作原理是：

• 把请求基于线程池或者信号量隔离，一旦下游服务在指定配置的超时时间内无法响应会进入预设或者默认的降级实现。
• 每个请求的状态都会记录下来，在一个滑动窗口内处理失败的比率超过设定的阈值就会触发熔断器(Circle Breaker)开启，熔断器开启之后所有请求都会直接进入预设或者默认的降级逻辑。
• 熔断器打开后，且距离熔断器打开的时间或上一次试探请求放行的时间超过设定值，熔断器器进入半开状态，允许放行一个试探请求。
• 请求成功率提高后，基于统计数据确定对熔断器进行关闭，所有请求正常放行。

这里不对Hystrix的细节做更深入分析，而是接着谈谈Spring Cloud Gateway中如何使用Hystrix，主要包括内置的Hystrix过滤器和定制过滤器结合Hystrix实现我们想要的功能。除了要引入spring-cloud-starter-gateway依赖之外，还需要引入spring-cloud-starter-netflix-hystrix。

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-gateway</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
        </dependency>
    </dependencies>    

前提

• 本文编写的时候使用的Spring Cloud Gateway版本为当时最新的版本Greenwich.SR1。

我们在使用Spring Cloud Gateway的时候，注意到过滤器（包括GatewayFilter、GlobalFilter和过滤器链GatewayFilterChain），都依赖到ServerWebExchange：

public interface GlobalFilter {

    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

public interface GatewayFilter extends ShortcutConfigurable {

	Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}

public interface GatewayFilterChain {

    Mono<Void> filter(ServerWebExchange exchange);
}    

这里的设计和Servlet中的Filter是相似的，当前过滤器可以决定是否执行下一个过滤器的逻辑，由GatewayFilterChain#filter()是否被调用来决定。而ServerWebExchange就相当于当前请求和响应的上下文。ServerWebExchange实例不单存储了Request和Response对象，还提供了一些扩展方法，如果想实现改造请求参数或者响应参数，就必须深入了解ServerWebExchange。

前提

我们平时在用SpringMVC的时候，只要是经过DispatcherServlet处理的请求，可以通过@ControllerAdvice和@ExceptionHandler自定义不同类型异常的处理逻辑，具体可以参考ResponseEntityExceptionHandler和DefaultHandlerExceptionResolver，底层原理很简单，就是发生异常的时候搜索容器中已经存在的异常处理器并且匹配对应的异常类型，匹配成功之后使用该指定的异常处理器返回结果进行Response的渲染，如果找不到默认的异常处理器则用默认的进行兜底(个人认为，Spring在很多功能设计的时候都有这种“有则使用自定义，无则使用默认提供”这种思想十分优雅)。

SpringMVC中提供的自定义异常体系在Spring-WebFlux中并不适用，其实原因很简单，两者底层的运行容器并不相同。WebExceptionHandler是Spring-WebFlux的异常处理器顶层接口，因此追溯到子类可以追踪到DefaultErrorWebExceptionHandler是Spring Cloud Gateway的全局异常处理器，配置类是ErrorWebFluxAutoConfiguration。

前提

GatewayFilter的作用域是指定的路由配置，路由配置选项里面需要通过filters指定想要使用的GatewayFilter列表。我们可以通过自定义GatewayFilter，做额外的扩展，实现一些内建GatewayFilter不存在的功能，并且应用到我们的路由配置中。

前提

GlobalFilter的作用域是所有的路由配置，我们可以通过自定义GlobalFilter，做额外的扩展，用来实现一些全局的功能。

前提

最近在做老系统的重构，重构完成后新系统中需要引入一个网关服务，作为新系统和老系统接口的适配和代理。之前，很多网关应用使用的是Spring-Cloud-Netfilx基于Zuul1.x版本实现的那套方案，但是鉴于Zuul1.x已经停止迭代，它使用的是比较传统的阻塞(B)IO + 多线程的实现方案，其实性能不太好。后来Spring团队干脆自己重新研发了一套网关组件，这个就是本次要调研的Spring-Cloud-Gateway。

简介

Spring Cloud Gateway依赖于Spring Boot 2.0, Spring WebFlux,和Project Reactor。许多熟悉的同步类库(例如Spring-Data和Spring-Security)和同步编程模式在Spring Cloud Gateway中并不适用，所以最好先阅读一下上面提到的三个框架的文档。

Spring Cloud Gateway依赖于Spring Boot和Spring WebFlux提供的基于Netty的运行时环境，它并非构建为一个WAR包或者运行在传统的Servlet容器中。