天天看點

撸了一個 Feign 增強包前言問題使用實作總結

技術幹貨每日送達!

撸了一個 Feign 增強包前言問題使用實作總結

前言

最近準備将公司的一個核心業務系統用

Java

進行重構,大半年沒寫

Java

JDK

都更新到 14 了,考慮到穩定性等問題最終還是選擇的

JDK11

在整體架構選型時,由于是一個全新的系統,是以沒有曆史包袱,同時團隊中也有多位大牛坐鎮,是以我們的選項便大膽起來。

最終結果就是直接一把梭,直接上未來的大趨勢:

Service Mesh

,直接把什麼

SpringCloud

Dubbo

這類分布式架構全部幹掉。

本次的重點不是讨論

Service Mesh

是什麼、能解決什麼問題、為什麼選擇它,畢竟我也在學習階段,啥時候整明白線上也穩定了再和大家來交流。

問題

既然方向定了就開始實際撸碼了,不過剛一開始就驗證了”理想很豐滿、現實很骨感“;

由于我們去掉了

SpringCloud

Dubbo

這類架構,服務的注冊、發現、負載均衡等需求全部都下沉到

Service Mesh

中提供了。

但對于開發來說依然希望可以調用本地方法的方式來調用遠端服務,這在

SpringCloud

這類架構中是很容易實作的,架構本身就有很好的支援。

回到我們這個場景,需求其實很簡單,就是想達到

SpringCloud

中的

Feign

這樣的聲明式+注解的方式調用。

撸了一個 Feign 增強包前言問題使用實作總結
@Autowired
    private StoreClient client ;
    
    Store store = client.update(1, store)
           

複制

使用

spring-cloud-openfeign

這個包其實就能實作上述的需求了,但這樣會引入一些我們根本不會使用的

SpringCloud

的相關依賴,讓人感覺”不幹淨了“;同時也和

Service Mesh

的理念相反,其中的一大目的就是要降低這類架構的侵入性。

其實

spring-cloud-openfeign

的核心就是 Feign,本身它也是可以開箱即用的,是以便嘗試看

Feign

自己是否支援這樣的用法。

撸了一個 Feign 增強包前言問題使用實作總結

通過官方文檔可以得知:是可以定義接口的形式來調用遠端接口的,但它本質上是不依賴其他庫便可以使用,是以它本身是沒有和

Spring

整合也是合情合理,但也就造成了沒有現成庫可供我們使用。

我們自然是不想寫上圖紅框處的代碼的,希望所有接口直接注入就可以使用。

使用

是以結合以上的需求便有了這個庫 feign-plus

它的使用流程其實就是翻版的

spring-cloud-openfeign

@FeignPlusClient(name = "github", url = "${github.url}")
public interface Github {

    @RequestLine("GET /repos/{owner}/{repo}/contributors")
    List<GitHubRes> contributors(@Param("owner") String owner, @Param("repo") String repo);
}
           

複制

SpringBoot

入口進行掃描:

@SpringBootApplication
@EnableFeignPlusClients(basePackages = "top.crossoverjie.feign.test")
public class DemoApplication {

 public static void main(String[] args) {
  SpringApplication.run(DemoApplication.class, args);
 }

}
           

複制

Spring

上下文中直接注入使用:

@Autowired
    private Github github ;
    
    List<GitHubRes> contributors = github.contributors("crossoverJie", "feign-plus");
    logger.info("contributors={}", new Gson().toJson(contributors));    
           

複制

是以當我們需要調用一些外部第三方接口時(比如支付寶、外部 OpenAPI)便可類似于這樣定義一個接口,把所有 HTTP 請求的細節屏蔽掉。

當然也适合公司内部之間的服務調用,和咱們以前寫

SpringCloud

Dubbo

時類似;服務提供方提供一個

Client

包,消費方直接依賴便可以調用。其他的負載均衡、容錯之類的由

Service Mesh

替我們完成。

對于内部接口,也可以加上

@RequestMapping("/path")

注解:

撸了一個 Feign 增強包前言問題使用實作總結

在請求時便會在 url 後拼接上

/order

,這樣在配置

feign.order.service.url

時隻需要填入服務提供方的域名或 IP 即可。

feign-plus

也支援切換具體的 httpclient,預設是

okhttp3

,通過以下配置便可更改。

# default(okhttp3)
feign.httpclient=http2Client
           

複制

當然也有其他相關配置:

feign.plus.max-idle-connections = 520
feign.plus.connect-timeout = 11000
feign.plus.read-timeout = 12000
           

複制

實作

最後簡單聊聊是如何完成的吧,其實本質上就是

spring-cloud-openfeign

的濃縮版。

其中最為核心的便是

top.crossoverjie.feign.plus.factory.FeignPlusBeanFactory

類。

撸了一個 Feign 增強包前言問題使用實作總結

該類實作了

org.springframework.beans.factory.FactoryBean

接口,并重寫了

getObject()

方法傳回一個對象。

這段代碼是不是似曾相識,其實就是

Feign

的官方

demo

這裡所傳回的對象其實就是我們定義的接口的代理對象,而這個對象本身則是

Feign

,是以再往裡說:我們的

http

請求編解碼、發起請求等邏輯又被這個

feign

對象所代理了。

撸了一個 Feign 增強包前言問題使用實作總結

這個

HardCodedTarget

則是

Feign

内部用于代理最終請求的對象。

有一個小難受的地方:這樣的自己定義 Bean 然後注入對象 Idea 是識别不了的,認為目前上下文沒有該 Bean,但是 spring-cloud-openfeign 卻可以識别。

由于

Feign

支援多個用戶端,是以這裡的用戶端可以通過配置檔案動态指定。

撸了一個 Feign 增強包前言問題使用實作總結

利用

SpringBoot

提供的

@ConditionalOnExpression

注解可以根據配置動态的選擇使用哪個

httpclient

,也就是動态選擇生成哪個

Bean

總結

這個庫的邏輯非常簡單,本質上就是封裝了

Feign

并提供了

SpringBoot

的支援,歡迎有類似需求的朋友下載下傳使用。

feign-plus

源碼:https://github.com/crossoverJie/feign-plus

你的點贊與分享是對我最大的支援

繼續閱讀