剖析SpringCloud Feign中所隱藏的坑

Posted on by

背景

前段時間同事碰到一個問題，需要在 SpringCloud 的 Feign 調用中使用自定義的 URL；通常情況下是沒有這個需求的；畢竟都用瞭 SpringCloud 的瞭，那服務之間的調用都是走註冊中心的，不會需要自定義 URL 的情況。

但也有特殊的，比如我們這裡碰到 ToB 場景，需要對每個商戶自定義的 URL 進行調用。

雖說也可以使用原生的 Feign 甚至是自定義一個 OKHTTP Client 實現，但這些方案都得換一種寫法；

打算利用現有的 SpringCloud OpenFeign 來實現，畢竟原生的 Feign 其實是支持該功能的，而 SpringCloud OpenFeign 也隻是在這基礎上封裝瞭一層。

隻需要在接口聲明處加上一個 URI 參數即可，這樣就可以在每次調用時傳遞不同的 URI 來實現動態 URL 的目的。

想法很簡單，但實踐起來卻不是那麼回事瞭。 偽代碼如下：

	@FeignClient(name = "dynamic")
	interface DynamicClient {
		@GetMapping("/")
		String get(URI uri);
	}
	dynamicClient.get(URI.create("https://github.com"));

執行後會拋出負載均衡的異常：

java.lang.RuntimeException: com.netflix.client.ClientException:
Load balancer does not have available server for client: github.com

這個異常也能理解，就是找不到 github 這個服務；找不到也是合理的，畢竟也不是一個內部註冊的服務。

但按照 Feign 的官方介紹，隻要接口中聲明瞭 URI 這個參數就能自定義，同時我自己也用原生的 Feign 測試過確實沒什麼問題。

Debug

那問題隻能出在 SpringCloud OpenFeign 的封裝上瞭；經過同事的搜索在網上找到一篇博客解決瞭這個問題。

按照文中的說法，確實隻需要加上 URL 參數同時有值就可以瞭，但原因不明。

本著打破砂鍋問到底的精神，我個人也想知道 OpenFeign 是如何處理的，隻要 url 有值就可以，這完全是個黑盒，而且在官方的註釋中並沒有對這種情況有特殊說明。

所以我準備從源碼中找到答案。

既然是 url 有值就能正常運行，那一定是在運行過程中獲取瞭這個值；

但我在源碼中查看 url 所使用的地方，並沒有在單測之外找到哪裡有所應用，說明源碼中並沒有直接調用 url() 這個函數來獲取值。

但 org.springframework.cloud.openfeign.FeignClient 這個註解總會使用吧，於是我又查詢這個註解的使用情況。

最終在這裡查到瞭使用的痕跡。

這裡查閱源碼時也有一些小技巧，比如如果我們直接查詢時，IDEA 默認的查詢范圍是整個項目和所有依賴庫，會有許多幹擾信息。

比如我這裡就需要隻看項目源碼，單測這些都不用看；所以在查詢的時候可以過濾一下，這樣幹擾信息就會少很多。

左邊的工具欄還有許多過濾條件，大傢可以自行研究一下。

接著從源碼中進行閱讀，會發現是將 @FeignClient 中的所有數據都寫到一個 Map 裡進行使用的。

最終會發現這個 url 被寫入到瞭 FeignClientFactoryBean 中的 url 成員變量中瞭。

查看哪裡在使用這個 url 就知道背後的原理瞭。

在這裡打個斷點會發現：當 url 為空時會返回一個 LoadBalance 的 client，也就是會從註冊中心獲取 url 的客戶端，而 url 有值時則會獲取一個默認的客戶端，這樣就不會走負載均衡瞭。

所以我們如果想在 OpenFeign 中使用動態 url 時就得讓 @Feign 的 url 有值才行，無論是什麼都可以。

Feign 的實現

既然已經看到這一步瞭，我也比較好奇 Feign 是如何做到隻要有 URI 參數就使用指定的 URL 呢？

這裡也分享一個讀源碼的小技巧，如果我們跟著程序執行的思路去一步步 debug 的話會非常消耗時間，畢竟這類成熟庫的代碼量也不小。

這裡我們從官方文檔中可以得知隻要在接口參數中使用瞭 java.net.URI 便會走自定義的 url，所以我們反過來隻要在源碼中找到哪裡在使用 java.net.URI 便能知道關鍵源碼。

畢竟使用 java.net.URI 的場景也不會太多。

所以隻需要在這個依賴的地方 cmd+shift+f 全局搜索 java.net.URI 就能查到結果，果然不多，隻有兩處使用。

再結合使用場景猜測大概率是判斷參數中是否是有 URL.class 這樣的條件，或者是 url 對象；總之我們先用 URL 這樣關鍵字在這兩個文件中搜索一下，記得勾選匹配大小寫；最後會發現的確是判斷瞭參數中是否有 URL 這個類，同時將這個索引位置記錄瞭下來。

想必後續會通過這個索引位置讀取最終的 url 信息。

最終通過這個索引的使用地方查詢到瞭核心源碼，如果有值時就取這個 URI 中所指定的地址作為 target。

到此為止這個問題的背後原理都已經分析完畢瞭。

總結

其實本文重點是分析瞭一些 debug 和閱讀源碼的一些小技巧，特別是在讀關於 Spring 相關的代碼時一定不能 debug 跟蹤到細節中，因為調用鏈通常是很長的，稍不留神就把自己都繞暈瞭，隻需要知道核心、關鍵源碼是如何處理的即可。

最後對於 OpenFeign 處理動態 url 的方案確實也有些疑惑，是一個典型的約定大於配置的場景，但問題就在於我們並不知道這個約定是 @Feign 的 url 得有值。

所以我也提瞭一個 PR 給 OpenFeign，感興趣的朋友也可以查看一下：

github.com/spring-clou…

以上就是剖析SpringCloud Feign中所隱藏的坑的詳細內容，更多關於SpringCloud Feign坑的資料請關註WalkonNet其它相關文章！

推薦閱讀：