自从采用了中台架构，看到内部服务间无比复杂的调用链路，内心对平台性能就是七上八下的，一直没时间做性能摸底，刚好7月份满足了业务的上线需求，又经过1个多月的打磨，现在终于能腾出手来看看性能情况了。来吧！压抑吧！

先来个查询的场景，2000并发，3个阶梯，10分钟跑起来，话说现在云服务真TM好用，考虑又周到，绝对不是打广告哈！阿里云的压测服务用起来还是比较给力的，多机输送流量，压起来杠杠的，花钱也是杠杠的~_~!

 

CPU、负载都上来了：

 

没对啊，TPS这么低？？？这不科学，多试几个接口还是一样，到底哪儿在作妖？空口再测一次，有点点提高，难道是gateway？跳过网关测，原来真是，gateway吃掉了将近65%的TPS性能

 

参考网上公开的数据，确实网关对性能的损耗是很大的，spring gateway性能表现要好于zuul，但实际损耗也蛮大的，没办法，这就是使用微服务的代价，不过现在都容器化了，多开几个gateway容器也能一定程度上缓解这个问题，同时新版本gateway性能要比老版本表现好些，如果实在接受不了的话，据说kong接近于原生nginx代理的性能，但是开发使用起来复杂度要高些。

这里附上网上其他大神的测试结果，（测试版本未知，环境未知，仅作参考，请勿拍砖）：

服务	平均时延(ms)	RPS	性能损失
Origin	2.94	33014.70	0
Netflix Zuul	12.39	13175.21	60.09%
Spring Cloud Gateway	4.95	21685.14	34.32%
Kong	4.01	24397.35	26.10%

 

单实例服务，不经过gateway，结果：

 

4服务实例，不经过gateway，结果：

后端单实例服务，8个gateway实例：

做个总结，代码优化空间较大： 

场景	服务实例数	成功率	并发数	平响ms	TPS	峰值TPS	CPU	DB CPU	DB连接数	接收KB/s	发送KB/s	备注
空口有网关	1	98%	1000	529	1463	1759
	1	99.99%	2000	1132	4178	17455
	2	100%	2000	467	2547	3173
	4	100%	2000	208	5948	7249
空口无网关	1	100%	2000	80	12174	15659
	2	100%	2000	46	13161	16286
	2	99.81%	4000	108	23774	31854
空口升级网关	1	100%	2000	288	3606	4877
下单	1	95.06%	500	2349	179
	1	96%	1000	4241	177
	1	88%	1000	3709	193
商品列表页	1		1000	2560	258		0.89	0.3	67	~11922	~118	达到带宽上限
	4		1000	1725	413		0.84	0.45	197	~12680	~120	达到带宽上限
	8		1000	1534	426
	16		1000	1397	465
查询订单	1		1000	1922	607	991	0.71	0.22	32	691
	4		1000	585	1977	2914	0.8	0.22	34	2210