SpringCloud - Gateway服务网关

0. 概述

① Gateway简介：

外部请求------》负载均衡（nginx）------》网关（Gateway）-----》微服务

Spring Cloud Gateway作为Spring Cloud生态系统中的网关，目标是替代Zuul 1，在Spring Cloud 2.x版本中，没有对新版本Zuul 2最新高性能版本进行集成，仍然使用的Zuul 1非Reactor模式的老版本，为了提升网关性能，Spring Cloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway目标是提供统一的路由方式，并且基于Filter链方式提供网关基本功能：安全、监控、指标、限流。

gateway之所以性能好,因为底层使用WebFlux,而webFlux底层使用netty通信(NIO)

网关的作用：反向代理、鉴权、流量控制、熔断、日志监控等。

在微服务架构中，网关的位置，位于各个微服务的上一层，通过网关后，就访问到了具体的微服务了。

② SpringCloud Gateway的特性：

• 基于Spring Framework 5+Project Reactor+Spring Boot 2.x进行构建
• 动态路由：能够匹配任何请求属性
• 支持路由指定Predicate（断言）和Filter（过滤器），而且编写容易
• 集成了Hystrix断路器功能
• 集成Spring Cloud服务发现功能
• 支持请求限流功能
• 支持路径重写功能

③ SpringCloud Gateway和Zuul 1.x的区别：

Zuul 1采用的是阻塞I/O的API网关，Zuul 1使用Servlet2.5的阻塞架构实现，不支持任何长连接（如WebSocket），Zuul的设计模式和Nginx比较像，每次I/O都从工作线程中选择一个执行，请求线程在工作线程完成之前一直是阻塞的，Nginx是C++实现，Zuul是Java实现，JVM在第一次的加载时候，会比较慢，所以Zuul的性能比较差

Zuul 2设计理念跟先进，基于Netty非阻塞和支持长连接，但是目前Spring Cloud没有整合它，Zuul 2的性能比Zuul 1性能有较大提升，Spring Cloud Gateway的性能也不错，官方测试数据表示，Spring Cloud Gateway的RPS（每秒请求数）是Zuul 1的1.6倍

Spring Cloud Gateway建立在Spring Framework 5+Project Reactor+Spring Boot 2.x之上，使用异步非阻塞API，Spring Cloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层使用了高性能的Reactor模式通信框架Netty；Spring Cloud Gateway还支持WebSocket，与Spring紧密集成拥有更好的开发体验

④ Zuul 1.x的模型：

SpringCloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是传统的Servlet IO处理模型。

servlet由servlet container进行生命周期管理，container启动时构造servlet对象并调用servlet init()进行初始化；container运行时接收请求，并为每一个请求分配一个线程(一般从线程池中获取空闲线程)然后调用service()方法，container关闭时调用servlet destory()方法销毁servlet。

servlet是一个简单的网络IO模型，当请求进入servlet container时，servlet container会为其绑定一个线程，在并发并不高的场景下，这种模型是适用的，但是一旦高并发，线程数量就会上涨，而线程资源代价是昂贵的（线程上下文切换内存消耗大）严重影响请求的处理时间，在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或者几个线程就能应对极大并发的请求，这种业务场景下servlet模型并没有优势。

所以Zuul 1.x是基于servlet之上的一个阻塞式处理模型，即Spring实现了处理所有request请求的一个servlet（DispatchServlet）并由该servlet阻塞式处理，所以SpringCloud Zuul无法摆脱servlet模型的弊端。

⑤ Webflux是什么：

是一个非阻塞的web框架，类似springmvc这样的，其底层使用了高性能的Reactor模式通信框架Netty

传统的web框架，比如说springmvc，struts2等都是基于servlet API与servlet容器基础上运行的，但是在servlet3.1之后有了异步非阻塞的支持。而WebFlux是一个典型的异步非阻塞框架，他的核心是基于Reactor的相关API实现的。相对于传统的web框架来说，它可以运行在诸如Netty以及Servlet3.1的容器上。非阻塞式+函数式编程

⑥ Gateway的核心概念：

路由：就是根据某些规则,将请求发送到指定服务上

断言：就是判断，果符合条件就是xxx，反之yyyy

过滤：路由前后过滤请求

路由的功能是由断言和过滤组合来实现的，一个Web请求发送后，先经过网关，网关里的断言和过滤用来判断这个请求是否需要路由转发，当断言为true，过滤器放行时候，这个请求进行路由转发，此时，请求才到达具体的微服务模块。

⑦ Gateway的工作原理：

客户端向SpringCloud Gateway发出请求，然后在Gateway Handler Mapping中找到与请求向匹配的路由，将其发送到Gateway Web Handler。Handler再通过指定的过滤器来将请你去发送到我们实际的服务执行业务逻辑，然后返回。

1. Gateway 案例

1.1 Gateway通过yml配置路由

① 创建cloud-gateway-gateway9527模块，修改pom.xml，加入spring-cloud-starter-gateway和spring-cloud-starter-netflix-eureka-client的坐标。记住这里需要删除一直配置的两个依赖，否则后面会报错

spring-boot-starter-web和spring-boot-starter-actuator

<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-eureka-client</artifactId></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-devtools</artifactId><scope>runtime</scope><optional>true</optional></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><optional>true</optional></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency>
</dependencies>

② 编写yml文件：

server:port: 9527
spring:application:name: cloud-gateway
eureka:instance:hostname: cloud-gateway-serviceclient:service-url:register-with-eureka: truefetch-registry: truedefaultZone: http://eureka7001.com:7001/eureka

③ 编写主启动类：

@SpringBootApplication
@EnableEurekaClient
public class GateWayMain9527 {public static void main(String[] args) {SpringApplication.run(GateWayMain9527.class,args);}
}

④ 针对pay 8001模块，给Gateway网关服务9527添加路由规则：

我们目前不想暴露8001端口，想在8001端口外面套一层9527

相比之前的yml，这里的yml多了Gateway结点，配置这个的目的在于隐藏localhost:8001的地址，如果想访问payment8001服务的/payment/get/**地址，之前需要访问http://localhost:8001/payment/get/1，配置了路由之后，访问http://localhost:9527/payment/get/1也可以实现，于是，原来的8001端口就隐藏了。

server:port: 9527
spring:application:name: cloud-gatewaycloud:gateway:routes:# - 是yml语法，代表数组的意思# 路由ID，没有固定规则，需要保证唯一- id: payment_route1# 路由到哪个地址，实际提供微服务的地址uri: http://localhost:8001# 路径匹配断言predicates:# 当访问http://localhost:9527/payment/get/1路由到localhost:8001/payment/get/1- Path=/payment/get/**- id: payment_route2uri: http://localhost:8001predicates:- Path=/payment/loadbalance
eureka:instance:hostname: cloud-gateway-serviceclient:register-with-eureka: truefetch-registry: trueservice-url:defaultZone: http://eureka7001.com:7001/eureka/

⑤ 测试：启动7001、8001、9527模块

访问http://localhost:9527/payment/get/1发现访问的是http://localhost:8001/payment/get/1：

1.2 Gateway 配置动态路由

现在存在的问题：真实服务地址写死了（如8001写死了，访问8002还得重新写），我们应该通过服务名来找服务，而不是通过服务地址找服务。

默认情况下，Gateway会根据注册中心注册的服务列表，以注册中心上微服务名为路径创建动态路由转发，从而实现动态路由的功能。

为了演示网关的负载均衡，修改Provider8001和Provider8002的yml配置文件，将它们的注册地址改成eureka7001的地址。启动Eureka7001和Provider8001和Provider8002服务。修改Gateway9527模块的application.yml配置文件，修改为如下内容。

主要将uri更改，uri: lb://cloud-payment-service # 使用微服务名称查找路由地址，lb是用于识别负载均衡的前缀，不能修改

server:port: 9527
spring:application:name: cloud-gatewaycloud: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/**              # 断言，路径相匹配的进行路由#- After=2020-02-21T15:51:37.485+08:00[Asia/Shanghai]#- Cookie=username,zhangsan#- Header=X-Request-Id, \d+  # 请求头要有X-Request-Id属性并且值为整数的正则表达式
eureka:instance:hostname: cloud-gateway-serviceclient: #服务提供者provider注册进eureka服务列表内service-url:register-with-eureka: truefetch-registry: truedefaultZone: http://eureka7001.com:7001/eureka

测试：启动7001、8001、8002、9527模块

通过浏览器访问http://localhost:9527/payment/lb，在页面端可以看到端口号的不断变化，如果要实现负载均衡，注意uri中的lb是固定的（uri: lb😕/cloud-payment-service），它是识别开启负载均衡的标志。

1.3 断言

在Gateway9527启动的时候，在Console可以看到如下内容，代表执行加载Predicate，我们目前使用的Predicate是Path。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0tXX5TmD-1606276855373)(assets/image-20201125111857615.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-n2DOnQcC-1606276855376)(assets/image-20201125113006088.png)]

① 时间断言

After：可以指定只有在指定时间后才可以路由到指定微服务；

这里表示只有在2020年的2月21的15点51分37秒之后访问才可以路由，在此之前的访问都会报404

Before：与after类似，他说在指定时间之前的才可以访问

Between：需要指定两个时间，在他们之间的时间才可以访问

② Cookie断言：只有包含某些指定cookie(key,value),的请求才可以路由

Cookie Route Predicate需要两个参数，一个是Cookie name，一个是正则表达式。路由规则会通过获取对应的Cookie name值和正则表达式匹配，如果匹配上就会执行欧，如果没有匹配上就不会执行。

这里表示cookie中包含username，并且username=zhangsan才可以路由

③ Header断言：只有包含指定请求头的请求,才可以路由， \d+表示正数,-123就路由转发失败

④ host断言：只有指定主机的才可以访问，比如我们当前的网站的域名是www.aa.com，那么这里就可以设置，只有用户是www.aa.com的请求才进行路由

⑤ Method断言：只有指定请求才可以路由，比如get请求…

⑥ Path断言：只有访问指定路径才进行路由；比如访问/abc才路由

⑦ Query断言：必须带有请求参数才可以访问

1.4 过滤器

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用，

Spring Cloud Gateway内置了多种路由过滤器，它们是通过Gateway Filter Factory工厂类产生的。

从生命周期来分类，可以分为Pre和Post，类似于Spring AOP的前置通知和后置通知。

从种类上来分类，可以分为Gateway Filter单一过滤器和Global Filter全局过滤器。具体可以参考官网，这个的配置也是在application.yml里加配置即可。

Gateway Filter：https://cloud.spring.io/spring-cloud-gateway/2.2.x/reference/html/#gatewayfilter-factories

Global Filter：https://cloud.spring.io/spring-cloud-gateway/2.2.x/reference/html/#global-filters

① 自定义过滤器：

自定义过滤器实现两个接口：

@Component
@Slf4j
public class GatewayFilter implements GlobalFilter, Ordered {@Overridepublic Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {log.info("全局过滤器："+new Date());String uname = exchange.getRequest().getQueryParams().getFirst("uname");//如果uname为空，就会过滤if(uname==null){log.info("用户名为null");exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);return exchange.getResponse().setComplete();}//放行，进行下一个过滤链return chain.filter(exchange);}@Overridepublic int getOrder() {return 0;}
}

测试： 如果请求时uname!=null则不会过滤，路由就会转发到指定路径访问，如果为null就不会放行