SpringCloud笔记06-Zuul

传送门
SpringCloud笔记01-简介
SpringCloud笔记02-Eureka
SpringCloud笔记03-Ribbon
SpringCloud笔记04-Hystix
SpringCloud笔记05-Feign

简介：
Zuul是Netlix开源的微服务网关。核心是一系列的过滤器,这些过滤器可以完成以下功能。

• 身份认证与安全：识别每个资源的验证要求,并拒绝那些与要求不符的请求。
• 审查与监控：在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图。
• 动态路由：动态地将请求路由到不同的后端集群。
• 压力测试：逐渐增加指向集群的流量,以了解性能。
• 负载分配：为每一种负载类型分配对应容量,并弃用超出限定值的请求。
• 静态响应处理：在边缘位置直接建立部分响应,从而避免其转发到内部集群。
• 多区域弹性：跨越AWS Region进行请求路由,旨在实现ELB ( Elastic Load Balancing
  )使用的多样化,以及让系统的边缘更贴近系统的使用者。

Spring Cloud对Zuul进行了整合与增强。目前, Zuul使用的默认HTTP客户端是ApacheHTTP Client,也可以使用RestClient或者okhttp3.0kHttpClient,如果想要使用RestClient,可以设置ribbon.restclient.enabled-true;想要使用okhttp3.0kHttpClient,可以设置ribbon.okhttp. enabled-true

依赖

<dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-zuul</artifactId>
</dependency>

启动类注解：@EnableZuulProxy

yml配置

zuul:
  routes:
    user-service: # 这里是路由id，随意写
      serviceId: user-service # 指定服务名称
      path: /user-service/** # 这里是映射路径

可简化成：

zuul:
  routes:
    ignored-patterns: /user-service/getname/** # 不路由getname下的所有请求
    user-service: /user-service/** # 这里是映射路径

默认的路由规则：默认情况下，一切服务的映射路径就是服务名本身。也就是说上面这个映射规则可以完全不配置。

路径匹配：在zuul中，路由匹配的路径表达式采用ant风格定义
路由前缀

zuul:
  prefix: /api # 添加路由前缀

cookie与头信息
默认情况下，常用的cookie在spring cloud zuul网关中默认时不传递的，如果使用了spring security，shiro等安全框架构建的web应用通过spring cloud zuul构建的网关来进行路由时，由于cookie信息无法传递，web应用将无法实现登录和鉴权。为解决这个问题，以下介绍两种配置方式：

• 通过设置全局参数为空来覆盖默认值

zuul:
  routes:
    user-service:
      path: /user-service/**
      serviceId: user-service
  # 允许敏感头，设置为空就行了
  sensitive-headers:

• 通过指定路由的参数来设置

zuul:
  routes:
    user-service:
      path: /user-service/**
      serviceId: user-service
      # 将指定路由的敏感头设置为空
      sensitiveHeaders:

过滤器

1. ZuulFilter
   ZuulFilter是过滤器的顶级父类。其中定义的4个最重要的方法：

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种：

  1. pre：请求在被路由之前执行
  2. routing：在路由请求时调用
  3. post：在routing和errror过滤器之后调用
  4. error：处理请求时发生错误调用

• filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。

过滤器执行生命周期

• 正常流程：
  请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
• 异常流程：
  -整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
  -如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
  -如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。

2. 自定义过滤器

@Component
public class LoginFilter extends ZuulFilter{
    @Override
    public String filterType() {
        // 登录校验，肯定是在前置拦截
        return "pre";
    }

    @Override
    public int filterOrder() {
        // 顺序设置为1
        return 1;
    }

    @Override
    public boolean shouldFilter() {
        // 返回true，代表过滤器生效。
        return true;
    }

    @Override
    public Object run() throws ZuulException {
        // 登录校验逻辑。
        // 1）获取Zuul提供的请求上下文对象
        RequestContext ctx = RequestContext.getCurrentContext();
        // 2) 从上下文中获取request对象
        HttpServletRequest req = ctx.getRequest();
        // 3) 从请求中获取token
        String token = req.getParameter("access-token");
        // 4) 判断
        if(token == null || "".equals(token.trim())){
            // 没有token，登录校验失败，拦截
            ctx.setSendZuulResponse(false);
            // 返回401状态码。也可以考虑重定向到登录页。
            ctx.setResponseStatusCode(HttpStatus.UNAUTHORIZED.value());
        }
        // 校验通过，可以考虑把用户信息放入上下文，继续向后执行
        return null;
    }
}

负载均衡和熔断

Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：

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