如何優化定時任務與feign超時的糾葛

這篇文章主要介紹如何優化定時任務與feign超時的糾葛，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

1 背景

業務定時器應用半夜經常會觸發熔斷異常的告警郵件

根據郵件提示的類找到歸納以下表格

以上A~D都是在一個分布式定時器事件處理應用(pinka-mod-scheduler)中對外的feign微服務調用產生的，相當于4類任務，每類都會調1次或多次外部feign微服務接口，而其中的A~D接口發生了問題

其中A和B都是如下形式的異常

com.netflix.hystrix.exception.HystrixTimeoutException
at com.netflix.hystrix.AbstractCommand$HystrixObservableTimeoutOperator$1$1.run(AbstractCommand.java:1154)
at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:45)
at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:41)
...

而C和D都是如下形式的異常

feign.RetryableException: 10.13.32.111:56000 failed to respond executing POST http://pinka-mod-customer/vip/partner/wallet/handlePartnerWithdraw
at feign.FeignException.errorExecuting(FeignException.java:67)
at feign.SynchronousMethodHandler.executeAndDecode(SynchronousMethodHandler.java:104)
at feign.SynchronousMethodHandler.invoke(SynchronousMethodHandler.java:76)
at feign.hystrix.HystrixInvocationHandler$1.run(HystrixInvocationHandler.java:114)
...
Caused by: org.apache.http.NoHttpResponseException: 10.13.32.111:56000 failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:141)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
...

2 追查

2.1 HystrixTimeoutException超時異常

A與B的異常幾乎每天都發生，且提示很明顯，是Hystrix中設置了超時時間（目前為10s），并且執行超時導致的。為何會超時？去接口實現發現是有for循環場景的耗時邏輯 通過Kibana日志系統查歷史執行耗時，也可以發現都基本>13s，所以這類異常基本確因

2.1.1 解決與思考

這其實是一個很典型場景，定時器任務執行并且處理邏輯是在另外一個微服務中，而處理邏輯屬于復雜耗時，怎么辦？

A. 增加超時時間，這是個粗暴的思路，因為設長了可能導致更大的問題，因為超時本來就是為了fastfail，設20s那之后可能還會遇到要30s甚至更久的場景。所以這個方案不能用在所有調用的公共默認超時時間上；

但是可以考慮用在某些接口上，比如VipTradeReportFeignService#getShopTradeReportByDate接口評估正常耗時就是要15s以上，那就單獨為其設置。相關配置方式：

#默認公共超時
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000
#單獨為某個feign接口設置超時
hystrix.command."FeignService#sayHello(String)".execution.isolation.thread.timeoutInMilliseconds=15000

B. 優化接口提供方的邏輯執行時間。比如上述VipTradeReportFeignService#getShopTradeReportByDate中的for循環，能否移到接口調用方，相當于接口提供方每次只執行for循環的1次操作。說白了就是確保接口返回要在超時時間內，這也符合微服務接口的設計原則。

C. 還有種思路是接口處理異步化，即接口提供方立刻返回，自己再用異步線程去處理最終邏輯。但是單純這樣會導致任務執行不可靠，即接口返回成功不代表真實一定執行成功了，如果此時接口提供方重啟或異常導致耗時的異步邏輯執行一半就中斷了，反而無法利用分布式定時任務調度的機制去重試執行等。所以使用此思路時，接口立刻返回但不能立刻將任務也作為成功執行完畢，需要配合一些異步通知機制，即接口提供方真實成功結束耗時操作，通知給接口調用方，接口調用方再將任務作為成功返回上報。

2.2 feign.RetryableException failed to respond executing 異常

這是C和D的異常，是隨機低頻告警。看字面意思是接口請求無響應，再結合郵件中的“熔斷”字眼就自然推測是接口提供應用的問題了（事后證明被“熔斷”字眼坑了）。所以去追查接口所屬應用pinka-mod-customer在告警前后的監控指標，發現tcp連接、CPU、內存、網絡流量表現都沒什么異常狀況。另外如果是熔斷，那此接口必然得是調用失敗多次呀，而每次定時任務對該接口調用卻只有一次。

這時候查看接口提供方Controller層日志，發現告警時刻確實提供方沒進入controller處理。 由此推測，提供方應用本身并無問題。而查看調用方應用日志和性能指標，在那個時刻也無異常情況，還在不斷向其他應用調用產生日志。再結合這個異常日志，推測原因是由于調用方與提供方某次調用的網絡閃斷導致的（所以是隨機低頻）。

但為何會開啟“熔斷”，這個還無法解釋。此時去追查郵件告警的代碼源頭，告警本質是通過重寫了openfeign官方的HystrixCommand創建邏輯中的getFallback方法實現的，即進入fallback邏輯就會發郵件 此時真相大白了，其實只是進了fallback降級，并不代表開啟熔斷，比如在HystrixCommand的run中拋出異常會進fallback，run執行超時會進fallback，熔斷也會進fallback。即A~D這些異常，雖然郵件寫的是熔斷，但其實都沒開啟熔斷，而只是進了fallback降級！

所以feign.RetryableException failed to respond executing這個其實只是一次偶然的調用失敗進了fallback而已，并沒之前猜想的那么復雜。

2.2.1 解決與思考

郵件告警邏輯自然是要修改，區分熔斷和降級。如果要判斷熔斷，可以用如下方法

protected Object getFallback() {
        if (this.isCircuitBreakerOpen()) {
          // 熔斷告警方式
          sendExceptionEmail(...);
        }else{
          // 非熔斷降級告警，如果無需告警也可不寫
          sendExceptionEmail(...);
        }
				....
}				

以上是“如何優化定時任務與feign超時的糾葛”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！