本節我們主要介紹 Ribbon 的一些常用配置和配置 Ribbon 的兩種方式。

當我們在 RestTemplate 上添加 @LoadBalanced 注解后，就可以用服務名稱來調用接口了，當有多個服務的時候，還能做負載均衡。

這是因為 Eureka 中的服務信息已經被拉取到了客戶端本地，如果我們不想和 Eureka 集成，可以通過下面的配置方法將其禁用。

# 禁用 Eurekaribbon.eureka.enabled=false

當我們禁用了 Eureka 之后，就不能使用服務名稱去調用接口了，必須指定服務地址。

上面我們講了可以禁用 Eureka，禁用之后就需要手動配置調用的服務地址了，配置如下：

# 禁用 Eureka 后手動配置服務地址ribbon-config-demo.ribbon.listOfServers=localhost:8081,localhost:8083

這個配置是針對具體服務的，前綴就是服務名稱，配置完之后就可以和之前一樣使用服務名稱來調用接口了。

Ribbon 默認的策略是輪詢，從我們前面講解的例子輸出的結果就可以看出來，Ribbon 中提供了很多的策略，這個在后面會進行講解。我們通過配置可以指定服務使用哪種策略來進行負載操作。

Ribbon 中有兩種和時間相關的設置，分別是請求連接的超時時間和請求處理的超時時間，設置規則如下：

# 請求連接的超時時間ribbon.ConnectTimeout=2000# 請求處理的超時時間ribbon.ReadTimeout=5000也可以為每個Ribbon客戶端設置不同的超時時間, 通過服務名稱進行指定：ribbon-config-demo.ribbon.ConnectTimeout=2000ribbon-config-demo.ribbon.ReadTimeout=50005. 并發參數

# 最大連接數ribbon.MaxTotalConnections=500# 每個host最大連接數ribbon.MaxConnectionsPerHost=500代碼配置 Ribbon

配置 Ribbon 最簡單的方式就是通過配置文件實現。當然我們也可以通過代碼的方式來配置。

通過代碼方式來配置之前自定義的負載策略，首先需要創建一個配置類，初始化自定義的策略，代碼如下所示。

@Configurationpublic class BeanConfiguration { @Bean public MyRule rule() { return new MyRule(); }}

創建一個 Ribbon 客戶端的配置類，關聯 BeanConfiguration，用 name 來指定調用的服務名稱，代碼如下所示。

@RibbonClient(name = 'ribbon-config-demo', configuration = BeanConfiguration.class)public class RibbonClientConfig {}

可以去掉之前配置文件中的策略配置，然后重啟服務，訪問接口即可看到和之前一樣的效果。

除了使用代碼進行 Ribbon 的配置，我們還可以通過配置文件的方式來為 Ribbon 指定對應的配置：

<clientName>.ribbon.NFLoadBalancerClassName: Should implement ILoadBalancer(負載均衡器操作接口)<clientName>.ribbon.NFLoadBalancerRuleClassName: Should implement IRule(負載均衡算法)<clientName>.ribbon.NFLoadBalancerPingClassName: Should implement IPing(服務可用性檢查)<clientName>.ribbon.NIWSServerListClassName: Should implement ServerList(服務列表獲取)<clientName>.ribbon.NIWSServerListFilterClassName: Should implement ServerList­Filter(服務列表的過濾)重試機制

在集群環境中，用多個節點來提供服務，難免會有某個節點出現故障。用 Nginx 做負載均衡的時候，如果你的應用是無狀態的、可以滾動發布的，也就是需要一臺臺去重啟應用，這樣對用戶的影響其實是比較小的，因為 Nginx 在轉發請求失敗后會重新將該請求轉發到別的實例上去。

由于 Eureka 是基于 AP 原則構建的，犧牲了數據的一致性，每個 Eureka 服務都會保存注冊的服務信息，當注冊的客戶端與 Eureka 的心跳無法保持時，有可能是網絡原因，也有可能是服務掛掉了。

在這種情況下，Eureka 中還會在一段時間內保存注冊信息。這個時候客戶端就有可能拿到已經掛掉了的服務信息，故 Ribbon 就有可能拿到已經失效了的服務信息，這樣就會導致發生失敗的請求。

這種問題我們可以利用重試機制來避免。重試機制就是當 Ribbon 發現請求的服務不可到達時，重新請求另外的服務。

解決上述問題，最簡單的方法就是利用 Ribbon 自帶的重試策略進行重試，此時只需要指定某個服務的負載策略為重試策略即可：

ribbon-config-demo.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RetryRule2. Spring Retry 重試

除了使用 Ribbon 自帶的重試策略，我們還可以通過集成 Spring Retry 來進行重試操作。

在 pom.xml 中添加 Spring Retry 的依賴，代碼如下所示。

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

配置重試次數等信息：

# 對當前實例的重試次數ribbon.maxAutoRetries=1# 切換實例的重試次數ribbon.maxAutoRetriesNextServer=3# 對所有操作請求都進行重試ribbon.okToRetryOnAllOperations=true# 對Http響應碼進行重試ribbon.retryableStatusCodes=500,404,502

到此這篇關于Spring Cloud Ribbon配置詳解的文章就介紹到這了,更多相關Spring Cloud Ribbon配置內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！