SpringCloud组件性能优化的技巧

Springcloud 的性能问题

Springcloud 原始的配置，性能是很低的，大家可以使用 Jmeter 测试一下，QPS 不会到 50。

要做到高并发，需要做不少的配置优化，主要的配置优化有以下几点：

• Feign 配置优化
• hystrix 配置 优化
• ribbon 优化
• Servlet 容器 优化
• Zuul 配置 优化

应用服务组件调优

Servlet 容器 优化

默认情况下，Spring Boot 使用 Tomcat 来作为内嵌的 Servlet 容器，可以将 Web 服务器切换到 Undertow 来提高应用性能，Undertow 是红帽公司开发的一款基于 NIO 的高性能 Web 嵌入式

Zuul 使用的内置容器默认是 Tomcat，可以将其换成 undertow，可以显著减少线程的数量，替换方式即在 pom 中添加以下内容：

第一步，移除 Tomcat 依赖

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-web</artifactId>
   <exclusions>
      <exclusion>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-starter-tomcat</artifactId>
      </exclusion>
   </exclusions>
</dependency>

第二步，增加 Untertow 依赖

<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

第三步, Undertow 的属性配置

server:
  undertow:
     io-threads: 16
     worker-threads: 256
     buffer-size: 1024
     buffers-per-region: 1024
     direct-buffers: true

server.undertow.io-threads: 设置 IO 线程数, 它主要执行非阻塞的任务, 它们会负责多个连接, 默认设置每个 CPU 核心一个线程, 不要设置过大，如果过大，启动项目会报错：打开文件数过多

server.undertow.worker-threads: 阻塞任务线程池, 当执行类似 servlet 请求阻塞 IO 操作, undertow 会从这个线程池中取得线程, 它的值设置取决于系统线程执行任务的阻塞系数，默认值是 IO 线程数 * 8

server.undertow.buffer-size: 以下的配置会影响 buffer, 这些 buffer 会用于服务器连接的 IO 操作, 有点类似 netty 的池化内存管理, 每块 buffer 的空间大小, 越小的空间被利用越充分，不要设置太大，以免影响其他应用，合适即可

server.undertow.buffers-per-region: 每个区分配的 buffer 数量 , 所以 pool 的大小是 buffer-size * buffers-per-region

server.undertow.direct-buffers: 是否分配的直接内存 (NIO 直接分配的堆外内存)

Feign 配置优化

feign 默认不启用 hystrix，需要手动指定 feign.hystrix.enabled=true 开启熔断

feign 启用压缩也是一种有效的性能优化方式，具体的配置如下

feign:
	compression:
		request:
			enabled: true
			mime-types: text/xml,application/xml,application/json
		response:
			enabled: true

feign HTTP 请求方式选择 feign 默认使用的是基于 JDK 提供的 URLConnection 调用 HTTP 接口，不具备连接池, 所以资源开销上有点影响，经测试 JDK 的 URLConnection 比 Apache HttpClient 快很多倍。Apache HttpClient 和 okhttp 都支持配置连接池功能, 也可以使用 okhttp 请求方式。 当使用 HttpClient 时，可如下设置：

feign:
  httpclient:
    enabled: true
    max-connections:1000
    max-connections-per-route: 200

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

feign:
  okhttp:
    enabled: true
  httpclient:
    max-connections: 1000
    max-connections-per-route: 200

max-connections 设置整个连接池最大连接数（该值默认为 200）， 根据自己的场景决定 max-connections-per-route 设置路由的默认最大连接（该值默认为 50），限制数量实际使用

Gateway 组件调优

Zuul 配置 优化

我们知道 Hystrix 有隔离策略：THREAD 以及 SEMAPHORE ，默认是 SEMAPHORE 。

Zuul 默认是使用信号量隔离，并且信号量的大小是 100，请求的并发线程超过 100 就会报错，可以调大该信号量的最大值来提高性能，配置如下：

zuul:  semaphore:    max-semaphores: 5000

表示，当 Zuul 的隔离策略为 SEMAPHORE 时，设置指定服务的最大信号量为 5000。对于特定的微服务，可以通过下面的方式，设置最大信号量

设置默认最大信号量：

zuul:

semaphore:

max-semaphores: 5000 # 默认值

设置指定服务的最大信号量：

zuul:
  semaphore:
    max-semaphores: 5000

为了方便 ThreadLocal 的使用，也可以改为使用线程隔离的策略，这种场景下，就需要调大 hystrix 线程池线程大小，该线程池默认 10 个线程，调整的配置示例如下：

zuul:
  ribbonIsolationStrategy: THREAD
hystrix:
  threadpool:
    default:
      coreSize: 100
      maximumSize: 400
      allowMaximumSizeToDivergeFromCoreSize: true
      maxQueueSize: -1

hystrix.threadpool.default.allowMaximumSizeToDivergeFromCoreSize：是否让 maximumSize 生效，false 的话则只有 coreSize 会生效

hystrix.threadpool.default.maxQueueSize：线程池的队列大小，-1 代表使用 SynchronousQueue 队列

hystrix.threadpool.default.maximumSize：最大线程数量

hystrix.threadpool.default.allowMaximumSizeToDivergeFromCoreSize：是否让 maximumSize 生效，false 的话则只有 coreSize 会生效

hystrix.threadpool.default.maxQueueSize：线程池的队列大小，-1 代表使用 SynchronousQueue 队列

zuul.ribbon-isolation-strategy: 设置线程隔离，thread 线程隔离，SEMAPHORE 表示信号量隔离

默认配置都可以去 HystrixThreadPoolProperties 和 ZuulProperties 这两个 java 文件中查找

hystrix 配置 优化

首先需要设置参数 hystrix.threadpool.default.coreSize 来指定熔断隔离的线程数，这个数需要调优，经测试线程数我们设置为和提供方的容器线程差不多，吞吐量高许多。

其次，启用 Hystrix 后，很多服务当第一次访问的时候都会失败 是因为初始化负载均衡一系列操作已经超出了超时时间了，因为默认的超时时间为 1S，需要修改超时时间参数，方可解决这个问题。

参考的 hystrix 配置如下：

hystrix:
  threadpool:
    default:
      coreSize: 500
  command:
    default:
	  circuitBreaker: 
	    requestVolumeThreshold: 1000
      fallback:
        enabled: true
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 100000

hystrix.command.default: 全局的作用域，作用的所有的 hystrix 的客户端, 如果需要对某个微服务，可以写 serviceId

hystrix.command.default.fallback.enabled 是否开启回退方法

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 请求处理的超时时间，缺省为 1000, 表示默认的超时时间为 1S

hystrix.threadpool.default.coreSize 核心线程池数量

hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 回退最大线程数

hystrix.command.default.circuitBreaker.requestVolumeThreshold 熔断器失败的个数，进入熔断器的请求达到 1000 时服务降级（之后的请求直接进入熔断器）

ribbon 优化

Ribbon 进行客户端负载均衡的 Client 并不是在服务启动的时候就初始化好的，而是在调用的时候才会去创建相应的 Client，所以第一次调用的耗时不仅仅包含发送 HTTP 请求的时间，还包含了创建 RibbonClient 的时间，这样一来如果创建时间速度较慢，同时设置的超时时间又比较短的话，很容易就会出现上面所描述的显现。

因此我们可以通过设置:

ribbon:
	eager-load:
    	enabled：true
	clients：service-1,service-2,service-n

参数说明:

ribbon.eager-load.enabled : 开启 Ribbon 的饥饿加载模式

ribbon.eager-load.clients: 指定需要饥饿加载的服务名，如果不指定服务名称，饥饿加载模式无效

Zuul 的饥饿加载，没有设计专门的参数来配置，而是直接采用了读取路由配置来进行饥饿加载。所以，如果我们使用默认路由，而没有通过配置的方式指定具体路由规则，那么 zuul.ribbon.eager-load.enabled=true 的配置就没有什么作用了。

如果需要真正启用 Zuul 的饥饿加载，需要通过 zuul.ignored-services=* 来忽略所有的默认路由，让所有路由配置均维护在配置文件中，以达到网关启动的时候就加载好各个路由的负载均衡对象。

关于 Zuul 的默认路由，这里详细介绍一下。假设你的注册服务中心有三个已经注册的服务名称 service-a，service-b，service-c。但是在 zuul 配置文件中，只映射了 service-a，service-b，如下：

zuul:
  ribbon:
    eager-load:
      enabled: true 
  ignored-services: ‘*'
  routes:
    a:
      path: /a/**
      serviceId: service-a
    b:
     path: /b/**
     serviceId: service-b

这里，虽然没有配置 service-c 的映射，但是，由于 zuul 有默认的映射机制，还是可以通过 //ip:port/service-c / 的 Url，访问到你的 service-c 服务，如果不想向外界暴露默认的服务映射，可以加上 zuul.ignored-services:*

到此这篇关于SpringCloud组件性能优化的技巧的文章就介绍到这了,更多相关SpringCloud组件优化内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！