Feign是一種宣告式、 模板化的HTTP使用者端。在Spring Cloud中使用Feign,可以做到使用HTTP請求存取遠端服務,就像呼叫本地方法一一樣的, 開發者完全感知不到這是在呼叫遠端方法,更感知不到在存取HTTP請求。接下來介紹一下Feign的特性,具體如下:
Feign是一個宣告式的Web Service使用者端,它的目的就是讓Web Service 呼叫更加簡單。它整合了Ribbon和Hystrix,從而不需要開發者針對Feign對其進行整合。Feign 還提供了HTTP請求的模板,通過編寫簡單的介面和註解,就可以定義好HTTP請求的引數、格式、地址等資訊。Feign 會完全代理HTTP的請求,在使用過程中我們只需要依賴注人Bean,然後呼叫對應的方法傳遞引數即可。
通常這個註解標註在 SpringBoot專案啟動類,或者設定類,其本質是@Import(FeignClientsRegistrar.class)
。在 SpringBoot原始碼學習1——SpringBoot自動裝配原始碼解析+Spring如何處理設定類的 中我們講到過,spring中的ConfigurationClassPostProcessor
中會使用ConfigurationClassParser
解析設定類,對於@Import
註解根據註解匯入的類有如下處理
匯入的類是ImportSelector
型別
反射範例化ImportSelector
如果此ImportSelector
實現了BeanClassLoaderAware
,BeanFactoryAware
,EnvironmentAware
,EnvironmentAware
,ResourceLoaderAware
會回撥對應的方法
呼叫當前ImportSelector
的selectImports
,然後遞迴執行處理@Import
註解的方法,也就是說可以匯入一個具備@Import
的類,如果沒有``@Import`那麼當中設定類解析
匯入的類是ImportBeanDefinitionRegistrar
型別
反射範例化ImportBeanDefinitionRegistrar
,然後加入到importBeanDefinitionRegistrars
集合中後續會回撥其registerBeanDefinitions
既不是ImportBeanDefinitionRegistrar
也不是ImportSelector
,將匯入的類當做設定類處理,後續會判斷條件註解是否滿足,然後解析匯入的類,並且解析其父類別
這裡匯入FeignClientsRegistrar
是一個ImportBeanDefinitionRegistrar
,因而會回撥其registerBeanDefinitions
這裡我們關注下 registerFeignClients
此方法會掃描標記有@FeignClient
註解的介面,包裝成BeanDefinition 註冊到BeanDefinitionRegistry
,後續在feignClient被依賴注入的時候,根據此BeanDefinition進行範例化
如果我們在@EnableFeignClients
註解中的clients
指定了類,那麼只會將這些FeignClient 包裝成AnnotatedGenericBeanDefinition
否則使用ClassPathScanningCandidateComponentProvider
掃描生成BeanDefinition
ClassPathScanningCandidateComponentProvider
允許 重寫isCandidateComponent
方法自定義什麼樣的BeanDefinition是我們的候選者,以及新增TypeFilter
來進行限定(其addExcludeFilter
,addIncludeFilter
可以設定排除什麼,包含什麼)
這個getScanner
方法,對isCandidateComponent
進行了重寫,限定不能是內部類且不能是註解
哪些包下的類需要掃描
如果@EnableFeignClients
指定了value
,basePackages
,basePackageClasses
,那麼優先掃描指定的包,如果沒有,那麼掃描@EnableFeignClients
標註設定類所在的包
如何掃描
呼叫ClassPathScanningCandidateComponentProvider#findCandidateComponents
進行掃描
底層還是基於ClassLoader#getResources
獲取資源
註冊每一個FeignClient
的個新化設定
openFeign 支援每一個 FeignClient
介面使用個新化的設定,基於父子容器實現,這點我們在後續進行分析
註冊FeignClient
的BeanDefinition
這裡非常關鍵,因為我們的FeignClient
介面的BeanDefinition
其記錄的class 是 一個介面,spring無法範例化,這裡要設定為FactoryBean
,然後後續才能呼叫FactoryBean#getObject
,生成介面的動態代理類,從而讓動態代理類物件實現傳送Http請求的功能
BeanDefinitionBuilder definition = BeanDefinitionBuilder
.genericBeanDefinition(FeignClientFactoryBean.class);
其中會生成一個FeignClientFactoryBean
的BeanDefinition,並且將@FeignClient中的url
,path
,name
,contextId
等都呼叫BeanDefinition.addPropertyValue
進行設定,這樣spring在範例化的使用會據此來對FeignClientFactoryBean
物件的屬性進行填充
其中最關鍵的是,記錄了原FeignClient介面的型別,因為FeignClientFactoryBean
使用的是Jdk動態代理,需要介面型別。
至此feignClient型別的bean都被載入並註冊到BeanDefinitionRegistry
,後續在Spring容器重新整理時便會觸發FeignClient的範例化
在其他spring bean需要注入FeignClient
的時候,將觸發FeignClient 的範例化。會先範例化FeignClientFactoryBean
,並且進行屬性填充(之前將@FeignClient註解中的內容,使用BeanDefinition.addPropertyValue
進行了繫結,後面由spring據此進行屬性填充),然後呼叫getObject
方法範例化出原本FeignClient 介面
實現類
下面我們看下FeignClient是如何生成代理類的(這裡設計到編碼器,解碼器等元件,這部分內容再傳送請求的章節進行解釋,這一章節關注於FeignClient是如何生成代理物件的)
FeignContext是Feign允許每一個FeignClient進行個性化設定的關鍵。
FeignContext是Spring上下文中的一個Bean,其內部使用一個Map儲存每一個Feign對應的個性化設定ApplicationContext
如上圖這種使用方式,可以為一個FeignClient指定特定的設定類,然後再這個設定類中使用@Bean注入特定的Encoder(將FeignClient入參轉化Http報文的一部分的一個元件),Decoder(將Http請求解析為介面出參的一個元件)等。
上圖中AClientConfig
會被註冊到A這個FeignClient的個性化ApplicationContext(下圖的黃色部分)
上圖中,我們標註了AClient個性化設定ApplicationContext的父容器時Spring上下文(SpringBoot啟動後建立的上下文,最大的上下文)。這樣設計的目的是,如果當前個性化設定中沒有指定Decoder 那麼使用預設的容器中的Decoder,如果指定了那麼使用個性化的設定。
上圖中,獲取Encoder,Decoder等都使用get方法,get方法內容如下
利用了AnnotationConfigApplicationContext#getBean
會去父容器找的特點,實現個性化設定不存在,使用預設設定,具體邏輯在DefaultListableBeanFactory
中,如下
feign還支援我們在組態檔中,進行若干設定,下面展示一部分設定
這些設定都將對映FeignClientProperties
中
如果@FeignClient註解指定了url,將無法進行負載,比如我們業務系統,指定請求外部系統的API,這個API和我們並不在同一個註冊中心,那麼便無從進行負載均衡。這裡會將原本的LoadBalanceFeignClient
中的delegate
拿出來(這個delegate被LoadBalanceFeignClient
裝飾,再請求之前會先根據註冊中心和負載均衡選擇一個範例,然後重構url,然後再使用delegate傳送請求)
最終生成代理物件的邏和指定服務名的FeignClient殊途同歸
生成動態代理物件最終呼叫到Feign(實現類ReflectiveFeign)#newInstance
其中生成的MethodHandler
這一步將根據SpringMvcContract
(springmvc合約)去解析介面方法上的註解,最關鍵的是構建出RequestTemplate
物件,它是請求的模板,後續Http請求物件由它轉化而來。
這一步還會解析@RequestMapping註解(包括@PostMapping這種複合註解)
produces
,報文Accept攜帶這部分內容consumes
,報文頭Content-Type攜帶這部分內容這一步還會解析以下三個方法上的註解:
Map<String, Collection<String>> queries
,最終會表單的格式加入到Http報文的bodyList<String> formParams
,最終會以路徑引數的形式加入到Http路徑請求中Map<String, Collection<String>> headers
,最終會加入到http請求報文的頭部解析的操作交由AnnotatedParameterProcessor#processArgument
處理
InvocationHandlerFactory
構建出InvocationHandler
並進行jdk動態代理。這裡產生的InvocationHandler(一般為ReflectiveFeign.FeignInvocationHandler,如果由熔斷設定那麼是HystrixInvocationHandler,此類會在呼叫失敗的時候,回撥FeignClient對應的fallBack)
最後使用JDK動態代理生成代理物件。
至此FeignClient介面的動態代理物件生成,那麼如何傳送請求呢,如果將入參轉化為http請求報文,如何將http響應轉換為實體物件呢?
上面我們已經分析了FeignClient是如何被掃描,被包裝成BeanDefinition註冊到BeanDefinitionRegistry中,也看了FeignClientFactoryBean
是如何生成FeignClient介面代理類的,至此我們可用知道的我們平時依賴注入的介面其實是FeignClientFactoryBean#getObject
生成的動態代理物件。那麼這個代理物件是如何傳送請求的暱?
這一步使用工廠模式生成InvocationHandler,如果沒有hystrix熔斷的設定,那麼這裡生成的是ReflectiveFeign.FeignInvocationHandler
,反之生成的是HystrixInvocationHandler
這裡是從dispatch
根據Method
獲取到MethodHandler
(通常是SynchronousMethodHandler
)
這裡使用RequestTemplate.Factory(請求模板物件)
生成RquestTemplate
,比較關鍵的點是:
將http請求頭,表單引數,路徑引數,根據引數的值設定到RequestTemplate
3.2.1中,我們知道Feign會使用AnnotatedParameterProcessor解析引數註解內容,並解析@RequestMapping註解的內容,放在對應的資料結構中,然後當真正呼叫的時候,它會根據之前解析的內容,將引數中的值設定到RequestTemplate中,這部分會填充url,表單引數,請求頭等。
使用Encoder對@RequestBody註解標註的引數解析到RequestTemplate
Encoder會被回撥encoder
方法,其中最重要的是SpringEncoder
,它負責解析
這裡並沒有說必須標註@RequestBody
註解,即使不標註,且沒有標註@RequestParam
,@RequestHead
,@PathVariable
,都會一股腦,進行序列化寫入到body,看來是不支援@RequestPart
這種multipart/form-data格式的引數。
重試器提供兩個方法
我們可以通過在容器中,或者FeignClient個性化設定類中,注入Retryer實現重試邏輯,如果不注入使用的是預設的實現Retryer.Default
。這裡需要注意
下面是Feign預設的重試策略,總結就是,請求失敗後獲取間隔多久重試(響應頭可指定,或者使用1.5的冪次計算),然後讓當前執行緒休眠,後發起重試
傳送請求並解碼的邏輯在executeAndDecoder
方法中,這個方法外層是一個while(true)
的死迴圈,如果丟擲的異常是RetryableExecption
那麼交由Retryer
來控制是重試,還是丟擲異常結束重試。如果丟擲的不是重試異常那麼將直接結束,不進行重試。
整個excuteAndDecode 可用分為三步:
回撥RequestInterceptor,並將RequestTemplate轉化為Request
RequestInterceptor
的apply
方法在此被回撥,我們可自定義自己的RequestIntereptor
實現token
透傳等操作
RequestTemplate(請求模板)
轉化為Request(請求物件)
,這裡可理解為什麼叫請求模板,在FeignClient被動態代理前,就對介面中方法進行了掃描,為每一個方法要傳送怎樣的報文制定了模板(RequestTemplate)後面針對引數的不同來補充模板,然後用模板生成請求物件,這何嘗不是一種單一職責的體驗!下面是RequestTemplate如何轉變為Request物件
使用Client
傳送請求
Client具備兩個重要的實現:Default
(使用jdk自帶的HttpConnection傳送http請求,也支援Https)LoadBalancerFeignClient
(基於Ribbon實現負載均衡功能增強的裝飾器)
LoadBalancerFeignClient
本質是一個裝飾器,內部持有了一個Client實現類範例,使用Ribbon根據請求應用名和負載均衡策略選擇合適的範例,然後重構url(替換成實際的域名或者ip)然後再使用Client傳送http請求。
Feign預設使用的就是 LoadBalancerFeignClient
裝飾後的Default(沒有連線池,對每一個請求都保持一個長連線)
,建議替換成其他的Http元件,如OkHttp,Apache的HttpClient等。
使用Decoder
對響應進行解碼
Response
,那麼將直接返回Response
,而不會進行解碼。[200,300)
的範圍,那麼將使用Decoder
進行解碼,解析成介面方法指定的型別Decoder
進行解碼ErrorDecoder
進行解碼,根據響應資訊決定丟擲異常(如果丟擲RetryException 將由Retryer控制重試,還是結束)可看到只要是非FeignException的RuntimeExeption會被包裝成DecoderExeption丟擲。下面我們看下Decoder
的實現類
Default
主要是對Byte陣列的支援
StringDecoder
主要是將body轉成字串
SpringDecoder
底層使用HttpMessageConverter對body進行裝換,會從響應頭中拿出Content-Type
決定使用什麼策略,通常返回json這裡將使用基於Jackson
的MappingJackson2HttpMessageConverter
進行轉換。(這部分在springmvc原始碼中有過介紹,不再贅述)
ResponeEntityDecoder
一個Decoder裝飾器實現對ResponeEntity
的支援
ErrorDecoder存在一個實現類Default
,它會根據響應頭中的Retry-After
丟擲重試異常,反之丟擲FeignExeption,如果是重試異常那麼,由Retryer控制重試還是結束
但是遺憾的是,這個重試通常是不生效的,它需要服務提供方返回重試時間塞到Retry-After
的頭中,且會使用下面這個SimpleDateFormat加鎖進行序列化,序列化為Date,咱中國人的服務估計不是這樣的時間格式,且現在企業級的服務都是返回code,data,message
這樣的響應體,http響應狀態碼基本上都是200,所以想實現這種重試,需要我們自定義Decoder(不是ErrorDecoder)
去實現
可看到Feign是很模組的化的,也提供了很多擴充套件的介面讓我們做自定義,以下是筆者做過(或者見過)的一些擴充套件。
RequestIntercptor
實現認證資訊的透傳class AService{
void process(){
feign.getSomething(xxxx);
}
}
我們服務中,需要AService呼叫process的時候,將認證資訊透傳到微服務提供方,我們自定義RequestIntercptor拿到當前的請求資訊,然後獲取其中的認證資訊通過apply
方法寫入到RequestTemplate
的head中。
基於SpringBoot的服務,通過使用SpringMVC ResponseAdvice
實現統一包裝集,即使業務邏輯丟擲異常,也通過ExeptionHandler
進行統一包裝,包裝形式如下
{
"code":"業務錯誤碼",
"data": "業務資料",
"message":"錯誤資訊"
}
這就導致,我們微服務呼叫方,使用feign的時候,結果返回值也是這種統一返回結果集形式的物件,需要自己對code進行校驗,然後選擇丟擲異常,還是反序列化為目標物件。
我們可以實現自己的Decoder結果這一問題!在Decoder中對code
進行判斷,決定丟擲異常,還是序列化data
。但是需要注意Decoder
丟擲的異常,都將被包裝為FeignExeption
或者DecodeExption
,所以呼叫方還需要針對這兩種異常設定ExeptionHandler
RequestIntercptor
實現分散式鏈路追蹤原理同一,只不過拿的是呼叫方請求中的 traceId,將traceId,寫到RequestTemplate的head中。