关于zuul，ribbon和hystrix的配置和说明

在使用spring cloud框架开发微服务时，会遇到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重试的配置。

# hystrix的超时时间必须大于ribbon的超时时间
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
# 开启重试
zuul.retryable=true
spring.cloud.loadbalancer.retry.enabled=true
# 请求连接的超时时间
ribbon.connectTimeout=2000
# 请求处理的超时时间
ribbon.readTimeout=5000
# 对当前实例的重试次数
ribbon.maxAutoRetries=1
# 切换实例的重试次数
ribbon.maxAutoRetriesNextServer=3
# 对所有操作请求都进行重试
ribbon.okToRetryOnAllOperations=true

关于hystrix的超时时间计算的问题说明，以上面的配置时间为例：

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

最后，要使配置生效，项目需要导入相应的依赖：

    org.springframework.retry
    spring-retry
    1.2.1.RELEASE