Spring Cloud Ribbon(客户端负载均衡)（2）

悠悠 2022-05-14 12:23 181阅读 0赞

## 1.参数配置 ##

对于Ribbon的参数配置通常有两种方式：全局配置以及指定客户端配置：

全局配置：ribbon.<key>=<value>格式进行配置即可。<key>代表了Ribbon客户端配置的参数名，<value>代表了对应参数值。比如设置超时时间：

ribbon.connectTimeout=250

全局配置可以作为默认值进行设置，当指定客户端配置了相应key值时，将覆盖全局配置的内容。

客户端配置：<client>.ribbon.<key>=<value>的格式进行配置。<key>和<value>含义与全局配置相同，而<client>代表了客户端的名称，可以理解为一个服务名。如：

hello-service.ribbon.listOfServers=localhost:8001,localhost:8002

对于Ribbon参数的key以及value类型的定义可以通过查看com.netflix.client.config.commonClientConfigKey类看详细配置。

## 2.与Eureka结合 ##

当Spring Cloud的应用中引入Spring Cloud Ribbon和Spring Cloud Eureka依赖时，会触发Eureka中实现的对Ribbon的自动化配置。这时ServerList的维护机制实现将被com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList的实例所覆盖，该实现会将服务清单列表交给Eureka的服务治理机制来进行维护。

在与Spirng Cloud Eureka结合使用的时候，不需要通过类似hello-service.ribbon.listOfServers的参数来指定具体的服务实例清单，因为Eureka会为我们维护所有服务的实例清单。对于Ribbon的参数配置，我们依然可以使用之前的两种配置方式实现，而指定客户端的配置方式可以直接使用Eureka中的服务名作为<client>来完成对各个微服务的个性化配置。

如果想要禁止Eureka对Ribbon服务实例的维护实现。只需要加入如下参数：

ribbon.eureka.enabled=false

## 3.重试机制 ##

在Spring Cloud Eureka实现的服务治理机制强调了CAP原理中的AP（可用性与可靠性），Zookeeper这类强调CP(一致性与可靠性)的服务治理框架最大的区别是Eureka为了实现更高的服务可用性，牺牲了一定的一致性，在极端情况下它宁愿接受故障实例也不会丢掉“健康”实例。

spring.cloud.loadbalancer.retry.enabled=true

spring.cloud.loadbalancer.retry.enabled该参数用来开启重试机制，它默认是关闭的。

spring.cloud.loadbalancer.retry.enabled
    
    hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
    
    hello-service.ribbon.ConnectTimeout=250
    hello-service.ribbon.ReadTimout=1000
    hello-service.ribbon.OkToRetryOnAllOperations=true
    hello-service.ribbon.MaxAutoRetriesNextServer=2
    hello-service.ribbon.MaxAutoRetries=1

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：断路器的超时时间需要大于Ribbon的超时时间，不然不会触发重试。
    hello-service.ribbon.ConnectTimeout：请求连接的超时时间。
    hello-service.ribbon.ReadTimout：请求处理的超时时间。
    hello-service.ribbon.OkToRetryOnAllOperations：对所有操作请求都进行重试。
    hello-service.ribbon.MaxAutoRetriesNextServer：切换实例的重试次数。
    hello-service.ribbon.MaxAutoRetries：对当前实例的重试次数。

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