问题描述

• 尝试使用zuul的pre filter修改request的uri
• 过程中设置filter的order为0
• 发现uri无法被修改
• zuul filter 如下

  
  public class SimpleFilter extends ZuulFilter {
    @Override
    public String filterType() {
        return "pre";
    }
  
    @Override
    public int filterOrder() {
        return 0;
    }
  
    @Override
    public boolean shouldFilter() {
        return true;
    }
  
    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();
        
        String uri = request.getRequestURI()
        String newUri = uri.replaceAll("/users/\d*","/users/5");
        //仅仅只是为了修改uri
        ctx.set("requestURI", newUri);
        return null;
        //请求uri /api/users/1  应该被修改成
        //  ----> /api/users/5
    }
    }
  

矛盾点

根据网上demo，使用RequestContext.getCurrentContext().set()确实可以做到修改请求的uri，那么为什么经过filter请求的uri仍然没有任何改变？

解决思路

• Q1：在set之后发现使用ctx.getRequest().getRequestURI()此时的值和set之前完全一样。是否是调用的api是错的？
• A1:根据查看网上demo的结果：
  • RequestContext.getCurrentContext()：专门用来获取用户发送给zuul的所有请求内容。
  • RequestContext.getCurrentContext().getRequest()通过这个api我们可以获得用户发过来的原生请求，也就是说通过这种方式获得的request的内容永远和用户发送过来的完全一样。就算使用setRequest也不会修改这个api获取的request信息
    • 这个api的存在：为了让我们能够看到用户原生发出的请求
    • 因此，这就可以解释，当我们使用了这个api查看我们set request的结果，自然就发现请求好像从来没有改变过。其实，是因为这个请求获取的是原生的用户请求。
  • RequestContext.getCurrentContext().get("{key}")：这个api是为了获取当前真实请求的内容而不是原生的请求内容。
    • 例子：假设我们发到zuul的请求URI是/api/users/1 使用filter将其修改为/api/users/5
      • 那么使用RequestContext.getCurrentContext().getRequest().getRequestURI()得到的就是RequestContext.getCurrentContext().getRequest().getRequestURI()前一个uri。
      • 使用RequestContext.getCurrentContext().get("requestURI")得到的就是后面这个uri

结论：get***()获取原生的request信息。get("*****")获取当前真实request信息。

• Q2:zuul不仅可以让我自定义filter，他也默认的会在zuul的运行过程中添加了一些过滤器，他们是什么，作用又是什么？
• A2:根据介绍我们知道，zuul中根据作用时机，将过滤器分成了四大type。然后根据过滤器的order依次执行filter。由小执行到大。因此其提供的默认过滤器也符合这些规范。并且他提供的默认过滤器一定会执行。下图就是简单描述默认filter作用和时机。

• 因此我们可以知道，pre阶段最后一个必然执行的filter是PreDecorationFilter（5）他的作用：是为当前请求做一些预处理，比如：进行路由规则的匹配、在请求上下文中设置该请求的基本信息以及将路由匹配结果等一些设置信息等，这些信息将是后续过滤器进行处理的重要依据。
  • zuul通过路由匹配规则，在这个filter中对请求的request的所有内容进行改写，并且赋值
  • 举个例子：通过RequestContext.getCurrentContext().get获取到的所有属性都是在这个filter中进行赋值的。
  • 简单总结：这个filter就是将原生的请求进行彻底改变，变成一个可以发送到对应服务器的正确的请求。
  • 得出结论：
    • 修改uri的filter应该在这个filter之后做。因为在这个filter之前修改的内容都会在这个filter中根据路由匹配规则，改成一个可以获取到真实服务器response的请求。因此在这个filter之前对request的修改，都会在这个filter中被重置。
    • 所有的RequestContext.getCurrentContext().get的数据在这个filter之前都是undefined。因为，只有这个filter具有对request进行修改和包装和赋值的功能。

----> 这个问题解决

• 修改filter order为大于5的值，这样为了保证我们的filter修改的request不会再5被重置。
• 通过RequestContext.getCurrentContext().get("requestURI")获取真实的uri，这个requestURI属性已经在filter5的时候被包装过了。

反思

• 学习东西的时候，总是会害怕而且不想看一些比较深的内容，比如这个默认filter，我在刚开始学习的时候就看到有人用他们做对比学习，但是看起来多而且复杂，我就没有看。对于新的知识还是感觉有些恐惧心理。

Action

• 遇到任何不想看的东西，就必须逼迫自己去看，并且。以后学习的时候，看不懂的就全部列出来，然后每天从列的东西里面挑一个来学习。