spring cloud性能调优

今天药忘吃喽~ 2022-03-08 14:12 218阅读 0赞

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

先说明线上调用的实际例子：  
通过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 的隔离策略为**semaphor**e 。semaphore 隔离策略通常只用于非网络调用。  
**说明：高并发时，优先使用semaphore 。**

hystrix.threadpool.default.coreSize=10
    hystrix.threadpool.default.maximumSize=10
    hystrix.threadpool.default.maxQueueSize=-1

\#如该值为-1，那么使用的是SynchronousQueue，否则使用的是LinkedBlockingQueue。注意，修改MQ的类型需要重启。例如从-1修改为100，需要重启，因为使用的Queue类型发生了变化  
如果想对特定的 HystrixThreadPoolKey 进行配置，则将 default 改为 HystrixThreadPoolKey 即可。

**如果隔离策略是SEMAPHORE：**

hystrix.command.default.execution.isolation.strategy=SEMAPHORE
    hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests=10# 默认值

如果想对指定的 HystrixCommandKey 进行配置，则将 default 改为 HystrixCommandKey 即可。

## zuul参数控制 ##

我们知道Hystrix有隔离策略：THREAD 以及SEMAPHORE ，默认是 SEMAPHORE 。  
查询资料发现是因为zuul默认每个路由直接用信号量做隔离，并且默认值是100，也就是当一个路由请求的信号量高于100那么就拒绝服务了，返回500。

线程池提供了比信号量更好的隔离机制，并且从实际测试发现高吞吐场景下可以完成更多的请求。但是信号量隔离的开销更小，对于本身就是10ms以内的系统，显然信号量更合适。

当 zuul.ribbonIsolationStrategy=THREAD时，Hystrix的线程隔离策略将会作用于所有路由。  
此时，HystrixThreadPoolKey 默认为“RibbonCommand”。这意味着，所有路由的HystrixCommand都会在相同的Hystrix线程池中执行。可使用以下配置，让每个路由使用独立的线程池：

zuul:
      threadPool:
        useSeparateThreadPools: true

只有在隔离策略是thread才有效

**1. 隔离策略**

zuul.ribbon-isolation-strategy=thread

**2. 最大信号**  
当Zuul的隔离策略为SEMAPHORE时：  
全局设置默认最大信号量：

zuul.ribbon-isolation-strategy=Semaphore
    zuul:
      semaphore:
        max-semaphores: 100 # 默认值

对路由linkflow和oauth单独设置最大信号量

routes:
        linkflow:
          path: /api1/**
          serviceId: lf
          stripPrefix: false
          semaphore:
            maxSemaphores: 2000
        oauth:
          path: /api2/**
          serviceId: lf
          stripPrefix: false
          semaphore:
            maxSemaphores: 1000

**3.zuul并发连接参数**  
**针对url的路由配置**

zuul:
      host:
        max-total-connections: 200 # 默认值
        max-per-route-connections: 20 # 默认值

**针对serviceId的路由配置**

serviceId:
      ribbon:
        MaxTotalConnections: 0   # 默认值
        MaxConnectionsPerHost: 0 # 默认值

## Feign参数调优 ##

在默认情况下 spring cloud feign在进行各个子服务之间的调用时，http组件使用的是jdk的HttpURLConnection，没有使用线程池。本文先从源码分析feign的http组件对象生成的过程，然后通过为feign配置http线程池优化调用效率。  
有种可选的线程池：HttpClient和OKHttp  
个人比较推荐OKHttp，请求封装的非常简单易用，性能也很ok。

**当使用HttpClient时，可如下设置：**

feign.httpclient.enabled=true
    feign.httpclient.max-connections=200# 默认值
    feign.httpclient.max-connections-per-route=50# 默认值

代码详见：

org.springframework.cloud.netflix.feign.FeignAutoConfiguration.

HttpClientFeignConfiguration\#connectionManager

org.springframework.cloud.netflix.feign.ribbon.HttpClientFeignLoadBalancedConfiguration.

HttpClientFeignConfiguration\#connectionManager

**当使用OKHttp时，可如下设置：**

feign.okhttp.enabled=true
    feign.okhttp.max-connections=200# 默认值
    feign.okhttp.max-connections-per-route=50# 默认值

代码详见：

org.springframework.cloud.netflix.feign.FeignAutoConfiguration.

OkHttpFeignConfiguration\#httpClientConnectionPool 。

org.springframework.cloud.netflix.feign.ribbon.OkHttpFeignLoadBalancedConfiguration.

OkHttpFeignConfiguration\#httpClientConnectionPool

## tomcat调优 ##

**如果使用的是内嵌的tomcat保持默认就好**

server.tomcat.max-connections=0 # Maximum number of connections that the server accepts and processes at any given time.
    server.tomcat.max-http-header-size=0 # Maximum size, in bytes, of the HTTP message header.
    server.tomcat.max-http-post-size=0 # Maximum size, in bytes, of the HTTP post content.
    server.tomcat.max-threads=0 # Maximum number of worker threads.
    server.tomcat.min-spare-threads=0 # Minimum number of worker threads.

由于默认的最大连接数，最大线程数都是0，没有限制，所以在spring boot中启动内嵌的tomcat，**一般保持默认的配置就可以了。**

## JVM参数调优 ##

关于Jvm调优Oracle官网有一份指导说明：  
[Oracle官网对Jvm调优的说明][Oracle_Jvm]  
有兴趣大家可以去看看。

执行启动设置Jvm参数的操作。

java   -Xms1024m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m  -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC    -jar   user-1.0.0.jar

关于这些设置的JVM参数是什么意思，请参考第二步中的oracle官方给出的调优文档。

我在这边简单说一下：  
**-XX:MetaspaceSize=128m （元空间默认大小）  
\-XX:MaxMetaspaceSize=128m （元空间最大大小）  
\-Xms1024m （堆最大大小）  
\-Xmx1024m （堆默认大小）  
\-Xmn256m （新生代大小）  
\-Xss256k （棧最大深度大小）  
\-XX:SurvivorRatio=8 （新生代分区比例 8:2）  
\-XX:+UseConcMarkSweepGC （指定使用的垃圾收集器，这里使用CMS收集器）  
\-XX:+PrintGCDetails （打印详细的GC日志）**

## 请求的超时，重试，以及幂等性 ##

#配置首台服务器重试1次
    ribbon.MaxAutoRetries=1
    ##配置其他服务器重试1次
    ribbon.MaxAutoRetriesNextServer=1
    ##获取连接的超时时间
    ribbon.ConnectTimeout=1000
    ###请求处理时间
    ribbon.ReadTimeout=1000
    ##每个操作都开启重试机制
    ribbon.OkToRetryOnAllOperations=true
    
    #开启Feign请求压缩
    feign.compression.request.enabled=true
    feign.compression.request.mime-types=text/xml,application/xml,application/json
    feign.compression.request.min-request-size=2048
    feign.compression.response.enabled=true
    #配置断路器超时时间，默认是1000（1秒）
    feign.hystrix.enabled=true
    #feign use okhttp
    feign.httpclient.enabled=false
    feign.okhttp.enabled=true
    #是否开启超时熔断, 如果为false, 则熔断机制只在服务不可用时开启
    hystrix.command.default.execution.timeout.enabled=true
    hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

请求在1s内响应，超过1秒先同一个服务器上重试1次，如果还是超时或失败，向其他服务上请求重试1次。  
那么整个ribbon请求过程的超时时间为：  
**ribbonTimeout = (ribbonReadTimeout + ribbonConnectTimeout) \* (maxAutoRetries + 1) \* (maxAutoRetriesNextServer + 1);**  
ribbonTimeout = (1000 + 1000) \* (1 + 1) \* (1 + 1) = 8000  
由于Hystrix timeout一定要大于ribbonTimeout 超时，所以  
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds>8000

**超时**设置是为了防止某些耗时操作积压在线程池中，导致后续请求无法进行，压爆服务器。  
**重试**是为了防止网络抖动等原因出现偶然性异常的自动补偿机制，不过这时一定要保证所有接口的幂等性。  
**Feign请求压缩**是为了减少网络IO传递的耗时

你的系统架构中，**只要涉及到了重试，那么必须上接口的幂等性保障机制。**  
否则的话，试想一下，你要是对一个接口重试了好几次，结果人家重复插入了多条数据，该怎么办呢？  
其实幂等性保证本身并不复杂，根据业务来，**常见的方案**：  
可以在数据库里建一个唯一索引，插入数据的时候如果唯一索引冲突了就不会插入重复数据  
或者是通过redis里放一个唯一id值，然后每次要插入数据，都通过redis判断一下，那个值如果已经存在了，那么就不要插入重复数据了。  
类似这样的方案还有一些。总之，要保证一个接口被多次调用的时候，不能插入重复的数据。

> [Spring Cloud各组件调优参数][Spring Cloud]

[Oracle_Jvm]: https://docs.oracle.com/middleware/11119/wls/PERFM/jvm_tuning.htm#i1146060
[Spring Cloud]: https://www.jianshu.com/p/ebd62bac2ed4