SpringCloud 的Gateway网关性能到底如何，网上各种传言太多。我用Wrk和Jmeter两种测试工具，在相同环境和代码下进行压测。这里分享一下Wrk压测过程的数据和结果，希望对你的技术选型等有所助益。
已把网关项目上传到csdn，可免费下载使用
（不知道为啥csdn上传的资源，所需积分/C币 老是自己变，而且还需要审核...所以提供个百度云的）
提取码：plfe
- Wrk压测时可能出现超时甚至报错，很大可能是工具问题。用比较专业的Jmeter就几乎没有出现超时和报错。
不想看过程的可直接跳到第四章节，我会贴出wrk和jmeter两种压测结果，几乎一致。
目录
1、测试环境
2、测试所用命令及参数
3、测试过程
3.1做简单路由 只是匹配所有/test/** 请求路由到下游SpringBoot项目，把我提供网关项目yml中的spring提供的默认过滤器、5个自定义过滤器及aop代理全注掉。如图Get测试结果：
3.2 简单路由+Gateway提供的两个默认过滤器增加AddRequestParameterGatewayFilterFactory和SetRequestHeaderGatewayFilterFactory两个默认的过滤器。 配置如图： Get请求测试结果：
3.3 路由+默认过滤器+1个自定义全局过滤器自定义全局过滤器用来修改Post请求时request body的
3.4 路由+默认过滤器+3个自定义全局过滤器+1个aop代理
3.5 路由+默认过滤器+5个自定义全局过滤器+1个aop代理
4、 结论 （重点.....)
Wrk压测结果:
Jmeter压测结果：
1、测试环境
- SpringCloud版本：Hoxton.SR6
Gateway 版本：2.2.3.RELEASE - 下游服务
SpringBoot版本： 2.2.8.RELEASE
- 服务主机(本地Windows10) 内存：8G
Cpu: Intel(R) Core(TM) i5-9400F @ 2.90GHz
核数：6核 - 测试客户端(Centos7) 内存：8G
Cpu : Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
核数：4核
安装Wrk
我是在Centos7上通过 yum 安装的，过程简单，无非就是先装个git ，然后clone代码，再ln个快捷引用就完事了；可参照如下命令：
cd /usr/local/src
yum install git -y
git clone https://github.com/wg/wrk.git
cd wrk
yum -y install gcc
make
ln -s /usr/local/src/wrk/wrk /usr/local/bin
wrk -t 2 -c 50 -d 20 --latency http://localhost:80812、测试所用命令及参数
以下命令皆使用15个线程500个连接，进行10秒的压测，并要求在压测结果中输出响应延迟信息。
- get请求 ：./wrkbin -t 15 -c500 -d 10 --latency http://localhost:8081/test/mt
- post请求： ./wrkbin -t 15 -c500 -d 10 --latency -s post.lua http://192.168.2.252:8081/test/mt
post请求需要使用lua脚本，这里也贴下：
wrk.method = "POST"
wrk.headers["Content-Type"] = "application/json"
wrk.body = "{}"
3、测试过程
3.1做简单路由
只是匹配所有/test/** 请求路由到下游SpringBoot项目，把我提供网关项目yml中的spring提供的默认过滤器、5个自定义过滤器及aop代理全注掉。如图
Get测试结果：
第一次---->
第二次---->
第三次->
结论： 三次压测平均QPS: 4719 ,出现超时。
- Post测试结果 第一次---->
第二次---->
第三次----->
第四次----->
第五次----->
结论： 五次压测平均QPS: 3545 ,出现超时。
3.2 简单路由+Gateway提供的两个默认过滤器
增加AddRequestParameterGatewayFilterFactory和SetRequestHeaderGatewayFilterFactory两个默认的过滤器。 配置如图：
Get请求测试结果：
第一次---->
第二次---->
第三次->
第四次-->
结论： 三次压测平均QPS: 5193,出现超时及错误。
Post测试结果
第一次---->
第二次---->
第三次----->
第四次----->
第五次----->
结论： 五次压测平均QPS: 3357,出现超时。
3.3 路由+默认过滤器+1个自定义全局过滤器
自定义全局过滤器用来修改Post请求时request body的
Post测试结果
第一次---->
第二次---->
第三次----->
第四次----->
第五次----->
结论： 五次压测平均QPS: 979 ,出现超时及错误。
3.4 路由+默认过滤器+3个自定义全局过滤器+1个aop代理
Post测试结果：
第一次---->
第二次---->
第三次----->
第四次----->
第五次----->
结论： 五次压测平均QPS: 724,出现超时及错误。
3.5 路由+默认过滤器+5个自定义全局过滤器+1个aop代理
post测试结果：
第一次---->
第二次---->
第三次----->
结论： 三次压测平均QPS: 431,出现超时及错误。
4、 结论 （重点.....)
Wrk压测结果:
用途 | QPS | 备注 |
只做简单路由 | 4131 | 当请求方式为get时直接放行，并没有修改request body，所以其QPS看起来较高。 |
路由+默认过滤器 | 4275 | 竟然比第一个要高点？其实不尽然....跟我收集的数据和计算有点关系，但不影响整体测试结果。 |
路由+默认过滤器+1个自定义全局过滤器 | 979 |
|
路由+默认过滤器+3个自定义全局过滤器+1个aop代理 | 724 |
|
路由+默认过滤器+5个自定义全局过滤器+1个aop代理 | 431 |
|
注1：当有get和post两种QPS时，下表中的QPS=（get+post）%2
注2：由于2.x gateway 使用的是netty，可通过设置netty下的reactor.netty.ioWorkerCount参数来优化并发，适当增加一倍后与以上测试结果基本一致，不合理的设置反而会降低QPS。
Jmeter压测结果：
用途 | QPS | 测试次数 | 备注 |
只做简单路由 | 5170 | 10 |
|
路由+默认过滤器 | 4257 | 5 |
|
路由+默认过滤器+1个自定义全局过滤器 | 1469 | 5 |
|
路由+默认过滤器+3个自定义全局过滤器+1个aop代理 | 792 | 5 |
|
路由+默认过滤器+5个自定义全局过滤器+1个aop代理 | 579 | 5 |
|
Jmeter测试环境和过程跟wrk完全一样，这里我只测的最常用的Post请求。
Jmeter在linux测post请求时可能需要*.jmx文件，可以在你的windows客户端装个jmeter，在界面上配置好保存后找到本地的*.jmx文件，上传到liunx就可以直接用。
- 高并发两大杀手锏：1、单机 。 2、复杂操作。
- 自定义过滤器里不过是从网上找了一段修改request body的代码，个人觉得并不能算是复杂操作，而是常用操作。
至于为什么qps下降如此之大还没有在代码层面做调研，欢迎指正、解惑。- spencergibb 在GIt上也有一个gateway和其他网关的性能测试，，参见
https://github.com/spencergibb/spring-cloud-gateway-bench （将所有请求路由到一个go搭建的取静态文件的服务中）
注意：其实当我们使用了默认提供的过滤器、自定义过滤器和aop代理这些技术导致性能降低时，其实瓶颈可能并不在网关本身了。
比如你的网关层还有访问数据库、redis缓存之类的操作，那QPS会进一步降低这是显而易见的。
延迟和吞吐量是衡量性能的重要标准，我网关环境的机器并不是只有网关服务，其Cpu和内存并不是只为网关服务,所以如果一台Liunx上只部署网关的话，相信性能应该会比较客观。
