网关的其中一个重要功能，就是实现请求的鉴权：zuulFilter

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

ZuulFilter

ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：

public abstract class ZuulFilter implements IZuulFilter{

    abstract public String filterType();// 过滤类型，前置过滤器，后置过滤器

    abstract public int filterOrder();// 过滤器的执行顺序，数字越小越先执行(0,1,2,3,8,9,100)
    
    boolean shouldFilter();// 来自IZuulFilter 返回true，必须执行过滤器；false，不执行过滤器

    Object run() throws ZuulException;// IZuulFilter   这是过滤器核心业务方法
}

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

过滤器执行生命周期：

这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。

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

所有内置过滤器列表：

自定义过滤器

过滤器场景非常多：

• 请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
• 异常处理：一般会在error类型和post类型过滤器中结合来处理。
• 服务调用时长统计：pre和post结合使用。

接下来我们来自定义一个过滤器，模拟一个登录的校验。基本逻辑：如果请求中有access-token=123参数，则认为请求有效，放行。

定义过滤器类

/**
     * 进行权限控制
     * 实现思路：
     *
     *      获取URL中的请求参数是否包含access_token，
     *      如果包含了，就放行
     *      如果未包含，则拒绝请求
     *
     * 难点：如果获取URL中的请求参数
     *
     *
     */
@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;
}

}

测试

没有token参数时，访问失败：

添加token参数后：

负载均衡和熔断

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 # 熔断超时时长：6000ms