Zuul1与SpringCloudGateway对⽐
⼀、API⽹关
1.1 Zuul1简介
1.2 Spring Cloud Gateway简介
⼆、对⽐
2.0 产品对⽐
2.1 性能对⽐
2.1.1 低并发场景
2.1.2 ⾼并发场景
2.1.3 官⽅性能对⽐
三、总结
⼀、API⽹关
  微服务架下，服务之间容易形成⽹状的调⽤关系，这种⽹状的调⽤关系不便管理和维护，这种场景下API⽹关应运⽽⽣。作为后端服务的⼊⼝，API⽹关在微服务架构中尤其重要，在对外部系统提供API⼊⼝的要求下，API⽹关应具备路由转发、负载均衡、限流熔断、权限控制、轨迹追踪和实时监控等功能。
  ⽬前，很多微服务都基于的Spring Cloud⽣态构建。Spring Cloud⽣态为我们提供了两种API⽹关产品，分别是Netflix开源的Zuul1和Spring⾃⼰开发的Spring Cloud Gateway（下边简称为Gateway）。Spring Cloud以Finchley版本为分界线，Finchley版本发布之前使⽤Zuul1作为API⽹关，之后更推荐使⽤Gateway。
  虽然Netflix已经在2018年5⽉开源了Zuul2，但是Spring Cloud已经推出了Gateway，并且在github上表⽰没有集成Zuul2的计划。所以从Spring Cloud发展的趋势来看，Gateway代替Zuul是必然的。
1.1 Zuul1简介
  Zuul1是Netflix在2013年开源的⽹关组件，⼤规模的应⽤在Netflix的⽣产环境中，经受了实践考验。它可以与Eureka、Ribbon、Hystrix等组件配合使⽤，实现路由转发、负载均衡、熔断等功能。Zuul1的核
⼼是⼀系列过滤器，过滤器简单易于扩展，已经有⼀些三⽅库如spring-cloud-zuul-ratelimit等提供了过滤器⽀持。
  Zuul1基于Servlet构建，使⽤的是阻塞的IO，引⼊了线程池来处理请求。每个请求都需要独⽴的线程来处理，从线程池中取出⼀个⼯作线程执⾏，下游微服务返回响应之前这个⼯作线程⼀直是阻塞的。
1.2 Spring Cloud Gateway简介
  Spring Cloud Gateway 是Spring Cloud的⼀个全新的API⽹关项⽬，⽬的是为了替换掉Zuul1。Gateway可以与Spring Cloud Discovery Client（如Eureka）、Ribbon、Hystrix等组件配合使⽤，实现路由转发、负载均衡、熔断等功能，并且Gateway还内置了限流过滤器，实现了限流的功能。  Gateway基于Spring 5、Spring boot 2和Reactor构建，使⽤Netty作为运⾏时环境，⽐较完美的⽀持异步⾮阻塞编程。Netty使⽤⾮阻塞的IO，线程处理模型建⽴在主从Reactors多线程模型上。其中Boss Group轮询到新连接后与Client建⽴连接，⽣成NioSocketChannel，将channel绑定到Worker；Worker Group轮询并处理Read、Write事件。
⼆、对⽐
2.0 产品对⽐
下边以表格形式对Zuul1和Gateway作简单对⽐：
对⽐项Zuul1.x Gateway
实现基于Servlet2.x构建，使⽤阻塞的API。基于Spring 5、Project Reactor、Spring Boot 2，使⽤⾮阻塞式的API。
长连接不⽀持⽀持
不适⽤场景后端服务响应慢或者⾼并发场景下，因为线程数量是
固定（有限）的，线程容易被耗尽，导致新请求被拒
绝。
中⼩流量的项⽬，使⽤Zuul1.x更合
适。
限流⽆内置限流过滤器
上⼿难
度
同步编程，上⼿简单门槛较⾼，上⼿难度中等Spring
Cloud集
成
是是
Sentinel
集成
是是
技术栈
沉淀
Zuul1开源近七年，经受考验，稳定成熟。未见实际落地案例Github
used by
1007 repositories102 repositories Github
issues
微服务网关设计
88 Open / 2736 Closed135 Open / 850 Closed 注：Github used by和Github issues统计时间截⽌2019/8/26。
2.1 性能对⽐
2.1.1 低并发场景
不同的tps，同样的请求时间（50s），对两种⽹关产品进⾏压⼒测试，结果如下：
tps
测试样本
Zuul1/Gateway，单
位个
平均响应时间
Zuul1/Gateway, 单位毫
秒
99%响应时间⼩于
Zuul1/Gateway，单位毫秒
错误⽐例
Zuul1/Gateway
20tps20977 / 2058011 / 1416 / 400% / 0%
50tps42685 / 5058618 / 1266 / 220% / 0%
并发较低的场景下，两种⽹关的表现差不多
2.1.2 ⾼并发场景
配置同样的线程数（2000），同样的请求时间（5分钟），后端服务在不同的响应时间（休眠时间），对两种⽹关产品进⾏压⼒测试，结果如下：
休眠时
间
测试样本
Zuul1/Gateway，
单位个
平均响应时间
Zuul1/Gateway,
单位毫秒
99%响应时间⼩
于
Zuul1/Gateway，
单位毫秒
错误次数
Zuul1/Gateway，
单位个
错误⽐例
Zuul1/Gateway
休眠
100ms
294134 / 10593212026 / 5466136 / 1774104 / 00.04% / 0%休眠
300ms
101194 / 3999095595 / 148915056 / 16901114 / 0  1.10% / 0%休眠
600ms
51732 / 20126211768 / 297527217 / 32032476 / 0  4.79% / 0%休眠
1000ms
31896 / 12095619359 / 491446259 / 51153598 / 011.28% / 0% Zuul⽹关的tomcat最⼤线程数为400，hystrix超时时间为100000。
Gateway在⾼并发和后端服务响应慢的场景下⽐Zuul1的表现要好。
2.1.3 官⽅性能对⽐
Spring Cloud Gateway的开发者提供了benchmark项⽬⽤来对⽐Gateway和Zuul1的性能，官⽅提供的性能对⽐结果如下：
⽹关Avg Req/sec/Thread Avg Latency
Spring Cloud Gateway3.24k  6.61ms
Zuul1  2.09k12.56ms
none11.77k  2.09ms
测试⼯具为wrk，测试时间30秒，线程数为10，连接数为200。
从官⽅的对⽐结果来看，Gateway的RPS是Zuul1的1.55倍，平均延迟是Zuul1的⼀半。
三、总结
  Zuul1的开源时间很早，Netflix、Riot、携程、拍拍贷等公司都已经在⽣产环境中使⽤，⾃⾝经受了实践考验，是⽣产级的API⽹关产品。
  Gateway在2019年离开Spring Cloud孵化器，应⽤于⽣产的案例少，稳定性有待考证。
  从性能⽅⾯⽐较，两种产品在流量⼩的场景下性能表现差不多；并发⾼的场景下Gateway性能要好很多。从开发⽅⾯⽐较，Zuul1编程模型简单，易于扩展；Gateway编程模型稍难，代码阅读难度要⽐Zuul⾼不少，扩展也稍复杂⼀些。
附：⼀⽂理解Netty模型架构

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。