執行緒超時是什麼原因
這篇文章將透過一個真實的線上事故，系統性地介紹：在微服務架構下，該如何正確理解並設定 RPC 介面的超時時間，讓大家在開發服務端介面時有更全域性的視野。
圖片來自 Pexels
上面這張監控圖，對於服務端的研發同學來說再熟悉不過了。在日常的系統維護中，“服務超時”應該屬於監控報警最多的一類問題。
尤其在微服務架構下，一次請求可能要經過一條很長的鏈路，跨多個服務呼叫後才能返回結果。
當服務超時發生時，研發同學往往要抽絲剝繭般去分析自身系統的效能以及依賴服務的效能，這也是為什麼服務超時相對於服務出錯和服務呼叫量異常更難調查的原因。
本篇文章將分成以下四個部分：
從一次 RPC 介面超時引發的線上事故說起超時的實現原理是什麼？設定超時時間到底是為了解決什麼問題？應該如何合理的設定超時時間？
從一次 RPC 介面超時引發的線上事故說起
事故發生在電商 APP 的首頁推薦模組，某天中午突然收到使用者反饋：APP 首頁除了 banner 圖和導航區域，下方的推薦模組變成空白頁了（推薦模組佔到首頁 2/3 的空間，是根據使用者興趣由演算法實時推薦的商品 list）。
上面的業務場景可以藉助上圖的呼叫鏈來理解：
APP 端發起一個 HTTP 請求到業務閘道器。業務閘道器 RPC 呼叫推薦服務，獲取推薦商品 list。如果第 2 步呼叫失敗，則服務降級，改成 RPC 呼叫商品排序服務，獲取熱銷商品 list 進行託底。如果第 3 步呼叫失敗，則再次降級，直接獲取 Redis 快取中的熱銷商品 list。
粗看起來，兩個依賴服務的降級策略都考慮進去了，理論上就算推薦服務或者商品排序服務全部掛掉，服務端都應該可以返回資料給 APP 端。
但是 APP 端的推薦模組確實出現空白了，降級策略可能並未生效，下面詳細說下定位過程。
問題定位過程
第 1 步：APP 端透過抓包發現：HTTP 請求存在介面超時（超時時間設定的是 5 秒）。
第 2 步：業務閘道器透過日誌發現：呼叫推薦服務的 RPC 接口出現了大面積超時（超時時間設定的是 3 秒）。
錯誤資訊如下：
第 3 步：推薦服務透過日誌發現：Dubbo 的執行緒池耗盡。
錯誤資訊如下：
透過以上 3 步，基本就定位到了問題出現在推薦服務，後來進一步調查得出：是因為推薦服務依賴的 Redis 叢集不可用導致了超時，進而導致執行緒池耗盡。
詳細原因這裡不作展開，跟本文要討論的主題相關性不大。
降級策略未生效的原因分析
下面再接著分析下：當推薦服務呼叫失敗時，為什麼業務閘道器的降級策略沒有生效呢？理論上來說，不應該降級去呼叫商品排序服務進行託底嗎？
最終跟蹤分析找到了根本原因：APP 端呼叫業務閘道器的超時時間是 5 秒，業務閘道器呼叫推薦服務的超時時間是 3 秒，同時還設定了 3 次超時重試。
這樣當推薦服務呼叫失敗進行第 2 次重試時，HTTP 請求就已經超時了，因此業務閘道器的所有降級策略都不會生效。
下面是更加直觀的示意圖：
解決方案
解決方案如下：
將業務閘道器呼叫推薦服務的超時時間改成了 800ms（推薦服務的 TP99 大約為 540ms），超時重試次數改成了 2 次。將業務閘道器呼叫商品排序服務的超時時間改成了 600ms（商品排序服務的 TP99 大約為 400ms），超時重試次數也改成了 2 次。
關於超時時間和重試次數的設定，需要考慮整個呼叫鏈中所有依賴服務的耗時、各個服務是否是核心服務等很多因素。這裡先不作展開，後文會詳細介紹具體方法。
超時的實現原理是什麼？
只有瞭解了 RPC 框架的超時實現原理，才能更好地去設定它。不論是 Dubbo、Spring Cloud 或者大廠自研的微服務框架（比如京東的 JSF），超時的實現原理基本類似。
下面以 Dubbo 2。8。4 版本的原始碼為例來看下具體實現。熟悉 Dubbo 的同學都知道，可在兩個地方配置超時時間：分別是 Provider（服務端，服務提供方）和 Consumer（消費端，服務呼叫方）。
服務端的超時配置是消費端的預設配置，也就是說只要服務端設定了超時時間，則所有消費端都無需設定，可透過註冊中心傳遞給消費端。
這樣：一方面簡化了配置，另一方面因為服務端更清楚自己的介面效能，所以交給服務端進行設定也算合理。
Dubbo 支援非常細粒度的超時設定，包括：方法級別、介面級別和全域性。如果各個級別同時配置了，優先順序為：消費端方法級>服務端方法級>消費端介面級>服務端介面級>消費端全域性>服務端全域性。
透過原始碼，我們先看下服務端的超時處理邏輯：
可以看到，服務端即使超時，也只是列印了一個 warn 日誌。因此，服務端的超時設定並不會影響實際的呼叫過程，就算超時也會執行完整個處理邏輯。
再來看下消費端的超時處理邏輯：
FailoverCluster 是叢集容錯的預設模式，當呼叫失敗後會切換成呼叫其他伺服器。
再看下 doInvoke 方法，當呼叫失敗時，會先判斷是否是業務異常，如果是則終止重試，否則會一直重試直到達到重試次數。
繼續跟蹤 Invoker 的 Invoke 方法，可以看到在請求發出後透過 Future 的 get 方法獲取結果。
原始碼如下：
進入方法後開始計時，如果在設定的超時時間內沒有獲得返回結果，則丟擲 TimeoutException。
因此，消費端的超時邏輯同時受到超時時間和超時次數兩個引數的控制，像網路異常、響應超時等都會一直重試，直到達到重試次數。
設定超時時間是為了解決什麼問題？
RPC 框架的超時重試機制到底是為了解決什麼問題呢？從微服務架構這個宏觀角度來說，它是為了確保服務鏈路的穩定性，提供了一種框架級的容錯能力。
微觀上如何理解呢？可以從下面幾個具體 case 來看：
①Consumer 呼叫 Provider，如果不設定超時時間，則 Consumer 的響應時間肯定會大於 Provider 的響應時間。
當 Provider 效能變差時，Consumer 的效能也會受到影響，因為它必須無限期地等待 Provider 的返回。
假如整個呼叫鏈路經過了 A、B、C、D 多個服務，只要 D 的效能變差，就會自下而上影響到 A、B、C，最終造成整個鏈路超時甚至癱瘓，因此設定超時時間是非常有必要的。
②假設 Consumer 是核心的商品服務，Provider 是非核心的評論服務，當評價服務出現效能問題時，商品服務可以接受不返回評價資訊，從而保證能繼續對外提供服務。
這樣情況下，就必須設定一個超時時間，當評價服務超過這個閾值時，商品服務不用繼續等待。
③Provider 很有可能是因為某個瞬間的網路抖動或者機器高負載引起的超時，如果超時後直接放棄，某些場景會造成業務損失（比如庫存介面超時會導致下單失敗）。
因此，對於這種臨時性的服務抖動，如果在超時後重試一下是可以挽救的，所以有必要透過重試機制來解決。
但是引入超時重試機制後，並非一切就完美了。它同樣會帶來副作用，這些是開發 RPC 介面必須要考慮，同時也是最容易忽視的問題：
①重複請求：有可能 Provider 執行完了，但是因為網路抖動 Consumer 認為超時了，這種情況下重試機制就會導致重複請求，從而帶來髒資料問題，因此服務端必須考慮介面的冪等性。
②降低 Consumer 的負載能力：如果 Provider 並不是臨時性的抖動，而是確實存在效能問題，這樣重試多次也是沒法成功的，反而會使得 Consumer 的平均響應時間變長。
比如正常情況下 Provider 的平均響應時間是 1s，Consumer 將超時時間設定成 1。5s，重試次數設定為 2 次。
這樣單次請求將耗時 3s，Consumer 的整體負載就會被拉下來，如果 Consumer 是一個高 QPS 的服務，還有可能引起連鎖反應造成雪崩。
③爆炸式的重試風暴：假如一條呼叫鏈路經過了 4 個服務，最底層的服務 D 出現超時，這樣上游服務都將發起重試。
假設重試次數都設定的 3 次，那麼 B 將面臨正常情況下 3 倍的負載量，C 是 9 倍，D 是 27 倍，整個服務叢集可能因此雪崩。
應該如何合理的設定超時時間？
理解了 RPC 框架的超時實現原理和可能引入的副作用後，可以按照下面的方法進行超時設定：
設定呼叫方的超時時間之前，先了解清楚依賴服務的 TP99 響應時間是多少（如果依賴服務效能波動大，也可以看 TP95），呼叫方的超時時間可以在此基礎上加 50%。如果 RPC 框架支援多粒度的超時設定，則：全域性超時時間應該要略大於介面級別最長的耗時時間，每個介面的超時時間應該要略大於方法級別最長的耗時時間，每個方法的超時時間應該要略大於實際的方法執行時間。區分是可重試服務還是不可重試服務，如果介面沒實現冪等則不允許設定重試次數。注意：讀介面是天然冪等的，寫介面則可以使用業務單據 ID 或者在呼叫方生成唯一 ID 傳遞給服務端，透過此 ID 進行防重避免引入髒資料。如果 RPC 框架支援服務端的超時設定，同樣基於前面3條規則依次進行設定，這樣能避免客戶端不設定的情況下配置是合理的，減少隱患。如果從業務角度來看，服務可用性要求不用那麼高（比如偏內部的應用系統），則可以不用設定超時重試次數，直接人工重試即可，這樣能減少介面實現的複雜度，反而更利於後期維護。重試次數設定越大，服務可用性越高，業務損失也能進一步降低，但是效能隱患也會更大，這個需要綜合考慮設定成幾次（一般是 2 次，最多 3 次）。如果呼叫方是高 QPS 服務，則必須考慮服務方超時情況下的降級和熔斷策略。（比如超過 10% 的請求出錯，則停止重試機制直接熔斷，改成呼叫其他服務、非同步 MQ 機制、或者使用呼叫方的快取資料）
總結
最後，再簡單總結下：RPC 介面的超時設定看似簡單，實際上有很大學問。不僅涉及到很多技術層面的問題（比如介面冪等、服務降級和熔斷、效能評估和最佳化），同時還需要從業務角度評估必要性。
知其然知其所以然，希望這些知識能讓你在開發 RPC 介面時，有更全域性的視野。