微服务网关Gateway(七）

前言zuul目前已经出现了分歧，zuul 升级到 Zuul2的时候出现了内部分歧，并且导致Zuul的核心人员的离职，导致Zuul2一直跳票，等了两年，目前造成的局面是Zuul已经没人维护，Zuul2一直在开发中目前主流的服务网关采用的是Spring Cloud 社区推出了 Gateway概念Zuul官网：https://github.com/Netflix/zuul/wikiZuul是所有来自设备

浮华1994

353人浏览 · 2021-04-14 17:32:17

浮华1994 · 2021-04-14 17:32:17 发布

前言

zuul目前已经出现了分歧，zuul 升级到 Zuul2的时候出现了内部分歧，并且导致Zuul的核心人员的离职，导致Zuul2一直跳票，等了两年，目前造成的局面是Zuul已经没人维护，Zuul2一直在开发中

目前主流的服务网关采用的是Spring Cloud 社区推出了 Gateway

概念

Zuul

官网：https://github.com/Netflix/zuul/wiki

Zuul是所有来自设备和web站点到Netflix流媒体应用程序后端的请求的前门。作为一个边缘服务应用程序，Zuul的构建是为了支持动态路由、监视、弹性和安全性。它还可以根据需要将请求路由到多个Amazon自动伸缩组。

Gateway

Cloud全家桶有个很重要的组件就是网关，在1.X版本中都是采用Zuul网关，但在2.X版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是SpringCloudGateway，一句话Gateway是原来Zuul 1.X 版本的替代品
在这里插入图片描述
Gateway是在Spring生态系统之上构建的API网关服务，基于Spring 5，Spring Boot 2 和 Project Reactor等技术。Gateway旨在提供一种简单而且有效的方式来对API进行路由，以及提供一些强大的过滤器功能，例如：熔断，限流，重试等。

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

Spring Cloud Gateway的目标提供统一的路由方式，且基于Filter链的方式提供了网关基本的功能，例如：安全，监控、指标和限流。
在这里插入图片描述

能做啥

反向代理
鉴权
流量控制
熔断
日志监控

使用场景

在这里插入图片描述
网关可以想象成是所有服务的入口

为什么选用Gateway

目前已经有了Zuul了，为什么还要开发出Gateway呢？

一方面是因为Zuul 1.0已经进入了维护阶段，而且Gateway是Spring Cloud团队研发的，属于亲儿子，值得信赖，并且很多功能Zuul都没有用起来，同时Gateway也非常简单便捷

Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。虽然Netflix早就发布了Zuul 2.X，但是Spring Cloud没有整合计划，因为NetFlix相关组件都进入维护期，随意综合考虑Gateway是很理想的网关选择。

Gateway特性

基于Spring Framework 5，Project Reactor 和Spring boot 2.0 进行构建

动态路由，能匹配任何请求属性
可以对路由指定Predicate（断言）和 Filter（过滤器）
集成Hystrix的断路器功能集成Spring Cloud服务发现功能
易于编写Predicate 和 Filter
请求限流功能
支持路径重写

Spring Cloud Gateway 和 Zuul的区别

在Spring Cloud Gateway Finchley正式版发布之前，Spring Cloud推荐网关是NetFlix提供的Zuul

Zuul 1.X 是一个基于阻塞IO的API Gateway
Zuul 1.x 基于Servlet 2.5使用阻塞架构，它不支持任何场连接，Zuul的设计模式和Nginx比较像，每次IO操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx用C++实现，Zuul用Java实现，而JVM本身会有第一次加载较慢的情况，使得Zuul的性能较差。
Zuul 2.X理念更先进，想基于Netty非阻塞和支持长连接，但Spring Cloud目前还没有整合。Zuul 2.X的性能相比于1.X有较大提升，在性能方面，根据官方提供的基准测试，Spring Cloud Gateway的RPS（每秒请求数）是Zuul的1.6倍。
Spring Cloud Gateway建立在Spring 5，Spring Boot 2.X之上，使用非阻塞API
Spring Cloud Gateway还支持WebSocket，并且与Spring紧密集成拥有更好的开发体验。

上述模式的缺点：

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

所以Zuul 1.X是基于Servlet之上的一种阻塞式锤模型，即Spring实现了处理所有request请求的Servlet（DispatcherServlet）并由该Servlet阻塞式处理，因此Zuul 1.X无法摆脱Servlet模型的弊端

WebFlux框架

传统的Web框架，比如Struts2，Spring MVC等都是基于Servlet API 与Servlet容器基础之上运行的，但是在Servlet 3.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.Predicate

开发人员可以匹配HTTP请求中的所有内容，例如请求头和请求参数，如果请求与断言想匹配则进行路由

Filter 过滤

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

Gateway工作流程

Web请求通过一些匹配条件，定位到真正的服务节点，并在这个转发过程的前后，进行了一些精细化的控制。

Predicate就是我们的匹配条件，而Filter就可以理解为一个无所不能的拦截器，有了这两个元素，在加上目标URL，就可以实现一个具体的路由了。
在这里插入图片描述
客户端向Spring Cloud Gateway发出请求，然后在Gateway Handler Mapping中找到与请求相匹配的路由，将其发送到Gateway Web Handler。
Handler在通过指定的过滤器链来将请求发送到我们实际的服务执行业务逻辑，然后返回。
过滤器之间用虚线分开是因为过滤器可能会在发送代理请求前（pre）或之后（post）执行业务逻辑。
在这里插入图片描述
Filter在 Pre 类型的过滤器可以做参数校验，权限校验，流量监控，日志输出，协议转换等。

在 Post类型的过滤器中可以做响应内容，响应头的修改，日志的输出，流量监控等有着非常重要的作用。

Gateway的核心逻辑：路由转发 + 执行过滤链

入门配置

引入依赖

	<!--gateway-->
	<dependency>
	    <groupId>org.springframework.cloud</groupId>
	    <artifactId>spring-cloud-starter-gateway</artifactId>
	</dependency>

修改YML

server:
  port: 9527

spring:
  profiles:
    active: payment_route 
  application:
    name: cloud-gateway
  #############################新增网关配置###########################
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true #开启从注册中心动态创建路由的功能，利用微服务名进行路由


eureka:
  instance:
    hostname: cloud-gateway-service
  client: #服务提供者provider注册进eureka服务列表内
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka
---
spring:
  cloud:
    gateway:
      routes:
        - id: payment_route # 路由的id,没有规定规则但要求唯一,建议配合服务名
          #匹配后提供服务的路由地址
          #uri: http://localhost:8001
          uri: lb://CLOUD-PAYMENT-SERVICE
          predicates:
            - Path=/payment/get/** # 断言，路径相匹配的进行路由
  profiles: payment_route

各字段含义如下：

id：我们自定义的路由 ID，保持唯一
uri：目标服务地址可以使用IP地址也可以使用微服务名称
predicates：路由条件，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。
filters：过滤规则，本示例暂时没用。

访问

在添加网关之前，我们的访问是

http://localhost:8001/payment/get/31

添加网关之后，我们的访问路径是

http://localhost:9527/payment/get/31

这么做的好处是慢慢淡化我们真实的IP端口号

路由匹配

在这里插入图片描述

Spring Cloud Gateway 的功能很强大，我们仅仅通过 Predicates 的设计就可以看出来，前面我们只是使用了 predicates 进行了简单的条件匹配，其实 Spring Cloud Gataway 帮我们内置了很多 Predicates 功能。

Spring Cloud Gateway 是通过 Spring WebFlux 的 HandlerMapping 做为底层支持来匹配到转发路由，Spring Cloud Gateway 内置了很多 Predicates 工厂，这些 Predicates 工厂通过不同的 HTTP 请求参数来匹配，多个 Predicates 工厂可以组合使用。

Predicate 介绍

Predicate 来源于 Java 8，是 Java 8 中引入的一个函数，Predicate 接受一个输入参数，返回一个布尔值结果。该接口包含多种默认方法来将 Predicate 组合成其他复杂的逻辑（比如：与，或，非）。可以用于接口请求参数校验、判断新老数据是否有变化需要进行更新操作。

在 Spring Cloud Gateway 中 Spring 利用 Predicate 的特性实现了各种路由匹配规则，有通过 Header、请求参数等不同的条件来进行作为条件匹配到对应的路由。网上有一张图总结了 Spring Cloud 内置的几种 Predicate 的实现。
在这里插入图片描述
图片来源于网络

说白了 Predicate 就是为了实现一组匹配规则，方便让请求过来找到对应的 Route 进行处理，接下来我们接下 Spring Cloud GateWay 内置几种 Predicate 的使用

通过时间匹配

Predicate 支持设置一个时间，在请求进行转发的时候，可以通过判断在这个时间之前或者之后进行转发。比如我们现在设置只有在2021年04月11日才会转发到我的网站，在这之前不进行转发，我就可以这样配置：

After Route Predicate

spring:
  profiles:
    active: after_route  

---
spring:
  cloud:
    gateway:
      routes:
        - id: after_route  #根据时间路由
          uri: http://httpbin.org:80 #在浏览器上访问http://localhost:9527/get，会显示http://httpbin.org:80/get返回的结果
          predicates:
            - After=2021-04-11T18:05:38.254+08:00[Asia/Shanghai]
  profiles: after_route

获取时间的测试方法为：

public class Test1 {
    @Test
    public void test() {
        System.out.println(ZonedDateTime.now());
    }
}

Spring 是通过 ZonedDateTime 来对时间进行的对比，ZonedDateTime 是 Java 8 中日期时间功能里，用于表示带时区的日期与时间信息的类，ZonedDateTime 支持通过时区来设置时间，中国的时区是：Asia/Shanghai。
After Route Predicate 是指在这个时间之后的请求都转发到目标地址。上面的示例是指，请求时间在2021年04月11日18:05:38之后的所有请求都转发到地址http://httpbin.org:80

添加完路由规则之后，访问地址http://localhost:9527会自动转发到http://httpbin.org:80。

Before Route Predicate

Before Route Predicate 刚好相反，在某个时间之前的请求的请求都进行转发。我们把上面路由规则中的 After 改为 Before，如下：

spring:
  profiles:
    active: before_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: before_route  #根据时间路由
          uri: http://httpbin.org:80 #在浏览器上访问http://localhost:9527/get，会显示http://httpbin.org:80/get返回的结果
          predicates:
            - Before=2021-04-11T18:05:38.254+08:00[Asia/Shanghai]  # 我进行测试的时间为 2021年04月14日
  profiles: before_route

就表示在这个时间之前可以进行路由，在这时间之后停止路由，修改完之后重启项目再次访问地址http://localhost:9527/
在这里插入图片描述
将时间修改为 - Before=2021-05-11T18:05:38.254+08:00[Asia/Shanghai] 则可以进行正常访问

Between Route Predicate

除过在时间之前或者之后外，Gateway 还支持限制路由请求在某一个时间段范围内，可以使用 Between Route Predicate 来实现。

spring:
  profiles:
    active: between_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: between_route  #根据时间路由
          uri: http://httpbin.org:80 #在浏览器上访问http://localhost:9527/get，会显示http://httpbin.org:80/get返回的结果
          predicates:
            - Between= 2021-04-11T18:05:38.254+08:00[Asia/Shanghai],2021-05-11T18:05:38.254+08:00[Asia/Shanghai]
  profiles: between_route

这样设置就意味着在这个时间段内可以匹配到此路由，超过这个时间段范围则不会进行匹配。通过时间匹配路由的功能很酷，可以用在限时抢购的一些场景中。

通过 Cookie 匹配

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

spring:
  profiles:
    active:  cookie_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: cookie_route
          uri: http://httpbin.org:80
          predicates:
            - Cookie=name, forezp
  profiles: cookie_route

使用 curl 测试，命令行输入:

curl http://localhost:9527 --cookie "name=forezp"

则会返回页面代码，如果去掉–cookie “name=forezp”，后台汇报 404 错误

通过 Header 属性匹配

Header Route Predicate 和 Cookie Route Predicate 一样，也是接收 2 个参数，一个 header 中属性名称和一个正则表达式，这个属性值和正则表达式匹配则执行。

spring:
  profiles:
    active:  header_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: header_route
          uri: http://httpbin.org:80
          predicates:
            - Header=X-Request-Id, \d+   # HeaderRoutePredicateFactory需要2个参数，一个是header名，另外一个header值，该值可以是一个正则表达式。 当此断言匹配了请求的header名和值时，断言通过，进入到router的规则中去。
  profiles: header_route

使用 curl 测试，命令行输入:

curl http://localhost:9527  -H "X-Request-Id:666666"

则返回页面代码证明匹配成功。将参数-H "X-Request-Id:666666"改为-H "X-Request-Id:neo"再次执行时返回404证明没有匹配。

通过 Host 匹配

Host Route Predicate 接收一组参数，一组匹配的域名列表，这个模板是一个 ant 分隔的模板，用.号作为分隔符。它通过参数中的主机地址作为匹配规则。

spring:
  profiles:
    active:  host_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: host_route
          uri: http://httpbin.org:80
          predicates:
            - Host=**.sunfeng.com #请求头中含有Host为www.sunfeng.com的请求将会被路由转发转发到配置的uri。
  profiles: host_route

使用 curl 测试，命令行输入:

curl http://localhost:9527 -H "Host: www.sunfeng.com" 
curl http://localhost:9527 -H "Host: md.sunfeng.com"

经测试以上两种 host 均可匹配到 host_route 路由，去掉 host 参数则会报 404 错误。

通过请求方式匹配

可以通过是 POST、GET、PUT、DELETE 等不同的请求方式来进行路由。

spring:
  profiles:
    active:  method_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: method_route
          uri: http://httpbin.org:80
          predicates:
            - Method=GET # 请求方式为GET的路由转发到此uri
  profiles: method_route

使用 curl 测试，命令行输入:

# curl 默认是以 GET 的方式去请求
curl http://localhost:9527

测试返回页面代码，证明匹配到路由，我们再以 POST 的方式请求测试。

# curl 默认是以 GET 的方式去请求
curl -X POST http://localhost:9527

返回 404 没有找到，证明没有匹配上路由

通过请求路径匹配

入门示例已经讲过
Path Route Predicate 接收一个匹配路径的参数来判断是否走路由。

spring:
  profiles:
    active:   path_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: path_route
          uri: http://httpbin.org:80
          predicates:
            - Path=/delay/{segment} #所有的请求路径满足/delay/{segment}的请求将会匹配并被路由
  profiles: path_route

如果请求路径符合要求，则此路由将匹配，例如：/delay/1
在这里插入图片描述
如果匹配不上则会报404

通过请求参数匹配

Query Route Predicate 支持传入两个参数，一个是属性名一个为属性值，属性值可以是正则表达式。

spring:
  profiles:
    active: query_route
---
spring:
  cloud:
    gateway:
      routes:
        - id: query_route
          uri: http://httpbin.org:80/get
          predicates:
            - Query=foo, bar  #配置了请求中含有参数foo，并且foo的值匹配ba.，则请求命中路由  http://localhost:9527/get?foo=bar
  profiles: query_route

访问 http://localhost:9527/get?foo=bar
在这里插入图片描述
访问 http://localhost:9527/get?foo1=bar

访问 http://localhost:9527/get?foo=bar1

这样只要当请求中包含 foo属性并且参数值是以 bar的字符串才会进行匹配和路由。

通过请求 ip 地址进行匹配（暂时未测试成功，稍后跟新）

总结

通过今天的学习发现 Spring Cloud Gateway 使用非常的灵活，可以根据不同的情况来进行路由分发，在实际项目中可以自由组合使用。同时 Spring Cloud Gateway 还有更多很酷的功能，比如 Filter 、熔断和限流等，下次我们继续学习 Spring Cloud Gateway 的高级功能。

示例代码-码云

开放原子开发者工作坊

开放原子开发者工作坊旨在鼓励更多人参与开源活动，与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动，如meetup、训练营等，主打技术交流，干货满满，真诚地邀请各位开发者共同参与！

更多推荐

一文解决Cellphonedb单细胞互作分析及可视化作图（2）

开放原子开发者工作坊

[工具使用]——时序图与UML类图

开放原子开发者工作坊

CTFHub技能树 Web-SQL注入详解

整数型注入我们输入 1不断尝试发现闭合方式就是 1 ，整数型存在两列order by 2存在两个注入点/?id=-1 union select 8,9爆库，当前数据库为sqli/?id=-1 union select 8,database()爆出所有表名,这里我们需要吧sqli转换为16进制/?id=-1 union select 8,group_concat(table_name) from i