攜程10個有效降低客戶端超時的方法-全球微速訊

2023-06-06 12:12:52來源：攜程技術

一、背景

在現(xiàn)今的信息時代，微服務技術已成為一種重要的解決方案，微服務技術可以使系統(tǒng)的規(guī)模和功能變的更加靈活，從而獲得更高的可擴展性和可用性。然而，微服務調用中出現(xiàn)的超時問題，卻也成為系統(tǒng)可用性的一大隱患。超時會導致客戶端的性能下降，甚至可能無法正常工作。本文針對超時問題，提出相關的優(yōu)化手段，降低微服務調用超時的風險。

1.1 誤區(qū)

當我們遇到超時或執(zhí)行慢的問題時，我們往往會認為是依賴方出現(xiàn)了問題。

例如：訪問 Redis、DB、 RPC 接口變慢、超時，第一時間找依賴方排查問題，對方反饋的結論是，我這邊（服務端）沒有問題，請檢查一下你那邊（客戶端）是否有問題。

(資料圖)

實際上，性能下降是一個非常復雜的問題，它可能涉及多個方面，包括服務端和客戶端。例如：代碼質量、硬件資源、網絡狀況等問題都會導致性能下降，從而引發(fā)響應慢、超時等問題。因此，我們需要全面地分析問題，找出影響性能的各種因素。

1.2 分享的目的

本文將詳細介紹我們在生產環(huán)境中遇到的慢執(zhí)行和超時等問題，并提出相關的優(yōu)化手段，通過優(yōu)化長尾性能，降低變慢或超時的風險，提升系統(tǒng)的穩(wěn)定性。

二、超時的分類

常見的超時一般有兩類：

a. 連接超時（ConnectTimeout）：指建立網絡連接所需要的時間超出了設定的等待時間。

b. Socket 超時（SocketTimeout）：指在數(shù)據(jù)傳輸過程中，客戶端等待服務端響應的時間超出了設定的等待時間。

如下圖，①就是連接超時關注的時間，②就是 Socket 超時關注的時間，本文講解的超時為 Socket 超時。

圖1 客戶端請求過程

三、超時問題分析與優(yōu)化3.1 設置合理的超時時間

根據(jù)實際情況設置合理的超時時間，避免因為超時時間設置不合理導致的接口超時。

1）分析

看下客戶端設置的超時時間是否合理。比如調用服務端 P99.9 是100ms ，客戶端設置的超時時間是 100ms ，就會有 0.1% 的請求會超時。

2）優(yōu)化方案

我們在設置超時時間需要綜合考慮網絡延遲、服務響應時間、GC 等情況。

以門票活動查詢引擎為例：

核心接口：最小值（ P99.9*3 ，用戶可接受的等待時間），核心會影響到訂單，在用戶可接受范圍內盡可能出結果。非核心接口：最小值（ P99.9*1.5，用戶可接受的等待時間），非核心不影響訂單，不展示也沒關系。3.2限流

當系統(tǒng)遇到突發(fā)流量時，通過限流的方式，控制流量的訪問速度，避免系統(tǒng)崩潰或超時。

1）分析

看下超時時間點的請求量是否有突增，比如有某些突然的活動，這個時候應用沒有提前擴容，面對突增流量會導致應用負載比較高，從而導致超時問題。

2）優(yōu)化方案

評估當前應用最大可承載的流量，配置限流，維度可以是單機+集群。

單機限流：在面對突增流量時避免單機崩潰。

集群限流：在有限的資源下提供最大化的服務能力，保證系統(tǒng)穩(wěn)定性，不會出現(xiàn)崩潰或故障。

3.3 提升緩存命中率

提升緩存命中率，可以提高接口的響應速度，降低接口的響應時間，從而減少超時的發(fā)生。

1）分析

分析調用鏈路，找到慢的地方對其進行優(yōu)化，提升服務端的響應速度。

如下圖所示，很明顯可以看到服務端執(zhí)行時間超過了客戶端配置的超時時間 200ms 導致超時。

圖2 客戶端調用服務端超時鏈路

繼續(xù)分析服務端執(zhí)行鏈路，發(fā)現(xiàn)是因為緩存沒有命中導致的。

圖3 緩存未命中鏈路

2）優(yōu)化方案

對于高并發(fā)系統(tǒng)來說，常見的是使用緩存來提升性能。

如下圖是之前的緩存架構，這種緩存架構有兩個風險。

a. 緩存是固定過期的，會導致某個時間大量 key 失效直接擊穿到數(shù)據(jù)庫。

b. 主動刷新機制是刪除緩存，監(jiān)聽數(shù)據(jù)庫 binlog 消息刪除緩存，如果大批量刷數(shù)據(jù)會導致大量 key 失效。

圖4 固定過期+懶加載模式

針對上面的風險我們優(yōu)化了緩存架構，固定過期改為主動續(xù)期緩存，主動監(jiān)聽消息刷新緩存的方案，如下圖所示。

圖5 緩存前后架構對比

3）效果

緩存命中率提升到 98% 以上，接口性能（RT）提升 50%以上。

圖6 處理性能提升50%

這個緩存優(yōu)化方案在我們團隊之前寫的一篇文章《1分鐘售票8萬張！門票搶票背后的技術思考》中有詳細的介紹，具體細節(jié)這個地方不再展開，有興趣的同學可以自行閱讀。

3.4 優(yōu)化線程池

減少不合理的線程，降低線程切換帶來的超時。

1）分析

a. HTTP 線程數(shù)

先看下服務端 HTTP 線程數(shù)是否有明顯增加，且流量沒有增長，要確認 HTTP 線程數(shù)增加不是因為流量增長導致的。如下面兩張圖，流量正常的情況下 HTTP 線程數(shù)增加，說明是服務端響應變慢導致，可以確認超時是服務端原因。

圖7 服務流量平穩(wěn)

圖8 HTTP線程數(shù)突增

b. 總線程數(shù)

再看下總線程數(shù)是否有增加（排除 HTTP 線程數(shù)），如果有，說明有使用多線程導致線程數(shù)量增加。這個時候需要 Dump 下線程，看下哪些線程使用的比較多。

2）解決方案

a. 統(tǒng)一管理線程池：動態(tài)配置參數(shù)+監(jiān)控能力

通過工具類封裝統(tǒng)一的線程池，提供動態(tài)配置參數(shù)和線程池監(jiān)控能力。

效果

線程池具備監(jiān)控能力，如下圖是最小值（核心線程數(shù)）、最大值（最大線程數(shù)）和當前線程池中線程數(shù)量的監(jiān)控，可以參考這個來調整線程池參數(shù)。

圖9 線程池水位線監(jiān)控

b. 異步改同步：小于10ms 的不使用多線程

高并發(fā)的場景下線程太多，線程調度時間得不到保障，一次任務需要多個 CPU 時間片，下一次調度的時間無法得到保障。

如下圖是一個線程池執(zhí)行耗時埋點，通過埋點發(fā)現(xiàn) A 在線程池中執(zhí)行的比較快，平均線和 P95 都在 10ms 以下，沒有必要使用線程池，改成同步執(zhí)行。

圖10 優(yōu)化前執(zhí)行耗時

效果

接口性能提升明顯，平均線從 2.7ms 降低到 1.6ms，P99.9 從 23.7ms 降低到 1.7ms。

之前使用多線程，請求量有波動的時候線程增加比較多，導致線程調度時間得不到保障，體現(xiàn)到 P99.9 就很高。

圖11 優(yōu)化前后耗時對比

另外可以明顯看到總線程數(shù)也相應減少了很多。

圖12 異步改同步后總線程數(shù)減少

3.5 優(yōu)化 GC

優(yōu)化 GC，減少 GC 的停頓時間，提高接口的性能。

1 ）分析

首先看超時時間點是否有 Full GC，沒有再看下 Yong GC 是否有明顯的毛刺，如下圖可以看到 3 個明顯的毛刺。

圖13 Yong GC時間

如果超時的時間點（如下圖）可以對應上 GC 毛刺時間點，那可以確認問題是由于Yong GC 導致。

圖14 客戶端調用服務端超時次數(shù)

2）解決方案

a. 通用性 JVM 參數(shù)調優(yōu)

檢查 -Xmx -Xms 這兩個值設置的是否一樣，如果不一樣 JVM 在運行時會根據(jù)實際情況來動態(tài)調整堆大小，這個調整頻繁會有性能開銷，并且初始化堆較小的話，GC 次數(shù)會比較頻繁。

效果

-Xmx3296m -Xms1977m 改成 -Xmx3296m -Xms3296m 后效果如下圖所示，頻率和時間都有明顯的下降。

圖15 通用性JVM參數(shù)調優(yōu)后效果

b. G1 垃圾回收器參數(shù)調優(yōu)

背景：如果沒有設置新生代最大值和最小值或者只設置了最大值和最小值中的一個，那么 G1 將根據(jù)參數(shù) G1MaxNewSizePercent（默認值為60）和 G1NewSizePercent（默認值為5）占整個堆空間的比例來計算最大值和最小值，會動態(tài)平衡來分配新生代空間。

JVM剛啟動默認分配新生代空間是總堆的 5%，隨著流量的增加，新生代很容易就滿了，從而發(fā)生 Yong GC，下一次重新分配更多新生代空間，直到從默認的 5% 動態(tài)擴容和合適的初始值。這種配置在發(fā)布接入流量或者大流量涌入時容易發(fā)生頻繁的 Yong GC。

針對這類問題，優(yōu)化方案是調大 G1NewSizePercent，調大初始值，讓 GC 更加平穩(wěn)。這個值需要根據(jù)業(yè)務場景參考GC日志中Eden初始大小分布來設置，太大可能會導致 Full GC 問題。

以查詢引擎為例，根據(jù) GC 日志分析，新生代大小占堆比例在 35% 后相對平穩(wěn)，設置的參數(shù)為：

-XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=35

效果

優(yōu)化后效果如下圖，可以看到優(yōu)化之后 GC 次數(shù)從 27次/min 降低到 11次/min，GC 時間從 560ms 降低到 250ms。

圖16 G1參數(shù)調優(yōu)后效果

3.6 線程異步改成 NIO 異步編程

NIO（非阻塞 IO）可以減少線程數(shù)量，提高線程的利用率，從而降低線程切換帶來的超時。

1）分析：CPU 指標

分析 CPU 相關指標，如果出現(xiàn) CPU 利用率正常，CPU Load 高需要重點關注（如果是CPU 利用率高的情況，說明 CPU 本身就很繁忙，那 CPU Load 高也比較正常）。

在分析之前，先介紹幾個概念：

a. CPU時間片

CPU 將時間分成若干個時間片，每個時間片分配給一個線程使用。當一個時間片用完后，CPU 會停止當前線程的執(zhí)行，進行上下文切換到下一個任務，以此類推。

這樣可以讓多個任務在同一時間內并發(fā)執(zhí)行，提高系統(tǒng)的效率和響應速度。

下圖模擬了單核 CPU 執(zhí)行的過程，需要注意的進行上下文切換是需要開銷的，但實際一次上下文切換需要的時間很短（一般是微秒級別）。

圖17 CPU執(zhí)行線程流程

b. CPU利用率

按時間片維度來理解，假設每次時間片都正好被使用完。

c. CPU Load

從上面概念分析，如果出現(xiàn) CPU 利用率正常，但是 CPU Load 高，那說明 CPU 空閑時間片、等待線程數(shù)很多，正在使用的時間片很少，這種情況要減少 CPU Load 需要減少等待線程數(shù)。

2）分析：實際案例

我們之前生產遇到過多次 CPU Load 高 CPU 利用率正常的情況。問題出現(xiàn)前后代碼沒有變動，比較明顯的變化是流量有上漲。排查代碼發(fā)現(xiàn)有使用線程池并發(fā)調用接口的地方，調用方式如下圖。

圖18 線程池執(zhí)行模型

這種方式在流量較低的情況下看不出什么問題，流量變高會導致需要的線程數(shù)量成倍增加。

例如：一次請求 A 需要調用 BCD 3個接口，那100個并發(fā)需要的線程數(shù)就是100 + 3*100=400（第一個100是A對應的主線程，后面的3*100是 BCD 需要的100個線程）。

3）解決方案

線程池并發(fā)調用改成 NIO 異步調用，如下圖所示。

和之前對比，100 個并發(fā)，需要的線程數(shù)也是 100（這個地方不考慮 NIO 本身的線程，這個是全局的，并且是相對固定很少的線程數(shù)）。

圖19 NIO異步調用執(zhí)行模型

4）效果

超時問題沒再出現(xiàn)，CPU Load 平均下降50%，之前 Load 經常超過2（CPU 核數(shù)為2），改造之后 Load 降到 0.5 左右。

圖20 CPU Load優(yōu)化后效果

3.7 啟動階段預熱

啟動階段預熱可以提前建立鏈接，減少流量接入時的鏈接建立，從而降低超時的發(fā)生。

1）分析

應用拉入后出現(xiàn)大量超時，并且 CPU Load 高 CPU 利用率正常，說明有很多等待線程，這種是拉入后有大量請求在等待被處理。

之前我們生產遇到過是在等待 Redis 建立鏈接，建鏈的過程是同步的，應用剛拉入請求量瞬間涌入就會導致大量請求在等待 Redis 建鏈完成。

2）解決方案

啟動階段預熱提前建立鏈接，或者是配置 Redis 的最小空閑連接數(shù)。其他資源準備也可以通過啟動階段預熱完成，比如 DB 鏈接、本地緩存加載等。

3.8 優(yōu)化 JIT

JIT（Just-In-Time）編譯可以提高程序的運行效率，灰度接入流量將字節(jié)碼編譯成本地機器碼，避免對接口性能的影響。

1）JIT 介紹

JIT 是 Just-In-Time 的縮寫，意為即時編譯。JIT 是一種在程序運行時將字節(jié)碼編譯為本地機器碼的技術，可以提高程序的執(zhí)行效率。

在 Java 中，程序首先被編譯為字節(jié)碼，然后由 JVM 解釋執(zhí)行。但是，解釋執(zhí)行的效率較低，因為每次執(zhí)行都需要解釋一遍字節(jié)碼。為了提高程序的執(zhí)行效率，JIT 技術被引入到 Java 中。JIT 會在程序運行時，將頻繁執(zhí)行的代碼塊編譯為本地機器碼，然后再執(zhí)行機器碼，這樣可以大大提高程序的執(zhí)行效率。

2）分析

JIT 技術可以根據(jù)程序的實際運行情況，動態(tài)地優(yōu)化代碼，使得程序的性能更好。但是JIT 編譯過程需要一定的時間，因此在程序剛開始運行時，可能會出現(xiàn)一些性能瓶頸。

如下圖應用拉入后 JIT 時間很久，那可以確認是 JIT 導致超時。

圖21 JIT執(zhí)行時間

3）解決方案

優(yōu)化 JIT 一個比較好的方案是開啟服務預熱（預熱功能攜程 RPC 框架是支持的）。

原理是讓應用拉入后不是立馬接入100% 流量，而是隨著時間移動來逐漸增加流量，最終接入100% 流量，這種會讓小部分流量將熱點代碼提前編譯好。

4）效果

開啟服務預熱后，如下圖所示，應用流量是逐漸增加的，可以看到響應時間隨著時間越來越低，這就達到了預熱的效果。

圖22 服務拉入后請求量和響應時間

3.9 換宿主機

當宿主機負載過高時，可以考慮更換宿主機，避免宿主機負載過高影響容器負載。