前言react
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
动机服务器
已经不止一次看到“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 ,里面官方人员回答道:ui
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 simpleab-n1-c1http://localhost:8082/items/10on 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 GatewayRequests/sec: 32213.38
ZuulRequests/sec: 20800.13
LinkerdRequests/sec: 28050.76
从结果可知,Spring Cloud Gateway的RPS是Zuul1的1.6倍!比Linkerd性能还好!在这里顺便给你们推荐一个架构交流群:617434785,里面会分享一些资深架构师录制的视频录像
展望
本文的Zuul,指的是Zuul 1.x,是一个基于阻塞io的API Gateway。
Spring Cloud Gateway是一个颇有前途的项目,上手简单,功能也比较强大。
Linkerd也是一个很是有前途的项目,是基于Scala实现的、目前市面上仅有的生产级别的Service Mesh(其余诸如Istio、Conduit暂时还不能用于生产)。
Zuul已经发布了Zuul 2.x,基于Netty,也是非阻塞的,支持长链接,但Spring Cloud暂时尚未整合计划。