前言
动机
已经不止一次看到“Spring Cloud Gateway性能比Zuul更差”的言论了，不少人人云亦云，来问我，既然如此，那Spring官方还开发Spring Cloud Gateway干嘛？难道仅仅是为了支持Zuul 1.x不支持的长连接、Web Socket吗？
故而写篇博客，纠正一下大家的错误观点。
开端
作者使用ab进行benchmark，操作非常标准。从结果来看，确实Spring Cloud Gateway比Zuul差了一大截。
但，让我们打开官方的Issue：Throughput problems when compared with Netflix Zuul and Nginx ，里面官方人员回答道：
不妨跟踪到reactor/reactor-netty#21 ，看看说了啥：
里面说了，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性能还好！
展望
本文的Zuul，指的是Zuul 1.x，是一个基于阻塞io的API Gateway。
Spring Cloud Gateway是一个很有前途的项目，上手简单，功能也比较强大。
Linkerd也是一个非常有前途的项目，是基于Scala实现的、目前市面上仅有的生产级别的Service Mesh（其他诸如Istio、Conduit暂时还不能用于生产）。
Zuul已经发布了Zuul 2.x，基于Netty，也是非阻塞的，支持长连接，但Spring Cloud暂时还没有整合计划。
在这里顺便给大家推荐一个架构交流群：617434785，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。相信对于已经工作和遇到技术瓶颈的码友，在这个群里会有你需要的内容。