Question

由于Spring Cloud Eureka实现的服务治理机制强调了CAP原理中的AP，即可用性与可靠性，它与ZooKeeper这类强调CP（一致性、可靠性）的服务治理框架最大的区别就是，Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下它宁愿接受故障实例也不要丢掉“健康”实例，比如，当服务注册中心的网络发生故障断开时，由于所有的服务实例无法维持续约心跳，在强调 AP 的服务治理中将会把所有服务实例都剔除掉，而Eureka则会因为超过85%的实例丢失心跳而会触发保护机制，注册中心将会保留此时的所有节点，以实现服务间依然可以进行互相调用的场景，即使其中有部分故障节点，但这样做可以继续保障大多数的服务正常消费。

由于Spring Cloud Eureka在可用性与一致性上的取舍，不论是由于触发了保护机制还是服务剔除的延迟，引起服务调用到故障实例的时候，我们还是希望能够增强对这类问题的容错。所以，我们在实现服务调用的时候通常会加入一些重试机制。在目前我们使用的Brixton版本中，对于重试机制的实现需要我们自己来扩展完成。而从Camden SR2版本开始，Spring Cloud整合了Spring Retry来增强RestTemplate的重试能力，对于开发者来说只需通过简单的配置，原来那些通过 RestTemplate 实现的服务访问就会自动根据配置来实现重试策略。

以我们之前对hello-service服务的调用为例，可以在配置文件中增加如下内容：

spring.cloud.loadbalancer.retry.enabled=true

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

hello-service.ribbon.ConnectTimeout=250

hello-service.ribbon.ReadTimeout=1000

hello-service.ribbon.OkToRetryOnAllOperations=true

hello-service.ribbon.MaxAutoRetriesNextServer=2

hello-service.ribbon.MaxAutoRetries=1

其中各参数的配置说明如下所示。

- spring.cloud.loadbalancer.retry.enabled：该参数用来开启重试机制，它默认是关闭的。这里需要注意，官方文档中的配置参数少了enabled。该参数的源码定义如下：

@ConfigurationProperties（"spring.cloud.loadbalancer.retry"）

public class LoadBalancerRetryProperties {

private boolean enabled=false;

...

}

- hystrix.command.default.execution.isolation.thread.timeoutIn Milliseconds：断路器的超时时间需要大于 Ribbon 的超时时间，不然不会触发重试。

- hello-service.ribbon.ConnectTimeout：请求连接的超时时间。

- hello-service.ribbon.ReadTimeout：请求处理的超时时间。

- hello-service.ribbon.OkToRetryOnAllOperations：对所有操作请求都进行重试。

- hello-service.ribbon.MaxAutoRetriesNextServer：切换实例的重试次数。

- hello-service.ribbon.MaxAutoRetries：对当前实例的重试次数。

根据如上配置，当访问到故障请求的时候，它会再尝试访问一次当前实例（次数由MaxAutoRetries配置），如果不行，就换一个实例进行访问，如果还是不行，再换一次实例访问（更换次数由MaxAutoRetriesNextServer配置），如果依然不行，返回失败信息。