上面這張監控圖，對于服務端的研發同學來說再熟悉不過了，在日常的系統維護中，『服務超時』應該屬于監控報警最多的一類問題，
尤其在微服務架構下，一次請求可能要經過一條很長的鏈路，跨多個服務呼叫后才能回傳結果，當服務超時發生時，研發同學往往要抽絲剝繭般去分析自身系統的性能以及依賴服務的性能，這也是為什么服務超時相對于服務出錯和服務呼叫量例外更難調查的原因，
這篇文章將通過一個真實的線上事故，系統性地介紹下：在微服務架構下，該如何正確理解并設定RPC介面的超時時間，讓大家在開發服務端介面時有更全域的視野，內容將分成以下4個部分：
1、從一次RPC介面超時引發的線上事故說起
2、超時的實作原理是什么？
3、設定超時時間到底是為了解決什么問題？
4、應該如何合理的設定超時時間？
01 從一次線上事故說起
事故發生在電商APP的首頁推薦模塊，某天中午突然收到用戶反饋：APP首頁除了banner圖和導航區域，下方的推薦模塊變成空白頁了（推薦模塊占到首頁2/3的空間，是根據用戶興趣由演算法實時推薦的商品list），
上面的業務場景可以借助下面的呼叫鏈來理解
1、APP端發起一個HTTP請求到業務網關
2、業務網關RPC呼叫推薦服務，獲取推薦商品list
3、如果第2步呼叫失敗，則服務降級，改成RPC呼叫商品排序服務，獲取熱銷商品list進行托底
4、如果第3步呼叫失敗，則再次降級，直接獲取Redis快取中的熱銷商品list
粗看起來，兩個依賴服務的降級策略都考慮進去了，理論上就算推薦服務或者商品排序服務全部掛掉，服務端都應該可以回傳資料給APP端，但是APP端的推薦模塊確實出現空白了，降級策略可能并未生效，下面詳細說下定位程序，
1、問題定位程序
第1步：APP端通過抓包發現：HTTP請求存在介面超時（超時時間設定的是5秒），
第2步：業務網關通過日志發現：呼叫推薦服務的RPC介面出現了大面積超時（超時時間設定的是3秒），錯誤資訊如下：
第3步：推薦服務通過日志發現：dubbo的執行緒池耗盡，錯誤資訊如下：
通過以上3步，基本就定位到了問題出現在推薦服務，后來進一步調查得出：是因為推薦服務依賴的redis集群不可用導致了超時，進而導致執行緒池耗盡，詳細原因這里不作展開，跟本文要討論的主題相關性不大，
2、降級策略未生效的原因分析
下面再接著分析下：當推薦服務呼叫失敗時，為什么業務網關的降級策略沒有生效呢？理論上來說，不應該降級去呼叫商品排序服務進行托底嗎？
最終跟蹤分析找到了根本原因：APP端呼叫業務網關的超時時間是5秒，業務網關呼叫推薦服務的超時時間是3秒，同時還設定了3次超時重試，這樣當推薦服務呼叫失敗進行第2次重試時，HTTP請求就已經超時了，因此業務網關的所有降級策略都不會生效，下面是更加直觀的示意圖：
3、解決方案
1、將業務網關呼叫推薦服務的超時時間改成了800ms（推薦服務的TP99大約為540ms），超時重試次數改成了2次
2、將業務網關呼叫商品排序服務的超時時間改成了600ms（商品排序服務的TP99大約為400ms），超時重試次數也改成了2次
關于超時時間和重試次數的設定，需要考慮整個呼叫鏈中所有依賴服務的耗時、各個服務是否是核心服務等很多因素，這里先不作展開，后文會詳細介紹具體方法，
02 超時的實作原理是什么？
只有了解了RPC框架的超時實作原理，才能更好地去設定它，不論是dubbo、SpringCloud或者大廠自研的微服務框架（比如京東的JSF），超時的實作原理基本類似，下面以dubbo 2.8.4版本的原始碼為例來看下具體實作，
熟悉dubbo的同學都知道，可在兩個地方配置超時時間：分別是provider（服務端，服務提供方）和consumer（消費端，服務呼叫方），服務端的超時配置是消費端的預設配置，也就是說只要服務端設定了超時時間，則所有消費端都無需設定，可通過注冊中心傳遞給消費端，這樣：一方面簡化了配置，另一方面因為服務端更清楚自己的介面性能，所以交給服務端進行設定也算合理，
dubbo支持非常細粒度的超時設定，包括：方法級別、介面級別和全域，如果各個級別同時配置了，優先級為：消費端方法級 > 服務端方法級 > 消費端介面級 > 服務端介面級 > 消費端全域 > 服務端全域，
通過原始碼，我們先看下服務端的超時處理邏輯
1 public class TimeoutFilter implements Filter {
2
3 public TimeoutFilter() {
4 }
5
6 public Result invoke(...) throws RpcException {
7 // 執行真正的邏輯呼叫，并統計耗時
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 }
可以看到，服務端即使超時，也只是列印了一個warn日志，因此，服務端的超時設定并不會影響實際的呼叫程序，就算超時也會執行完整個處理邏輯，
再來看下消費端的超時處理邏輯
1 public class FailoverClusterInvoker {
2
3 public Result doInvoke(...) {
4 ...
5 // 回圈呼叫設定的重試次數
6 for (int i = 0; i < retryTimes; ++i) {
7 ...
8 try {
9 Result result = invoker.invoke(invocation);
10 return result;
11 } catch (RpcException e) {
12 // 如果是業務例外，終止重試
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是集群容錯的預設模式，當呼叫失敗后會切換成呼叫其他服務器，再看下doInvoke方法，當呼叫失敗時，會先判斷是否是業務例外，如果是則終止重試，否則會一直重試直到達到重試次數，
繼續跟蹤invoker的invoke方法，可以看到在請求發出后通過Future的get方法獲取結果，原始碼如下：
1 public 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 // 回圈判斷
12 while(!isDone()) {
13 // 放棄鎖，進入等待狀態
14 done.await((long)timeout, TimeUnit.MILLISECONDS);
15
16 // 判斷是否已經回傳結果或者已經超時
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 // 如果未回傳結果，則拋出超時例外
30 throw new TimeoutException(...);
31 }
32 }
33
34 return returnFromResponse();
35 }
進入方法后開始計時，如果在設定的超時時間內沒有獲得回傳結果，則拋出TimeoutException，因此，消費端的超時邏輯同時受到超時時間和超時次數兩個引數的控制，像網路例外、回應超時等都會一直重試，直到達到重試次數，
03 設定超時時間是為了解決什么問題？
RPC框架的超時重試機制到底是為了解決什么問題呢？從微服務架構這個宏觀角度來說，它是為了確保服務鏈路的穩定性，提供了一種框架級的容錯能力，微觀上如何理解呢？可以從下面幾個具體case來看：
1、consumer呼叫provider，如果不設定超時時間，則consumer的回應時間肯定會大于provider的回應時間，當provider性能變差時，consumer的性能也會受到影響，因為它必須無限期地等待provider的回傳，假如整個呼叫鏈路經過了A、B、C、D多個服務，只要D的性能變差，就會自下而上影響到A、B、C，最終造成整個鏈路超時甚至癱瘓，因此設定超時時間是非常有必要的，
2、假設consumer是核心的商品服務，provider是非核心的評論服務，當評價服務出現性能問題時，商品服務可以接受不回傳評價資訊，從而保證能繼續對外提供服務，這樣情況下，就必須設定一個超時時間，當評價服務超過這個閾值時，商品服務不用繼續等待，
3、provider很有可能是因為某個瞬間的網路抖動或者機器高負載引起的超時，如果超時后直接放棄，某些場景會造成業務損失（比如庫存介面超時會導致下單失敗），因此，對于這種臨時性的服務抖動，如果在超時后重試一下是可以挽救的，所以有必要通過重試機制來解決，
但是引入超時重試機制后，并非一切就完美了，它同樣會帶來副作用，這些是開發RPC介面必須要考慮，同時也是最容易忽視的問題：
1、重復請求：有可能provider執行完了，但是因為網路抖動consumer認為超時了，這種情況下重試機制就會導致重復請求，從而帶來臟資料問題，因此服務端必須考慮介面的冪等性，
2、降低consumer的負載能力：如果provider并不是臨時性的抖動，而是確實存在性能問題，這樣重試多次也是沒法成功的，反而會使得consumer的平均回應時間變長，比如正常情況下provider的平均回應時間是1s，consumer將超時時間設定成1.5s，重試次數設定為2次，這樣單次請求將耗時3s，consumer的整體負載就會被拉下來，如果consumer是一個高QPS的服務，還有可能引起連鎖反應造成雪崩，
3、爆炸式的重試風暴：假如一條呼叫鏈路經過了4個服務，最底層的服務D出現超時，這樣上游服務都將發起重試，假設重試次數都設定的3次，那么B將面臨正常情況下3倍的負載量，C是9倍，D是27倍，整個服務集群可能因此雪崩，
04 應該如何合理的設定超時時間？
理解了RPC框架的超時實作原理和可能引入的副作用后，可以按照下面的方法進行超時設定：
1、設定呼叫方的超時時間之前，先了解清楚依賴服務的TP99回應時間是多少（如果依賴服務性能波動大，也可以看TP95），呼叫方的超時時間可以在此基礎上加50%
2、如果RPC框架支持多粒度的超時設定，則：全域超時時間應該要略大于介面級別最長的耗時時間，每個介面的超時時間應該要略大于方法級別最長的耗時時間，每個方法的超時時間應該要略大于實際的方法執行時間
3、區分是可重試服務還是不可重試服務，如果介面沒實作冪等則不允許設定重試次數，注意：讀介面是天然冪等的，寫介面則可以使用業務單據ID或者在呼叫方生成唯一ID傳遞給服務端，通過此ID進行防重避免引入臟資料
4、如果RPC框架支持服務端的超時設定，同樣基于前面3條規則依次進行設定，這樣能避免客戶端不設定的情況下配置是合理的，減少隱患
5、如果從業務角度來看，服務可用性要求不用那么高（比如偏內部的應用系統），則可以不用設定超時重試次數，直接人工重試即可，這樣能減少介面實作的復雜度，反而更利于后期維護
6、重試次數設定越大，服務可用性越高，業務損失也能進一步降低，但是性能隱患也會更大，這個需要綜合考慮設定成幾次（一般是2次，最多3次）
7、如果呼叫方是高QPS服務，則必須考慮服務方超時情況下的降級和熔斷策略，（比如超過10%的請求出錯，則停止重試機制直接熔斷，改成呼叫其他服務、異步MQ機制、或者使用呼叫方的快取資料）
最后，再簡單總結下：
RPC介面的超時設定看似簡單，實際上有很大學問，不僅涉及到很多技術層面的問題（比如介面冪等、服務降級和熔斷、性能評估和優化），同時還需要從業務角度評估必要性，知其然知其所以然，希望這些知識能讓你在開發RPC介面時，有更全域的視野，
作者簡介：程式員，985碩士，前亞馬遜Java工程師，現58轉轉技術總監，持續分享技術和管理方向的文章，如果感興趣，可微信掃描下面的二維碼關注我的公眾號：『IT人的職場進階』
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/162674.html
標籤：Java
下一篇：03、MyBatis 映射檔案