vlambda博客
学习文章列表

生产级基于SpringCloud微服务架构性能优化实战,建议收藏

前言

 

本文将从Tomcat性能优化,SpringCloud开启重试机制,Zuul网关性能参数优化,Ribbon性能参数优化,Feign与Hystrix性能优化等五个方面分享在生产环境如何做好SpringCloud性能优化。

Tomcat性能优化

生产级基于SpringCloud微服务架构性能优化实战,建议收藏

 

一般基于SpringCloud的微服务能够脱离传统的tomcat,独立跑起来,SpringBoot功不可没,其原理是SpringBoot内嵌了tomcat(当然可以换成其他servlet容器,如jetty),能够以java -jar形式就能跑起来。

所以针对每个springboot服务,我们需要对tomcat的一些参数进行优化,以下是楼主项目组优化的tomcat参数配置,供大家参考。

server:
tomcat:
accept-count: 10000
max-threads: 5000
max-connections: 5000

tomcat参数说明:

maxThreads:tomcat起动的最大线程数,即同时处理的任务个数,默认值为200
acceptCount:当tomcat起动的线程数达到最大时,接受排队的请求个数,默认值为100

maxThreads,acceptCount参数应用场景

场景一

tomcat的请求线程数未达到maxThreads最大阀值,tomcat新建线程处理此请求。

场景二

tomcat的请求线程数达到maxThreads最大阀值,tomcat会把当前请求放入队列,等待空闲线程处理该请求。

场景三

tomcat的请求线程数达到maxThreads最大阀值,并且请求队列以达到acceptCount的最大阀值,tomcat拒绝请求,返回连接拒绝(connection refused)。

maxThreads调优

一般说服务器性能要从两个方面说起:

1、cpu计算型指标

如果是cpu计算型请求,那么系统响应时间的主要限制就是cpu的运算能力,此时maxThreads应该尽量设的小,降低同一时间内争抢cpu的线程个数,可以提高计算效率,提高系统的整体处理能力

2、io密集型指标

如果是IO密集型请求,例如数据库读写,那么响应时间的主要限制就变为等待外部资源,此时maxThreads应该尽量设的大,这样才能提高同时处理请求的个数,从而提高系统整体的处理能力。

所以大部分情况下,tomcat处理io型请求比较多,比如常见的连数据库查询数据进行接口调用。

另外,要考虑tomcat的并发请求量大的情况下,对于服务器系统参数优化,如虚拟机内存设置和linux的open file限制。

maxThreads设置多大合适?

我们知道线程过多,会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大;线程太少,服务器的请求响应吞吐量会急剧下降,所以maxThreads的配置绝对不是越大越好。

实际情况是设置maxThreads大小没有最优解,要根据具体的服务器配置,实际的应用场景不断的调整和优化。

acceptCount设置多大合适?

尽量与maxThreads的大小保持一致这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

如果设的较小,可以保证接受的请求较快相应,但是超出的请求可能就直接被拒绝

如果设的较大,可能就会出现大量的请求超时的情况,因为我们系统的处理能力是一定的。

SpringCloud开启重试机制

 

spring. cloud.loadbalancer.retry.enabled=true

Zuul网关性能参数优化

当使用URL进行路由时,则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。

zuul.host. connect-timeout-millis: 10000
zuul.host. socket-timeout-millis: 60000

Ribbon性能参数优化

请求连接的超时时间

ribbon.ConnectTimeout=60000

请求处理的超时时间

ribbon.ReadTimeout=60000

对所有操作请求都进行重试

ribbon.OkToRetryOnAllOperations=false

对当前实例的重试次数,针对同一个服务实例,最大重试次数(不包括首次调用)

ribbon.MaxAutoRetries=1

对下个实例的重试次数,针同其它的服务实例,最大重试次数(不包括首次server)

ribbon.MaxAutoRetriesNextServer=2

注意Hystrix断路器的超时时间需要大于ribbon的超时时间,不然不会触发重试

Feign与Hystrix性能优化

Feign和Ribbon在整合了Hystrix后,首次调用失败的问题?

在实际项目中,如果使用了Feign,会出现首次调用失败,造成该问题的原因是Hystrix默认的超时时间是1秒,如果超过这个时间尚未响应,将会进入fallback代码。而首次请求往往会比较慢(因为Spring的懒加载机制,要实例化一些类),这个响应时间可能就大于1秒了。

目前楼主的强烈做法是:禁用Hystrix的超时时间,设为false

hystrix.command.default.execution.timeout.enabled: false

还有一种是官方提倡的是设置超时时间。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000

在实际的项目中亲测,这种方式也有不好的地方,如请求时间超过5s会出现请求数据时有时无的情况,给用户的感觉是系统不稳定,要求整改

另外,禁用hystrix,官方不推荐

hystrix超时设置原则

hytrix设置超时时间 > 默认的hytrix超时时间 > ribbon超时时间

问题:一个http请求,如果feign和ribbon都配置了重试机制,异常情况下一共会请求多少次?

请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积:

n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默认的请求。

其实二者的重试机制相互独立,并无联系。但是因为用了feign肯定会用到ribbon,所以feign的重试机制相对来说比较鸡肋,一般会关闭该功能。ribbon的重试机制默认配置为0,也就是默认是去除重试机制的,建议不要修改。


期推





如果你觉得文章不错,文末的赞 👍 又回来啦,记得给我「点赞」和「在看」哦~