SpringCloud-Zuul

一、SpringCloud zuul介绍

Zuul是spring cloud中的微服务网关。网关：是一个网络整体系统中的前置门户入口。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。

Zuul是一个微服务网关，首先是一个微服务。也是会在Eureka注册中心中进行服务的注册和发现。也是一个网关，请求应该通过Zuul来进行路由。

Zuul网关不是必要的。是推荐使用的。

使用Zuul，一般在微服务数量较多（多于10个）的时候推荐使用，对服务的管理有严格要求的时候推荐使用，当微服务权限要求严格的时候推荐使用。

二、工作原理

zuul的核心是一系列的filters，zuul把请求路由到用户处理逻辑的过程中，这些filter参与一些过滤处理，比如Authentication，Load Shedding等

Zuul使用一系列不同类型的过滤器，使我们能够快速灵活地将功能应用于我们的边缘服务。

这些过滤器可帮助我们执行以下功能：

• 身份验证与安全保障: 识别面向各类资源的验证要求并拒绝那些不满足要求的请求

  • 审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论

    • 动态路由: 以动态方式根据需要将请求路由至不同后端集群处

      • 压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平

        • 负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求

          • 静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群

            • 多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近

              三、过滤器的实现方式

              继承父类ZuulFilter。在父类中提供了4个抽象方法，分别是：filterType, filterOrder, shouldFilter, run。其功能分别是：

              filterType：方法返回字符串数据，代表当前过滤器的类型。可选值有-pre, route, post, error。

              • pre - 前置过滤器，在请求被路由前执行，通常用于处理身份认证，日志记录等；

                • route - 在路由执行后，服务调用前被调用；

                  • error - 任意一个filter发生异常的时候执行或远程服务调用没有反馈的时候执行（超时），通常用于处理异常；

                    • post - 在route或error执行后被调用，一般用于收集服务信息，统计服务性能指标等，也可以对response结果做特殊处理。

                      filterOrder：返回int数据，用于为同filterType的多个过滤器定制执行顺序，返回值越小，执行顺序越优先。

                      shouldFilter：返回boolean数据，代表当前filter是否生效。

                      run：具体的过滤执行逻辑。如pre类型的过滤器，可以通过对请求的验证来决定是否将请求路由到服务上；如post类型的过滤器，可以对服务响应结果做加工处理（如为每个响应增加footer数据）。

                      四、Zuul中默认实现的Filter

                      五、Zuul网关的容错（与Hystrix的无缝结合）

                      在spring cloud中，Zuul启动器中包含了Hystrix相关依赖，在Zuul网关工程中，默认是提供了Hystrix Dashboard服务监控数据的(hystrix.stream)，但是不会提供监控面板的界面展示。可以说，在spring cloud中，zuul和Hystrix是无缝结合的。

                      5.1 Zuul中的服务降级处理

                      在Edgware版本之前，Zuul提供了接口ZuulFallbackProvider用于实现fallback处理。从Edgware版本开始，Zuul提供了ZuulFallbackProvider的子接口FallbackProvider来提供fallback处理。

                      Zuul的fallback容错处理逻辑，只针对timeout异常处理，当请求被Zuul路由后，只要服务有返回（包括异常），都不会触发Zuul的fallback容错逻辑。

                      因为对于Zuul网关来说，做请求路由分发的时候，结果由远程服务运算的。那么远程服务反馈了异常信息，Zuul网关不会处理异常，因为无法确定这个错误是否是应用真实想要反馈给客户端的。

                      六、Zuul网关的限流保护

                      Zuul网关组件也提供了限流保护。当请求并发达到阀值，自动触发限流保护，返回错误结果。只要提供error错误处理机制即可。

                      Zuul的限流保护需要额外依赖spring-cloud-zuul-ratelimit组件。

                      6.1 全局限流配置

                      使用全局限流配置，zuul会对代理的所有服务提供限流保护。

                      6.2 局部限流配置

                      使用局部限流配置，zuul仅针对配置的服务提供限流保护。

                      6.3 限流参数简介

                      七、如何使用

                      1、导入zuul依赖

                      2、pom文件编写路由配置

                      • 如果不使用注册中心，我们可以直接通过url访问具体服务路径

                        • 因为已经有了Eureka客户端，我们可以从Eureka获取服务的地址信息，因此映射时无需指定IP地址，而是通过服务名称来访问，而且Zuul已经集成了Ribbon的负载均衡功能。

                          3、启动类

                          4、启动测试，会利用Ribbon进行负载均衡访问

                          5、简化路由配置

                          在刚才的配置中，我们的规则是这样的：

                          • zuul.routes..path=/xxx/**：来指定映射路径。是自定义的路由名。

                            • zuul.routes..serviceId=service-provider：来指定服务名。

                              而大多数情况下，我们的路由名称往往和服务名会写成一样的。因此Zuul就提供了一种简化的配置语法：zuul.routes.=

                              比方说上面我们关于service-provider的配置可以简化为一条：

                              6、默认路由配置

                              在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：

                              • 默认情况下，一切服务的映射路径就是服务名本身。例如服务名为：service-provider，则默认的映射路径就 是：/service-provider/**

                                也就是说，刚才的映射规则我们完全不配置也是OK的。

                                7、路由前缀

                                我们通过zuul.prefix=/gateway来指定了路由的前缀，这样在发起请求时，路径就要以/gateway开头。