ajax接口一直在重复调用请求是什么原因_为什么RPC超时设置非常重要
尤其在微服務(wù)架構(gòu)下，一次請求可能要經(jīng)過一條很長的鏈路，跨多個服務(wù)調(diào)用后才能返回結(jié)果。當(dāng)服務(wù)超時發(fā)生時，研發(fā)同學(xué)往往要抽絲剝繭般去分析自身系統(tǒng)的性能以及依賴服務(wù)的性能，這也是為什么服務(wù)超時相對于服務(wù)出錯和服務(wù)調(diào)用量異常更難調(diào)查的原因。
這篇文章將通過一個真實的線上事故，系統(tǒng)性地介紹下：在微服務(wù)架構(gòu)下，該如何正確理解并設(shè)置RPC接口的超時時間，讓大家在開發(fā)服務(wù)端接口時有更全局的視野。內(nèi)容將分成以下4個部分：從一次RPC接口超時引發(fā)的線上事故說起
超時的實現(xiàn)原理是什么？
設(shè)置超時時間到底是為了解決什么問題？
應(yīng)該如何合理的設(shè)置超時時間？
01?從一次線上事故說起
事故發(fā)生在電商APP的首頁推薦模塊，某天中午突然收到用戶反饋：APP首頁除了banner圖和導(dǎo)航區(qū)域，下方的推薦模塊變成空白頁了(推薦模塊占到首頁2/3的空間，是根據(jù)用戶興趣由算法實時推薦的商品list)。上面的業(yè)務(wù)場景可以借助下面的調(diào)用鏈來理解APP端發(fā)起一個HTTP請求到業(yè)務(wù)網(wǎng)關(guān)
- 業(yè)務(wù)網(wǎng)關(guān)RPC調(diào)用推薦服務(wù)，獲取推薦商品list
- 如果第2步調(diào)用失敗，則服務(wù)降級，改成RPC調(diào)用商品排序服務(wù)，獲取熱銷商品list進行托底
- 如果第3步調(diào)用失敗，則再次降級，直接獲取Redis緩存中的熱銷商品list
粗看起來，兩個依賴服務(wù)的降級策略都考慮進去了，理論上就算推薦服務(wù)或者商品排序服務(wù)全部掛掉，服務(wù)端都應(yīng)該可以返回數(shù)據(jù)給APP端。但是APP端的推薦模塊確實出現(xiàn)空白了，降級策略可能并未生效，下面詳細(xì)說下定位過程。
1、問題定位過程第1步：APP端通過抓包發(fā)現(xiàn)：HTTP請求存在接口超時(超時時間設(shè)置的是5秒)。
第2步：業(yè)務(wù)網(wǎng)關(guān)通過日志發(fā)現(xiàn)：調(diào)用推薦服務(wù)的RPC接口出現(xiàn)了大面積超時(超時時間設(shè)置的是3秒)，錯誤信息如下：
第3步：推薦服務(wù)通過日志發(fā)現(xiàn)：dubbo的線程池耗盡，錯誤信息如下：
通過以上3步，基本就定位到了問題出現(xiàn)在推薦服務(wù)，后來進一步調(diào)查得出：是因為推薦服務(wù)依賴的redis集群不可用導(dǎo)致了超時，進而導(dǎo)致線程池耗盡。詳細(xì)原因這里不作展開，跟本文要討論的主題相關(guān)性不大。
2、降級策略未生效的原因分析下面再接著分析下：當(dāng)推薦服務(wù)調(diào)用失敗時，為什么業(yè)務(wù)網(wǎng)關(guān)的降級策略沒有生效呢？理論上來說，不應(yīng)該降級去調(diào)用商品排序服務(wù)進行托底嗎？
最終跟蹤分析找到了根本原因：APP端調(diào)用業(yè)務(wù)網(wǎng)關(guān)的超時時間是5秒，業(yè)務(wù)網(wǎng)關(guān)調(diào)用推薦服務(wù)的超時時間是3秒，同時還設(shè)置了3次超時重試，這樣當(dāng)推薦服務(wù)調(diào)用失敗進行第2次重試時，HTTP請求就已經(jīng)超時了，因此業(yè)務(wù)網(wǎng)關(guān)的所有降級策略都不會生效。下面是更加直觀的示意圖：
3、解決方案- 將業(yè)務(wù)網(wǎng)關(guān)調(diào)用推薦服務(wù)的超時時間改成了800ms(推薦服務(wù)的TP99大約為540ms)，超時重試次數(shù)改成了2次
將業(yè)務(wù)網(wǎng)關(guān)調(diào)用商品排序服務(wù)的超時時間改成了600ms(商品排序服務(wù)的TP99大約為400ms)，超時重試次數(shù)也改成了2次
關(guān)于超時時間和重試次數(shù)的設(shè)置，需要考慮整個調(diào)用鏈中所有依賴服務(wù)的耗時、各個服務(wù)是否是核心服務(wù)等很多因素。這里先不作展開，后文會詳細(xì)介紹具體方法。
02 超時的實現(xiàn)原理是什么？
只有了解了RPC框架的超時實現(xiàn)原理，才能更好地去設(shè)置它。不論是dubbo、SpringCloud或者大廠自研的微服務(wù)框架(比如京東的JSF)，超時的實現(xiàn)原理基本類似。下面以dubbo 2.8.4版本的源碼為例來看下具體實現(xiàn)。熟悉dubbo的同學(xué)都知道，可在兩個地方配置超時時間：分別是provider(服務(wù)端，服務(wù)提供方)和consumer(消費端，服務(wù)調(diào)用方)。服務(wù)端的超時配置是消費端的缺省配置，也就是說只要服務(wù)端設(shè)置了超時時間，則所有消費端都無需設(shè)置，可通過注冊中心傳遞給消費端，這樣：一方面簡化了配置，另一方面因為服務(wù)端更清楚自己的接口性能，所以交給服務(wù)端進行設(shè)置也算合理。
dubbo支持非常細(xì)粒度的超時設(shè)置，包括：方法級別、接口級別和全局。如果各個級別同時配置了，優(yōu)先級為：消費端方法級 >?服務(wù)端方法級 >?消費端接口級 > 服務(wù)端接口級 >?消費端全局 > 服務(wù)端全局。
通過源碼，我們先看下服務(wù)端的超時處理邏輯 1public?class?TimeoutFilter?implements?Filter?{2
3????public?TimeoutFilter()?{
4????}
5
6????public?Result?invoke(...)?throws?RpcException?{
7????????//?執(zhí)行真正的邏輯調(diào)用，并統(tǒng)計耗時
8????????long?start?=?System.currentTimeMillis();
9????????Result?result?=?invoker.invoke(invocation);
10????????long?elapsed?=?System.currentTimeMillis()?-?start;
11
12????????//?判斷是否超時
13????????if?(invoker.getUrl()?!=?null?&&?elapsed?>?timeout)?{
14????????????//?打印warn日志
15????????????logger.warn("invoke?time?out...");
16????????}
17
18????????return?result;
19????}
20}
可以看到，服務(wù)端即使超時，也只是打印了一個warn日志。因此，服務(wù)端的超時設(shè)置并不會影響實際的調(diào)用過程，就算超時也會執(zhí)行完整個處理邏輯。再來看下消費端的超時處理邏輯 1public?class?FailoverClusterInvoker?{
2
3????public?Result?doInvoke(...)??{
4????????...
5????????//?循環(huán)調(diào)用設(shè)定的重試次數(shù)
6????????for?(int?i?=?0;?i? 7????????????...
8????????????try?{
9????????????????Result?result?=?invoker.invoke(invocation);
10????????????????return?result;
11????????????}?catch?(RpcException?e)?{
12????????????????//?如果是業(yè)務(wù)異常，終止重試
13????????????????if?(e.isBiz())?{
14????????????????????throw?e;
15????????????????}
16
17????????????????le?=?e;
18????????????}?catch?(Throwable?e)?{
19????????????????le?=?new?RpcException(...);
20????????????}?finally?{
21????????????????...
22????????????}
23????????}
24
25????????throw?new?RpcException("...");
26????}
27}
FailoverCluster是集群容錯的缺省模式，當(dāng)調(diào)用失敗后會切換成調(diào)用其他服務(wù)器。再看下doInvoke方法，當(dāng)調(diào)用失敗時，會先判斷是否是業(yè)務(wù)異常，如果是則終止重試，否則會一直重試直到達(dá)到重試次數(shù)。
繼續(xù)跟蹤invoker的invoke方法，可以看到在請求發(fā)出后通過Future的get方法獲取結(jié)果，源碼如下：
1public?Object?get(int?timeout)?{2????????if?(timeout?<=?0)?{
3????????????timeout?=?1000;
4????????}
5
6????????if?(!isDone())?{
7????????????long?start?=?System.currentTimeMillis();
8????????????this.lock.lock();
9
10????????????try?{
11????????????????//?循環(huán)判斷
12????????????????while(!isDone())?{
13????????????????????//?放棄鎖，進入等待狀態(tài)
14????????????????????done.await((long)timeout,?TimeUnit.MILLISECONDS);
15
16????????????????????//?判斷是否已經(jīng)返回結(jié)果或者已經(jīng)超時
17????????????????????long?elapsed?=?System.currentTimeMillis()?-?start;
18????????????????????if?(isDone()?||?elapsed?>?(long)timeout)?{
19????????????????????????break;
20????????????????????}
21????????????????}
22????????????}?catch?(InterruptedException?var8)?{
23????????????????throw?new?RuntimeException(var8);
24????????????}?finally?{
25????????????????this.lock.unlock();
26????????????}
27
28????????????if?(!isDone())?{
29????????????????//?如果未返回結(jié)果，則拋出超時異常
30????????????????throw?new?TimeoutException(...);
31????????????}
32????????}
33
34????????return?returnFromResponse();
35????}
進入方法后開始計時，如果在設(shè)定的超時時間內(nèi)沒有獲得返回結(jié)果，則拋出TimeoutException。因此，消費端的超時邏輯同時受到超時時間和超時次數(shù)兩個參數(shù)的控制，像網(wǎng)絡(luò)異常、響應(yīng)超時等都會一直重試，直到達(dá)到重試次數(shù)。
03 設(shè)置超時時間是為了解決什么問題？
RPC框架的超時重試機制到底是為了解決什么問題呢？從微服務(wù)架構(gòu)這個宏觀角度來說，它是為了確保服務(wù)鏈路的穩(wěn)定性，提供了一種框架級的容錯能力。微觀上如何理解呢？可以從下面幾個具體case來看：1、consumer調(diào)用provider，如果不設(shè)置超時時間，則consumer的響應(yīng)時間肯定會大于provider的響應(yīng)時間。當(dāng)provider性能變差時，consumer的性能也會受到影響，因為它必須無限期地等待provider的返回。假如整個調(diào)用鏈路經(jīng)過了A、B、C、D多個服務(wù)，只要D的性能變差，就會自下而上影響到A、B、C，最終造成整個鏈路超時甚至癱瘓，因此設(shè)置超時時間是非常有必要的。2、假設(shè)consumer是核心的商品服務(wù)，provider是非核心的評論服務(wù)，當(dāng)評價服務(wù)出現(xiàn)性能問題時，商品服務(wù)可以接受不返回評價信息，從而保證能繼續(xù)對外提供服務(wù)。這樣情況下，就必須設(shè)置一個超時時間，當(dāng)評價服務(wù)超過這個閾值時，商品服務(wù)不用繼續(xù)等待。3、provider很有可能是因為某個瞬間的網(wǎng)絡(luò)抖動或者機器高負(fù)載引起的超時，如果超時后直接放棄，某些場景會造成業(yè)務(wù)損失(比如庫存接口超時會導(dǎo)致下單失敗)。因此對于這種臨時性的服務(wù)抖動，如果在超時后重試一下是可以挽救的，所以有必要通過重試機制來解決。但是引入超時重試機制后，并非一切就完美了。它同樣會帶來副作用，這些是開發(fā)RPC接口必須要考慮，同時也是最容易忽視的問題：1、重復(fù)請求：有可能provider執(zhí)行完了，但是因為網(wǎng)絡(luò)抖動consumer認(rèn)為超時了，這種情況下重試機制就會導(dǎo)致重復(fù)請求，從而帶來臟數(shù)據(jù)問題，因此服務(wù)端必須考慮接口的冪等性。2、降低consumer的負(fù)載能力：如果provider并不是臨時性的抖動，而是確實存在性能問題，這樣重試多次也是沒法成功的，反而會使得consumer的平均響應(yīng)時間變長。比如正常情況下provider的平均響應(yīng)時間是1s，consumer將超時時間設(shè)置成1.5s，重試次數(shù)設(shè)置為2次，這樣單次請求將耗時3s，consumer的整體負(fù)載就會被拉下來，如果consumer是一個高QPS的服務(wù)，還有可能引起連鎖反應(yīng)造成雪崩。3、爆炸式的重試風(fēng)暴：假如一條調(diào)用鏈路經(jīng)過了4個服務(wù)，最底層的服務(wù)D出現(xiàn)超時，這樣上游服務(wù)都將發(fā)起重試，假設(shè)重試次數(shù)都設(shè)置的3次，那么B將面臨正常情況下3倍的負(fù)載量，C是9倍，D是27倍，整個服務(wù)集群可能因此雪崩。04 應(yīng)該如何合理的設(shè)置超時時間？
理解了RPC框架的超時實現(xiàn)原理和可能引入的副作用后，可以按照下面的方法進行超時設(shè)置：
設(shè)置調(diào)用方的超時時間之前，先了解清楚依賴服務(wù)的TP99響應(yīng)時間是多少(如果依賴服務(wù)性能波動大，也可以看TP95)，調(diào)用方的超時時間可以在此基礎(chǔ)上加50%
- 如果RPC框架支持多粒度的超時設(shè)置，則：全局超時時間應(yīng)該要略大于接口級別最長的耗時時間，每個接口的超時時間應(yīng)該要略大于方法級別最長的耗時時間，每個方法的超時時間應(yīng)該要略大于實際的方法執(zhí)行時間
- 區(qū)分是可重試服務(wù)還是不可重試服務(wù)，如果接口沒實現(xiàn)冪等則不允許設(shè)置重試次數(shù)。注意：讀接口是天然冪等的，寫接口則可以使用業(yè)務(wù)單據(jù)ID或者在調(diào)用方生成唯一ID傳遞給服務(wù)端，通過此ID進行防重避免引入臟數(shù)據(jù)
- 如果RPC框架支持服務(wù)端的超時設(shè)置，同樣基于前面3條規(guī)則依次進行設(shè)置，這樣能避免客戶端不設(shè)置的情況下配置是合理的，減少隱患
- 如果從業(yè)務(wù)角度來看，服務(wù)可用性要求不用那么高(比如偏內(nèi)部的應(yīng)用系統(tǒng))，則可以不用設(shè)置超時重試次數(shù)，直接人工重試即可，這樣能減少接口實現(xiàn)的復(fù)雜度，反而更利于后期維護
- 重試次數(shù)設(shè)置越大，服務(wù)可用性越高，業(yè)務(wù)損失也能進一步降低，但是性能隱患也會更大，這個需要綜合考慮設(shè)置成幾次(一般是2次，最多3次)
- 如果調(diào)用方是高QPS服務(wù)，則必須考慮服務(wù)方超時情況下的降級和熔斷策略。(比如超過10%的請求出錯，則停止重試機制直接熔斷，改成調(diào)用其他服務(wù)、異步MQ機制、或者使用調(diào)用方的緩存數(shù)據(jù))
最后，再簡單總結(jié)下：
RPC接口的超時設(shè)置看似簡單，實際上有很大學(xué)問。不僅涉及到很多技術(shù)層面的問題(比如接口冪等、服務(wù)降級和熔斷、性能評估和優(yōu)化)，同時還需要從業(yè)務(wù)角度評估必要性。知其然知其所以然，希望這些知識能讓你在開發(fā)RPC接口時，有更全局的視野。推薦閱讀
「DUBBO系列」超時機制實現(xiàn)原理
「DUBBO系列」服務(wù)降級實現(xiàn)原理
「DUBBO系列」并發(fā)控制實現(xiàn)原理
「DUBBO系列」集群容錯之Failover
IT人的職場進階?
前亞馬遜工程師，現(xiàn)58轉(zhuǎn)轉(zhuǎn)技術(shù)總監(jiān)，持續(xù)分享個人的成長經(jīng)歷，希望為你的職場發(fā)展帶來些新思路，歡迎掃碼關(guān)注
JAVA前線?
互聯(lián)網(wǎng)技術(shù)人思考與分享，歡迎掃碼關(guān)注
總結(jié)
以上是生活随笔為你收集整理的ajax接口一直在重复调用请求是什么原因_为什么RPC超时设置非常重要的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 贵州瑶山古寨旅游产品设计_快领取！贵州推
- 下一篇： aaynctask控制多个下载进度_史上