定時任務與feign超時的糾葛，該咋優化？

1 背景

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

根據郵件提示的類找到概括如下表格

編號	報錯方法	接口所屬應用	所屬定時任務類
A	VipTradeReportFeignService#getShopTradeReportByDate	pinka-mod-stats	ShopOrderSturctureTask
B	VipMemberStatsFeignService#statMemberRecord	pinka-mod-stats	MemberStatTask
C	VipPartnerWalletFeignService.handlePartnerWithdraw	pinka-mod-customer	PartnerWithdrawCheckTask
D	VipWeixinBabyActivityFeignService.getBabyActivityNoticePage	pinka-mod-weixin	VipWeixinBabyNoticeTask

以上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(...);
        }
				....
}

「架構人生，迭代生命」 ——深邃老夏，搜索summer_deep微信公衆號可獲取更多幫助