Endpoint过滤器担任基于incoming过滤器的执行来处置央求。Zuul有一个内置的过滤器（ProxyEndpoint），用于将央求代理到后端效劳器，因此这些过滤器的典型用途是用于静态端点。例如:安康反省照应，静态错误照应，404照应。

Outgoing

Outgoing过滤器在从后端接纳到照应以后执行处置操作。通常状况下，它们更多地用于构成照应和添加目的，而不是用于任何繁重的任务。例如:存储统计信息、添加/剥离标准标题、向实时流发送事情、gziping照应。

过滤器类型

下面是与一个央求典型的生命周期对应的标准的过滤器类型：

PRE ：路由到Origin之前执行

ROUTING ：路由到Origin时期执行

POST ：央求被路由到Origin之后执行

ERROR ：发作错误的时分执行

这些过滤器协助我们执行以下功用：

身份验证和安全性 ：辨认每个资源的身份验证需求，并拒绝不满足它们的央求

监控 ：在边缘跟踪有意义的数据和统计数据，以便给我们一个准确的消费视图

静态路由 ：静态路由央求到不同的后端集群

压力测试 ：逐渐添加集群的流量，以评价功用

限流 ：为每种央求类型分配容量，并丢弃超过限制的央求

静态照应处置 ：直接在边缘构建一些照应，而不是将它们转发到外部集群

Zuul 1.0 央求生命周期

Netflix宣布了通用API网关Zuul的架构转型。Zuul本来采用同步阻塞架构，转型后叫作Zuul 2，采用异步非阻塞架构。Zuul 2和Zuul 1在架构方面的主要区别在于，Zuul 2运转在异步非阻塞的框架上，比如Netty。Zuul 1依赖多线程来支持吞吐量的增长，而Zuul 2运用的Netty框架依赖事情循环和回调函数。

Zuul 2.0

Zuul 2.0架构图：

上图是Zuul2的架构，和Zuul 1没有本质区别，两点变化：

前端用Netty Server替代Servlet，目的是支持前端异步。后端用Netty Client替代Http Client，目的是支持后端异步。

过滤器换了一下名字，用Inbound Filters替代Pre-routing Filters，用Endpoint Filter替代Routing Filter，用Outbound Filters替代Post-routing Filters。

Inbound Filters ：路由到Origin之前执行，可以用于身份验证、路由和装饰央求

Endpoint Filters ：可用于前往静态照应，否则内置的ProxyEndpoint过滤器将央求路由到Origin

Outbound Filters ：从Origin那里获取照应后执行，可以用于度量、装饰用户的照应或添加自定义header

有两种类型的过滤器：sync和async。由于Zuul是运转在一个事情循环之上的，因此历来不要在过滤中阻塞。假设你非要阻塞，可以在一个异步过滤器中这样做，并且在一个独自的线程池上运转，否则可以运用同步过滤器。

上文提到过 Zuul 2末尾采用了异步模型 。

优势是异步非阻塞形式启动的线程很少，基本上一个CPU core上只需启一个事情环处置线程，它运用的线程资源就很少，上下文切换（Context Switch）开支也少。非阻塞形式可以接受的衔接数大大添加，可以复杂了解为央求来了只需求进队列，这个队列的容量可以设得很大，只需不超时，队列中的央求都会被依次处置。

(责任编辑：admin)