记一次Spring Cloud压力测试

前言

公司打算举办一场活动，现场参与活动人数比较多。针对于可能访问比较密集的接口进行压力测试。使用jmeter进行测试，请求并发稍微多些，系统就会挂起。

　　针对压力测试出现的问题，因为并发超过1秒钟100笔就会出现问题，Spring Cloud作为一个成熟的框架，不可能是框架不支持。所以首先想到的是配置上需要进行调优。

1、Spring Cloud配置调优

　　请求从jmeter发出后，需要通过Zuul网关，然后到Spring Cloud微服务端。所以，整个调优方向分为两个地方：微服务端和zuul网关。

1.2、微服务应用

　　当jmeter调整到每秒钟70个并发请求时，服务应用端的日志中出现了很多hystrix回滚，并且有很多HystrixRuntimeException。

com.netflix.hystrix.exception.HystrixRuntimeException ... could not be queued for execution...

　　原因：Hystrix请求线程池缺省为最大10个线程，在大量请求下，很容易超过这个数值，导致抛出异常。

　　解决方法：在配置文件中修改线程池中的coreSize（properties方式的配置文件）

hystrix.threadpool.default.coreSize=500

　　配置上测试后，客户端不再出现hystrix的异常了，但是并发请求数进一步提高到100以上后，依然会无法响应请求。

1.3、zuul网关

　　由于网关也配置使用了Hystrix，在并发请求过大时，也会抛出异常：

com.netflix.hystrix.exception.HystrixRuntimeException: ggx-test short-circuited and no fallback available

　　显示的异常时，具体的ggx-test服务系统短路并且没有熔断可用，但ggx-test系统还正在运行，所以问题出现在zuul网关上。

　　① zuul内部路由可以理解为使用一个线程池去发送路由请求，所以我们也需要扩大这个线程池的容量。

zuul.host.maxTotalConnections=1000

zuul.host.maxPerRouteConnections=1000

　　② zuul使用Hystrix，而Hystrix有隔离策略： THREAD 以及 SEMAPHORE ，默认是 SEMAPHORE ，默认大小是100。请求的并发线程超过100就会报错。

zuul.semaphore.max-semaphores=5000

　　配置完上述配置后，重新进行测试，在日志中不会出现错误了，但是并发请求超过100/S时，系统挂起，不再响应请求。于是，排查各种可能后，想到了可能是数据库连接池的问题。

2、数据库连接池

　　我们系统使用数据库连接池是c3p0，最大的数据库配置的连接数为30个，尝试将数据库最大连接数修改到100时，使用jmeter测试，并发请求能够稍微提高些。这样能够定位到问题就在数据库连接池上。

　　目前市场上主流的开源数据库连接池有：C3P0,DBCP,Druid,HikariCp。其中C3P0和DBCP是出现的比较早的数据库连接，比较稳定，在低并发的情况下，整体表现还不错，但是在高并发下，响应时间变长，性能很差，甚至于死锁。Druid是阿里巴巴开源的高性能数据库连接池，虽然性能不及HikariCp，但是它提供的各种维度的统计分析的功能，在国内市场流行度很高。

　　相关的数据库连接池对比：

	C3P0/DBCP	Druid	hikariCP
应用	主要在Hibernate	各大主流平台	起源于boneCP
性能	较差	强	很强
线程池容器	Blocking Queue	List Reentrantlock

　　综合，Druid性能比较优异，网上文档资料很健全，加上可视化的统计分析很适合我们解决当前问题。我们将数据库连接池从C3P0换到了Druid。

3、总结

　　经过上面优化，压力测试达到了预期，jmeter每秒钟发送1000个并发请求，系统能够在预期时间内顺利返回响应结果。虽然不是很高，但是应对我们当前业务需求是足够的。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑。当然这并不能影响我们对技术的追求，在碰到并发请求大的情况下，有几个维度可以进行尝试优化：首先就是限流，将请求拦截下来，不要对系统造成太大压力；其次使用各种缓存，对于不需要访问数据库的资源缓存起来，提高响应速度，减少数据库压力；然后使用分布式部署，使用集群替代单机；还有优化接口对SQL进行调优等等。