Zuul & Spring Cloud Gateway & Linkerd性能对比

Spring Cloud从一开始最受大家质疑的就是网关性能,那是由于Spring Cloud最初选择了使用Netflix几年前开源的Zuul作为基础,而高性能版的Zuul 2在经过了多次跳票之后,对于Spring这样的整合专家可能也不愿意再继续等待,Spring Cloud Gateway应运而生,那么这个由Spring社区自己开发推出的网关又如何呢?最近一篇《实测 | 转型微服务,这4大工具谁是API网关性能最优?》的翻译中对比了NGINX、ZUUL、Spring Cloud Gateway、Linkerd,得出的结论让不少读者感到诧异,Spring Cloud Gateway是否真的有这么差?不妨通过下文来进一步了解(以下内容转载自来《Spring Cloud与Docker微服务实战》作者周立的博文,原文地址:http://www.itmuch.com/spring-cloud-sum/performance-zuul-and-gateway-linkerd/)。

动机

已经不止一次看到“Spring Cloud Gateway性能比Zuul更差”的言论了,不少人人云亦云,来问我,既然如此,那Spring官方还开发Spring Cloud Gateway干嘛?难道仅仅是为了支持Zuul 1.x不支持的长连接、Web Socket吗?

故而写篇博客,纠正一下大家的错误观点。

开端

网上搜索了一下,说Spring Cloud Gateway性能比Zuul差的言论来自:http://www.servicemesh.cn/?/article/45

作者使用 ab 进行benchmark,操作非常标准。从结果来看,确实Spring Cloud Gateway比Zuul差了一大截。

但,让我们打开官方的Issue:Throughput problems when compared with Netflix Zuul and Nginx ,里面官方人员回答道:

reactor-netty has issues with http 1.0 and hence ab. reactor/reactor-netty#21

不妨跟踪到reactor/reactor-netty#21 ,看看说了啥:

As discussed recently about the issue raised on https://jira.spring.io/browse/SPR-14964, a very simple ab-n1-c1http://localhost:8082/items/10 on Spring + Reactor Netty based server block forever likely because Reactor Netty does not support HTTP 1.0.

里面说了,Reactor Netty不支持HTTP 1.0,而Spring Cloud Gateway依赖了 reactor-netty 。

也就是说——由于reactor-netty的bug,使用 ab 压测结果并不准确!

正确姿势

官方建议使用 wrk 进行benchmark测试。不仅如此,官方人员还十(丧)分(心)贴(病)心(狂)地创建了一个benchmark的项目:spring-cloud-gateway-bench ,其中对比了:

  • Spring Cloud Gateway
  • Zuul
  • Linkerd

三者的性能。

思路非常简单:static 项目是一个使用Go语言编写的简单服务器;然后分别使用Gateway/Zuul/Linkerd来代理该服务的端点,并对比。

最终结果:

组件 RPS(request per second)
Spring Cloud Gateway Requests/sec: 32213.38
Zuul Requests/sec: 20800.13
Linkerd Requests/sec: 28050.76

从结果可知,Spring Cloud Gateway的RPS是Zuul1的1.6倍!比Linkerd性能还好!

展望

  • 本文的Zuul,指的是Zuul 1.x,是一个基于阻塞io的API Gateway。
  • Spring Cloud Gateway是一个很有前途的项目,上手简单,功能也比较强大。
  • Linkerd也是一个非常有前途的项目,是基于Scala实现的、目前市面上仅有的生产级别的Service Mesh(其他诸如Istio、Conduit暂时还不能用于生产)。
  • Zuul已经发布了Zuul 2.x,基于Netty,也是非阻塞的,支持长连接,但Spring Cloud暂时还没有整合计划。

原文地址:https://www.cnblogs.com/772933011qq/p/11583824.html

时间: 2024-08-30 16:51:24

Zuul & Spring Cloud Gateway & Linkerd性能对比的相关文章

最全面的改造Zuul网关为Spring Cloud Gateway(包含Zuul核心实现和Spring Cloud Gateway核心实现)

前言: 最近开发了Zuul网关的实现和Spring Cloud Gateway实现,对比Spring Cloud Gateway发现后者性能好支持场景也丰富.在高并发或者复杂的分布式下,后者限流和自定义拦截也很棒. 提示: 本文主要列出本人开发的Zuul网关核心代码以及Spring Cloud Gateway核心代码实现.因为本人技术有限,主要是参照了 Spring Cloud Gateway 如有不足之处还请见谅并留言指出. 1:为什么要做网关 (1)网关层对外部和内部进行了隔离,保障了后台服

API网关性能比较:NGINX vs. ZUUL vs. Spring Cloud Gateway vs. Linkerd(转)

前几天拜读了 OpsGenie 公司(一家致力于 Dev & Ops 的公司)的资深工程师 Turgay ?elik 博士写的一篇文章(链接在文末),文中介绍了他们最初也是采用 Nginx 作为单体应用的网关,后来接触到微服务架构后开始逐渐采用了其他组件. 我对于所做的工作或者感兴趣的技术,喜欢刨根问底,所以当读一篇文章时发现没有看到我想要看到的设计思想,我就会四处搜集资料,此外这篇文章涉及了我正在捣鼓的 Spring Cloud,所以我就决定写一篇文章,争取能从设计思路上解释为什么会有这样的性

跟我学SpringCloud | 第十二篇:Spring Cloud Gateway初探

SpringCloud系列教程 | 第十二篇:Spring Cloud Gateway初探 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 前面我们在聊服务网关Zuul的时候提到了Gateway,那么Zuul和Gateway都是服务网关,这两个有什么区别呢? 1. Zuul和Gateway的恩怨情仇 1.1 背景 Zuul是Netflix开源的一个项目,Spring只是将Zuul集成在了Spring

Spring Cloud Gateway真的有那么差吗?

动机 已经不止一次看到“Spring Cloud Gateway性能比Zuul更差”的言论了,不少人人云亦云,来问我,既然如此,那Spring官方还开发Spring Cloud Gateway干嘛?难道仅仅是为了支持Zuul 1.x不支持的长连接.Web Socket吗? 故而写篇博客,纠正一下大家的错误观点. 开端 网上搜索了一下,说Spring Cloud Gateway性能比Zuul差的言论来自:http://www.servicemesh.cn/?/article/45 作者使用 ab

Spring Cloud Gateway初探

Zuul和Gateway的恩怨情仇 1.1 背景 Zuul是Netflix开源的一个项目,Spring只是将Zuul集成在了Spring Cloud中.而Spring Cloud Gateway是Spring Cloud的一个子项目. 还有一个版本的说法是Zuul2的连续跳票和Zuul1的性能并不是很理想,从而催生了Spring Cloud Gateway. 1.2 性能比较 网上很多地方都说Zuul是阻塞的,Gateway是非阻塞的,这么说是不严谨的,准确的讲Zuul1.x是阻塞的,而在2.x

Spring Cloud Gateway 结合配置中心限流

前言 假设你领导给你安排了一个任务,具体需求如下: 针对具体的接口做限流 不同接口限流的力度可以不同 可以动态调整限流配置,实时生效 如果你接到上面的任务,你会怎么去设计+实现呢? 每个人看待问题的角度不同,自然思考出来的方案也不同,正所谓条条大路通罗马,能到达目的地的路那就是一条好路. 如何分析需求 下面我给出我的实现方式,仅供各位参考,大牛请忽略. 具体问题具体分析,针对需求点,分别去做分析. 需求一 "如何针对具体的接口做限流" 这个在上篇文章中也有讲过,只需要让KeyResol

Spring Cloud Gateway服务网关

原文:https://www.cnblogs.com/ityouknow/p/10141740.html Spring 官方最终还是按捺不住推出了自己的网关组件:Spring Cloud Gateway ,相比之前我们使用的 Zuul(1.x) 它有哪些优势呢?Zuul(1.x) 基于 Servlet,使用阻塞 API,它不支持任何长连接,如 WebSockets,Spring Cloud Gateway 使用非阻塞 API,支持 WebSockets,支持限流等新特性. Spring Clou

从0开始构建你的api网关--Spring Cloud Gateway网关实战及原理解析

API 网关 API 网关出现的原因是微服务架构的出现,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信,会有以下的问题: 客户端会多次请求不同的微服务,增加了客户端的复杂性. 存在跨域请求,在一定场景下处理相对复杂. 认证复杂,每个服务都需要独立认证. 难以重构,随着项目的迭代,可能需要重新划分微服务.例如,可能将多个服务合并成一个或者将一个服务拆分成多个.如果客户端直接与微服务通信,那么重构将会很难实施. 某些微

Spring Cloud Gateway入坑记

Spring Cloud Gateway入坑记 前提 最近在做老系统的重构,重构完成后新系统中需要引入一个网关服务,作为新系统和老系统接口的适配和代理.之前,很多网关应用使用的是Spring-Cloud-Netfilx基于Zuul1.x版本实现的那套方案,但是鉴于Zuul1.x已经停止迭代,它使用的是比较传统的阻塞(B)IO + 多线程的实现方案,其实性能不太好.后来Spring团队干脆自己重新研发了一套网关组件,这个就是本次要调研的Spring-Cloud-Gateway. 简介 Spring