本文针对公司微服务并发的实际场景以及网上调研的资料,记录影响微服务并发的各种优化配置。
先说明线上调用的实际例子:
通过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 隔离策略通常只用于非网络调用。
说明:高并发时,优先使用semaphore