关于Zuul

一.Zuul是什么

zuul 是netflix开源的一个API Gateway 服务器，本质上是一个web servlet应用。

Zuul 在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

Zuul可以通过加载动态过滤机制，从而实现以下各项功能：

（1）验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。

（2）审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。

（3）动态路由: 以动态方式根据需要将请求路由至不同后端集群处。

（4）压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平。

（5）负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求。

（6）静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群。

（7）多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。

除此之外，Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。

使用Zuul的关键在于自定义 Filter ，当然这个Filter不是Servlet对应的Filter，并且不同类型的Filter使用相同的配置却有不同的效果。

Zuul网关的核心是一系列的过滤器，这些过滤器可以对请求或者响应结果做一系列过滤，Zuul 提供了一个框架可以支持动态加载，编译，运行这些过滤器，

这些过滤器是使用责任链方式顺序对请求或者响应结果进行处理的，这些过滤器直接不会直接进行通信，但是通过责任链传递的RequestContext参数可以共享一些东西。

虽然Zuul 支持任何可以在jvm上跑的语言，但是目前zuul的过滤器只能使用Groovy脚本来编写。

编写好的过滤器脚本一般放在zuul服务器的固定目录，zuul服务器会开启一个线程定时去轮询被修改或者新增的过滤器，然后动态进行编译，

加载到内存，然后等后续有请求进来，新增或者修改后的过滤器就会生效了。

在zuul中过滤器分为四种：

（1）PRE Filters(前置过滤器) ：当请求会路由转发到具体后端服务器前执行的过滤器，比如鉴权过滤器，日志过滤器，还有路由选择过滤器；

（2）ROUTING Filters （路由过滤器）：该过滤器作用是把请求具体转发到后端服务器上，一般是通过Apache HttpClient 或者 Netflix Ribbon把请求发送到具体的后端服务器上；

（3）POST Filters（后置过滤器）：当把请求路由到具体后端服务器后执行的过滤器；场景有添加标准http 响应头，收集一些统计数据（比如请求耗时等），写入请求结果到请求方等。

（4）ERROR Filters（错误过滤器）：当上面任何一个类型过滤器执行出错时候执行该过滤器；

（5）内置的特殊过滤器：zuul还提供了一类特殊的过滤器，分别为：StaticResponseFilter和SurgicalDebugFilter

StaticResponseFilter：StaticResponseFilter允许从Zuul本身生成响应，而不是将请求转发到源。

SurgicalDebugFilter：SurgicalDebugFilter允许将特定请求路由到分隔的调试集群或主机。

（6）自定义的过滤器：除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。

例如，可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。

Zuul请求的生命周期如图，该图详细描述了各种类型的过滤器的执行顺序：

Netty作为高性能异步网络通讯框架，在dubbo，rocketmq,sofa等知名开源框架中都有使用。

zuul2.0使用netty server作为网关监听服务器监听客户端发来的请求，然后把请求转发到前置过滤器（inbound filters）进行处理，

处理完毕后在把请求使用netty client代理到具体的后端服务器进行处理，处理完毕后在把结果交给后者过滤器（outbound filters）进行处理，然后把处理结果通过nettyServer写回客户端。

如下图：

总结：

在zuul1.0时候客户端发起的请求后需要同步等待zuul网关返回，zuul网关这边对每个请求会分派一个线程来进行处理，这会导致并发请求数量有限。

而zuul2.0使用netty作为异步通讯，可以大大加大并发请求量。