上面這張監(jiān)控圖，對(duì)于服務(wù)端的研發(fā)同學(xué)來(lái)說(shuō)再熟悉不過(guò)了。在日常的系統(tǒng)維護(hù)中，『服務(wù)超時(shí)』應(yīng)該屬于監(jiān)控報(bào)警最多的一類問(wèn)題。

尤其在微服務(wù)架構(gòu)下，一次請(qǐng)求可能要經(jīng)過(guò)一條很長(zhǎng)的鏈路，跨多個(gè)服務(wù)調(diào)用后才能返回結(jié)果。當(dāng)服務(wù)超時(shí)發(fā)生時(shí)，研發(fā)同學(xué)往往要抽絲剝繭般去分析自身系統(tǒng)的性能以及依賴服務(wù)的性能，這也是為什么服務(wù)超時(shí)相對(duì)于服務(wù)出錯(cuò)和服務(wù)調(diào)用量異常更難調(diào)查的原因。

這篇文章將通過(guò)一個(gè)真實(shí)的線上事故，系統(tǒng)性地介紹下：在微服務(wù)架構(gòu)下，該如何正確理解并設(shè)置RPC接口的超時(shí)時(shí)間，讓大家在開(kāi)發(fā)服務(wù)端接口時(shí)有更全局的視野。內(nèi)容將分成以下4個(gè)部分：

• 從一次RPC接口超時(shí)引發(fā)的線上事故說(shuō)起

• 超時(shí)的實(shí)現(xiàn)原理是什么？

• 設(shè)置超時(shí)時(shí)間到底是為了解決什么問(wèn)題？

• 應(yīng)該如何合理的設(shè)置超時(shí)時(shí)間？

01?從一次線上事故說(shuō)起

事故發(fā)生在電商APP的首頁(yè)推薦模塊，某天中午突然收到用戶反饋：APP首頁(yè)除了banner圖和導(dǎo)航區(qū)域，下方的推薦模塊變成空白頁(yè)了（推薦模塊占到首頁(yè)2/3的空間，是根據(jù)用戶興趣由算法實(shí)時(shí)推薦的商品list）。

上面的業(yè)務(wù)場(chǎng)景可以借助下面的調(diào)用鏈來(lái)理解

• APP端發(fā)起一個(gè)HTTP請(qǐng)求到業(yè)務(wù)網(wǎng)關(guān)

• 業(yè)務(wù)網(wǎng)關(guān)RPC調(diào)用推薦服務(wù)，獲取推薦商品list

• 如果第2步調(diào)用失敗，則服務(wù)降級(jí)，改成RPC調(diào)用商品排序服務(wù)，獲取熱銷商品list進(jìn)行托底

• 如果第3步調(diào)用失敗，則再次降級(jí)，直接獲取Redis緩存中的熱銷商品list

粗看起來(lái)，兩個(gè)依賴服務(wù)的降級(jí)策略都考慮進(jìn)去了，理論上就算推薦服務(wù)或者商品排序服務(wù)全部掛掉，服務(wù)端都應(yīng)該可以返回?cái)?shù)據(jù)給APP端。但是APP端的推薦模塊確實(shí)出現(xiàn)空白了，降級(jí)策略可能并未生效，下面詳細(xì)說(shuō)下定位過(guò)程。

1、問(wèn)題定位過(guò)程

第1步：APP端通過(guò)抓包發(fā)現(xiàn)：HTTP請(qǐng)求存在接口超時(shí)（超時(shí)時(shí)間設(shè)置的是5秒）。

第2步：業(yè)務(wù)網(wǎng)關(guān)通過(guò)日志發(fā)現(xiàn)：調(diào)用推薦服務(wù)的RPC接口出現(xiàn)了大面積超時(shí)（超時(shí)時(shí)間設(shè)置的是3秒），錯(cuò)誤信息如下：

第3步：推薦服務(wù)通過(guò)日志發(fā)現(xiàn)：dubbo的線程池耗盡，錯(cuò)誤信息如下：

通過(guò)以上3步，基本就定位到了問(wèn)題出現(xiàn)在推薦服務(wù)，后來(lái)進(jìn)一步調(diào)查得出：是因?yàn)橥扑]服務(wù)依賴的redis集群不可用導(dǎo)致了超時(shí)，進(jìn)而導(dǎo)致線程池耗盡。詳細(xì)原因這里不作展開(kāi)，跟本文要討論的主題相關(guān)性不大。

2、降級(jí)策略未生效的原因分析

下面再接著分析下：當(dāng)推薦服務(wù)調(diào)用失敗時(shí)，為什么業(yè)務(wù)網(wǎng)關(guān)的降級(jí)策略沒(méi)有生效呢？理論上來(lái)說(shuō)，不應(yīng)該降級(jí)去調(diào)用商品排序服務(wù)進(jìn)行托底嗎？

最終跟蹤分析找到了根本原因：APP端調(diào)用業(yè)務(wù)網(wǎng)關(guān)的超時(shí)時(shí)間是5秒，業(yè)務(wù)網(wǎng)關(guān)調(diào)用推薦服務(wù)的超時(shí)時(shí)間是3秒，同時(shí)還設(shè)置了3次超時(shí)重試，這樣當(dāng)推薦服務(wù)調(diào)用失敗進(jìn)行第2次重試時(shí)，HTTP請(qǐng)求就已經(jīng)超時(shí)了，因此業(yè)務(wù)網(wǎng)關(guān)的所有降級(jí)策略都不會(huì)生效。下面是更加直觀的示意圖：

3、解決方案

• 將業(yè)務(wù)網(wǎng)關(guān)調(diào)用推薦服務(wù)的超時(shí)時(shí)間改成了800ms（推薦服務(wù)的TP99大約為540ms），超時(shí)重試次數(shù)改成了2次

• 將業(yè)務(wù)網(wǎng)關(guān)調(diào)用商品排序服務(wù)的超時(shí)時(shí)間改成了600ms（商品排序服務(wù)的TP99大約為400ms），超時(shí)重試次數(shù)也改成了2次

關(guān)于超時(shí)時(shí)間和重試次數(shù)的設(shè)置，需要考慮整個(gè)調(diào)用鏈中所有依賴服務(wù)的耗時(shí)、各個(gè)服務(wù)是否是核心服務(wù)等很多因素。這里先不作展開(kāi)，后文會(huì)詳細(xì)介紹具體方法。

?

02 超時(shí)的實(shí)現(xiàn)原理是什么？

只有了解了RPC框架的超時(shí)實(shí)現(xiàn)原理，才能更好地去設(shè)置它。不論是dubbo、SpringCloud或者大廠自研的微服務(wù)框架（比如京東的JSF），超時(shí)的實(shí)現(xiàn)原理基本類似。下面以dubbo 2.8.4版本的源碼為例來(lái)看下具體實(shí)現(xiàn)。

熟悉dubbo的同學(xué)都知道，可在兩個(gè)地方配置超時(shí)時(shí)間：分別是provider（服務(wù)端，服務(wù)提供方）和consumer（消費(fèi)端，服務(wù)調(diào)用方）。服務(wù)端的超時(shí)配置是消費(fèi)端的缺省配置，也就是說(shuō)只要服務(wù)端設(shè)置了超時(shí)時(shí)間，則所有消費(fèi)端都無(wú)需設(shè)置，可通過(guò)注冊(cè)中心傳遞給消費(fèi)端，這樣：一方面簡(jiǎn)化了配置，另一方面因?yàn)榉?wù)端更清楚自己的接口性能，所以交給服務(wù)端進(jìn)行設(shè)置也算合理。

dubbo支持非常細(xì)粒度的超時(shí)設(shè)置，包括：方法級(jí)別、接口級(jí)別和全局。如果各個(gè)級(jí)別同時(shí)配置了，優(yōu)先級(jí)為：消費(fèi)端方法級(jí) >?服務(wù)端方法級(jí) >?消費(fèi)端接口級(jí) > 服務(wù)端接口級(jí) >?消費(fèi)端全局 > 服務(wù)端全局。

通過(guò)源碼，我們先看下服務(wù)端的超時(shí)處理邏輯

public?class?TimeoutFilter?implements?Filter?{public?TimeoutFilter()?{}public?Result?invoke(...)?throws?RpcException?{//?執(zhí)行真正的邏輯調(diào)用，并統(tǒng)計(jì)耗時(shí)long?start?=?System.currentTimeMillis();Result?result?=?invoker.invoke(invocation);long?elapsed?=?System.currentTimeMillis()?-?start;//?判斷是否超時(shí)if?(invoker.getUrl()?!=?null?&&?elapsed?>?timeout)?{//?打印warn日志logger.warn("invoke?time?out...");}return?result;} }

可以看到，服務(wù)端即使超時(shí)，也只是打印了一個(gè)warn日志。因此，服務(wù)端的超時(shí)設(shè)置并不會(huì)影響實(shí)際的調(diào)用過(guò)程，就算超時(shí)也會(huì)執(zhí)行完整個(gè)處理邏輯。

再來(lái)看下消費(fèi)端的超時(shí)處理邏輯

public?class?FailoverClusterInvoker?{public?Result?doInvoke(...)??{...//?循環(huán)調(diào)用設(shè)定的重試次數(shù)for?(int?i?=?0;?i?<?retryTimes;?++i)?{...try?{Result?result?=?invoker.invoke(invocation);return?result;}?catch?(RpcException?e)?{//?如果是業(yè)務(wù)異常，終止重試if?(e.isBiz())?{throw?e;}le?=?e;}?catch?(Throwable?e)?{le?=?new?RpcException(...);}?finally?{...}}throw?new?RpcException("...");} }

FailoverCluster是集群容錯(cuò)的缺省模式，當(dāng)調(diào)用失敗后會(huì)切換成調(diào)用其他服務(wù)器。再看下doInvoke方法，當(dāng)調(diào)用失敗時(shí)，會(huì)先判斷是否是業(yè)務(wù)異常，如果是則終止重試，否則會(huì)一直重試直到達(dá)到重試次數(shù)。

繼續(xù)跟蹤invoker的invoke方法，可以看到在請(qǐng)求發(fā)出后通過(guò)Future的get方法獲取結(jié)果，源碼如下：

public?Object?get(int?timeout)?{if?(timeout?<=?0)?{timeout?=?1000;}if?(!isDone())?{long?start?=?System.currentTimeMillis();this.lock.lock();try?{//?循環(huán)判斷while(!isDone())?{//?放棄鎖，進(jìn)入等待狀態(tài)done.await((long)timeout,?TimeUnit.MILLISECONDS);//?判斷是否已經(jīng)返回結(jié)果或者已經(jīng)超時(shí)long?elapsed?=?System.currentTimeMillis()?-?start;if?(isDone()?||?elapsed?>?(long)timeout)?{break;}}}?catch?(InterruptedException?var8)?{throw?new?RuntimeException(var8);}?finally?{this.lock.unlock();}if?(!isDone())?{//?如果未返回結(jié)果，則拋出超時(shí)異常throw?new?TimeoutException(...);}}return?returnFromResponse();}

進(jìn)入方法后開(kāi)始計(jì)時(shí)，如果在設(shè)定的超時(shí)時(shí)間內(nèi)沒(méi)有獲得返回結(jié)果，則拋出TimeoutException。因此，消費(fèi)端的超時(shí)邏輯同時(shí)受到超時(shí)時(shí)間和超時(shí)次數(shù)兩個(gè)參數(shù)的控制，像網(wǎng)絡(luò)異常、響應(yīng)超時(shí)等都會(huì)一直重試，直到達(dá)到重試次數(shù)。

?

03 設(shè)置超時(shí)時(shí)間是為了解決什么問(wèn)題？

RPC框架的超時(shí)重試機(jī)制到底是為了解決什么問(wèn)題呢？從微服務(wù)架構(gòu)這個(gè)宏觀角度來(lái)說(shuō)，它是為了確保服務(wù)鏈路的穩(wěn)定性，提供了一種框架級(jí)的容錯(cuò)能力。微觀上如何理解呢？可以從下面幾個(gè)具體case來(lái)看：

1、consumer調(diào)用provider，如果不設(shè)置超時(shí)時(shí)間，則consumer的響應(yīng)時(shí)間肯定會(huì)大于provider的響應(yīng)時(shí)間。當(dāng)provider性能變差時(shí)，consumer的性能也會(huì)受到影響，因?yàn)樗仨殶o(wú)限期地等待provider的返回。假如整個(gè)調(diào)用鏈路經(jīng)過(guò)了A、B、C、D多個(gè)服務(wù)，只要D的性能變差，就會(huì)自下而上影響到A、B、C，最終造成整個(gè)鏈路超時(shí)甚至癱瘓，因此設(shè)置超時(shí)時(shí)間是非常有必要的。

2、假設(shè)consumer是核心的商品服務(wù)，provider是非核心的評(píng)論服務(wù)，當(dāng)評(píng)價(jià)服務(wù)出現(xiàn)性能問(wèn)題時(shí)，商品服務(wù)可以接受不返回評(píng)價(jià)信息，從而保證能繼續(xù)對(duì)外提供服務(wù)。這樣情況下，就必須設(shè)置一個(gè)超時(shí)時(shí)間，當(dāng)評(píng)價(jià)服務(wù)超過(guò)這個(gè)閾值時(shí)，商品服務(wù)不用繼續(xù)等待。

3、provider很有可能是因?yàn)槟硞€(gè)瞬間的網(wǎng)絡(luò)抖動(dòng)或者機(jī)器高負(fù)載引起的超時(shí)，如果超時(shí)后直接放棄，某些場(chǎng)景會(huì)造成業(yè)務(wù)損失（比如庫(kù)存接口超時(shí)會(huì)導(dǎo)致下單失敗）。因此，對(duì)于這種臨時(shí)性的服務(wù)抖動(dòng)，如果在超時(shí)后重試一下是可以挽救的，所以有必要通過(guò)重試機(jī)制來(lái)解決。

但是引入超時(shí)重試機(jī)制后，并非一切就完美了。它同樣會(huì)帶來(lái)副作用，這些是開(kāi)發(fā)RPC接口必須要考慮，同時(shí)也是最容易忽視的問(wèn)題：

1、重復(fù)請(qǐng)求：有可能provider執(zhí)行完了，但是因?yàn)榫W(wǎng)絡(luò)抖動(dòng)consumer認(rèn)為超時(shí)了，這種情況下重試機(jī)制就會(huì)導(dǎo)致重復(fù)請(qǐng)求，從而帶來(lái)臟數(shù)據(jù)問(wèn)題，因此服務(wù)端必須考慮接口的冪等性。

2、降低consumer的負(fù)載能力：如果provider并不是臨時(shí)性的抖動(dòng)，而是確實(shí)存在性能問(wèn)題，這樣重試多次也是沒(méi)法成功的，反而會(huì)使得consumer的平均響應(yīng)時(shí)間變長(zhǎng)。比如正常情況下provider的平均響應(yīng)時(shí)間是1s，consumer將超時(shí)時(shí)間設(shè)置成1.5s，重試次數(shù)設(shè)置為2次，這樣單次請(qǐng)求將耗時(shí)3s，consumer的整體負(fù)載就會(huì)被拉下來(lái)，如果consumer是一個(gè)高QPS的服務(wù)，還有可能引起連鎖反應(yīng)造成雪崩。

3、爆炸式的重試風(fēng)暴：假如一條調(diào)用鏈路經(jīng)過(guò)了4個(gè)服務(wù)，最底層的服務(wù)D出現(xiàn)超時(shí)，這樣上游服務(wù)都將發(fā)起重試，假設(shè)重試次數(shù)都設(shè)置的3次，那么B將面臨正常情況下3倍的負(fù)載量，C是9倍，D是27倍，整個(gè)服務(wù)集群可能因此雪崩。

?

04 應(yīng)該如何合理的設(shè)置超時(shí)時(shí)間？

理解了RPC框架的超時(shí)實(shí)現(xiàn)原理和可能引入的副作用后，可以按照下面的方法進(jìn)行超時(shí)設(shè)置：

• 設(shè)置調(diào)用方的超時(shí)時(shí)間之前，先了解清楚依賴服務(wù)的TP99響應(yīng)時(shí)間是多少（如果依賴服務(wù)性能波動(dòng)大，也可以看TP95），調(diào)用方的超時(shí)時(shí)間可以在此基礎(chǔ)上加50%

• 如果RPC框架支持多粒度的超時(shí)設(shè)置，則：全局超時(shí)時(shí)間應(yīng)該要略大于接口級(jí)別最長(zhǎng)的耗時(shí)時(shí)間，每個(gè)接口的超時(shí)時(shí)間應(yīng)該要略大于方法級(jí)別最長(zhǎng)的耗時(shí)時(shí)間，每個(gè)方法的超時(shí)時(shí)間應(yīng)該要略大于實(shí)際的方法執(zhí)行時(shí)間

• 區(qū)分是可重試服務(wù)還是不可重試服務(wù)，如果接口沒(méi)實(shí)現(xiàn)冪等則不允許設(shè)置重試次數(shù)。注意：讀接口是天然冪等的，寫接口則可以使用業(yè)務(wù)單據(jù)ID或者在調(diào)用方生成唯一ID傳遞給服務(wù)端，通過(guò)此ID進(jìn)行防重避免引入臟數(shù)據(jù)

• 如果RPC框架支持服務(wù)端的超時(shí)設(shè)置，同樣基于前面3條規(guī)則依次進(jìn)行設(shè)置，這樣能避免客戶端不設(shè)置的情況下配置是合理的，減少隱患

• 如果從業(yè)務(wù)角度來(lái)看，服務(wù)可用性要求不用那么高（比如偏內(nèi)部的應(yīng)用系統(tǒng)），則可以不用設(shè)置超時(shí)重試次數(shù)，直接人工重試即可，這樣能減少接口實(shí)現(xiàn)的復(fù)雜度，反而更利于后期維護(hù)

• 重試次數(shù)設(shè)置越大，服務(wù)可用性越高，業(yè)務(wù)損失也能進(jìn)一步降低，但是性能隱患也會(huì)更大，這個(gè)需要綜合考慮設(shè)置成幾次（一般是2次，最多3次）

• 如果調(diào)用方是高QPS服務(wù)，則必須考慮服務(wù)方超時(shí)情況下的降級(jí)和熔斷策略。（比如超過(guò)10%的請(qǐng)求出錯(cuò)，則停止重試機(jī)制直接熔斷，改成調(diào)用其他服務(wù)、異步MQ機(jī)制、或者使用調(diào)用方的緩存數(shù)據(jù)）

?

最后，再簡(jiǎn)單總結(jié)下：

RPC接口的超時(shí)設(shè)置看似簡(jiǎn)單，實(shí)際上有很大學(xué)問(wèn)。不僅涉及到很多技術(shù)層面的問(wèn)題（比如接口冪等、服務(wù)降級(jí)和熔斷、性能評(píng)估和優(yōu)化），同時(shí)還需要從業(yè)務(wù)角度評(píng)估必要性。知其然知其所以然，希望這些知識(shí)能讓你在開(kāi)發(fā)RPC接口時(shí)，有更全局的視野。

總結(jié)

以上是生活随笔為你收集整理的醉了，RPC 超时设置也能引起线上事故！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。