纠错帖:Zuul & Spring Cloud 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 -n 1 -c 1 http://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是Nginx的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暂时还没有整合计划。
已邀请:

gomyho

赞同来自:

正好解决了中午看到的那个对比,就是,差距也太远了,自己都不相信。

xds2000

赞同来自:

这块的测试用例是需要不断完善的。有一个基准的测试套件可以得到一个相对一直的反馈。但是在有了结果之后,也要细心判断,是什么导致效率低下,让结论更接近真实情况。谢谢楼主的解答。

不战の约

赞同来自:

none的时候是11k+,被代理之后反而更慢?

要回复问题请先登录注册