zuul route filter

情景描述

• 使用postman请求后端服务器http://localhost:8085/api/users/1可以顺利拿到response
• 使用zuul做route

server.port=8888
UserCenter:
  path: /user-center/**
  url: http://localhost:8085

• 使用route filter
• 请求https://localhost:8888/user-center/api/users/1
• 报错：404
• 但是将filter的类型修改成pre，就一直可以通过

矛盾点

• 正常情况下不论任何时候只要请求http://localhost:8085/api/users/1可以拿到response，那么https://localhost:8888/user-center/api/users/1永远可以收到正确的response，为什么针对route filter会出现有时候可以拿到，有时候不行？

问题解决

• Q1：zuul pre filter的执行时机

• A1:pre filter的run方法会在route之前执行。

  • 请求首先会进入filter的run方法，处理完毕之后继续将请求发送给route部分。
  • 如果filter中对请求相关信息没有改动，那么就会按照原来的request原来的url进行route。
    ---> 因此上面的例子，只要filter换成pre就可以正常的获取response。

• Q2: route filter 导致请求404，是route filter本身的运行机制导致的，还是filter中的内容导致的呢？

• A2: 我们将filter的内容全部清空，只留下return null发现请求获得了正确的response。由此可知。请求的路径并没有出现任何问题，仅仅是filter中的处理导致了url改变，请求404.

• Q3:那么filter里面执行了什么会出现，修改了url呢？

• A3:经过处理发现由于执行了RequestContext.getCurrentContext().set("requestURI", uri);导致请求出现了404。此时即使我set的requestURI和原来的完全一致，也会导致404.
  ----> 此时的现象就是：只要在route filter中对request做任何set都会导致请求404.

• Q4:那么为什么set request中的数据，就会导致url出现问题呢？

• A4:我尝试修改服务器的路径使得请求http://localhost:8085/user-center/api/users/1即可以拿到资源。然后再次发送请求https://localhost:8888/user-center/api/users/1发现资源拿到了。这样看来，明显就是：本来route可以去除请求前缀/user-center但是set reuqest之后把user-center前缀又加回来，导致最终到达服务器的路径中多了user-center前缀。

---- 但是 这个route filter的先后顺序仍然不得而知，如果想要彻底弄明白这个route filter可能要读一读源码了。

反思

• 对于一些新的知识，网上的相关文档真的有限，所以这时候应该尝试去看一看源代码才能解决心理的疑惑，可能是这么久以来太依赖文档，就算文档没有，也有Stack Overflow总有人能通过他的描述告诉问题答案。当什么都没有的时候，就只能靠猜测，其实要是有时间和精力真的应该去读一下。