记一次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进行调优等等。
