前言

首先要了解Feign是如何進(jìn)行遠(yuǎn)程調(diào)用的，這里面包括，注冊中心、負(fù)載均衡、FeignClient之間的關(guān)系，微服務(wù)通過不論是eureka、nacos也好注冊到服務(wù)端，F(xiàn)eign是靠Ribbon做負(fù)載的，而Ribbon需要拿到注冊中心的服務(wù)列表，將服務(wù)進(jìn)行負(fù)載緩存到本地，然后FeignClient客戶端在進(jìn)行調(diào)用，大概就是這么一個過程。

Ribbon是如何進(jìn)行負(fù)載的

首先我們要清楚Ribbon是如何進(jìn)行負(fù)載的，也就是如何獲取nacos、eureka的服務(wù)列表，這個很關(guān)鍵。

RibbonClientConfiguration

RibbonClientConfiguration類中通過LoadBalancer，我們知道ribbon是靠LoadBalancer做負(fù)載的

無非就是ILoadBalancer接口的方法，依次是添加新的服務(wù)、在負(fù)載均衡里選擇一個服務(wù)、markServerDown服務(wù)下線、獲取服務(wù)列表、獲取存活的服務(wù)器、獲取所有服務(wù)器（包括健康和不健康的）

圖片

ZoneAwareLoadBalancer

loadBalancer默認(rèn)的是ZoneAwareLoadBalancer負(fù)載均衡器，通過繼承父類DynamicServerListLoadBalancer的restOfInit方法，里面比較重要的兩個方法，enableAndInitLearnNewServersFeature和updateListOfServers方法

圖片

enableAndInitLearnNewServersFeature方法里面

LOGGER.info("Using serverListUpdater {}", serverListUpdater.getClass().getSimpleName());
serverListUpdater.start(updateAction);

讓我們看ServerListUpdater.start方法的實現(xiàn)，通過自定義線程去拿，這就是獲取服務(wù)列表；

圖片

Ribbon負(fù)載均衡策略

服務(wù)列表獲取說了，當(dāng)然負(fù)載均衡的策略這塊也有必要講一下，主要有七種：

• RoundRobinRule（輪詢策略，按照服務(wù)順序依次循環(huán)調(diào)用）
• WeightedResponseTimeRule（權(quán)重比策略，優(yōu)先選擇權(quán)重比高的服務(wù)，也就是服務(wù)響應(yīng)時間比較短的，響應(yīng)時間越長權(quán)重比越低）
• RandomRule（隨機策略，服務(wù)提供者列表隨機選擇一個服務(wù)）
• BestAvailableRule（最小連接數(shù)策略，獲取服務(wù)列表中連接數(shù)最小的服務(wù)實例）
• RetryRule（重試策略，重試獲取已經(jīng)失效的服務(wù)，指定時間沒有獲取到返回NULL）
• AvailabilityFilteringRule（可用性敏感策略，過濾非健康服務(wù)實例，選擇lianji）
• ZoneAvoidanceRule（區(qū)域敏感策略）

關(guān)于自定義負(fù)載均衡策略，可以看：

“

https://juejin.cn/post/7155754618486521869

Ribbon-eager-load（饑餓加載）模式

Ribbon對于負(fù)載Client是在服務(wù)啟動后，發(fā)生調(diào)用的時候才會去創(chuàng)建Client，所以在第一次發(fā)生http請求調(diào)用的時候，不光要算上http的請求時間，還要算上Client的創(chuàng)建時間，所以第一次調(diào)用的時候才會很慢，寫個方法調(diào)用下;

System 服務(wù)調(diào)用System2服務(wù)

@GetMapping("/requestSystem2Api")
public String requestSystem2Api(){
    long startTime = System.currentTimeMillis();
    R<String> stringR = iTestServiceClient.testRequestMethod();
    if (null !=stringR){
        log.info("接口返回："+stringR.getMsg());
    }
    long needTime = System.currentTimeMillis() - startTime;
    log.info("接口調(diào)用需要的時間："+needTime);
    return "";
}

從調(diào)用日志可以看出，第一次調(diào)用System2服務(wù)，Ribbon的DynamicServerListLoadBalancer會將feign客戶端進(jìn)行負(fù)載，然后進(jìn)行調(diào)用，第一次調(diào)用的時間就是會長一些，第二次調(diào)用直接進(jìn)行請求可以看到調(diào)用時間很快。

圖片

開啟Ribbon饑餓加載

ribbon:
  nacos:
    enabled: true # 開啟naocos輪詢
  eager-load:
   enabled: true  # 開啟Ribbon的饑餓加載模式(防止第一次請求超時的問題)
   clients: Lxlxxx-system2 # 指定需要開啟的服務(wù)(需要開啟Ribbon的饑餓加載模式)
   ReadTimeout: 10000
   ConnectTimeout: 10000
   MaxAutoRetries: 0
   MaxAutoRetriesNextServer: 1
   OkToRetryOnAllOperations: false

在項目啟動的時候，可以從日志看到，已經(jīng)把Lxlxxx-system2服務(wù)進(jìn)行加載，從而避免了第一次請求超時的情況；

圖片

總結(jié)

其實這種饑餓加載模式，類似于“客戶端負(fù)載預(yù)熱”的一個操作，項目啟動的時候進(jìn)行加載，防止服務(wù)之間調(diào)用可以因為數(shù)據(jù)量、業(yè)務(wù)邏輯處理復(fù)雜性導(dǎo)致接口超時，如果你的服務(wù)之間調(diào)用業(yè)務(wù)處理比較復(fù)雜、且慢，不妨可以試試這種解決方式。