大白话实战Gateway

网关功能

网关在分布式系统中起了什么作用？参考下图：

前端想要访问业务访问，就需要知道各个访问的地址，而业务集群服务有很多，前端需要记录非常多的服务器地址，这种情况下，我们需要对整个业务集群做一个整体屏蔽，这个时候就引入Gateway网关，它就是所有服务的请求入口。以后前端不需要记住每个微服务的地址，只需要记住网关的地址，它把请求发给网关，由网关来判断这个请求发给哪个服务，从而完成请求路由。
而网关如何实现把订单的需求转给订单服务而不是其他服务呢？依然要依赖服务注册/发现流程。所有的服务启动后，会注册到注册中心，这样网关就可以从注册中心中获取到所有微服务所在的地址，网关可以根据前端发送请求的路径可以判断该请求发给哪个服务，比如请求以order开头的就转给订单服务，这个时候，网关就可以从注册中心找到所有订单服务的机器列表端口号和访问地址。接下来随便挑个地址，把请求转发。挑选地址的时候，可以融入负载均衡算法，这个就是网关存在的意义。所以网关的功能如下：

1. 统一入口

以后所有流量的统一入口都可以经过网关。

2. 请求路由

交给网关的请求，网关会自动判断该交给哪个服务。

3. 负载均衡

在路由的时候，网关可以融入负载均衡算法，均衡集群中每个服务器的负载量。

4. 流量控制

sentinel可以控制每个服务的QPS，它还能融入网关，由于网关是统一入口，一旦和网关整合后，可以在入口处，对全局的QPS进行统一限流。

5. 身份认证

比如请求过来后，网关发现是未登录的用户，而访问的资源必须登录，那就可以把这个请求挡回，让重新登录。或者有些是非法攻击请求，也可以拦截。

6. 协议转换

比如前端发的请求带的是json数据，但后端微服务直接远程调用需要GRPC协议，网关就可以把json数据转为GRPC通用的数据模型，再往下转发。

7. 系统监控

由于所有的入口都在网关，那就可以监控每个请求，从收到到结束处理了多长时间，来统计全局的慢请求，统计当天的访问总量等等各种监控数据。

8. 安全防护

从网关层，我们可以配置防止跨站脚本攻击，SQL注入等常见的安全问题。

而我们接下来学的是Spring Cloud Gateway：

Spring Cloud Gateway有两个版本，一个是Reactive Server，是基于响应式生产的网关，它可以占用少量资源就能实现高并发，Server MVC是个传统的网关，用的是之前Serverlet那一套，现在都推荐使用响应式编程的网关。使用的时候两个的区别就是导入不同的starter。

接下来我们通过一个例子来熟悉网关的用法。

创建网关

来到项目中，由于网关不属于业务，它属于架构组件的一部分，所以推荐直接创建在cloud-demo下面，新创建个module。

在网关模块的pom文件中配置：
根据网关的原理，要做路由转发，需要用到路由中心，所以也引入nacos，配置中心可以暂时不需要，还要引入负载均衡。

 <dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-gateway</artifactId></dependency><dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-loadbalancer</artifactId></dependency>

接下来直接启动这个项目，它就是个网关了，即创建一个网关启动类：

每个项目都脱离不了它的配置文件，我们创建一个application.yml，并配置名称和nacos：

spring:application:name: gatewaycloud:nacos:discovery:server-addr: 127.0.0.1:8848
# 写上80端口，以后访问就不用加端口了
server:port: 80

我们来启动这个项目，然后去nacos服务列表查看：

我们访问网关如果能看到这个错误页面说明网关启动成功了：

路由-规则配置

创建好了网关，解析来在网关里面配置路由规则，让以/api/order/开头的所有请求交给订单服务，/api/product/开头的所有请求交给商品服务，这个怎么做呢？Spring cloud提供了两种方式，第一种在配置文件里面配置路由规则，第二种是使用编码的方式编写路由规则。

我们先来测试第一种，用配置文件，为了方便起见，我们新建一个application-route.yml配置文件：

spring:cloud:gateway:routes:- id: order-routeuri: lb://service-orderpredicates:- Path=/api/order/**- id: product-routeuri: lb://service-productpredicates:- Path=/api/product/**

说明：
uri: lb://service-order：lb是负载均衡的意思，即负载均衡访问订单服务

• Path=/api/order/**：访问以/api/order开头的网址

接下来需要给所有微服务的请求都加上前缀：

订单请求：

商品请求：

还有所有的远程调用也要加前缀（注意，OpenFeign客户端不能用@RequestMapping注解）：

重启订单和商品服务进行测试：

我们再启动一个订单服务，测试一下负载均衡：

请求两次，发现每个服务各打印了一次日志，说明负载均衡也没有问题：

路由-工作原理

通过路由配置，我们很容易的就知道网关的工作原理，如下图：

当请求进来后优先交给网关，网关里面会配置非常多的路由规则，每个路由规则重要的几项有：

• id

全局唯一不重复，

• uri

就是我们要去的目的地

• predicate

最终这个请求一定要交给指定的目的地，但是什么情况下才转给这个目的地，我们需要配置一个断言规则，规则可以有很多，因为它是一个数组的方式，如果多个的话，那就必须同时成立才可以，满足这个规则，就会把请求转给目的地。

• filter

转的过程中还可以进行一系列的filter过滤器。

所有可配置的参数如源码的变量：

我们主要就是看有多少断言规则，目前我们只是根据路径进行往下转，再就是看每次转的时候如何使用过滤器，做一些前置和后置的逻辑，另外需要注意，这些规则是有序的，如果第一个匹配上了，就不会匹配第二个了，比如第一个是订单，匹配上后，就不会往下匹配了。

此时我们可以配置order，越小优先级越高。

断言-长短写法

前面我们说了网关的三个核心：路由、断言和过滤器。

接下来我们看一下断言，常用的断言就是Path，看请求路径有没有满足某种规则，而断言功能是有路由断言工厂提供的，官网的路由断言工厂中列举了到底有多少种断言机制，用法都一样，我们测试一个，通过文档再看其他的就可以了。在测试之前，说一下它们的写法，在SpringCloud里面有两种写法，一种叫短写法，另一种叫全写法。区别如下图：

短写法就是断言的名，比如Path，等于一个值。而全写法，需要配置name是什么，这里是由于要用路径断言，所以写Path，参数args是什么，指的就是那些值。我们点开predicates源码就可以看到每个断言有两个参数：

name为什么可以配置为Path呢？实际上在底层对应的是:

这个断言的名字，完全取决于当时类在命名的时候，断言工厂RoutePredicateFactory前面的字符串是什么，这里我们要选择路径，字符串就是Path，而args参数取决于断言里面有个Config配置：

配置中有两个：

所以我们args参数第一个是partterns，即规则，第二个是matchTrailingSlash，默认是true。

设置为true，那么/red/1和/red/1/是一个路径，也就是后面加不加/都可以，否则就是不同路径了。

我们现在把订单改成了全写法后重启服务看看是否正常：

这里记住一点&#