穩定性建設系列 -- 全鏈路壓測

一、前言

隨着哈囉用戶體量的不斷增大，業務場景越發複雜化，尤其在目前已變成羣衆出行必不可少的基礎設施的背景下，如何識別線上系統瓶頸、風險，保證系統的高可用已經變得尤爲重要，讓技術更好的服務業務，創造更多的價值。        

聊到全鏈路壓測，對很多同學來說更關注它的技術實現細節，這沒錯。但全鏈路壓測想要成功的在生產環境實施、落地，其實也需要很好的組織和流程機制。本文也會着重從技術細節和流程機制兩個方面來給大家介紹如何通過生產全鏈路壓測來識別系統風險，保證高可用的。

二、關於全鏈路壓測

爲什麼要在生產實施

首先，如果在線下做全鏈路壓測，我們需要部署和維護一套線下的全鏈路系統，加上線下環境的不穩定性等特性，我們會疲於保證線下系統可用性上，投入成本極高；並且線下的服務器和存儲以及其他基礎設施資源規格和線上不一致，產出的壓測結果並一定能夠真正指導我們進行線上合理的容量預估和基準線設定的穩定性相關工作。

其次，很多同學可能都針對單接口、單鏈路或者單服務做壓測，不管是線上還是線下，我們會發現，其實等到線上全網流量真正起來之後還是會存在很多問題。由於線上流量和業務的複雜性，做這樣的壓測，我們會遺漏掉很多流量對系統的影響，最終得出的壓測接口也不能真正合理的指導維護線上系統的穩定性。

再有，我們的功能從一個月迭代一次到現在一週迭代一次，留給測試的時間越來越短。功能測試時間從之前的一週、兩週縮短到現在三四天、兩三天的時間，那性能測試就沒有辦法按時上線，很有可能會出現各種各樣的性能問題，這會直接影響到公司的品牌影響力。

總之，我們希望通過生產全鏈路壓測，使得生產系統有足夠的冗餘和合理的預案來應對線上的複雜度和不確定性。

全鏈壓測的作用

1、精準的容量評估和系統基準線設定；

2、端到端的全鏈路巡檢，主動發現線上問題和風險；

3、驗證相關預案的合理性和時效性。

何時需要全鏈路壓測

1、正常迭代測試完成，上線後出現各種系統故障；

2、對線上系統容量和資源預估只能根據 "重點服務、核心鏈路，資源多給點" 的經驗之談；

3、性能團隊在盡力完成相關的性能測試，但是線上還是會有相關的系統故障出現；

4、根據業務場景，比如 B 端業務可能全鏈路壓測的訴求不是很大，C 端業務的大概率是需要做全鏈路的壓測。

三、全鏈路壓測演進

3.1 荒蠻時期

參與人員：非功能測試、業務開發 (單人)、DBA

這個階段，主要針對核心開關鎖鏈路進行壓測，由於還沒有整個鏈路詳細的上下游依賴，以及業務影響，我們只能通過不斷壓測來調整用戶模型和流量模型，業務改造，來保證鏈路能夠壓通並達到目前壓力，在此過程中，事前準備到壓測值班，再到壓測問題定位和覆盤，都只單人蔘與，其他同學對壓測整個項目的進程以及本質並沒有很清楚，甚至是完全不知道。

3.2 動員時期

參與人員：非功能測試、業務開發 (多人)、中間件、DBA、大數據

在我們核心鏈路能夠正常進行壓測後，我們開始考慮和擴大壓測業務的範圍，使我們能夠真正的瞭解線上服務的容量、瓶頸以及風險。在這個階段，我們選取了佔網關前 95% 的流量，也動員了更多的業務開發參與其中，通過全鏈路壓測人讓更多的人提升風險意識。中間件同學的接入，讓我也開始開始考慮數據、日誌隔離的問題，不斷完善壓測的技術方案。

3.3 標準化時期

參與人員：非功能測試、技術風險、業務開發

通過以上兩個階段，全鏈路壓測在線上的實施流程已經全部跑通，這個時候我們更多的關注是如何讓全鏈路壓測變得更加規範和更加有效率，常規化，並且做出更加精準的線上容量預估和基準線的設定。我們增加了很多規範和機制，不斷的演習和完善，從以前的每次壓測（數據預埋、壓測、數據清理、覆盤）4 天的時間週期，縮減至 2 兩天，並且建立起每月 2 次全鏈路壓測（月中單獨全鏈路壓測，月底跟隨全業務線進行全鏈路壓測）的常規機制。

四、全鏈路壓測最佳實踐

下面我們通過 “技術細節” 和“流程機制細節”兩個方面來詳細展開講述全鏈路壓測在的落地歷程

4.1 技術細節

4.1.1 壓測拓撲視圖

整體：

某業務線：

4.1.2 壓測流量發起

從 2018 年開始，我們開始進行生產全鏈路壓測，出於之前並沒有太多在生產使用 jmeter 進行分佈式加壓的實操經驗，當時壓測流量主要是通過 Jmeter 發起，以手動執行腳本爲主。

從 2019 開始，通過線下對 Jmeter 工具的不斷使用和一些特性的掌握，性能測試同學逐步開始全部用 Jmeter 來進行生產全鏈路壓測，自研壓測平臺也在研發和調試中。

從 2021 開始，開始使用自研壓測平臺 pt-test 正式進行生產全鏈路壓測。

4.1.3 壓測流量構造

首先，我們來看下業務場景。如上圖，該業務線主要的業務有三個要素構成：運營區、用戶、車輛，所以我們主要需要構造的壓測流量就是壓測城市、壓測用戶、壓測車輛，下面我們來具體聊一下，這個三個數據是如何構造的。

壓測城市選定

選取一塊目前在業務上實際未使用的區域，劃定爲了運營區，並且按照產品模型，劃定了相應的站點、規範停車區、禁停區等，還原線上的運營實情。

壓測車輛

關於壓測車輛，我們本應該走車輛投放流程，造一批虛擬車輛，但是由於考慮到走正式投放流程，事件流較長，涉及到的業務部門的人較多，不易推進，而且會產生很多無用的壓測相關數據，故我們最後選擇直接操作儲存介質，將相關需要的壓測單車信息直接寫入到數據庫和 redis 中，造出一批虛擬壓測單車。

壓測用戶

壓測虛擬用戶和壓測虛擬車輛做法相同，也是通過直接操作儲存介質，來造一批虛擬用戶，通過對線上用戶的特徵分析，得出了用戶模型。我們的用戶有持卡類型，非持卡類型，開通免密未開通免密等，通過相關對用戶的騎行卡，免密簽約 token 等數據提前預埋，來還原線上各類用戶的佔比，儘量使我們的壓測用戶流量和真實流量靠近。

4.1.4 壓測流量過濾

業務改造 + 壓測用戶特徵識別

針對一些業務場景需要對壓測數據進行過濾，比如：投保，數據迴流、超時訂單結束等，我們前期通過識別壓測用戶標識，硬編碼來過濾壓測用戶流量和數據，不讓這些數據走到後面的業務邏輯中去。

中間件改造 + 壓測流量標透傳

爲了徹底消除壓測前業務開發和數倉信息不對等的情況發生，以及由於壓測數據流入數倉，導致數倉模型的數據準確性受到嚴重影響，以及兼容後續其他方需對壓測數據無感知的情況。故中間件針對壓測進行了升級，支持了壓測流量標識透傳，保證在壓測鏈路的每一環和每一個參與方在需要的時候都可以識別壓測流量。具體實現如下圖：

4.2 流程機制細節

4.2.1 明確壓測環節

正如前言部分提到的，想要將全鏈路壓測在生產上高效率、可控的執行，並且壓測常態化，我們除了關注壓測的一些技術實現外，我們還需要一個完善且可執行的流程機制，以及模板化的文檔。如下圖，這邊將整個壓測生命週期分成了壓測前、壓測開始、壓測結束，在各對應的節點也明確了操作流程規範和一些標準化、模板化文檔，使整個壓測過程落地變得執行可控和高效率。

4.2.2 明確參與人員職責

如下圖，在壓測的整個執行落地的各個環節，我們明確各位參與同學的職責，提升參與人員的專注度和壓測的效率、成功率。

4.2.3 常態化機制建立

在公司微服務架構的技術背景下，一個服務從開發、構建、測試、集成到部署再到升級，都變得更加靈活、敏捷了，以及可擴展性的提高等。但微服務架構並非銀彈，也存在很多缺點。比如，系統網絡拓撲的複雜度變高，會引起一系列的高可靠相關的問題和風險。如何提前發現這些問題和風險？這個也是我們一定要在生產進行全鏈路壓測的理由，建立起常態化的壓測機制。

目前公司爲大小發布周，故這邊按照每月兩次（月中單獨進行全鏈路壓測，月底跟隨全業務線進行壓測）的節奏進行常態化的生產壓測。來提前發現生產問題和風險，以及驗證線上預案。

五、未來

5.1 業務側

系統基準線設定

現在目前已經達成歷史峯值 2 倍壓力的目標，後續準備拉出一份，壓測目標下，各個接口的 tps 的，用於推進各接口基準線設定，給限流以及壓測終止的相關提供參考。

數據、指標隔離

目前壓測數據隔離方便我們還有很大欠缺，我們的相關壓測數據都落到了生產真實數據所在的儲存介質中，大量壓測數據的堆積，佔用了可用空間，影響了儲存介質的性能，同時針對某些數據我們不得不進行壓測後的清理，大大增加了壓測操作的生命週期，降低了壓測效率。後續會對影子表相關解決方案的落地進行推進。

業務指標這塊也還沒有進行隔離，壓測期間會影響會導致真實指標的波動，會造成我們指標波動的誤判，從而放過了當時由線上真實業務、流量引起的波動，給系統穩定性埋下隱患。後續準備推進針對壓測指標和非壓測指標進行重新配置。

5.2 平臺側

完善壓測模型。

我們現在的壓測流量模型的完善基本是靠每次的壓測問題中分析得出，沒有提前得出十分貼近線上流量的模型，這樣會導致我們有相關線上真實場景是覆蓋不到的，而且也有可能因流量模型和線上系統容量不一致導致此次壓測不能順利完成。我們目前也在與測試效能組探討，流量錄製接入壓測的可能性，通過流量錄製，錄製反映鏈路流量的熱力圖，將非壓測期間的熱力圖與壓測期間的熱力圖對比，得出沒有被壓測流量覆蓋的場景，通過調整壓測入參，使得壓測模型更加趨近生產。

壓測生命週期平臺化、自動化

這一塊主要期望壓測平臺在自動化方便更加完善，從壓測接口模型、壓力發起，到根因分析，再到壓測報告改進優化跟蹤等方面，做得更加的自動化和平臺化。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/tQMZ-X0p7N997TCoqGHdgg