這篇文章將通過一個真實的線上事故，系統性地介紹：在微服務架構下，該如何正確理解并設置 RPC 接口的超時時間，讓大家在開發服務端接口時有更全局的視野。

[[320724]]

圖片來自 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 接口時，有更全局的視野。