前言

zuul1.0与spring-cloud-gateway的区别
Zuul:

zuul是netflix公司的项目，本质上是web servlet，基于JavaEE Servlet技术栈，使用阻塞API，处理的是http请求，没有提供异步支持，不支持任何长连接，比如websocket。
目前zuul有两个版本：zuul1和zuul2，目前spring cloud只集成了zuul1。zuul2是Netflix在2018年5月推出，它最大的特点就是支持异步调用 (zuul1仅支持同步) ，可惜springcloud暂时没有计划集成zuul2，而且还推出spring cloud gateway来替代zuul1。

来看下zuul1的编程模型（同步阻塞）

在这里插入图片描述

本质上就是一个同步 Servlet，每来一个请求，zuul会专门分配一个线程去处理，然后转发到后端服务，后端再启线程处理请求，后端处理时网关的线程会阻塞，当请求数量比较大时，很容易造成线程池被沾满而无法接受新的请求，Netflix 为此还专门研发了Hystrix熔断组件来解决慢服务耗尽资源问题。

zuul2的编程模型（异步非阻塞）
在这里插入图片描述

zuul2是基于Netty实现的异步非阻塞编程模型，一般异步模式的本质都是使用队列 Queue(或称总线 Bus)。网关中会有一个队列专门处理用户请求，一个队列专门负责后端服务调用，中间有个事件环线程 (Event Loop Thread)同时监听两个队列，它的主要作用是将请求转发给后端，并将后端服务的处理结果返回给客户端，用队列的形式减轻了前端请求数量的压力。

在这里插入图片描述

Zuul1 同步编程模型简单，门槛低，开发运维方便，容易调试定位问题。Zuul2 门槛高，调试不方便。 Zuul1 监控埋点容易，比如和调用链监控工具 CAT 集成，如果你用 Zuul2 的话，CAT 不好埋点是个问题。 Zuul1 已经开源超过 6 年，稳定成熟，坑已经被踩平。Zuul2 刚开源很新，实际落地案例不多，难说有 bug 需要踩坑。大部分公司达不到 Netflix 那个量级，Netflix 是要应对每日千亿级流量，它们才挖空心思搞异步，一般公司亿级可能都不到，Zuul1 绰绰有余。 Zuul1 可以集成 Hystrix 熔断组件，可以部分解决后台服务慢阻塞网关线程的问题。 Zuul1 可以使用 Servlet 3.0 规范支持的 AsyncServlet 进行优化，可以实现前端异步，支持更多的连接数，达到和 Zuul2 一样的效果，但是不用引入太多异步复杂性。

spring-cloud-gateway:
Spring Boot和Spring Webflux提供的Netty底层环境，不能和传统的Servlet容器一起使用，也不能打包成一个WAR包，使用非阻塞API，支持websocket。
zuul1与spring-cloud-gateway的区别：

1、gateway对比zuul多依赖了spring-webflux，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件。
zuul则可以扩展至其他微服务框架中

2、zuul仅支持同步，gateway支持异步,gateway吞吐率比zuul高，耗时比zuul少，性能比zuul高倍左右。

3、gateway线程开销少，支持各种长连接、websocket，spring官方支持，但运维复杂，
zuul编程模型简单,开发调试运维简单，有线程数限制，延迟堵塞会耗尽线程连接资源。

4、过滤器的实现不同
zuul:
其核心是一系列的filters，定义了四套标准
PRE：路由之前调用，实现身份验证
ROUTING:将请求路由到微服务
POST，微服务以后执行，响应header
ERROR，错误时执行
Filter有四个方法，分别为
filterType():过滤器的类型，它决定过滤器在请求的哪个生命周期中执行。
fiterOrder:过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行。通过数字指定，数字越大，优先级越低。
shouldFiter:判断该过滤器是否需要被执行。直接返回true，则该过滤器对所有请求都会生效。实际运用中我们可以利用该函数来指定过滤器的有效范围。
gateway:
gateway使用了高性能框架Netty，由三部分组成
1、filter过滤器：拦截和修改请求
2、route路由：断言为真，则路由匹配，目标URI会被访问
3、predicate断言：匹配HTTP请求的任何内容