背景

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

但也有特殊的，比如我們這里碰到 ToB 場景，需要對每個商戶自定義的 URL 進(jìn)行調(diào)用。

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

打算利用現(xiàn)有的 SpringCloud OpenFeign 來實(shí)現(xiàn)，畢竟原生的 Feign 其實(shí)是支持該功能的，而 SpringCloud OpenFeign 也只是在這基礎(chǔ)上封裝了一層。

只需要在接口聲明處加上一個 URI 參數(shù)即可，這樣就可以在每次調(diào)用時傳遞不同的 URI 來實(shí)現(xiàn)動態(tài) URL 的目的。

想法很簡單，但實(shí)踐起來卻不是那么回事了。 偽代碼如下：

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

執(zhí)行后會拋出負(fù)載均衡的異常：

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

這個異常也能理解，就是找不到 github 這個服務(wù)；找不到也是合理的，畢竟也不是一個內(nèi)部注冊的服務(wù)。

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

Debug

那問題只能出在 SpringCloud OpenFeign 的封裝上了；經(jīng)過同事的搜索在網(wǎng)上找到一篇博客解決了這個問題。

按照文中的說法，確實(shí)只需要加上 URL 參數(shù)同時有值就可以了，但原因不明。

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

所以我準(zhǔn)備從源碼中找到答案。

既然是 url 有值就能正常運(yùn)行，那一定是在運(yùn)行過程中獲取了這個值；

但我在源碼中查看 url 所使用的地方，并沒有在單測之外找到哪里有所應(yīng)用，說明源碼中并沒有直接調(diào)用 url() 這個函數(shù)來獲取值。

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

最終在這里查到了使用的痕跡。

這里查閱源碼時也有一些小技巧，比如如果我們直接查詢時，IDEA 默認(rèn)的查詢范圍是整個項(xiàng)目和所有依賴庫，會有許多干擾信息。

比如我這里就需要只看項(xiàng)目源碼，單測這些都不用看；所以在查詢的時候可以過濾一下，這樣干擾信息就會少很多。

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

接著從源碼中進(jìn)行閱讀，會發(fā)現(xiàn)是將 @FeignClient 中的所有數(shù)據(jù)都寫到一個 Map 里進(jìn)行使用的。

最終會發(fā)現(xiàn)這個 url 被寫入到了 FeignClientFactoryBean 中的 url 成員變量中了。

查看哪里在使用這個 url 就知道背后的原理了。

在這里打個斷點(diǎn)會發(fā)現(xiàn)：當(dāng) url 為空時會返回一個 LoadBalance 的 client，也就是會從注冊中心獲取 url 的客戶端，而 url 有值時則會獲取一個默認(rèn)的客戶端，這樣就不會走負(fù)載均衡了。

所以我們?nèi)绻朐?OpenFeign 中使用動態(tài) url 時就得讓 @Feign 的 url 有值才行，無論是什么都可以。

Feign 的實(shí)現(xiàn)

既然已經(jīng)看到這一步了，我也比較好奇 Feign 是如何做到只要有 URI 參數(shù)就使用指定的 URL 呢？

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

這里我們從官方文檔中可以得知只要在接口參數(shù)中使用了 java.net.URI 便會走自定義的 url，所以我們反過來只要在源碼中找到哪里在使用 java.net.URI 便能知道關(guān)鍵源碼。

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

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

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

想必后續(xù)會通過這個索引位置讀取最終的 url 信息。

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

到此為止這個問題的背后原理都已經(jīng)分析完畢了。

總結(jié)

其實(shí)本文重點(diǎn)是分析了一些 debug 和閱讀源碼的一些小技巧，特別是在讀關(guān)于 Spring 相關(guān)的代碼時一定不能 debug 跟蹤到細(xì)節(jié)中，因?yàn)檎{(diào)用鏈通常是很長的，稍不留神就把自己都繞暈了，只需要知道核心、關(guān)鍵源碼是如何處理的即可。

最后對于 OpenFeign 處理動態(tài) url 的方案確實(shí)也有些疑惑，是一個典型的約定大于配置的場景，但問題就在于我們并不知道這個約定是 @Feign 的 url 得有值。

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

github.com/spring-clou…

以上就是剖析SpringCloud Feign中所隱藏的坑的詳細(xì)內(nèi)容，更多關(guān)于SpringCloud Feign坑的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論