SpringCloud初探(三) - zuul、ribbon、h

前言

• 有的同学在刚开始使用spring cloud 框架开发微服务时，会遇到zuul、ribbon、hystrix相关的配置，不懂的同学对这几个配置都比较蒙，例如：如下配置

spring:
  application:
    name: test-gateway
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
server:
  port: 16000

#zuul转发规则配置
zuul:
  host:
    socket-timeout-millis: 60000
    connect-timeout-millis: 10000
  #关闭请求转发重试机制(全局关闭)
  retryable: false
  #添加默认前缀
  prefix: /api
  #不移除前缀
  strip-prefix: true
  #重新定义敏感请求头信息，放行全部的请求头部信息
  sensitive-headers:
  #解决重定向跳转路径问题
  add-host-header: true
  #配置路由git
  routes:
    client:
      path: /client-01/**
      serviceId: client-01
      strip-prefix: true

#ribbon的全局配置项
ribbon:
  #http请求连接建立超时时间（ms）
  ConnectTimeout: 10000
  #http请求处理超时时间（ms）
  ReadTimeout: 15000
  #默认重试次数
  MaxAutoRetries: 1
  #默认尝试的实例数
  MaxAutoRetriesNextServer: 4
#http请求客户端负载均衡各项配置
feign:
  #开启客户端熔断机制
  hystrix:
    enabled: true
  #开启请求和响应的压缩机制（GZIP）
  compression:
    request:
      enabled: true
    response:
      enabled: true

#熔断机制配置
hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 15000 #熔断的超时时间（ms）
          #线程隔离策略配置，官方推荐使用THREAD，即下游依赖的请求在一个单独的线程中隔离，这里为了解决feign转发时需要携带head信息所以讲策略设置为SEMAPHORE，即下游依赖请求在当前调用线程中执行
          strategy: SEMAPHORE

上述配置包含了zuul、ribbon、hystrix配置，下面我们讨论一下三者的区别

名词解释

• zuul 是gateway的核心，叫做路由。在一个项目中，有很多微服务，他们之间的相互调用就是通过zuul的设置才能实现的
• ribbon 负载均衡，spring cloud是一个分布式框架，所以ribbon是针对业务模块的多实例负载均衡的配置
• hystrix 熔断器，当gateway调用具体的业务模块时，难免会收到网络，查询效率等因素的影响，导致响应超时，这时候就需要配置hystrix了，以免线程一直占用内存，导致内存溢出等问题，使程序down掉

配置

• 关于这三个超时策略额问题,zuul和ribbon都有connect-timeout和socket-timeout的配置，当zuul.routes的配置走url的时候，是zuul.host.connect-timeout-millis,zuul.host.socket-timeout-millis这两个配生效，当zuul.routes的配置走serviceid的时候，是ribbon.Readtimeout,ribbon.Sockettimeout生效
• hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000这个配置是hystrix的熔断时间，当请求时间超过这个时间，会自动熔断，释放内存
• ribbon的重试机制：当一个请求过来被分发到其中的一个实例处理，当这个实例出现问题无法响应或者响应超时的时候，继续请求当前实例，或者请求其他实例

时间配置

• ribbon.connectTimeot是请求连接的时间，基本上都是很短的，所以这个请求的时间可以忽略不记，所耗费的时间基本上都是在请求的处理时间上。所以计算的公式是（1+maxAutoRetries+maxAutoRetriesNestServer)*5000,该计算公式会得出一个值，hystrix的超时时间最好要大于这个值，如果小于这个值的话，那么配置重试就没有意义了，因为当系统还在进行重试的时候，就把这一次的请求熔断了
• 最后，要使配置生效，项目还要导入重试依赖

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
    <version>1.2.1.RELEASE</version>
</dependency>

希望对你有所帮助，如有不对，欢迎指正