SpringCloud-Zuul（一）：技术选型及请求流程源码走
2019-03-28 本文已影响113人
jsbintask
本文原创地址，
我的博客：https://jsbintask.cn/2019/03/28/springcloud/springcloud-zuul-process/(食用效果最佳)，转载请注明出处!
前言
最近公司最新架构确定使用微服务之后，经过讨论，最终还是选用了SpringCloud的体系。我负责网关，鉴权服务的研发。记录下这段时间新接触的知识。
网关技术选型
springcloud选用了最新的稳定版本Greenwich，所以对于网关来说，有两种框架选择：SpringCloud Gateway， Zuul，经过调研我最终选用了Zuul，原因如下：
- 目前项目在一个快速迭代的过程中，Zuul相比于Gateway来说更加稳定。
- Gateway文档还有待完善，我在调查的过程中，发现官网文档甚至代码还留有很多
TODO，这不是一个大坑吗！ Gateway文档 - Gateway相对Zuul来说显得难以使用，Gateway使用Spring5开发，基于函数，响应式编程，可能对于刚接触
Reactive的人来说阅读源码有一定难度。 - 虽然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的过程如下：
Zuul
http依然先进入DispatchServlet，接着调用ZuulController，再接着调用ZuulServlet。这中间经过不少反射处理，可能这也是性能低的一个原因。不太明白为什么不直接进入ZuulServlet。
源码走读
Zuul
进入了ZuulServlet后，调用service方法，这个时候就开始调用各个类型的ZuulFilter了，它主要做了如下事情。
- 初始化RequestContext，其实就是一个
ThreadLocal，将httpServlet，httResponse放入其中，方便后面自定义的ZuulFilter可以获取。 - 调用
pre filter。 - 调用
route filter。 - 调用
post filter。
注意点：再调用各个filter的过程中如果出现异常，都会调用error filter。
接着我们查看pre filter是如何调用的：
Zuul
Zuul
Zuul
Zuul
也就是说，现在上面的流程图变成了这样:
Zuul
这样，我们的思路就很清晰了，从请求进入，到zuul的调用完整过程都已经整理了出来，接下来我们只要开始自定义filter处理我们的业务逻辑即可。
总结
本章我们从技术选型出发，比较了zuul和gateway的优缺点。最后通过阅读源码的方式整理了Zuul处理请求的整个过程。
下一章：如何自定义Zuul Filter以及所遇到坑！
关注我，这里只有干货！
