這篇文章主要介紹如何優(yōu)化定時(shí)任務(wù)與feign超時(shí)的糾葛，文中介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們一定要看完！

創(chuàng)新互聯(lián)建站2013年開創(chuàng)至今，先為通遼等服務(wù)建站，通遼等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為通遼企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

1 背景

業(yè)務(wù)定時(shí)器應(yīng)用半夜經(jīng)常會觸發(fā)熔斷異常的告警郵件

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

以上A~D都是在一個分布式定時(shí)器事件處理應(yīng)用(pinka-mod-scheduler)中對外的feign微服務(wù)調(diào)用產(chǎn)生的，相當(dāng)于4類任務(wù)，每類都會調(diào)1次或多次外部feign微服務(wù)接口，而其中的A~D接口發(fā)生了問題

其中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超時(shí)異常

A與B的異常幾乎每天都發(fā)生，且提示很明顯，是Hystrix中設(shè)置了超時(shí)時(shí)間（目前為10s），并且執(zhí)行超時(shí)導(dǎo)致的。為何會超時(shí)？去接口實(shí)現(xiàn)發(fā)現(xiàn)是有for循環(huán)場景的耗時(shí)邏輯 通過Kibana日志系統(tǒng)查歷史執(zhí)行耗時(shí)，也可以發(fā)現(xiàn)都基本>13s，所以這類異?；敬_因

2.1.1 解決與思考

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

A. 增加超時(shí)時(shí)間，這是個粗暴的思路，因?yàn)樵O(shè)長了可能導(dǎo)致更大的問題，因?yàn)槌瑫r(shí)本來就是為了fastfail，設(shè)20s那之后可能還會遇到要30s甚至更久的場景。所以這個方案不能用在所有調(diào)用的公共默認(rèn)超時(shí)時(shí)間上；

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

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

B. 優(yōu)化接口提供方的邏輯執(zhí)行時(shí)間。比如上述VipTradeReportFeignService#getShopTradeReportByDate中的for循環(huán)，能否移到接口調(diào)用方，相當(dāng)于接口提供方每次只執(zhí)行for循環(huán)的1次操作。說白了就是確保接口返回要在超時(shí)時(shí)間內(nèi)，這也符合微服務(wù)接口的設(shè)計(jì)原則。

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

2.2 feign.RetryableException failed to respond executing 異常

這是C和D的異常，是隨機(jī)低頻告警?？醋置嬉馑际墙涌谡埱鬅o響應(yīng)，再結(jié)合郵件中的“熔斷”字眼就自然推測是接口提供應(yīng)用的問題了（事后證明被“熔斷”字眼坑了）。所以去追查接口所屬應(yīng)用pinka-mod-customer在告警前后的監(jiān)控指標(biāo)，發(fā)現(xiàn)tcp連接、CPU、內(nèi)存、網(wǎng)絡(luò)流量表現(xiàn)都沒什么異常狀況。另外如果是熔斷，那此接口必然得是調(diào)用失敗多次呀，而每次定時(shí)任務(wù)對該接口調(diào)用卻只有一次。

這時(shí)候查看接口提供方Controller層日志，發(fā)現(xiàn)告警時(shí)刻確實(shí)提供方?jīng)]進(jìn)入controller處理。 由此推測，提供方應(yīng)用本身并無問題。而查看調(diào)用方應(yīng)用日志和性能指標(biāo)，在那個時(shí)刻也無異常情況，還在不斷向其他應(yīng)用調(diào)用產(chǎn)生日志。再結(jié)合這個異常日志，推測原因是由于調(diào)用方與提供方某次調(diào)用的網(wǎng)絡(luò)閃斷導(dǎo)致的（所以是隨機(jī)低頻）。

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

所以feign.RetryableException failed to respond executing這個其實(shí)只是一次偶然的調(diào)用失敗進(jìn)了fallback而已，并沒之前猜想的那么復(fù)雜。

2.2.1 解決與思考

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

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

以上是“如何優(yōu)化定時(shí)任務(wù)與feign超時(shí)的糾葛”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！