Feign重試

有朋友問到Feign的重試如何做，這裡寫一下。

先參照我之前寫的Feign、Hystrix等文章搭建工程，Eureka（基本上搞Spring Cloud這個是必備的），FeignService，OrderServiceX2。

《Spring Cloud服務間調用Feign》

《Spring Cloud斷路器Hystrix》

原理說明

在之前的文章也提到過，Feign是通過內置的Ribbon進行負載均衡，並通過HTTP去訪問被調用方（在本例中是OrderService）。

所以我們所說的Feign的重試，其實就是Ribbon的重試。

另外，我們在實際工作中使用Feign，必有Hystrix，在這裡說一下Hystrix的原理。

其實這一段應該寫在Hystrix那篇文章里，唉~~這就是技術債啊！原理這玩意兒，總是要還的。

以我在講Hystrix文章中舉的例子說明，沒有Hystrix的情況下，用戶一個下單操作需要調用訂單、支付、物流三個Service，如果其中物流Service因為種種問題不能提供服務，即便另外兩個服務都好好的，整個下單操作也會因為物流Service而阻塞住，導致下單服務崩潰。

而Hystrix為每個依賴的服務配置獨立的線程池並進行隔離，假設下單服務有90個線程，沒有Hystrix，則因為物流Service不能提供服務，不停地重試直到90個線程全卡死。而有了Hystrix，三個依賴的服務，每個30個線程，即便物流的30個全部阻塞了，也不影響另外兩個服務的線程。

Hystrix運行機制。Hystrix採用命令模式，簡單地說，就是先開啟命令，然後執行要調用的方法，在本例中其實就是Feign通過Ribbon調用OrderService服務，如果順利就返回結果。如果出現異常，比如Hystrix未開啟，線程池已滿，執行命令失敗，執行命令超時，就執行Fallback處理。

實現方案

在FeignService的application.yml添加配置：

application.yml

解釋一下，第一個紅框沒啥好說的，開啟負載均衡——就是Ribbon的重試。

第二個紅框，order-service是我們要重試的依賴服務。

ConnectTimeout：Http建立連接的超時時間。

ReadTimeout：Http請求讀取響應的超時時間。

MaxAutoRetriesNextServer：重試其他實例的最大次數，不包括第一次調用的實例。

MaxAutoRetries：當前實例最大重試次數，不含第一次調用。

第一次調用失敗後，對本實例進行MaxAutoRetries次調用。依然失敗則調用另一個實例，如果還不行則執行MaxAutoRetriesNextServer次切換，最後還是失敗則返回失敗信息。

OkToRetryOnAllOperations：對所有操作請求都進行重試。

這個得額外說明一下，如果是查詢操作，配置成true，操作失敗了進行重試是可行的，但是如果是非冪等性的寫操作，如果被調用方某個實例實際中執行了寫操作，僅僅是因為網路或其他原因造成了異常，調用方依然進行重試，這結果就大發了。所以要慎用，最好被調用的介面要保證冪等性——這個有機會寫一篇文章聊聊。

另外通過紅框內order-service的配置項，大家應該會想到一個實際問題：如果有N多個被調用方，那就要寫N多個第二個紅框的配置啊！所以我之前的文章中說內部調用也可以用網關Zuul，很多朋友留言說沒必要，現在看其實是蠻有必要的。

大家有另外的解決辦法么，請指教。

第三個紅框，之前在講原理時著重講了Hystrix，就是怕大家不明白這個參數設置的意義。這個是斷路器線程池超時時間，它一定要比Ribbon的超時時間長，否則還沒等調用方重試完畢，斷路器自己的超時時間到了，就直接進入Fallback了。

順便說一下，一開始整合Feign和Hystrix時，第一次調用總是會失敗，就是因為這個值，默認是1秒，但是我們實際使用的時候，Spring是懶載入的，第一次實例化總是很耗時的，所以很容易就超過1秒報異常。

PS：以上我設置的數值僅僅是本例測試用，工作中要按照實際情況進行配置。

測試

測試就比較簡單了，啟動Eureka、OrderServiceX2、FeignService，關閉OrderService，刷新一下看看，可以掐著秒錶看一下時間。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！