一、基础概述
1、为什么选择GateWay，放弃zuul？
zuul在升级zuul2过程中团队出现了分歧，后来核心人员又跳槽，导致zuul2迟迟未发布，且Netflix大量组件进入维护期，不知前景如何；
Spring官方就自己出了一个替代产品 Gateway；
2、Cloud全家桶中有个很重要的组件就是网关GateWay
在1.X版本中都是采用的Netflix公司的Zuul网关；
但是在2.X版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，即SpringCloud Gateway；
SpringCloud Gateway是在Spring生态系统之上构建的API网关服务，基于Spring5， SpringBoot2、和Project Reactor等技术；
SpringCloud Gateway旨在提供一种简单而有效地方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断、限流、重试等！
3、SpringCloud Gateway的强大之处，选择理由？
SpringCloud Gateway是SpringCloud 的一个全新项目，基于Spring5.0+SpringBoot2.0 和 Project Reactor等技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的API路由管理方式！
SpringCloud Gateway 作为SpringCloud生态中的网关，目的是取代Zuul，在 SpringCloud2.0以上的版本中，没有对新版本的Zuul2.0以上最高性能版本进行集成，仍然还是使用的Zuul1.x非Reactor模式的老版本。而为了提升网关的性能，SpringCLoud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
SpringCloud Gateway的目标是提供统一的路由管理方式，且基于Filter链的方式提供了网关基本的功能，如：安全、监控/指标、和限流等！
4、在微服务架构中Gateway能做什么？
-
反向代理
-
鉴权
-
流量控制
-
熔断
-
日志监控等
5、微服务架构中网关的具体位置在哪？
6、SpringCloud Gateway 和 Zuul的技术特性对比？
SpringCloud Gateway：
-
基于Spring Framework5、Project Reactor 和SpringBoot2.0进行设计构建
-
动态路由：能够匹配任何请求属性
-
可以对路由指定 Predicate（断言）和Filter（过滤器）
-
继承Hystrix的断路器功能
-
继承SpringCloud的服务发现功能；
-
易于编写的Predicate（断言）和Filter（过滤器）
-
请求限流功能
-
支持路径重写
Netflix Zuul：
-
Zuul1.x 基于阻塞I/O的API Gateway
-
Zuul1.x 基于Servlet2.5使用阻塞架构，它不支持任何长连接，如Websocket，Zuul的设计模式和Nginx较像，每次I/O操作都是从工作线程中选择一个执行，请求线程被堵塞到工作线程完成，但是差别是Nginx使用C++实现，Zuul使用Java实现，而JVM本身会有第一次加载较慢的情况，使得Zuul1.0 的性能较差！
-
Zuul2.x 考虑到1.x版本的劣势，想基于Netty非阻塞和支持长连接，但是SpringCloud目前还没有整合。Zuul2.x的性能较Zuul1.x有着较大的提升。在性能方面，根据官方的基准测试，SpringCloud Gateway的RPS（每秒处理请求数）是Zuul的1.6倍；
7、SpringCloud Gateway和Zuul1.x的模型对比
SpringCloud Gateway：
在Servlet3.1之后出现了异步非阻塞的支持，而WebFlux是一个典型的异步非阻塞的框架，它的核心是基于高性能的Reactor的相关API实现的。
相对于传统的web框架来说，他可以运行在诸如 Netty、Undertow及支持Servlet3.1的容器上。
非阻塞式+函数式编程（Spring5必须要使用Java8）
Spring WebFlux是Spring5.0引入的新的响应式框架，区别于SpringMVC，它不需要依赖Servlet API，它使用完全异步非阻塞的、并基于Reactor来实现响应式流规范！
Zuul1.0：
Zuul1.x采用的是Tomcat容器，使用的是传统的Servlet IO处理模型；
灵魂问题——生命周期：servlet是由servlet container进行生命周期管理；
contailer启动时，构建servlet对象并调用servlet init() 进行初始化；
container运行时接收请求，并为每个请求分配一个线程（一般是从线程池中获取空闲线程），然后调用service()；
container关闭时调用destory()销毁servlet；
缺点是：
上述的模型是一个简单的阻塞式网络I/O模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的。但是一旦高并发（比如适用Jmeter压测），线程数量就会上涨，而线程资源的代价是昂贵的（创建销毁切换等，内存消耗大），严重影响请求的处理时间。
在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极高的并发请求，这种业务场景下servlet模型没有优势！
二、Gateway的工作流程
1、Gateway的三大核心概念：
-
Route（路由）：路由是构建网关的基本模块，它由ID、目标URI、一系列的断言和过滤器组成，如果断言为true则匹配该路由；
-
Predicate（断言）：参考JDK8中的Predicate（Boolean），可以匹配HTTP请求中的所有内容（请求头、请求参数等），如果请求与断言相匹配，则进行路由；
-
Filter（过滤器）：Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前 或者 被路由后，队请求进行修改；
总结：
web请求，通过一些匹配条件，定位到真正的服务几点。并在这个转发过程的前后，进行一些精细化控制；
predicate就是我们的匹配条件，而filter就是一个无所不能的拦截器
有了上面这两个元素，再加上目标uri，就可以实现一个具体的路由了！
2、Gateway的工作流程？
客户端向SpringCLoud Gateway发送请求，然后在Gateway Handler Mapping中找到与请求相匹配的规则，并将其发送到Gateway Web Handler。
Gateway Web Handler再通过指定的过滤器链，来将请求发送到我们的实际的代理服务，执行业务逻辑，然后返回；
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求之前（“pre”），也可能在之后（“post”）执行其逻辑！
-
“pre”类型过滤器：可以做参数校验、权限校验、流量监控、日志输出、协议转换等；
-
“post”类型过滤器：响应内容、响应头的修改、日志的输出、流量监控等有者非常重要的作用！
三、Gateway服务的搭建——Gateway9527
1、新建服务cloud-gateway-gateway9527
<?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>cloud2020</artifactId>
<groupId>com.jiguiquan.springcloud</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>cloud-gateway-gateway9527</artifactId>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
<!--eureka-client-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!--公共服务模块依赖-->
<dependency>
<groupId>com.jiguiquan.springcloud</groupId>
<artifactId>cloud-api-commons</artifactId>
<version>${project.version}</version>
</dependency>
<!--网关中千万不要因为web和actuator依赖，否则会报错，因为Gateway的webflux和web会有冲突-->
<!--热部署devtools-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-devtools</artifactId>
<scope>runtime</scope>
<optional>true</optional>
</dependency>
<!--lombok-->
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<!--测试-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
</dependency>
</dependencies>
</project>
2、配置文件 application.yml：
server: port: 9527 spring: application: name: cloud-gateway eureka: instance: hostname: cloud-gateway-service client: register-with-eureka: true #表示向注册中心注册自己 默认为true fetch-registry: true #是否从EurekaServer抓取已有的注册信息，默认为true,单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡 service-url: defaultZone: http://localhost:7001/eureka # 单机版 入驻的EurekaServer地址
3、主启动类 GateWayMain9527.java：
@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {
public static void main(String[] args) {
SpringApplication.run(GateWayMain9527.class, args);
}
}
4、服务9527如果实现“路由映射”的功能呢？
以服务 cloud-provider-payment8001的API为例（get和lb）：
原访问路径为：
-
get：http://localhost:8001/payment/get/{id}
-
lb：http://localhost:8001/payment/lb
需求：我们目前不想暴露 8001端口，希望在8001外面套一层9527
在gateway9527服务的配置文件application.yml中增加以下配置：spring.cloud.gateway.routes:
server: port: 9527 spring: application: name: cloud-gateway cloud: gateway: routes: - id: payment_routh #payment_route路由的ID，没有固定规则，但是要求唯一，建议配合服务名 uri: http://localhost:8001 #匹配后提供服务的路由地址 predicates: - Path=/payment/get/** #断言：路径相匹配的进行路由 - id: payment_routh2 #payment_route路由的ID，没有固定规则，但是要求唯一，建议配合服务名 uri: http://localhost:8001 #匹配后提供服务的路由地址 predicates: - Path=/payment/lb/** #断言：路径相匹配的进行路由 eureka: instance: hostname: cloud-gateway-service client: register-with-eureka: true #表示向注册中心注册自己 默认为true fetch-registry: true #是否从EurekaServer抓取已有的注册信息，默认为true,单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡 service-url: defaultZone: http://localhost:7001/eureka # 单机版 入驻的EurekaServer地址
5、启动服务7001、8001、9527进行测试：
访问链接，对应地就可以变为：
-
get：http://localhost:9527/payment/get/{id}
-
lb：http://localhost:9527/payment/lb
显然，我们使用Gateway对我们的微服务payment8001进行了端口保护；
四、Gateway配置路由的两种方式
-
第一种：在配置文件application.yml中进行配置，上面就是；
-
第二种：代码中注入RouteLocator的Bean：
需求：通过代码注入的方式，经过配置：能让我们经过9527网关，访问到外网“百度新闻：http://news.baidu.com”
1、新建一个配置类：config.GatewayConfig.java
@Configuration
public class GateWayConfig {
@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder routeLocatorBuilder){
RouteLocatorBuilder.Builder routes = routeLocatorBuilder.routes();
routes.route("path_route_jiguiquan", r -> r.path("/guonei").uri("http://news.baidu.com/guonei")).build();
return routes.build();
}
}
2、启动项目，测试，访问链接： http://localhost:9527/guonei
显然，我们的配置生效了！
五、Gateway配置动态路由
1、为什么要引入动态路由？
很显然，我们的路由是不能写死的！
2、通过微服务名实现动态路由：
默认情况下：Gateway会根据注册中心注册的服务列表，以注册中心上微服务名为路径，创建动态路由进行转发，从而实现动态路由的功能；
3、我们使用微服务payment8001和payment8002演示动态路由+网关负载均衡，启动此两个服务：
4、修改Gateway项目的配置文件application.yml：
server: port: 9527 spring: application: name: cloud-gateway cloud: gateway: discovery: locator: enabled: true #开启从注册中心动态创建路由的功能，利用微服务名进行路由 routes: - id: payment_routh #payment_route路由的ID，没有固定规则，但是要求唯一，建议配合服务名 # uri: http://localhost:8001 #匹配后提供服务的路由地址 uri: lb://cloud-payment-service #负载均衡+服务名——》动态路由 predicates: - Path=/payment/get/** #断言：路径相匹配的进行路由 - id: payment_routh2 #payment_route路由的ID，没有固定规则，但是要求唯一，建议配合服务名 # uri: http://localhost:8001 #匹配后提供服务的路由地址 uri: lb://cloud-payment-service #负载均衡+服务名——》动态路由 predicates: - Path=/payment/lb/** #断言：路径相匹配的进行路由 eureka: instance: hostname: cloud-gateway-service client: register-with-eureka: true #表示向注册中心注册自己 默认为true fetch-registry: true #是否从EurekaServer抓取已有的注册信息，默认为true,单节点无所谓,集群必须设置为true才能配合ribbon使用负载均衡 service-url: defaultZone: http://localhost:7001/eureka # 单机版 入驻的EurekaServer地址
5、重新启动Gateway项目，进行测试：多次访问链接： http://localhost:9527/payment/lb
显然，动态路由生效，且实现了负载均衡！
六、Gateway常用的Predicate（断言）
1、在启动Gateway项目的时候，控制台会打印出这样的多条信息：
以上十几个，就是官方默认的断言工厂生产的断言（下面只列举常用的9种）：
https://cloud.spring.io/spring-cloud-gateway/reference/html/#gateway-request-predicates-factories
-
After：在xxxx.xx.xx时间之后；就以After做一个简单测试：
public class Test {
public static void main(String[] args) {
ZonedDateTime zbj = ZonedDateTime.now();
System.out.println(zbj);
}
}
获得当前时区时间：2020-03-28T20:57:22.115+08:00[Asia/Shanghai]
先在Gateway的配置文件中，加这样的一条断言：
- After=2020-03-28T20:57:22.115+08:00[Asia/Shanghai]
重启后，访问正常：
再将时间向后多一个小时，即：
- After=2020-03-28T21:57:22.115+08:00[Asia/Shanghai]
再次重启，访问，发现，请求404，所以当前断言没通过：
此功能举个应用场景，某个功能已经开发了，但是现在并不打算上线，我们可以通过此方法设置一个生效时间！
其它的就不一一试了！
-
Before：在xxxx.xx.xx时间之前；
-
Between：在xxxx.xx.xx时间与xxxx.xx.xx时间之间；
-
Cookie：
- Cookie=username,zzyy #cookie名，正则表达式
-
Header：
- Header=X-Request-Id, \d+ #属性名，正则表达式
-
Host：
- Host=**.jiguqiuan.com
-
Method：
- Method=GET
-
Path：这个第一个接触的，就不用讲了
-
Query：
- Query=username, \d+ #要有参数名username，且值为正数
七、Gateway的Filter（过滤器）
路由过滤器可用于修改 进入的HTTP请求和会返回的Http响应，路由过滤器只能指定路由进行使用；
SpringCloud Gateway内置了多种路由过滤器，他们都是由GatewayFilter工厂类来生产的；
https://cloud.spring.io/spring-cloud-gateway/reference/html/#gatewayfilter-factories
1、生命周期：
-
pre（业务处理之前）：
-
post（业务处理之后）：
2、种类：
-
GatewayFilter（单一过滤器）：31种之多；
-
GlobalFilter（全局过滤器）：十多种
使用方法就是在application.yml配置文件中，刚刚的predicates的同级增加filters配置：
filters: - AddRequestParameter=red, blue
3、自定义路由过滤器：——以自定义全局过滤器为例
全局过滤器一般能用来干嘛？——全局日志记录、统一网关鉴权。。。。。。等
涉及到的两个需要实现的接口：
-
GlobalFilter：
-
Ordered：
4、我们新建一个全局日志网关路由过滤器（filter.MyLogGateWayFilter）
@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter, Ordered {
/**
* 需求：当请求进入时，需要含有一个用户名：uname
*/
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
log.info("*********come in MyLogGateWayFilter：" + new Date());
String uname = exchange.getRequest().getQueryParams().getFirst("uname");//spring5.0的知识
if (uname == null){
log.info("******用户名为null，非法用户，o(╥﹏╥)o");
exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder() {
return 0; //加载过滤器的顺序，一般数值越小，优先级越高
}
}
5、启动项目，进行测试：
先访问： http://localhost:9527/payment/lb?uname=jiguiquan ，一切正常：
再次访问：http://localhost:9527/payment/lb ，即不带uname参数：
显然，访问被拒绝了，其实这个406状态码就是我们设置返回的 HttpStatus.NOT_ACCEPTABLE
到这里Gateway网关就全部结束了！
个人此项目代码地址（持续更新）：
