在Zuul中， 整个请求的过程是这样的，首先将请求给zuulservlet处理，zuulservlet中有一个 zuulRunner对象，该对象中初始化了RequestContext：作为存储整个请求的一些数据，并被所有的 zuulfilter共享。zuulRunner中还有 FilterProcessor，FilterProcessor作为执行所有的zuulfilter的管理 器。FilterProcessor从filterloader 中获取zuulfilter，而zuulfilter是被filterFileManager所加载，并支 持groovy热加载，采用了轮询的方式热加载。有了这些filter之后，zuulservelet首先执行的Pre类型的 过滤器，再执行route类型的过滤器，最后执行的是post 类型的过滤器，如果在执行这些过滤器有错误 的时候则会执行error类型的过滤器。执行完这些过

滤器，最终将请求的结果返回给客户端。

Zuul网关存在的问题

在实际使用中我们会发现直接使用Zuul会存在诸多问题，包括：

性能问题

Zuul1x版本本质上就是一个同步Servlet，采用多线程阻塞模型进行请求转发。简单讲，每来 一个请求，Servlet容器要为该请求分配一个线程专门负责处理这个请求，直到响应返回客户 端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被 阻塞，阻塞期间线程资源被占用，不能干其它事情。我们知道Servlet容器线程池的大小是有 限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，造成 容器无法接受新的请求。

不支持任何长连接，如websocket