spring-cloud（九）使用Zuul作为微服务网关

最新推荐文章于 2022-12-01 13:45:52 发布

保护我方胖虎

最新推荐文章于 2022-12-01 13:45:52 发布

阅读量5.4k

点赞数

分类专栏： springcloud 文章标签：网关 java spring

本文链接：https://blog.csdn.net/leilei1366615/article/details/108569154

版权

springcloud 专栏收录该内容

22 篇文章 25 订阅

订阅专栏

spring-cloud-Hoxton.SR6（九）网关 Zuul

本文spring-cloud 版本为：hoxton.sr6

本文spring-boot版本为：2.2.x-2.3.x

微服务不怎么接触的小伙伴可能有些疑惑，看到我的标题，心中难免产生了一些问题，问题可能如下！

什么是网关？
为什么要使用网关/不使用网关会有什么样的问题？

好的，我们先简单的了解下基本概念吧！

（一）微服务网关基本概念！

（1）什么是网关？

微服务中的网关也是一个独立业务的微服务，它的作用是统一各个服务的入口，网关统一服务入口，可方便实现对平台众多服务接口进行管控，对访问服务的身份认证、防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等等…

（2）为什么要使用网关/不使用网关会有什么样的问题？

我们来举个实际例子…

在前边的一系列学习之中，尤其是前边的OpenFeign结合Hystrix组件的使用中，我通常是以Order服务作为请求入口的（即浏览器直接调用我的order服务，order 服务负载调用我的两个product服务)

服务调用流程图例如下：

可以看到，我原来是以order作为了服务端入口，PC 直接请求到了order 服务，不知各位有没有注意到一个问题呀！如果真的是Order服务，那么这个服务安全性是不是很重要？我原来都没登录就直接CRUD了？？所以这肯定是不行的…

因此，暴露出了一个第一个问题：微服务未登录便直接访问，毫无安全性！

这个问题有没有办法解决呢？当然有啊！

没有登录，我们就让他登录不就得了？给order加个拦截器不就好了？好，那咱们就加！

OK,加好了，order安全性有保障了！那么问题来了，你Order一个服务有保障有什么用呢？我product不用保障安全性的吗？

这个时候怎么解决呢？好办！feign调用将order的登录信息传递到product即可！（需要feign额外配置）这样不就保证了product安全性了？

可能你的想法对应拓扑图就是这样…

如果你的整个后端微服务小服务就图上三个,那么你的服务安全问题便解决了！但是哈，实际开发中，微服务都是几十上百个啊！怎么会才我图上那般，一个请求入口呢（图上为order)

可能整个微服务链路是这样！…

**可能每一个微服务都会作为一个请求入口，然后去调用其他服务…**那这样,你一个链路鉴权做了，安全性保证了，其他链路呢？我原来链路鉴权完善了，现在在原有链路基础上新加微服务，鉴权又要改？

因此，一下暴露出了几个问题：

微服务众多，无统一请求入口

微服务众多，鉴权困难

…

基于这几个问题：所以出来了服务网关组件,网关的出现解决的问题就包括了微服务下的服务统一请求入口、请求转发、鉴权等等

有了服务网关，于是整个微服务请求拓扑图变为了这样！

再细化：

用户的请求都经过网关，无论你是要调哪个服务以及哪个服务作为原本的请求入口，现在全部统统请求走到网关上，在网关中进行登录校验判断等，校验成功，再根据你的请求，网关帮你转发到对应服务上！

即原本调用逻辑：

用户请求---->order（校验鉴权)----->product------>…
用户请求---->file(校验鉴权)------>mail------>…

改用网关后调用逻辑:

用户请求---->网关（鉴权）—根据请求转发到对应服务—>order ? file ? xxx ?

（3）网关的作用

统一入口：未全部为服务提供一个唯一的入口，隔离各个服务与外部直接联系，保障了后台服务的安全性。
鉴权校验：识别每个请求的权限，拒绝不符合要求的请求。
动态路由：动态的将请求路由到不同的后端集群中。
减少客户端与服务端的耦合：服务可以独立发展，通过网关层来做映射。

（二）Zuul网关！

（1）zuul知识点信息

What is Zuul?

Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.

Zuul是从设备和网站到Netflix流应用程序后端的所有请求的前门。作为边缘服务应用程序，Zuul旨在实现动态路由，监视，弹性和安全性。它还可以根据需要将请求路由到多个Amazon Auto Scaling组。

zuul官网地址:

springcloud 官方集成zuul文档

（2）zuul的使用

一共分为三个大部分：动态路由、网关作鉴权处理、网关作接口限流

（1）两分钟入门

（1）搭服务

我们需要新搭建一个网关服务，并引入依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-consul-discovery</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

核心依赖一共三个:

consul依赖（网关也是需要注册到咱们注册中心的，我们呢，还是使用consul作为注册中心)

zuul依赖：使用zuul功能必要的依赖

web依赖：（网关也需要作为一个服务进行启动，其服务只负责网关功能，不处理其余业务逻辑）

（2）开启网关功能

与其他cloud 的组件一样，引入依赖后，其功能仍需要我们注解进行开启

（3）基本配置

首先，我们将其作为一个最基础的服务，连接consul注册中心先

server:
  port: 7001 #端口
spring:
  application:
    #服务名称
    name: zuul-gateway
  ###开始配置consul的服务注册
  cloud:
    consul:
      #consul服务器的主机地址 默认:localhost
      host: localhost
      #consul服务器的ip地址 默认:8500
      port: 8500
      discovery:
        #是否需要注册
        register: true
        #注册的实例ID (唯一标志)
        instance-id: ${spring.application.name}-1
        #服务的名称
        service-name: ${spring.application.name}
        #当前服务的请求端口
        port: ${server.port}
        #指定开启ip地址注册
        prefer-ip-address: true
        #当前服务所在 ip ${spring.cloud.client.ip-address}
        ip-address: 192.168.124.17

（2）动态路由功能

我们前边也讲过了，网关一个非常大的作用便是统一入口，小伙伴们可能有些疑惑，如何统一呢？统一了入口，那么他是如何通过我的请求找到对应的服务呢？哎！这个时候，你的这个问题解决措施，便是zuul的功能动态路由了！

动态路由白话展示：

没用网关前：用户请求>order服务直接调用order服务的接口 localhost:9002/order/findAll

用了网关：用户请求>网关>order服务现在我们则要调用网关服务，然后让网关去调用Order localhost:7001/zuulserver/order/findAll

（1）传统路由功能

此配置是什么意思呢？

我们首选要关注点： zuul.routes.xx 没什么讲的，路由配置固定格式

demo-url: 具体的某一路由配置此名称无实际意义，需要保证在配置中唯一即可，可随意命令，zs …lisi 都行,看你喜欢

path: 固定配置格式需要映射的url 与nginx 映射配置一致

**url：**固定配置格式,被映射的url 即当请求触发到映射时被路由（转发）到哪个url

server:
  port: 7001 #端口
zuul:
  routes:
    #路由配置规则名 可多个，但配置文件中不可重复,此名称可以自定义
    demo-url:
      #映射的url
      path: /demo/**
      #路由转发的url 即路由规则触发时 zuul 帮我们的请求转发到何url
      url: http://localhost:8081/

即zuul 路由配置为：

server.port=7001
zuul.routes.你具体的某一路由配置名.path=xxxx
zuul.routes.你具体的某一路由配置名.url=xxxx
#例如：
zuul.routes.zs.path= /xxoo
zuul.routes.zs.url= http://www.baidu.com
#那么如上呢，则是配置了一个zs 路由规则，那么当我访问到 http://localhost:7001/xxoo/dd,则实际上zuul帮我们把请求转发到了 http://www.baidu.com

简单一句话举例：例如我现在访问网关 ``http://localhost:7001/demo/dd,那么该请求则会被zuul网关路由转发到我配置的 url:http://localhost:8081/dd`

ok，我们来验证一波

首先，我们访问一下zuul网关不存在的url…http://localhost:7001/xxl 发现报错404，为什么呢？因为啊，其Url在zuul网关服务中确实不存在啊！且没有触发任何路由规则

我们上边配置的，path：/demo/** ,那么只有url 含有 /demo时才会被触发

我们将路由触发规则 /demo 加上，测试一下

xxl job executor running. 这个响应在哪里来的呢？在我的一个普通Boot 项目

那么本次请求流程呢，则为：

用户请求网关：http://localhost:7001/demo/xxl 触发到了 demo-url 路由配置 请求被路由到了 http://localhost:8081/xxl接口

…

此种路由方式呢，仅仅证明了zuul其路由转发规则，但是，如果仅有以上配置的话，在我们的微服务中的作用，就比较局限了，为什么呢？因为啊，咱们的微服务这么多，我如果每一个都需要去写死配置path 、url的话，那不是累死？如果某些服务后续迁移了服务器地址，那么我们的url 不是又要更改了？

…

微服务注册中心一个强大的功能大家不要忘记了：服务注册列表清单！

而且，既然网关也是要加入到注册中心的，那么他自然也会在注册中心的服务注册表进行注册的！

既然他要注册，那就好办了啊，它是否可以像OpenFeign 一般通过服务名去找到对应服务呢？

答案是：true (MD废话，这点要求都不行，如此繁琐的配置早被淘汰了）

（2）路由匹配规则

匹配规则: 即路径配置规则

通配符	说明	演示
?	匹配单个字符	/order/? 、/order/1、/order/z
*	不支持多级目录	/order/*、/order/zs 、order/aaa
**	支持多级目录	/order/**、 /order/zs/li/wangwu/aa/cc

（3）根据服务进行路由（1）

让path不再映射到某个具体url上，而是映射到某个微服务上，具体的url交给注册中心的服务发现机制去自动维护，我们只需要指定服务名即可，无序关心服务接口地址是否变更，这类路由称为面向服务的路由。

yml配置路由规则修改：

server:
  port: 7001 #端口
zuul:
  routes:
    #路由配置规则名 可多个，但配置文件中不可重复,此名称可以自定义
    demo-url:
      #映射的url
      path: /demo/**
      #路由转发的url 即路由规则触发时 zuul 帮我们的请求转发到何url
      url: http://localhost:8081/
    #order服务路由配置
    order-route:
      #映射的url
      path: /order/**
      #路由转发的服务名
      service-id: demo-order
    #product服务路由配置
    product-route:
      path: /pro/**
      service-id: demo-product

与普通路由配置一致，我们只需将原来的url 修改为 service-id 指定服务名即可

这里需要注意一下：

指定的服务名，从注册表中copy最妥，我记得以前很早使用eureka 时候，注册表服务名为大写，我在配置中小写始终找不到对应服务…

那么，我们还是来分析一下配置

server.port=7001
zuul.routes.你具体的某一路由配置名.path= 触发路由的 映射Url
zuul.routes.你具体的某一路由配置名.service-id=服务名 （请求被路由到哪个服务）
#例如：
zuul.routes.zs.path= /xxoo
zuul.routes.zs.url= demo-product
#那么如上呢，则是配置了一个zs 路由规则，那么当我访问到 http://localhost:7001/xxoo/dd,则实际上zuul帮我们把请求转发到了 demo-product 服务中的/dd请求

OK！测试一番！

我们呢，就先测试一下触发order请求吧，以我们以前写OpenFeign组件讲解时的order接口为例

但是哈，我们现在是通过网关去访问了！那么如何才能触发网关路由规则请求到Order服务呢？且具体到 /find/product/{id} 这个接口呢？

已知order服务路由规则如下

#order服务路由配置
order-route:
  #映射的url
  path: /order/**
  #路由转发的服务名
  service-id: demo-order

且 order服务原接口url为：/order/find/product/{id}

那么如果要从网关触发路由规则，我们请求网关Url 则要变为这样：http://localhost:7001/order/order/find/product/{id}

这个url中呢，第一个/order 为zuul网关中的路由配置 path （即满足路由的触发条件），当满足后，会将其触发条件在路由的时候抹掉实际上请求Url 则会变为：http://order服务所在IP:端口/order/find/product/{id}

postman 请求测试：

额…出师不利？网关超时？

…

首先，咱们检查下请求的接口吧，我们的调用逻辑链为：请求>网关>order>product ,按照这个链路进行排查

原来如此，我们的product服务 9001 线程睡眠了4秒，最终导致网关超时了！

网关超时问题解决：

百度、谷歌永远的神！

zuul网关超时时间默认很短，我们需要额外配置，防止某些接口因业务逻辑复杂本身接口耗时较长导致系统出错！

zuul 网关服务yml配置更改，新增超时时间

zuul:
  host:
    connect-timeout-millis: 15000 #HTTP连接超时要大于Hystrix的超时时间
    socket-timeout-millis: 60000  #socket超时
ribbon:
  # 连接超时时间(ms)
  ConnectTimeout: 20000
  # 读取超时时间(ms)
  ReadTimeout: 20000

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation: #命令的执行超时时间  超时将执行回退
          thread:
            timeoutInMilliseconds: 10000

配置好后，从起项目，再测一波！

测试product服务路由规则配置

调用网关：http://localhost:7001/pro/product/1 触发配置的product路由规则 path:/pro/**，请求转发到了 demo-product 服务，且发现，网关调用也含有负载均衡效果

（4）根据服务进行路由（2）

根据服务路由配置其实还可以简化

上方为：

zuul.routes.你具体的某一路由配置名.path= 触发路由的 映射Url
zuul.routes.你具体的某一路由配置名.service-id=服务名 （请求被路由到哪个服务）

可简化为：

zuul.routes.服务名= 映射地址

此二者，实现的功能是一样的一个是以pro/** 前缀触发路由规则到 demo-product服务、一个是以/zsls/**为前缀触发路由规则到demo-product服务

测试查看效果：

（5）注意了：zuul路由规则默认配置

实际上，Zuul在注册到微服务群的注册中心之后，它会为注册表上的中每个服务都创建一个默认的路由规则，默认规则的path会使用serviceId配置的服务名作为请求前缀

默认路由规则验证：

首先，我们注释掉我们的order服务相关的路由配置

重启网关服务！通过服务名path 去调用Order服务中的接口

查看zuul网关所有的路由规则！

开启端点暴露（这个东西，生产时记得关掉）

management:
  endpoints:
    web:
      exposure:
      	# * 则暴露所有断点！
        include: '*'

http://localhost:7001/actuator/routes

可以看到，我们除了在网关Yml 配置的两个 product服务路由规则外，额外还有以product服务名作为path的路由规则，我们没有配置的demo-order 默认也配置了规则

问题浮现了！如果是这样的话，那么我们不希望的开放的服务有可能也会被外部访问到，那么服务的安全性似乎也不是那么可靠了！是否可以关闭其默认的配置规则呢？

当然是可以的

（6）关闭路由规则 -整个服务

关闭默认路由规则

zuul:
  # 关闭demo-order路由规则
  ignoredServices: demo-order

配置后，重启网关再次访问路由端点，发现order 相关的路由配置已经没了

我们再PostMan测一下

这样，我们就忽略了其默认的配置规则了，外部也无法通过服务名映射去访问我们不想开启外部访问的服务了！

如果想要关闭所有微服务默认路由规则，则写 * 即可

zuul:
  # 关闭所有微服务默认路由规则
  ignoredServices: *

（7）关闭路由规则 -精确到某些url

可能有时候，我们不想关闭整个服务的路由规则，可能仅仅只是想关闭某一url

Zuul提供了用于忽略路径表达式的参数zuul.ignored-patterns,使用该参数可以用来设置不希望被API网关进行路由的URL表达式。

例如：我们要忽略的某一Url长这样

zuul:
  #忽略具体url路由
  ignored-patterns: /**/find/product/{id}/**

（8）路由前缀设置

我们不难发现，我们的路由设置都是各管个的例如path:/pro/** 、path:/order/**

可能某些时候，我么需要设置一个统一的前缀例如调用到网关的请求，我们给他设置/zs 、/lisi 等开头的url

OK，我就设置个我名字的前缀啦，哈哈

统一url请求前缀设置

zuul:
  # 所有请求的前缀，访问网关必须带上该前缀才能匹配路由
  prefix: /leilei

路由转发前缀设置

路由转发前缀即我们前边讲的 path设置的映射url ，触发路由的关键

我们前边，请求order，调用网关需要这样!

调用 http://localhost:7001/leilei/order/order/place/order 路由后实际调用到了

http://order服务ip：端口/order/place/order

前一个order 为路由前缀映射的url 后一个order 为order服务接口定义的统一 url 前缀

目前url中，两个order 多多少少看着有些别扭，那是因为哈，我们不做额外配置的时候，当请求匹配到的时候，路由前缀的时候会触发对应的路由规则将请求转发到对应服务，同时也会将我们设置的路由前缀移除掉

那么，如果不让其移除设置的路由前缀呢？

全局禁止移除路由前缀

zuul.stripPrefix=false

针对某一服务，禁止移除路由前缀

zuul.routes.你具体的某一路由配置名.strip-prefix=false

点进源码可以看到，其移除路由前缀默认设置了true,因为如需关闭该功能，则设置为false即可

我们，以order服务为例：

zuul:
  prefix: /leilei
    #order服务路由配置
    order-route:
      #映射的url
      path: /order/**
      #路由转发的服务名
      service-id: demo-order
      stripPrefix: false

我们首先，仍以原来的url请求试一试喜闻乐见—404

然后，我们再去除一个order前缀

发现成功了，说明，路由前缀移除取消，起了效果

我们原来的请求调用 http://localhost:7001/leilei/order/place/order 路由后实际调用到了

http://order服务ip：端口/order/place/order

由于路由前缀与order服务提供的接口统一前缀一致，取消路由前缀移除的时候则可以少写一个order

如果这里有小伙伴有点懵，我再给你举个例子！

例如：路由前缀默认移除的时候

原来我请求http://localhost:7001/leilei/order/aa/order 路由后，请求Url 实际变成了http://localhost:7001/leilei/aa/order 我们原本设置的路由前缀/order 被移除掉了

路由篇到这里差不多就完了，后续有了新东西再不断更新吧
贴上完整yml 配置

server:
  port: 7001 #端口
zuul:
  host:
    connect-timeout-millis: 15000 #HTTP连接超时大于Hystrix的超时时间
    socket-timeout-millis: 60000  #socket超时
  ignoredServices: '*'
  prefix: /leilei
  routes:
    #路由配置规则名 可多个，但配置文件中不可重复,此名称可以自定义
    demo-url:
      #映射的url
      path: /demo/**
      #路由转发的url 即路由规则触发时 zuul 帮我们的请求转发到何url
      url: http://localhost:8081/
    #order服务路由配置
    order-route:
      #映射的url
      path: /order/**
      #路由转发的服务名
      service-id: demo-order
      stripPrefix: false
    #product服务路由配置方式1
    product-route:
      path: /pro/**
      service-id: demo-product
    #product服务路由配置方式2
    demo-product: /zsls/**
  #忽略具体url路由
  ignored-patterns: /**/find/product/{id}/**
spring:
  application:
    #服务名称
    name: zuul-gateway
  #开始配置consul的服务注册
  cloud:
    consul:
      #consul服务器的主机地址 默认:localhost
      host: localhost
      #consul服务器的ip地址 默认:8500
      port: 8500
      discovery:
        #是否需要注册
        register: true
        #注册的实例ID (唯一标志)
        instance-id: ${spring.application.name}-1
        #服务的名称
        service-name: ${spring.application.name}
        #当前服务的请求端口
        port: ${server.port}
        #指定开启ip地址注册
        prefer-ip-address: true
        #当前服务所在 ip ${spring.cloud.client.ip-address}
        ip-address: 192.168.124.17
logging:
  level:
    com.leilei: debug
ribbon:
  # 连接超时时间(ms)
  ConnectTimeout: 20000
  # 读取超时时间(ms)
  ReadTimeout: 20000

hystrix:
  command:
    default:
      execution:
        timeout:
          enabled: true
        isolation: #命令的执行超时时间  超时将执行回退
          thread:
            timeoutInMilliseconds: 10000
# 仅在测试默认路由设置时使用了，后续不用可移除该配置
management:
  endpoints:
    web:
      exposure:
        # *则暴露所有端点
        include: '*'

（3）zuul网关处如何作鉴权

（1）鉴权演示

zuul 网关处作鉴权，主要是使用ZuulFilter ，通过其访问规则，在请求前进行校验即可，如果校验失败，且接口需要登陆则强制踢出

如何使用zuulFilter？

编写一个类继承ZuulFilter ，再交由Spring容器管理即可

ZuulFilter包含4个核心方法：过滤类型、执行顺序、执行条件、具体操作

String filterType();
int filterOrder();
boolean shouldFilter();
Object run();

filterType: 该方法需要返回一个字符串来代表过滤器的类型,这个类型就是Zuul中的4种不同生命周期

pre：在请求到达路由前被调用
route：在路由请求时被调用
error：处理请求时发生的错误时被调用。
post：在route和error过滤器之后被调用，最后调用。

**filterOrder：**过滤器执行顺序，数字越小，执行优先级则越高

shouldFilter: 过滤器是否生效 true 过滤器生效,且执行下方的run方法(过滤器业务逻辑，即需要过滤器干什么…)

run: 过滤器的具体逻辑

…

zuul 的过滤器核心方法，简单讲，就这些内容了，那么我们完全可以根在路由前执行一个登陆校验嘛！完成我们的鉴权操作！

那么，我们需要先把zuulfilter过滤器类型设置为 pre ：即请求到达路由前调用

    /**
     * 过滤器类型，前置过滤器  后置 访问时 等  登陆肯定是请求接口前进行判断 ，此处为前置
     * @return
     */
    @Override
    public String filterType() {
        return "pre";
    }

设置过滤器执行顺序数字

    /**
     * 执行优先级，值越小则优先级越高
     * @return
     */
    @Override
    public int filterOrder() {
        return 1;
    }

设置执行过滤操作

    /**
     * 过滤器是否生效，true则生效，且需要执行下方run方法逻辑
     * @return
     */
    @Override
    public boolean shouldFilter() {
        return true;
    }

模拟权限校验 --检验token是否存在

    /**
     * 登录校验模拟
     * @return
     * @throws ZuulException
     */
    @Override
    public Object run() throws ZuulException {
        //获取上下文对象
        RequestContext requestContext =  RequestContext.getCurrentContext();
        HttpServletRequest request = requestContext.getRequest();
        //模拟获取token 进行判断
        String token = request.getHeader("Authorization");

        if(StringUtils.isBlank((token))){
            token  = request.getParameter("Authorization");
        }
        //登录校验逻辑  根据业务场景自定义
        if (StringUtils.isBlank(token)) {
            requestContext.setSendZuulResponse(false);
            //返回响应码 401
            requestContext.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
            requestContext.setResponseBody(JSON.toJSONString(Result.builder()
                    .code(HttpStatus.UNAUTHORIZED.value())
                    .message("not-login")
                    .data(null)
                    .build()));
        }
        return null;
    }

交由Spring管理

测试一波：我们不加请求头

发现直接401 无法正确的访问接口

于是，我们给其加上一个请求头，由于run方法是校验请求头，且名字为:“token”

那么问题来了。我有的接口不需要登录咋办呢？

可以，我们灵活运营 run 、shouldFilter这两个方法不就行了？

改造我们的 shouldFilter方法

    /**
     * 过滤器是否生效，true则生效，且需要执行下方run方法逻辑
     * @return
     */
    @Override
    public boolean shouldFilter() {
        RequestContext requestContext = RequestContext.getCurrentContext();
        HttpServletRequest request = requestContext.getRequest();
        //如果是访问 /leilei/order/place/order 则需要登录，其余则不需要
        if ("/leilei/order/place/order".equalsIgnoreCase(request.getRequestURI())) {
            return true;
        }

        return false;
    }

至于怎么灵活配置，看你业务来呀！！可以精确匹配 ,eqals ，也可以看服务，startWith 等等,

…

（2）zuul无法传递请求头问题解决

由于哈，我们微服务群呢，通常只会将网关向外部暴漏，即外部能够直接访问到的仅只有网关！

我们其余服务的操作可能需要基于当前用户，当前用户信息从哪里来呢？从token! 无论你是jwt也好，还是其余什么也好，你都需要经过网关，将你的用户信息带到微服务内网群，提供服务使用！

我们来测试一下，token是否能够传递到我们的业务服务！

首先我们需要修改zuul网关配置：（由于开始设置了此Url 忽略路由）

测试：

额…似乎，没有我们的自定义的请求头信息呀！

那么，如何处理呢?

百度、谷歌程序员永远的神！

springcloud 已经出现很多年了，且 zuul 网关也算是一个快淘汰组件了，所以呢，很多仙贝（先辈）已经帮我们把坑踩得差不多了，无需扣脑壳扣半天，百度一分钟…

解决措施：

zuul:
  # 将该值设置为空  即不填值 
  sensitive-headers:

查看源码，我们可以得知，其默认忽略了此三个请求头。所以呀，我们请求经过zuul后，再传递到后续服务，如果不设置的话，这几个请求头就拿不到了！…

设置取消忽略后，我们来测一波！

成功拿到请求头信息…ok 打完收工！

zuul 网关的基本使用就先到这里了…下一篇更新 gateway 网关组件

**项目源码：springcloud-HontoxSr6-zuul**