SpringCloud解析之Zuul(二)
本文基于Spring Cloud Edgware.SR6，Zuul版本1.3.1，解析Zuul的请求拦截机制，让大家对Zuul的原理有个大概的认识和了解。如有不对的地方，欢迎指正。
在上一期的SpringCloud解析之Zuul(一)，我们了解了spring boot在接收一个网关请求后，是如何找到与之匹配的ZuulHandlerMapping。今天我们继续探寻，这个ZuulHandlerMapping是如何处理网关请求的。
在开始之前，我们先了解一下，为什么spring boot要如此大费周章的，只为找到ZuulHandlerMapping。
通过上一期文章，我们知道所有的浏览器请求都会到达DispatcherServlet，并且DispatcherServlet中有一个成员变量handlerMappings，会扫描所有继承HandlerMapping接口的实现类，其实它里面还有一个成员变量handlerAdapters，这个变量会扫描所有HandlerAdapter接口的实现类。从名字命名上可以看出，handlerAdapters包含了所有的处理器适配器，所有的HandlerMapping都会通过其对应的HandlerAdapter来执行，目的是为了解耦。因为这样设计之后，DispatcherServlet和HandlerMapping都不会包含特定的逻辑代码，也不需要关心是什么类型的请求，只需要调用对应的HandlerAdapter的方法就可以了。
ZuulHandlerMapping里面有什么呢？ZuulHandlerMapping中有一个成员变量ZuulController，ZuulController继承了ServletWrappingController，ServletWrappingController中有servletClass和servletInstance。
在上一期开头，我粗略的提及，在spring boot启动过程中会初始化ZuulController，继而通过反射初始化ZuulServlet。详细的说，是spring boot启动过程中会通过org.springframework.cloud.netflix.zuul.ZuulServerAutoConfiguration自动配置类来初始化zuul，其中包括ZuulHandlerMapping。所以，ZuulHandlerMapping中有ZuulController，ZuulController中有ZuulServlet，这些对象实例在spring boot启动成功后就有了。
好，在了解了这些之后，我们继续今天的内容。DispatcherServlet.doDispatch()在获取到ZuulHandlerMapping之后，马上调用方法getHandlerAdapter()获取对应的HandlerAdapter。
可以看到，getHandlerAdapter()内部是在遍历handlerAdapters，然后通过调用各自的supports()方法判断哪一个handlerAdapter支持前面获取的handler处理器。这里取到的是SimpleControllerHandlerAdapter。
取到handlerAdapter之后，开始调用handlerAdapter的handle()方法，mappedHandler.getHandler()就是ZuulController。SimpleControllerHandlerAdapter.handle()内部，是ZuulController.handleRequest()，其内部又是调用父类的handleRequestInternal()，真正起作用的是servletInstance.service()，而servletInstance正是ZuulServlet（我们开头讲到的）
下面我们看下，ZuulServlet.service()做了什么。
public void service(javax.servlet.ServletRequest servletRequest, javax.servlet.ServletResponse servletResponse) throws ServletException, IOException { try {
// 初始化，将servletRequest和servletResponse存储到请求上下文RequestContext
init((HttpServletRequest) servletRequest, (HttpServletResponse) servletResponse);
// Marks this request as having passed through the "Zuul engine", as opposed to servlets
// explicitly bound in web.xml, for which requests will not have the same data attached
RequestContext context = RequestContext.getCurrentContext();
context.setZuulEngineRan();
// 顺序执行ZuulFilter过滤器，也包括我们继承ZuulFilter的自定义过滤器
try { preRoute(); } catch (ZuulException e) { error(e); postRoute(); return; } try { route(); } catch (ZuulException e) { error(e); postRoute(); return; } try { postRoute(); } catch (ZuulException e) { error(e); return; } } catch (Throwable e) { error(new ZuulException(e, 500, "UNHANDLED_EXCEPTION_" + e.getClass().getName())); } finally { RequestContext.getCurrentContext().unset(); } }
简直一目了然。我们往下看，它是如何会执行我们继承ZuulFilter的自定义过滤器。（上文忘了说，在ZuulServlet实例化后，会调用init()方法初始化ZuulRunner）。
以preRoute()为例，不难看出，最终的执行者是FilterProcessor，在runFilters()方法中，获取对应类型的List<ZuulFilter>，然后遍历执行processZuulFilter(zuulFilter)
FilterLoader.getInstance().getFiltersByType(sType)内容如下，就是从hashFiltersByType中获取filterType对应的List<ZuulFilter>
那么新问题就来了，hashFiltersByType里的值怎么来的。FilterLoader还有一个putFilter(File file)方法，通过查找源码很容易发现，这个方法是在FilterFileManager中被调用的。官方的解释是，FilterFileManager类负责初始化和更新filter（但是我一直搞不懂它是如何调用运行的，因为我打断点都没有效果，猜测是Groovy，不甚了解，知道的小伙伴帮忙评论解释下，感激不尽）。
INSTANCE.manageFiles()最终调用的就是FilterLoader.putFilter()方法，INSTANCE.startPoller()则是启动一个守护线程，轮询执行manageFiles()。
回过头来，我们继续看processZuulFilter(zuulFilter)干了什么。额，其实关键就下面一句，
ZuulFilter.runFilter()方法，首先判断!isFilterDisabled()，shouldFilter()，同时满足时才执行run()方法，即配置文件中isFilter没有禁用，并且自定义过滤器的shouldFilter()返回true，才会执行重写ZuulFilter的run()方法。
至此，zuul网关执行过滤器和自定义过滤器的过程就讲完了（啊，累死了）。
最后，总结一下：
1.spring boot通过适配器设计模式，使用对应的HandlerAdapter来执行ZuulHandlerMapping，以达到解耦的目的。而ZuulHandlerMapping最终是调用的ZuulServlet.service()
2.ZuulServlet.service()里面，也是取出filterType类型的所有ZuulFilter，然后遍历执行ZuulFilter的run()方法，这也是为什么我们写自定义过滤器要继承ZuulFilter的原因。
下一期，我们来聊聊Zuul对请求过滤处理后，是如何将请求转发到对应的服务器的。
