高德全鏈路壓測——精準控壓的建設實踐

作為國民級出行生活服務平臺，高德服務的穩定性不論是平時還是節假日都是至關重要的，服務穩定性一旦出問題，可能影響千萬級甚至上億使用者。春節、十一等節假日激增的使用者使用量，給高德整體服務的穩定性帶來了不小的挑戰。每年在大型節假日前我們都會做整體服務的全鏈路壓測。透過常態化全鏈路壓測專案的推進，已具備了月度級別的常態化全鏈路壓測能力，把戰前演練提到日常，持續推進穩定性保障建設。

TestPG壓測平臺2018年9月啟動，在2019年春節第一次支撐高德全鏈路壓測任務，當時前後花了近2周的時間才完成3個機房的壓測任務。後來成立了常態化全鏈路壓測專案，透過對流程的最佳化以及壓測平臺技術能力的升級，現在已經具備了1天內完成全國3個機房全鏈路壓測的能力。大型節假日的全鏈路壓測週期縮短到了3天。

全鏈路壓測的常態化不僅對高德整體服務的穩定性建設起到了推動作用，而且也推動了流程上的最佳化以及壓測平臺在技術能力上的改進提升。具體而言，我們主要從壓測前的語料準備和壓測過程中的壓力調控兩個方面入手，透過語料平臺化生產，規範語料生成流程，對語料生產提效；透過壓測過程中對發壓能力的精準調控，使我們能夠靈活調整壓力模型，從而使其更加接近於線上真實情況，讓全鏈路壓測過程平滑流暢，效率提升。本文會重點介紹TestPG壓測平臺在發壓能力精準調控方面的建設實踐。

高德全鏈路壓測涉及到接入層的上百個介面，每個壓測介面的壓測流量需要在鏈路梳理階段由運維和相關同學事先預估給定。壓測前會在壓測場景裡對每個介面的流量進行分配，透過流量佔比事先配置好，這是我們全鏈路壓測的壓力模型。壓測啟動之後，會逐步加壓，直到整體壓測流量到達預估值，在整個過程中，可能會對事先配置的壓力模型不斷做出調整，最終使壓測流量模型符合預期的線上流量模型。

高德全鏈路壓測涉及的鏈路比較長，壓測流量流經接入層，服務層最終到達引擎層，有可能出現實際到達引擎的流量與預估流量之間存在差異。這時候會先停止壓測，更新壓測場景裡的介面壓測流量佔比配置，然後再啟動壓測。

在高峰期，壓測叢集中可能有百十臺施壓機同時施壓，停止壓測，更改壓測場景裡的介面流量佔比配置，再啟動壓測，然後再一次逐步加壓，這樣一整套流程會非常耗時而且效率低下，有時只為了更新一兩個介面的流量佔比配置，不得不把前面的步驟再走一次，導致過多耗費時間精力。不斷起停也使整個過程不連貫，無端拉長了全鏈路壓測週期。

再者，在全鏈路壓測過程中，整體壓力是逐步增加的，多輪加壓，每一輪加壓後都會監控服務的各項指標來決定是否進一步增加壓力。TestPG壓測平臺採用分散式叢集施壓模式，增壓是透過往壓測叢集裡排程新的施壓機實現的，這樣帶來的問題就是，增加壓測流量的時候，需要相關人員根據壓測時候的單機施壓能力大致估算出需要增加多少機器。由於增減的壓力=單機施壓能力*n臺施壓機，這樣的壓力調控粒度也是比較粗糙的。比如要加壓1w qps，單機的施壓能力是3k qps, 那麼需要增加3臺或4臺施壓機，那麼實際增加的壓力為9k或者1.2w。

最後，也是最重要的，高德業務系統對介面特徵引數（對服務的功能/效能有重大影響的介面引數）尤為敏感，比如長短距離導航對後臺服務的算力和資源消耗都是不同，這就提出了更高的要求，我們需要有能力在全鏈路壓測中對介面的壓力調控精確到特徵引數級別。

簡單總結一下，在壓測過程中，針對壓力調控，我們面臨兩個主要問題，一是壓力調控效率低下，二是無法做到細粒度的精準調控。

全鏈路壓測是以真實流量提前對系統進行驗證。只有以接近於線上真實流量的壓力模型對系統進行壓測，才更能發現可能隱藏的穩定性問題，壓測才能更有價值。由於我們的壓力模型是預估給出的，難免會與實際服務預期的流量存在差異。所以壓測過程中透過對差異流量做調整，最終使壓測流量模型符合預期的線上流量模型。

既然現階段壓測過程中，壓力調整在所難免，並且由於其效率低下，已經影響到了全鏈路壓測的順利進行，那麼就可以以此為抓手，在壓力調控能力上做技術改進。首先是解決壓力調整效率低下問題，保障全鏈路壓測的流暢進行，提升效率。然後結合語料智慧化專案，實現精準壓測，使壓測流量（壓力模型+壓測場景）更加接近於線上真實流量。未來可以進一步探索，提供豐富的壓力模型以更好地支撐場景化壓測的訴求。

接下來會介紹TestPG壓測平臺，在施壓能力精準調控建設上的技術方案和落地成果。

上圖是壓力調控系統的一個抽象示意圖。

壓力調控中心是壓力調控系統的大腦。其主要作用是根據壓力調控策略向壓測叢集中的施壓機下發壓力調控指令，並且能夠根據調控反饋資料，決定進一步的調控策略。

壓測叢集作為壓力調控物件，接收壓力調控中心下發的調控指令，並實施具體的壓力調控動作。

壓測叢集與壓力調控中心之間存在一個反饋渠道，這樣壓力調控中心就可以知道調控的效果，並根據反饋資料，對下一步的調控進行決策。

以上是TestPG壓測平臺精準控壓建設的一個落地架構示意圖。

API Gateway模組承接使用者壓力調控指令，並把壓力調控指令轉發到Stress Contoller(壓力調控中心)。

Stress Controller是壓力調控的大腦，會根據壓力調控策略向壓測叢集中的施壓機下發調控指令，並根據反饋資料，決定下一步調控策略。

TestPG基於Redis實現了動態配置快取。壓力調控指令透過動態配置快取下發到壓測叢集，更具體來說是下發到壓測叢集中的每臺施壓機上，目前TestPG採用兩種方式實現動態配置的下發，分別是施壓機主動拉取和透過釋出訂閱模式進行實時推送。

壓力調控指令下達到施壓機後，壓測引擎執行例項會載入壓力調控配置，實時調整壓力。

每個壓測引擎都會實時上報自己到壓測指標（比如qps, rt等）和施壓機的效能指標（比如cpu佔用率，load率等）到TSDB時序資料庫，TSDB建立了壓測叢集和壓力調控中心之間的反饋渠道。Stress Controller定期查詢TSDB，獲取每臺施壓機以及整個壓測叢集的壓測指標作為反饋資料，根據這些反饋資料判定單機壓力調控成功與否，整個壓測叢集壓力調控成功與否，並且會根據反饋資料決策是否進行進一步的調控。

基於以上架構，TestPG壓測平臺在精準控壓建設上，已實現了叢集和介面兩個級別的精準調控。

透過叢集壓力精準調控，在壓測過程中，可以隨時指定要壓的預期qps，如果是下調壓力，平臺會非常快的把壓測叢集的輸出流量，壓到指定的預期qps。如果是上調壓力，當前壓測叢集中的施壓機整體輸出壓力上調後不能達到預期的qps，系統會從施壓機公共資源池調配一定數量的施壓機進入壓測叢集，確保在服務容量以內，壓測流量能夠上調到預期qps。透過這個功能，壓測過程中增減壓力，我們不再需要人工根據單機施壓能力估算要增減多少施壓機，整個壓力調控過程完全是由系統自動進行的。叢集的整體壓力也實現了精準調控，達到平臺在壓力輸出能力上指哪打哪能力。

介面級別的壓力調控，目前平臺已經落地了介面流量佔比動態調整能力，壓測過程中可以隨時對介面差異流量做調整，實現了在不停壓測的情況下對介面流量佔比的即時調整能力。該功能對保障全鏈路壓測的順利進行起到了關鍵作用，讓我們可以方便高效地對壓力模型做調整，使全鏈路壓測得以平滑順利進行，提升了全鏈路壓測參與各方的幸福感。

今年十一全鏈路壓測，由於業務增長較快，導致壓力預估模型與實際預期有較大出入，透過介面比例動態調整功能，在不停壓測的情況下我們對壓力模型進行了近百次調整，保證了全鏈路壓測的流暢度，保障了全鏈路壓測的順利進行。

針對於介面特徵引數級別的精準調控，我們的解決方案是：透過語料智慧化生產，對介面特徵引數提取和統計，可以把壓測介面按特徵引數分佈拆分為多個，結合介面調壓能力，最終在介面級別壓力調控上，可以進一步實現介面特徵引數級別的更精細調控，這對於高德業務系統的全鏈路壓測來說是非常重要，可以使我們實施更加精準的壓測。

透過發壓能力精準調控的建設，目前TestPG壓測平臺具備了叢集和介面兩個級別的高效精準壓力調控能力。提升了全鏈路壓測效率，有效縮短了全鏈路壓測的週期，在全鏈路壓測過程中可以使我們方便高效地對壓力模型做調整，使其更加接近於線上真實情況。

全鏈路壓測的目的在於驗證服務穩定性保障措施是否符合預期，提前發現服務穩定性問題。壓測的真實性至關重要，這裡的真實性是指壓測的語料資料與線上使用者場景相符合，壓力模型也要與線上相符合。目前我們的壓力模型是透過計算和預估的方式給出的，往往與線上壓力模型存在出入；而壓測資料雖然是基於線上流量生產的，但與春節、十一當天的場景還是有差異的。

在真實性保障上，目前TestPG壓測平臺也已經有了相應的解決方案，那就是語料智慧化生產加上精準控壓。未來，我們期望透過語料智慧化專案的推進，藉助機器學習等手段，透過對壓力模型，以及使用者場景的預測，並結合精準控壓技術，讓全鏈路壓測的壓測流量模型更加接近於春節、十一等節假日線上真實情況，實現真正意義上的精準壓測。

精準控壓技術，賦予了平臺對壓力的精準調控能力，解決了全鏈路壓測過程中，壓力調控效率低下問題，保障了全鏈路壓測的順暢度；並且透過對壓力模型的方便高效調整，也使得全鏈路壓測的壓力模型更加符合線上真實情況。但是精準控壓技術的用武之地不應該侷限於此。

未來我們可以在壓測型別上做進一步探索。目前從TestPG壓測平臺的使用情況大致來看，日常壓測上大家並沒有有意識的區分壓測型別。絕大多少情況下大家都是以固定qps持續對系統施壓。但是，線上系統面臨的真實流量有時候並不是固定，有可能出現極限尖峰脈衝等情況。平時系統如果沒有壓測過這種極限場景，那麼線上系統遇到這種異常流量時就有可能被打掛。