zuul的性能调优

文章目录

- zuul的性能调优
- [zuul 1.x 与2.x的区别与总结](#zuul 1.x 与2.x的区别与总结)

zuul的性能调优

在项目实践中，使用jemeter多线程并发访问微服务中的接口时候，在Zuul层出现异常、超时等，从而导致整个请求失败。经过实践，通过调整Zuul的参数、设计高可用架构等可提升TPS、QPS。

Zuul参数剖析

zuul下的routes节点可配置路由转发规则

设置全局ribbon

yml 复制代码

ribbon:
  ReadTimeout: 60000
  ConnectTimeout: 60000
  MaxAutoRetriesNextServer: 1
  MaxAutoRetries: 1

设置单个路由

yml 复制代码

zuul：
 routes：
  echo：
   path：/ myusers / **
   serviceId：myusers-service
   stripPrefix：true
 
myusers-service：
 ribbon：#负载
  NIWSServerListClassName：com.netflix.loadbalancer.ConfigurationBasedServerList
  listOfServers：http：//example1.com,http：//example2.com
  ConnectTimeout：1000 
  ReadTimeout：3000 
  MaxTotalHttpConnections：500 
  MaxConnectionsPerHost：100

如上面的配置，HTTP请求中满足 /myusers/** 规则转发到myuser-service服务。结合ribbon，可支持myusers-service多实例的动态负载。实际项目中可集成eureka或者consul等自动获取listOfServers(多实例服务hosts列表)。

semaphore(信号量)

在spring cloud Zuul中有2种对路由的隔离机制，其默认的是信号量（semaphore）对路由做隔离，默认值是100，当一个路由请求的信号量高于100就返回500。

yml 复制代码

zuul:
 semaphore:
  max-semaphores: 5000 #设置全部路由最大信号量
 routes:
  orchestration:
  service-id: orchestration
resource-manager:
  service-id: resource-manager
   semaphore:
    max-semaphores: 5000 #针对单个服务的路由设置最大信号量

设置信号量，可在Zuul节点下对所有路由统一设置信号量（semaphore）大小，在实际项目中推荐为每个服务设置不同的信号量（semaphore）。

ribbon

SpringCloud中ribbon提供负载均衡能力，实际项目中后端不同服务都是多实例，因此从Zuul路由到某个服务也需要支持负载均衡。

yml 复制代码

zuul:
 ribbon:
  OkToRetryOnAllOperations:true     #全部请求开启重试机制
  ReadTimeout: 6000                 #请求处理超时时间
  ConnectTimeout: 6000              #请求连接超时时间
  MaxTotalHttpConnections: 1000     #最大http连接数
  MaxConnectionsPerHost: 100        #每个host最大连接数
  MaxAutoRetries: 10                #最大重试次数
  MaxAutoRetriesNextServer: 10      #切换实例的重试次数
 eureka:
  enabled: true

在高并发或者后端服务由于网络等原因，导致请求某一瞬间发生故障，也许后端服务只是暂时不可达或者响应比较慢。通过调整响应时间以及重试次数提高请求成功率。

hystrix

hystrix(熔断)，当通过服务网关（基于Zuul实现）调用后端服务时候，难免会出现网络、响应超时等情况。通过hystrix可断掉与后端服务的连接，防止拖垮网关服务器。也可以通过hystrix实现服务降级，当发生异常时候，通过fallback处理熔断（比如：返回一些用户能看懂的错误提示等）。

yml 复制代码

hystrix:
 threadpool:
  default:
   coreSize: 1000   #线程池数量
 command:
  default:
   execution:
    isolation:
      thread:
        timeoutInMilliseconds: 60000  #发生熔断的超时时间
        strategy: SEMAPHORE   #隔离策略
       semaphore:
        max-semaphores: 2000 #信号量大小

高并发下常见Zuul异常

在高并发下，针对不同的系统架构、业务场景。需要自己调整Zuul各组件参数来满足性能需求。我们在使用jemeter进行并发测试，发现Zuul（服务网关）层出现了一些异常信息，解决了这些异常信息，QPS,TPS都提高了不少。

无法获取信号量(semaphore异常）

spring cloud zuul : could not acquire a semaphore for execution and no fallback

available.

无法获取信号量，系统默认每个路由的信号量为100，当后端一个实例且并发大于100就会经常出现这个异常信息

调优配置:

yml 复制代码

zuul:
 semaphore:
  max-semaphores: 5000 #可根据系统需要支持的并发数适当增加信号量的大小

超时

异常信息:

connect time out...

当并发访问时，有些服务所在主机响应可能会比较慢，或者某些业务本身比较耗时（比如上传一个大文件的接口）。如果在Zuul层设置的超时时间小于足业务的耗时，会导致正常的业务请求失败。

调优配置:

yml 复制代码

ribbon:
 ReadTimeout: 6000                 #请求处理超时时间
 ConnectTimeout: 6000              #请求连接时间根据业务可适当调大超时时间

熔断

异常信息：

short-circuited and no fallback available

并发访问时，后端某些服务发生熔断

调优配置:

yml 复制代码

hystrix:
 command:
  default:
   execution:
    isolation:
      thread:
        timeoutInMilliseconds: 60000  #发生熔断的超时时间调整熔断超时时间，熔断时间太短，些耗时的业务部不能work熔断时太长，Zuul服务器可能会被拖垮。所以根据具体业务找到一个合适值。
ribbon:
 OkToRetryOnAllOperations:true     #全部请求开启重试机制
 ReadTimeout: 6000                 #请求处理超时时间
 ConnectTimeout: 6000              #请求连接超时时间
 MaxAutoRetries: 10                #最大重试次数调整重试次数，实际项目中由于网络或者资源不够，偶尔会出现后端服务不能访问，一次访问失败不能代表后端服务就挂了。因此开启重试机制，调整重试次数。在一定时间内，重试几次都失败，我们才认为后端服务挂了。

zuul 1.x 与2.x的区别与总结

1、1.x 同步阻塞，编程模型简单，社区成熟，通过调整参数能满足生产性能需求

2、2.x 异步非阻塞，相对编程模型复杂，刚出来也许还有些坑(bug)，追求更好性能可以尝试

当高并发情况下，服务网关服务器(Zuul)可通过以下方法提高支持并发的能力。

1、调整Zuul组件参数

2、支持Zuul高可用，多实例

3、选择异步、非阻塞版本

转载：https://mp.weixin.qq.com/s/7S9zPM5lBDtOwtNJ5JOZyQ
https://blog.csdn.net/zhangzijiejiayou/article/details/101070379/