SpringCloud-Zuul（一）：技术选型及请求流程源码走读

本文原创地址，[jsbintask的博客](https://jsbintask.cn/2019/03/28/springcloud/springcloud-zuul-process/)(食用效果最佳)，转载请注明出处!

前言

最近公司最新架构肯定使用微服务以后，通过讨论，最终仍是选用了SpringCloud的体系。我负责网关，鉴权服务的研发。记录下这段时间新接触的知识。

网关技术选型

springcloud选用了最新的稳定版本Greenwich，因此对于网关来讲，有两种框架选择：SpringCloud Gateway， Zuul，通过调研我最终选用了Zuul，缘由以下：

1. 目前项目在一个快速迭代的过程当中，Zuul相比于Gateway来讲更加稳定。
2. Gateway文档还有待完善，我在调查过程当中，发现官网文档甚至代码还留有不少TODO，这不是一个大坑吗！ Gateway文档
3. Gateway相对Zuul来讲显得难以使用，Gateway使用Spring5开发，基于函数，响应式编程，可能对于刚接触Reactive的人来讲阅读源码有必定难度。
4. 虽然Zuul在性能上来讲不如Gateway，但对于咱们的业务来讲这点时间消耗显得不那么重要。

Proxy	    Avg Latency	    Avg Req/Sec/Thread
gateway	    6.61ms	        3.24k
linkered	7.62ms	        2.82k
zuul	    12.56ms	        2.09k
none	    2.09ms	        11.77k
复制代码

Zuul工做原理

使用Zuul的关键在于自定义Filter，固然这个Filter不是Servlet对应的Filter，而且不一样类型的Filter使用相同的配置却有不一样的效果。秉着知其因此然的精神，把整个Zuul处理过程的源码debug了一遍；

入口

Zuul处理请求的入口是一个Servlet：ZuulServlet，SpringCloud也提供另外的处理入口，一个Servlet Filter: ZuulServletFilter，修改配置文件zuul.use-filter=true便可。 它进入ZuulServlet的过程以下：

http依然先进入DispatchServlet，接着调用ZuulController，再接着调用ZuulServlet。这中间通过很多反射处理，可能这也是性能低的一个缘由。不太明白为何不直接进入ZuulServlet。

源码走读

进入了ZuulServlet后，调用service方法，这个时候就开始调用各个类型的ZuulFilter了，它主要作了以下事情。

1. 初始化RequestContext，其实就是一个ThreadLocal，将httpServlet，httResponse放入其中，方便后面自定义的ZuulFilter能够获取。
2. 调用pre filter。
3. 调用route filter。
4. 调用post filter。 注意点：再调用各个filter的过程当中若是出现异常，都会调用error filter。 接着咱们查看pre filter是如何调用的：

   

   

   

   

   也就是说，如今上面的流程图变成了这样:

   

   这样，咱们的思路就很清晰了，从请求进入，到zuul的调用完整过程都已经整理了出来，接下来咱们只要开始自定义filter处理咱们的业务逻辑便可。

总结

本章咱们从技术选型出发，比较了zuul和gateway的优缺点。最后经过阅读源码的方式整理了Zuul处理请求的整个过程。 下一章：如何自定义Zuul Filter以及所遇到坑！

关注我，这里只有干货！