全鏈路壓測的核心流程

核心流程

全鏈路壓測實施的核心流程如下：

步驟一：確定壓測目標

壓測目標主要包括壓測范圍、策略、目的，往往與業務、技術目標息息相關。例如：

壓測范圍：用戶注冊加登錄，為大規模拉新做准備。
壓測策略：高仿真生產環境壓測，提前經歷真實的業務高峰。
壓測目的：探測業務吞吐極限，驗證架構能力、探測性能瓶頸。

步驟二：梳理系統架構

梳理清楚端到端的請求鏈路、技術架構、分層結構、模塊划分，以及RPC、消息、緩存、數據庫等中間件的使用情況，分析潛在的瓶頸點，並針對性的增加監控指標、制定應急預案。

本文示例的系統架構圖如下：


組件	分類	潛在的瓶頸、問題
SLB	負載均衡	容量不足建連失敗
ApiGateway	API網關	容量不足線程等待觸發限流
UserService	微服務	容量不足線程池資源耗盡日志資源耗盡觸發限流 GC
SecurityService	微服務	容量不足線程池資源耗盡日志資源耗盡觸發限流消費延遲 GC
Redis	KV緩存	容量不足觸發限流緩存擊穿緩存熱點連接池耗盡大對象
MySQL	數據庫	容量不足觸發限流連接池耗盡慢SQL
Kafka	消息隊列	容量不足消息堆積磁盤寫達到100%
SmsService	第三方依賴	第三方可能會拒絕參與壓測

步驟三：梳理業務模型

壓測的業務模型對壓測結果的准確性至關重要。全鏈路壓測的鏈路代表要壓測的業務范圍，同一條鏈路需要構造海量的參數集合代表不同用戶的不同行為，系統的基礎數據、系統預熱情況等代表系統的狀態。鏈路范圍、鏈路的訪問量級、鏈路的參數集合、基礎數據、預熱情況一起構成了壓測的業務模型。

通常從以下維度梳理業務模型：

用戶行為維度
- 確定業務接口的范圍、接口的目標量級、接口的參數集合、壓力曲線等。
- 根據業務特性確定壓測數據的分布。例如用戶的規模和地域、商品的種類和數量、是否制造熱點商家和商品等。
系統狀態維度
- 根據業務和場景的特性，確定各組件（例如緩存）的狀態。例如拉新場景，緩存命中率非常低，而日常高峰場景，緩存命中率非常高，需要根據不同的場景來准備不同的緩存預熱策略。
- 根據業務和場景的特性，確定基礎數據的量級和范圍。例如拉新場景，需要考慮老用戶召回的情況，而日常高峰場景，一般准備與活躍用戶相當量級的基礎數據。

總之，業務模型與業務強相關，壓測的業務模型對壓測結果的准確性至關重要。

步驟四：准備壓測腳本

根據業務場景編寫壓測腳本，也可以直接復用已有腳本，建議將腳本錄入PTS場景，便於做場景調試。

步驟五：改造升級環境

在生產環境進行全鏈路壓測，最核心的是線上寫操作不能污染正常的業務數據。因此，需要針對存儲做影子庫表，即正常業務庫表的鏡像，讓壓測流量的數據流轉到影子庫表，正常業務流量流轉到正常業務庫表，在邏輯上隔離兩種流量，使之互不影響。

生產環境壓測的三大前提：

壓測標記不丟失
壓測流量在任何環節能夠被正確的識別出來。在流量入口層帶上壓測標，中間件識別並繼續往下傳遞壓測標，保證整條鏈路上壓測標不丟失，通過這種方式使得下游的應用和存儲也能接收到壓測標。
壓測流程不中斷
壓測流量能夠正常的調用下去，整個流程不被阻斷，返回符合預期的業務結果。業務的應用層，要支持全鏈路也需要進行對應的改造。應用層在識別到壓測標時，需要繞過參數校驗、安全校驗等校驗邏輯，例如手機號格式校驗、用戶狀態校驗、以及一些其它特殊業務校驗邏輯。
壓測數據不污染
壓測數據不對線上正常的業務造成數據污染。全鏈路場景往往包含多個讀寫場景，為了隔離壓測數據，存儲中間件識別到壓測標之后，將數據寫入影子庫表，與真實的數據區分開。為了更加真實的模擬真實場景，影子庫表中的基礎數據（例如買家、賣家、商品、店鋪等）是由真實數據加上固定偏移量構造而成，遷移過程中會進行采樣、過濾、脫敏等操作保證數據安全，一般在數據量級上和真實數據保持一致。

PTS探針已經具備以上三大能力，僅需在應用上部署好探針、配置好規則即可，無需改動業務代碼。

本文示例的架構圖升級方案如下：

步驟六：正常流量聯調

通常通過執行功能回歸用例完成聯調，是需要將正常回歸流量打上流量標（例如在請求中添加Header x-pts-test=2），這樣在查找調用鏈路時可以精准定位。該環節主要關注點如下：

驗證探針對正常業務邏輯無影響，用例的測試結果均符合預期。
驗證探針對依賴組件的適配情況，無遺漏的RPC調用、采集的數據准確無誤；調用鏈完整性是全鏈路壓測數據安全的核心。
將探針采集的調用鏈數據進行聚合（建議500+以上），抹平不同參數、不同邏輯分支帶來的調用鏈差異性。使用聚合后的依賴拓撲圖輔助梳理組件依賴可以極大程度的避免組件遺漏。
根據正常流量聯調的結果，需要梳理出影子庫表的范圍、第三方服務的依賴情況。

步驟七：准備壓測數據

注意壓測數據准備存在很高的風險，請與DBA、相關人員聯系，確保相關數據庫、中間件的容量、性能、資源足以支撐壓測數據的遷移、存儲，以及后續的壓測計划。

確認影子庫表范圍。
影子庫表的范圍就是壓測鏈路涉及到的應用使用到的庫表。在梳理過程中，需要包括庫名、表名、數據量級、核心業務字段（例如商品ID、用戶ID等），表與表之間字段的關聯性（外鍵、JSON字段中的引用等均包括在內）。

確認偏移字段、脫敏字段。

偏移字段：字段偏移可以極大的保證業務數據的安全。偏移字段一般選擇用戶ID、商品ID等關聯字段，如果有用到Sequence類的分布式ID組件，也需要進行偏移。根據業務的實際增長選擇不同的偏移量，一般會選擇10年以上都不會用到的值作為偏移量。

具體的偏移量需要根據業務增長和數據類型確定，常見的偏移方式如下：


字段類型	偏移量	示例值
Long/Sequence/分布式ID	900000000000000000	1021 -> 900000000000001021
手機號	90000000000	13888888888 -> 93888888888

說明脫敏字段：業務上認為是敏感數據的用戶數據，例如手機號、密碼、用戶名等，不同安全級別的字段會有不同的脫敏方式，根據業務要求脫敏即可。常見的脫敏方式包括遮蓋掩碼、加鹽哈希、高斯噪音等。需要確保脫敏之后的字段值在業務流程上是能走通的，如果在壓測聯調過程中出現校驗失敗，可以使用Mock規則繞過校驗。

新建影子庫表。

說明該步驟一般由DBA完成，根據影子庫表范圍創建庫表結構。
執行數據遷移。

說明該步驟一般由DBA完成，遷移工具一般選擇DataX，在業務低峰時段從備庫遷移到影子庫表，建議根據實際情況配置限流。遷移的數據量一般與線上數據保持數據量級上一致即可。
准備接口參數數據。

基於基礎數據和壓測模型構造業務接口的參數集合。根據各壓測平台的不同，支持的格式、配置方式也各有不同，一般都支持CSV文件格式，根據各平台要求構造即可。

壓測業務模型對壓測結果的准確性至關重要，而壓測數據准備是業務模型落地的核心環節。壓測數據主要包括基礎數據和鏈路數據兩種。

基礎數據：包括業務運行所需的庫表和數據，例如：買家、賣家、商品、優惠等，基礎數據的規模一般需要與實際業務數據在量級上保持一致。
鏈路數據：包括需要壓測的接口和多樣化的接口參數集合，接口請求的參數集合是基於基礎數據生成的。例如：商品詳情頁的接口為https://xxx.com/item?itemId=xxx，參數集合為具體的商品ID的集合。

基礎數據的准備方式通常有直接構造和數據遷移兩種：

直接構造：直接根據業務規則構造出來，一般用在少量數據的准備，例如聯調階段的數據構造。
數據遷移：對線上數據做清洗、采樣、偏移后遷移到影子庫表，數據完備性好，仿真度高，省時省力。建議使用DataX進行數據遷移。

數據准備環節，最核心的原則是需要保證鏡像、影子庫表的軟硬件配置與正常庫表一致，同時配置簡單易行。這樣可以保證在壓測的時候充分暴露線上的數據庫表的真實問題。

選擇數據隔離策略有以下方式：

影子表隔離：在生產庫建立業務表同結構的影子表，影子表名通常會在正常表名的基礎上加上固定的前后綴。表級別的隔離在設計上允許復用一部分只讀表，但是梳理難度有所增加。
影子庫隔離：在用一個實例上創建與源數據庫同配置的影子庫，影子庫名通常會在正常庫名的基礎上加上固定的前后綴，表名保持不變。庫級別的隔離是數據源的隔離，隔離相對比較徹底、安全。
影子Key隔離：一般用在KV緩存、存儲組件上（例如Redis），探針會攔截對KV緩存、存儲組件的所有操作，根據流量標自動修改Key和過期時間，達到隔離數據和數據清理的目的。

其他存儲組件的隔離原理基本上與上述三種思路上一致，您可以根據自身業務和架構特性，自行選擇最佳的隔離方式。

步驟八：聯調壓測流量

根據步驟七：准備壓測數據中梳理的庫表情況，在控制台填寫影子規則，不同規則需要填寫的字段不盡相同。
根據步驟六：正常流量聯調中梳理的第三方服務依賴情況在控制台配置Mock規則。如果需要使用復雜的動態響應結果，需要申請部署MockServer。

與正常流量聯調的方式基本一致，聯調過程中需要將壓測流量打上流量標（例如在請求中添加Header x-pts-test=1），在查找調用鏈時可以精准定位。該環節主要關注點如下：

驗證業務邏輯是否正常，用例的測試結果均需符合預期。此環節受基礎數據影響比較大，容易出現某個字段不符合某些校驗邏輯而導致業務進行不下去。
驗證壓測流量產生的調用鏈是否與正常流量一致，如果不一致需要相關人員介入排查原因。
驗證影子隔離和Mock規則是否有效，如果有正式表存在測試數據寫入或者影子表有正常數據寫入，則需要相關人員介入排查原因。

步驟九：單鏈路小流量試壓

開始全鏈路壓測。不同的業務、壓測目標往往對應不同的壓測節奏和方法，不可一概而論。除了注意以下要點之外，還需根據業務、架構、人員等自身情況，制定不同的壓測計划，在盡量避免線上故障的前提下，發現更多的線上問題。

制定明確的壓測計划、壓測通過標准，相關人員必須現場支持，分工明確，統一指揮。
線上壓測應在業務低峰時段進行，並制定應急預案。
應當具備監控大盤，密切關注相關監控指標。
遵循循序漸進的原則，單鏈路壓測>小流量驗收>全鏈路驗收。

對生產環境進行小流量試壓，暴露最表層的問題，保證流程的正確性。

步驟十：單鏈路壓測

驗證所有接口在無干擾、無競爭的情況下的性能基線數據，確定所有接口的性能SLA。

步驟十一：全鏈路小流量試壓

對生產環境進行小流量試壓，暴露最表層的問題，保證流程的正確性。

步驟十二：全鏈路壓測並驗收

按生產環境流量配比進行復合場景全鏈路壓測。探測相互干擾、競爭情況下的資源消耗水位和瓶頸。大致上分為以下5個階段：

階梯加壓與容量規划。
定位性能瓶頸；拿到各應用的性能基線數據與容量，獲取限流閾值。
瞬時加壓。
驗證系統預熱是否合理，比如數據庫連接、RPC連接、業務緩存、JIT預編譯等。
穩定性測試。
驗證系統資源使用是否合理，是否存在內存泄漏等情況。
故障演練。
通過人工注入故障，暴露架構的穩定性問題，提升系統的健壯性。
驗證限流、降級、預案的有效性，產出最終的交付物。