1、什么是GateWay

在微服务架构中，一个系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢？如果没有网关的存在，只能在客户端记录每个微服务的地址，然后分别去调用。这样的话会产生很多问题:
- 客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性；
- 认证复杂，每个微服务都有独立认证；
- 存在跨域请求，在一定场景下处理相对复杂；

为解决上面的问题所以引入了网关的概念：所谓的API网关，就是指系统的统一入口，提供内部服务的路由中转，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、路由转发等。

目前主流的网关有：

- Zuul 1.x：Netflix开源的网关，基于Servlet框架构建，功能丰富，使用JAVA开发，易于二次开发问题：即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。

- Zuul 2.x：Zuul2 采用了Netty实现异步非阻塞编程模型，每个 CPU 核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式减少了线程数量，因此开销较小。2.x性能上是提升不少，但是开源时间太晚，SpringCloud等不下去了，搞了个GateWay；

- GateWay：Spring公司为了替换Zuul而开发的网关服务，底层为Netty。

- Nginx+lua：使用nginx的反向代理和负载均衡可实现对api服务器的负载均衡及高可用，lua是一种脚本语言,可以来编写一些简单的逻辑, nginx支持lua脚本，问题在于：无法融入到微服务架构中。

- Kong：基于Nginx+Lua开发，性能高，稳定，有多个可用的插件(限流、鉴权等等)可以开箱即用。问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。

Spring Cloud Gateway 基于Spring Boot 2.x、Spring WebFlux和Project Reactor，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。它的目标是替代Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控和限流。

特点：
1. 性能强劲：是Zuul的1.6倍；
2. 功能强大：内置了很多实用的功能，例如转发、监控、限流等；
3. 设计优雅，容易扩展；

路由(Route) 是 gateway 中最基本的组件之一，表示一个具体的路由信息载体。主要定义了下面的几个信息：
- id：路由标识、区别于其他route；
- uri：路由指向的目的地uri，即客户端请求最终被转发到的微服务；
- order：用于多个route之间的排序，数值越小排序越靠前，匹配优先级越高；
- predicate：断言的作用是进行条件判断，只有断言都返回真，才会真正的执行路由；
- filter：过滤器用于修改请求和响应信息；

执行流程：
1、Gateway Client向Gateway Server发送请求；
2、请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文；
3、然后网关的上下文会传递到DispatcherHandler，它负责将请求分发给RoutePredicateHandlerMapping；
4、RoutePredicateHandlerMapping负责路由查找，并根据路由断言判断路由是否可用；
5、如果过断言成功，由FilteringWebHandler创建过滤器链并调用；
6、请求会一次经过PreFilter--微服务--PostFilter的方法，最终返回响应；

2、GateWay工作流程

客户端向 Gateway 发出请求，如果Gateway Handler Mapping确定请求与路由匹配，则将其发送到Gateway Web Handler 处理程序。此处理程序通过特定于请求的Fliter链运行请求。Fliter被虚线分隔的原因是Fliter可以在发送代理请求之前（pre）和之后（post）运行逻辑。执行所有pre过滤器逻辑，然后进行代理请求。发出代理请求后，将运行“post”过滤器逻辑。

Filter过滤器作用：
- Filter在pre类型的过滤器可以做参数效验、权限效验、流量监控、日志输出、协议转换等；
- Filter在post类型的过滤器可以做响应内容、响应头的修改、日志输出、流量监控等；
这两种类型的过滤器有着非常重要的作用。

GateWay三大核心点

- Route（路由）
路由是构建网关的基础模块，它由ID，目标URI，包括一些列的断言和过滤器组成，如果断言为true则匹配该路由；

- Predicate（断言）
参考的是Java8的java.util.function.Predicate，开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），请求与断言匹配则进行路由；

- Filter（过滤）
指的是Spring框架中GateWayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改；

三个核心点连起来：
当用户发出请求到达GateWay，GateWay会通过一些匹配条件，定位到真正的服务节点，并在这个转发过程前后，进行一些及细化控制。其中Predicate就是我们匹配的条件，而Filter可以理解为一个拦截器，有了这两个点，再加上目标URI，就可以实现一个具体的路由了。

3、GateWay搭建基础

现在已经了解了GateWay整体的基础概念以后，来搭建一个GateWay module：cloudalibaba-gateway-9999

虽然名字是cloudalibaba，其实GateWay是SpringCloud的，跟alibaba没关系，只不过可以和SpringCloud Alibaba整合在一起使用。因此在引入相关依赖的时候，一定要注意和SpringBoot版本之间的兼容关系：

我这里SpringBoot用的是2.7.x的版本，所以父项目引入的 spring-cloud-dependencies 的版本就应该是2021.0.x。建议这个版本和SpringCloud Alibaba的版本保持一致，我这里SpringCloud Alibaba使用的是2021.0.4.0，所以最终 spring-cloud-dependencies 使用2021.0.4版本。

在9999子项目中引入GateWay和Nacos相关依赖，GateWay也需要注册到Nacos中：

配置9999项目的yml文件：

在9001项目中写一个Controller，匹配GateWay配置文件中的路径：

启动9001和9999，访问9999，验证GateWay是否转发成功：

二者也都成功注册到Nacos中：

GateWay的基本配置路由的方式，通过yml配置文件来完成，但是实际上GateWay还提供了另外一种配置方式。就是通过代码的方式进行配置，也就是通过@Bean注入一个RouteLocator。

新建一个GateWayConfig，其实这里的配置对应的就是yml中配置的对应内容：

在9001项目中写一个Controller，匹配GateWay Config中的路径：

启动9001和9999，访问9999，验证GateWay是否转发成功：

4、GateWay负载均衡

自动负载均衡

首先看一下9999的yml配置，这里的配置信息，其实有一些是不需要写的：

再次启动9001和9999，访问9999，验证GateWay是否转发成功：

可以看到，即使yml中注释了某些属性，依然不影响GateWay功能的使用。那么注释掉的那些属性到底是啥意思呢？

将9001和9002的Controller保持一致，并都注册到Nacos中，并且这俩服务名一致：

discovery.locator.enabled: true
是否与服务发现组件进行结合，通过serviceID（服务名称）转发到具体的服务实例。默认为false，为true时开启通过服务中心的自动根据 serviceID 创建路由的功能。

说人话就是GateWay会自动去读取当前Nacos中的服务，当前在Nacos中有俩服务9001和9002，GateWay读取到这两个服务之后，会自动在相同名称的服务间进行负载均衡。

在9999配置文件中打开discovery.locator.enabled，并将routes删除：

既然要实现负载均衡，自然少不了要在9999引入 spring-cloud-starter-loadbalancer 依赖

重启9999网关服务，在请求网关的时候需要将对应的服务名写在URL上：

手动负载均衡

在以上的yml配置中，进行服务转发的时候会将目标服务名称暴露，并且太过于灵活，那么可以通过手动配置来解决。就是使用routes配置：

重启9999网关服务，在请求网关的时候不需要将对应的服务名写在URL上：

其实在启用routes配置之后，discovery.locator.enabled已经不起作用了。

每一个Predicate的使用，可以理解为当满足条件后才会进行转发。每个Predicate之间是&&的关系，也就是说不管写了多少个断言规则，必须要满足所有条件才会转发。

Predicate种类：
1、After：匹配在指定日期时间之后发生的请求；
2、Before：匹配在指定日期之前发生的请求；
3、Between：需要指定两个日期参数，设定一个时间区间，匹配此时间区间内的请求；
4、Cookie：需要指定两个参数，分别为name和regexp（正则表达式），也可以理解Key和Value，匹配具有给定名称且其值与正则表达式匹配的Cookie；
5、Header：需要两个参数header和regexp（正则表达式），也可以理解为Key和Value，匹配请求携带信息；
6、Host：匹配当前请求是否来自于设置的主机；
7、Method：可以设置一个或多个参数，匹配HTTP请求，比如GET、POST；
8、Path：匹配指定路径下的请求，可以是多个用逗号分隔；
9、Query：需要指定一个或者多个参数，一个必须参数和一个可选的正则表达式，匹配请求中是否包含第一个参数，如果有两个参数，则匹配请求中第一个参数的值是否符合正则表达式；
10、RemoteAddr：匹配指定IP或IP段，符合条件转发；
11、Weight：需要两个参数group和weight（int），实现了路由权重功能，按照路由权重选择同一个分组中的路由；

After

匹配在指定时间之后发生的请求，可以对应提前上线业务。演示这种断言规则需要知道目前的时间是什么时候，比如：
我现在的时间是：
2022-11-16T23:08:39.184751300+08:00[Asia/Shanghai]
那么想设置为2022-11-17才可以访问，则需要将时间设置为：
2022-11-17T00:00:00.000000000+08:00[Asia/Shanghai]

重启9999之后，再去访问就会发现没到设置的时间请求就会报错：

需要指定两个参数，分别为name和regexp（正则表达式），也可以理解Key和Value。匹配具有给定名称且其值与正则表达式匹配的Cookie。简单理解就是路由规则会通过获取Cookie name值和正则表达式去匹配，如果匹配上就会执行路由，如果匹配不上则不执行。

设置Cookie的匹配规则：

使用Postman在请求的时候添加一个符合规则的Cookie：

那么请求的结果是正常的：

但如果使用一个不符合规则的Cookie：

请求的结果就会直接报错：

需要两个参数header和regexp（正则表达式），也可以理解为Key和Value，匹配请求携带信息。实际上就是请求头携带的信息，官网给出的案例是X-Request-Id，那就用这个做实验。

设置Header断言规则：

使用Postman在请求的时候添加一个符合规则的Header，那么请求的结果是正常的：

使用Postman在请求的时候添加一个不符合规则的Header，那么请求的结果直接报错：

Host

匹配当前请求是否来自于设置的主机。

设置Host断言规则：

使用Postman在请求的时候添加一个符合规则的Host，那么请求的结果是正常的：

使用Postman在请求的时候添加一个不符合规则的Host，那么请求的结果直接报错：

Method

可以设置一个或多个参数，匹配HTTP请求，比如GET、POST 等。

设置Host断言规则：

使用Postman在请求的时候添加一个符合规则的Method，那么请求的结果是正常的：

使用Postman在请求的时候添加一个不符合规则的Method，那么请求的结果直接报错：

Query

需要指定一个或者多个参数，一个必须参数和一个可选的正则表达式。匹配请求中是否包含第一个参数，如果有两个参数，则匹配请求中第一个参数的值是否符合正则表达式。

设置Query断言规则：

使用Postman在请求的时候添加一个符合规则的Query，那么请求的结果是正常的：

使用Postman在请求的时候添加一个不符合规则的Query，那么请求的结果直接报错：

Weight

需要两个参数group和weight（int），实现了路由权重功能，按照路由权重选择同一个分组中的路由。

设置Weight断言规则：

该路由会将约 80% 的流量转发到weighthigh.org，将约 20% 的流量转发到weighlow.org。

5、GateWay过滤器

路由过滤器允许以某种方式修改传入的 HTTP 请求或传出的 HTTP 响应。路由过滤器的范围是特定的路由，Spring Cloud Gateway 包含许多内置的 GatewayFilter 工厂。

GateWay内置了很多Filter：
1、GateWay内置的Filter生命周期为两种：pre（业务逻辑之前）、post（业务逻辑之后）；
2、GateWay本身自带的Filter分为两种： GateWayFilter（单一）、GlobalFilter（全局）；
3、单一的有32种，全局的有9种；

其实GateWay自带的这些过滤器基本上不怎么会使用到，就拿StripPrefix举个例子吧：StripPrefix有一个参数：parts。该parts参数指示在将请求发送到下游之前要从请求中剥离的路径中的部分数。

在9001服务上加一个context-path配置：