Spring Cloud（十一）Zuul知识点

叁歲伎倆 2022-12-16 15:24 135阅读 0赞

## 1、什么是zuul ##

zuul 是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。

Zuul是Netflix开源的微服务网关，他可以和Eureka、Ribbon、Hystrix等组件配合使用，它的核心是一些列的过滤器，这些过滤器可以实现的功能：身份认证与安全、审查与监控、动态路由、压力测试、负载分配、静态响应处理、多区域弹性。

## 为什么需要 Zuul ##

Zuul 作为路由网关组件，在微服务架构中有着非常重要的作用，主要体现在以下 6 个方面。

1、Zuul、Ribbon 以及 Eureka 相结合，可以实现智能路由和负载均衡的功能，Zuul 能够  
将请求流量按某种策略分发到集群状态的多个服务实例。

2、网关将所有服务的 API 接口统一聚合，并统一对外暴露。外界系统调用 API 接口时，  
都是由网关对外暴露的 API 接口，外界系统不需要知道微服务系统中各服务相互调  
用的复杂性。微服务系统也保护了其内部微服务单元的 API 接口，防止其被外界直  
接调用，导致服务的敏感信息对外暴露。

3、网关服务可以做用户身份认证和权限认证，防止非法请求操作 API 接口，对服务器  
起到保护作用。

4、 网关可以实现监控功能，实时日志输出，对请求进行记录。

5、 网关可以用来实现流量监控，在高流量的情况下，对服务进行降级。

6、API 接口从内部服务分离出来，方便做测试。

## 2、zuul 的作用 ##

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

*  验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
 *  审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。
 *  动态路由: 以动态方式根据需要将请求路由至不同后端集群处。
 *  压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平。
 *  负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求。
 *  静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群。
 *  多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。

## 3、Zuul和Nginx的区别 ##

**相同点**

> Zuul和Nginx都可以实现负载均衡、反向代理（隐藏真实ip地址），过滤请求，实现网关的效果

**不同点**

> Nginx–c语言开发  
> Zuul–java语言开发  
> Zuul负载均衡实现：采用ribbon+eureka实现本地负载均衡  
> Nginx负载均衡实现：采用服务器实现负载均衡  
> Nginx相比zuul功能会更加强大，因为Nginx整合一些脚本语言（Nginx+lua）  
> Nginx适合于服务器端负载均衡  
> Zuul适合微服务中实现网关

## 4、Zuul的工作原理 ##

> Zuul 的核心是一系列过滤器，可以在 Http 请求的发起和响应返回期间执行一系列的过滤器。

**Zuul 包括以下 4 种过滤器**

*  PRE 过滤器：它是在请求路由到具体的服务之前执行的，这种类型的过滤器可以做  
    安全验证，例如身份验证、参数验证等。
 *  ROUTING 过滤器：它用于将请求路由到具体的微服务实例。在默认情况下，它使用  
    Http Client 进行网络请求。
 *  POST 过滤器：它是在请求已被路由到微服务后执行的。一般情况下，用作收集统计  
    信息、指标，以及将响应传输到客户端。
 *  ERROR 过滤器：它是在其他过滤器发生错误时执行的。

> Zuul 采取了动态读取、编译和运行这些过滤器。过滤器之间不能直接相互通信，而是通  
> 过 RequestContext 对象来共享数据，每个请求都会创建一个 RequestContext 对象。

**Zuul 过滤器具有以下关键特性**

*  Type（类型）：Zuul 过滤器的类型，这个类型决定了过滤器在请求的哪个阶段起作用，  
    例如 Pre、Post 阶段等。
 *  Execution Order（执行顺序）：规定了过滤器的执行顺序，Order 的值越小，越先执行。
 *  Criteria（标准）：Filter 执行所需的条件。
 *  Action（行动）：如果符合执行条件，则执行 Action（即逻辑代码）。

**Zuul 请求的生命周期**

**正常流程：**

请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。

**异常流程：**

整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。

如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。

如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]

## 5、Zuul路由规则配置 ##

**1、url方式（不建议使用）**

zuul:
      routes:
        api-a:      #key随意定义
          path: /service/a/**     #匹配service/a/为前缀的所有路径
          url: http://127.0.0.1:8082  #匹配service/a/为前缀的所有路径转发到此地址

请求`http://127.0.0.1:8769/service/a/1` 路由成功

> url方式，路径对应的服务地址写死的，不适用与同一个服务有多个实例的情况

**2、面向服务的路由**

eureka:
      client:
        serviceUrl:
          defaultZone: http://localhost:8761/eureka/
    server:
      port: 8769
    spring:
      application:
        name: service-zuul
    zuul:
      routes:
        api-a:
          path: /service/a/**
          serviceId: service-ribbon1
        api-b:
          path: /service/b/**
          serviceId: service-ribbon2

请求`http://127.0.0.1:8769/service/a/1` 路由成功

## 6、Zuul过滤器 ##

> Zuul作为网关的其中一个重要功能,就是实现请求的鉴权.而这个动作我们往往是通过Zuul提供的过滤器来实现的.

Zuul中的顶级过滤器是ZuulFilter.其中定义了四个最重要的方法.

public  abstract  ZuulFilter implements IZuulFilter{
    
        abstract  public  String  filterType();     //过滤器类型
    
        abstract  public  int  filterOrder();       //过滤器顺序.这个值越大,优先级越低
    
        boolean  shouldFilter();                    //来自IZuulFilter.要不要过滤
    
        Object  run() throws ZuulException;         //IZuulFilter. 过滤逻辑
    }

*  shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。
 *  run：过滤器的具体业务逻辑。
 *  filterType：返回字符串，代表过滤器的类型。包含以下4种：
    
     *  pre：请求在被路由之前执行
     *  routing：在路由请求时调用
     *  post：在routing和errror过滤器之后调用
     *  error：处理请求时发生错误调用
 *  filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

**Zuul自定义过滤器**

[Spring Cloud（十二）Zuul实战][Spring Cloud_Zuul]

## 7、Zuul负载均衡 ##

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。

但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

zuul:
        retryable: true
    ribbon:
        ConnectTimeout: 500                  # 连接超时时间(ms)
        ReadTimeout: 2000                    # 通信超时时间(ms),超时时长不能超过hystrix的熔断时长
        OkToRetryOnAllOperations: true       # 是否对所有操作重试
        MaxAutoRetriesNextServer: 2          # 同一服务不同实例的重试次数
        MaxAutoRetries: 1                    # 同一实例的重试次数
    hystrix:
        command:
            default:
                execution:
                    isolation:
                        thread:
                            timeoutInMillisecond: 6000  # 熔断超时时长：6000ms

**PS**

ConnectTimeout(连接超时时长) + ReadTimeout(读取超时时长) 是2500。

但是ribbon会进行一次重试. 那么默认就是(ConnectTimeout+ReadTimeout) \* 2 是真正的总超时时长。

所以timeoutInMillisecond熔断的时长必须要超过这个时间,否则会报错.。或者把ribbon的MaxAutoRetries设为0,那么久不进行重试了。

## 8、Zuul高可用配置 ##

Zuul作为服务网关，控制这全部请求的统一入口。Zuul的高可用服务提供是必要的。

**Nginx+Zuul集群实现高可用网关**

> 1、通过Nginx实现负载均衡  
> 2、Zuul集群实现高可用

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/55d0d502dc9b4cfea43fb4ff55451ebc.png
[Spring Cloud_Zuul]: https://blog.csdn.net/qq_29914837/article/details/109192156
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzI5OTE0ODM3_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/74e3df67ba26417f83781b824897c88a.png