Zuul简介
Zuul简介
What is Zuul?
Zuul is the front door for all requests from devices and web sites to the backend of the Netflix streaming application. As an edge service application, Zuul is built to enable dynamic routing, monitoring, resiliency and security. It also has the ability to route requests to multiple Amazon Auto Scaling Groups as appropriate.
Zuul是所有从设备和网站到Netflix流媒体应用程序后端的请求的前门。作为一个边缘服务应用程序，Zuul的构建是为了支持动态路由、监视、弹性负载和安全性。
实现功能
-
认证和安全：识别每个需要认证的资源，拒绝不符合要求的请求；
- 性能监测：在服务边界追踪并统计数据，提供精确的生产视图；
- 动态路由：根据需要将请求动态路由到后端集群；
- 压力测试：逐渐增加对集群的流量以了解其性能；
- 负载卸载：预先为每种类型的请求分配容量，当请求超过容量时自动丢弃；
- 静态资源处理：直接在边界返回某些响应；
工作原理
Zuul的核心就是一系列Filter，作用类似于Servlet中的Filter。Zuul提供了一个框架，可以对过滤器进行动态的加载，编译，运行。
Zuul的过滤器之间没有直接的相互通信，他们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据。Zuul的过滤器是由Groovy写成，这些过滤器文件被放在Zuul Server上的特定目录下面，Zuul会定期轮询这些目录，修改过的过滤器会动态的加载到Zuul Server中以便过滤请求使用。
过滤器特征
Zuul Filter有以下几个特征：
- Type：用以表示路由过程中的阶段（内置包含PRE、ROUTING、POST和ERROR）；
- Execution Order：表示相同Type的Filter的执行顺序；
- Criteria：执行条件;
- Action：执行体;
过滤器类型
Zuul中定义了四种标准过滤器类型，这些过滤器类型对应于请求的典型生命周期。
-
PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等；
-
ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用
Apache HttpClient或Netfilx Ribbon请求微服务； -
POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等；
-
ERROR：在其他阶段发生错误时执行该过滤器；
内置过滤器
zuul还提供了一类特殊的过滤器，分别为：StaticResponseFilter和SurgicalDebugFilter。
-
StaticResponseFilter：StaticResponseFilter允许从Zuul本身生成响应，而不是将请求转发到源； -
SurgicalDebugFilter：SurgicalDebugFilter允许将特定请求路由到分隔的调试集群或主机；
生命周期
过滤器优先级
- pre过滤器
- -3：
ServletDetectionFilter - -2：
Servlet30WrapperFilter - -1：
FormBodyWrapperFilter - 1：
DebugFilter - 5：
PreDecorationFilter
- -3：
-
routing过滤器 - 10：
RibbonRoutingFilter- 100：SimpleHostRoutingFilter- 500：SendForwardFilter -
post过滤器
-
900：
LocationRewriteFilter -
1000：
SendResponseFilter
-
- error过滤器
- 0：
SendErrorFilter
- 0：
版本
Zuul 1.0
优势
- 编程模型简单
- 开发调试运维简单
同步阻塞模式的编程模型比较简单，整个请求->处理->响应的流程(call flow)都是在一个线程中处理的，这样开发调试比较方便易于理解，比如出了问题跟踪调试比较方便。另外，线程局部变量(ThreadLocal)机制在同步多线程模式下可以工作，调用链关系的展示也比较直观。
劣势
- 线程上下文切换开销
- 连接数限制
- 延迟阻塞耗尽线程连接资源
同步阻塞模式比较适用于计算密集型(CPU bound)应用场景。对于IO密集型场景(IO bound)，同步阻塞模式会白白消耗很多线程资源，它们都在等待IO的阻塞状态，没有做实质性工作。
Zuul 2.0
优势
- 线程开销少
- 连接数易扩展
异步非阻塞模式启动的线程很少，基本上一个CPU core上只需启一个事件环处理线程，它使用的线程资源就很少，上下文切换(Context Switch)开销也少。非阻塞模式可以接受的连接数大大增加，可以简单理解为请求来了只需要进队列，这个队列的容量可以设得很大，只要不超时，队列中的请求都会被依次处理。
劣势
- 编程模型复杂
- 开发调试运维复杂
- ThreadLocal不工作
异步非阻塞模式比较适用于IO密集型(IO bound)场景，这种场景下系统大部分时间在处理IO，CPU计算比较轻，少量事件环线程就能处理。
