SpringCloudGateway初探
简述
SpringCloud全家桶中有个很重要的组件就是网关，在1.X版本中都是采用zuul网关，在2.X版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替带zuul——SpringCloud Gateway 。换言之，gateway就是原zuul1.X版 的替代。
Gateway是在spring生态系统上构建的api网关服务，基于Spring5，SpringBoot2和Project Reactor等技术。Gateway旨在提供一种简单而有效的方式来对api进行路由，以提供一些强大的过滤功能，例如熔断、限流、重试等。
为了提升网关性能，SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层使用了高性能的Reactor通信框架Netty。SpringCloud Gateway的目标提供统一的路由方式，且基于Filter链的方式提供了网关基本的功能，例如安全、监控/指标、限流。
特性
基于Spring FremeWork5，Project Reactor和Spring Boot2.0进行构建；
动态路由：能够匹配任何请求属性；
可以对路由指定Predictate（断言）和Filter（过滤器）；
集成Hystrix的断路器功能；
集成SpringCloud的服务发现功能；
请求限流功能；
支持路径重写。
与Zuul的区别
在SpringCloud Finchley 正式版之前，Spring Cloud推荐的网关是 Netflix提供的Zuul:
1、Zuul 1.x，是一个基于阻塞I/O的API Gateway；
2、Zuul 1.x基于Servlet 2.5使用阻塞架构，它不支持任何长连接(如WebSocket)。Zuul的设计模式和Nginx较像，每次I/О操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx用C++实现，Zuul用Java实现，而JVM本身会有第—次加载较慢的情况，使得Zuul的性能相对较差。
3、Zuul 2.x理念更先进，想基于Netty非阻塞和支持长连接，但SpringCloud目前还没有整合。Zuul 2.x的性能较Zuul 1.x有较大提升。在性能方面，根据官方提供的基准测试，Spring Cloud Gateway的RPS(每秒请求数）是Zuul的1.6倍。
4、Spring Cloud Gateway建立在Spring Framework 5、ProjectReactor和Spring Boot2之上，使用非阻塞API。
5、Spring Cloud Gateway还支持WebSocket，并且与Spring紧密集成拥有更好的开发体验
WebFlux
传统的Web框架，比如说: struts2，springmvc等都是基于Servlet API与Servlet容器基础之上运行的。但是在Servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型非阻塞异步的框架，它的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty,Undertow及支持Servlet3.1的容器上。非阻塞式+函数式编程（Spring5必须让你使用java8）
Spring WebFlux是Spring 5.0引入的新的响应式框架，区别于Spring MVC，它不需要依赖Servlet API，它是完全异步非阻塞的，并且基于Reactor来实现响应式流规范。
核心概念
ROUTE（路由）
路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true，则匹配该路由。
PREDICATE（断言）
参考的是Java8的java.util.function.Predictate，开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与路由相匹配则进行路由。
FILTER（过滤）
指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由之前或之后对请求进行修改。
web请求，通过一些匹配条件，定位到真正的服务节点，并在这个转发过程的前后，进行一些精细化控制。Predicate就是我们的匹配条件，而filter，就可以理解为一个无所不能的拦截器。有了这两个元素，再加上目标uri，就可以实现一个具体的路由。
GATEWEY工作流程
客户端向Spring Cloud Gateway发出请求。然后在Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway Web Handler。
Handler再通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”）或之后（“post”）执行业务逻辑的加强或其他处理。
Filter 在 “pre” 类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等；在 “post” 类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等，有着非常重要的作用
Gatewey的核心逻辑就是**路由转发+执行过滤链
DEMO
本例中使用Nacos作为注册和配置中心，系列源代码GitHub地址spring-cloud-demo
创建api-gateway子项目
完整pom.xml
spring-cloud-demo
cn.javayuli
1.0.0
4.0.0
api-gateway
api网关
org.springframework.cloud
spring-cloud-starter-gateway
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-config
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
com.alibaba.cloud
spring-cloud-alibaba-sentinel-gateway
org.springframework.boot
spring-boot-maven-plugin
启动类
package cn.javayuli.gateway;
import org.springframework.boot.SpringApplication;
import org.springframework.cloud.client.SpringCloudApplication;
/**
* 网关服务
*
* @author hanguilin
*/
@SpringCloudApplication
public class GatewayApplication {
public static void main(String[] args) {
SpringApplication.run(GatewayApplication.class, args);
}
}
api-provider项目作为接口提供者，提供了一个/hello接口，端口8000，访问路径http://localhost:8000/hello?s=1。api-provider项目在nacos中的服务名称为api-provider。
api-gateway配置
server:
port: 8001
spring:
cloud:
gateway:
routes:
- id: api-provider
uri: lb://api-provider
predicates:
- Path=/provider/**
filters:
- RewritePath=/provider/(?>.*), /$\{
segment}
spring.cloud.gateway.routes是对路由的配置
spring.cloud.gateway.routes.id是唯一的，需要自己定义，一般是用项目名称作为id
spring.cloud.gateway.routes.uri表示资源请求的真实路径
-
lb
在SpringCloud Gateway官方文档中有这么一句话
Note that this example also demonstrates (optional) Spring Cloud Netflix Ribbon load-balancing via the lb prefix on the destination URI.
意为如果项目中使用了Spring Cloud Netflix Ribbon，就可以用lb://${applicationName}的形式表示服务访问路径
或者还可以直接使用请求路径，如http://localhost:8001
spring.cloud.gateway.routes.predicates -Path表示请求路径匹配到此表达式的请求将由此规则进行转发
spring.cloud.gateway.routes.filters - RewritePath表示重写路由，此处可以将/provider/hello重写成/hello
启动api-gateway与api-provider服务，无需分先后
通过网关端口访问api-provider的接口
最后放上spring-cloud-gateway.2.2.RELEASE的文档