spring cloud性能调优

本文针对公司微服务并发的实际场景以及网上调研的资料，记录影响微服务并发的各种优化配置。

先说明线上调用的实际例子：
通过zuul网关 调用服务A的接口，服务A的接口里面通过Feign调用服务B的接口。

问题：
通过JMeter并发测试发现，并发数竟然没有达到30次/s，即QPS不到30。这显然不合理。

备注：
TPS(吞吐量) 系统在单位时间内处理请求的数量。
QPS(每秒查询率) 每秒的响应请求数

第一步：熔断器并发调优
首先想到的是Feign调用并发过大，导致的熔断问题，优化服务A中的熔断配置
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10
果然，hystrix在semaphore隔离方案下，最大的并发默认是10。
优化配置：

#线程策略
hystrix.command.default.execution.isolation.strategy=SEMAPHORE
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=500

第二步：Zuul并发调优
经历了将熔断器执行线程并发设置为500后，继续用JMeter进行并发测试，结果QPS到达100后，又出现大量请求失败。
查看日志，发现zuul很多请求连接关闭。

优化配置：

#zuul网关配置
zuul.semaphore.max-semaphores=500

再次使用JMeter测试，发现并发500没有在出现问题。

以上2个就是spring cloud并发调优最核心的2个参数。

下面系统说下spring cloud工程调优的问题
主要从以下几个方面入手：
1、hystrix熔断器并发调优
2、zuul网关的并发参数控制
3、Feign客户端和连接数参数调优
4、Tomcat并发连接数调优
5、timeout超时参数调优
6、JVM参数调优
7、ribbon和hystrix的请求超时，重试以及幂等性配置

下面说明下具体调优参数：

hystrix熔断器调优
表示HystrixCommand.run()的执行时的隔离策略，有以下两种策略

1 THREAD: 在单独的线程上执行，并发请求受线程池中的线程数限制
2 SEMAPHORE: 在调用线程上执行，并发请求量受信号量计数限制
在默认情况下，推荐HystrixCommands 使用 thread 隔离策略，HystrixObservableCommand 使用 semaphore 隔离策略。
只有在高并发(单个实例每秒达到几百个调用)的调用时，才需要修改HystrixCommands 的隔离策略为semaphore 。semaphore 隔离策略通常只