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配置）如果依然不行，返回失敗資訊。