全鏈路壓測改造之全鏈自動化測試實踐

本期作者

李思佳

bilibili 資深測試開發工程師

2020 年加入 B 站，深度參與全鏈路壓測、多活、混沌工程等專項的建設和實踐。

深耕系統穩定性測試領域。

01 背景與意義

B 站直播營收送禮業務有着高寫、在跨晚和 S 賽等大型活動下流量陡增、數據實時性要求高等特性，傳統壓測對於寫場景爲了避免影響線上數據做了各種屏蔽和黑名單處理，有着無法逼近線上真實情況的問題，因此業務對全鏈路壓測有着較大的訴求，需要通過全鏈路壓測來系統性地評估服務容量，發現瓶頸和隱患。

對於該訴求，直播技術側結合公司的全鏈路壓測方案，對營收送禮業務進行了全鏈路壓測的服務改造。整個過程涉及到營收核心服務、底層中間件、壓測 sdk、壓測控制檯、施壓平臺等多處改造，鏈路長、配置多、影響的業務廣，對質量方面的要求非常高，測試面臨了比較大的挑戰。一方面，要保障全鏈路壓測安全可控，各個改造節點均需確保正確可靠，另一方面因底層改動帶來的上層業務測試迴歸量巨大，測試效率難以保證。基於以上痛點，我們設計了全鏈自動化的測試方案，並與項目一起實踐落地。接下來，我們來詳細介紹下該方案的設計，希望能對一些正在或即將進行全鏈路壓測建設的團隊在質量保障工作上帶來一些靈感和參考。

首先，我們先來介紹下業內普遍的全鏈路壓測方案以及 B 站採用的方案，再基於具體的改造點來看測試範圍。

1.1 行業內全鏈路壓測方案對比

方案一：流量混布, 存儲隔離, 線上施壓

• 對線上服務壓測，壓測前根據容量預估和壓測目標，對線上服務進行擴容和 cpu、mem 等相關配置的變更。

• 壓測產生的數據與線上真實數據做隔離，採用影子庫表的方式，防止污染線上真實存儲。

• 需構造壓測數據和壓測流量，通過壓測標記來區分流量屬性。

方案二：對數據本身做標記, 邏輯隔離，線上施壓

• 對線上服務施壓，與方案一的區別在於數據隔離上，不是通過影子庫表，而是在原表上增加標記，做邏輯隔離。

• 業務需要做適配工作來識別流量屬性。

方案三：鏡像環境 OR 線下壓測             

• 此方案在線下進行壓測，部署線下測試環境或鏡像環境。

• 線下環境穩定性不高，硬件資源和壓測數據線上線下差異大，壓測結果參考價值有限。

技術同學經過調研，基於當前業務的語言棧較統一、基礎組件較統一以及服務治理較完善等特點，選擇了方案一作爲 B 站的全鏈路壓測方案。

1.2 B 站全鏈路壓測方案介紹

B 站的全鏈路壓測方案在 B 站在全鏈路壓測上的實踐一文中有詳細介紹，簡單來說主要爲流量混部、線上壓測和存儲隔離三個部分：

• 流量混部

  • 與線上集羣資源共用，在深夜低峯時期進行線上壓測

  • 通過流量打標的方式對流量進行區分，壓測流量均帶有壓測標識，支持對 http 請求和 grpc 請求打標進行全鏈路壓測

  • 服務接入壓測 sdk，對壓測流量進行識別、攔截和處理

• 線上壓測

  • 通過公司的壓測平臺，進行壓測任務和場景設計、壓測數據構造以及壓測結果分析等，具體壓測平臺的設計及原理在 B 站壓測實踐一文中有詳細介紹。

• 存儲隔離

  • 我們採用存儲隔離的手段，對 db 創建影子表，redis 創建影子 key，mq 創建影子 topic，將壓測流量完全隔離

  • 搭建全鏈路壓測配置控制檯，管理壓測規則，主要涉及對已接入全鏈路壓測的服務的以下幾點配置：

△ 需要壓測的接口

△ 壓測接口依賴的下游接口的透傳 / 鏡像 / Mock 規則

△ 數據庫表的透傳 / 鏡像 / 寫丟棄規則

△ 緩存的透傳 / 鏡像規則

△ 消息隊列的透傳 / 攔截 / 鏡像規則

圖片

直播的全鏈路壓測架構圖如下，可以看到整體鏈路，由壓測平臺施壓，被壓測的服務接入壓測 sdk，獲取到由壓測規則控制檯下發的壓測配置信息，根據配置信息對接收到的壓測流量做處理，如配置了鏡像規則的數據表，壓測數據寫入影子表，對配置了鏡像規則的 redis, 壓測的緩存數據寫入影子 key 等等。

圖片

針對此鏈路上如此多的服務改造點（SQL 改造、redis 改造、databus 改造、job 改造、context 改造、go channel 改造、sync/pipeline 改造...），如何能又快又好又全面的測試覆蓋，是我們設計全鏈自動化測試方案的初衷，我們將其主要分爲三個階段。

第一階段，我們對各個新增節點分別做了測試保障，如 mirror sdk、壓測配置控制檯等，保正底層基礎能力的正確性。

第二階段，當基礎建設已完成，進入到了業務接入及全流程驗證階段。業務是不停迭代的，其中隨着基架的不斷演進，業務所涉及的服務也包含了部分歷史債，當此套框架真正接入業務後，我們往往在業務實際使用中會發現很多不適配的地方，包括框架設計不夠健壯或者業務的使用姿勢不規範等原因，需要修復或兼容。這個階段的測試也是最繁瑣、測試量最大、重複性很高的地方，爲此全鏈自動化測試全面應用於此階段，來提升效率及業務覆蓋度。

第三階段，主要應對於未來的拓展，隨着全鏈路壓測覆蓋的業務越來越多，當” 常態化 “的全鏈路壓測計劃提上日程，重複的工作和人力成本隨之增加。此時測試工具更需要平臺化及可視化，爲壓測前、壓測中、壓測後各個階段的重複工作提供有效的自動化支持。

接下來，我們詳細介紹在第一和第二階段中，測試方案的設計及應用。

註釋：

1. 壓測配置控制檯：全鏈路壓測配置中心，配置被測服務、被測接口、下游依賴接口、被測接口涉及到的緩存、數據庫、消息隊列。

2. mirror sdk：爲大倉提供的壓測控制 sdk，通過配置文件可以直接控制數據庫、緩存、消息隊列等組件對壓測流量進行處理。

1.3 全鏈自動化測試方案

我們主要遇到的測試難點如下：

1. 改造均爲核心業務，涉及改造的服務數多、接口數多，測試量大。

2. 改造非常底層，涉及 mysql、tidb、redis、databus 等中間件，業務邏輯分支多，傳統手動測試很難高效全面覆蓋。

3. 改造的服務涉及的依賴和配置多，中間任何節點的錯誤均可能導致在壓測實施時影響到線上，如配置遺漏可能導致數據寫到線上庫、sdk 故障可能導致壓測標失效等，需要在壓測前的進行 “掃雷”。

設計方向思考

• 廣度：藉助接口自動化測試平臺來保障業務的覆蓋度

• 效率：人工校驗轉爲工具自動校驗，自動化校驗業務邏輯

全鏈自動化方案設計主要包含以下三個部分：

• 鏈路分析

• 配置確認

• 自動化校驗

圖片

02 主要測試過程與實施

2.1 鏈路梳理分析

鏈路梳理是保障全鏈路壓測安全實施的前提，服務改造、壓測配置、自動化校驗等工作都強依賴鏈路梳理與分析，梳理工作非常繁瑣，使用傳統翻代碼的手段不僅低效，而且容易遺漏而引發安全事故。這裏我們主要採用動靜結合的方式來完成鏈路梳理工作。

工具：

1. trace 追蹤：全鏈路跟蹤系統，提供分佈式環境下服務調用鏈監控，還原請求調用關係。

2. 自動化代碼規範掃描與檢查工具 bilicontextcheck lint：檢查代碼中不規範使用 context 的地方以及是否有 context 傳遞中斷的場景。

靜態掃描：調用鏈中容易出現因 ctx 使用不規範導致調用鏈斷裂的情況，對此使用 bilicontextcheck lint 工具用來檢查業務代碼中 ctx 不規範的地方，確保調用鏈不會斷，壓測標識能完整傳遞。

鏈路追蹤：依賴鏈路追蹤工具可視化的返回服務鏈路的依賴關係，各節點對數據庫、緩存、消息隊列的調用信息等，以下是使用示例。

圖片

以上兩個階段，我們完成了大部分梳理工作，但由於業務實際代碼邏輯的實現過於複雜和多樣，爲了保證梳理工作更全面且不遺漏，我們最後加上人工 check 代碼的方式做補充，打通鏈路完整性梳理的 “最後一公里”。

2.2 壓測配置確認

通過對業務的鏈路分析，我們明確了具體的壓測範圍，業務的服務依賴關係，接着需要在壓測控制檯進行整個鏈路的壓測規則配置，涉及服務的接口配置、依賴接口配置、數據庫配置、緩存配置、消息隊列配置，根據實際業務場景配置透傳、鏡像、寫丟棄、Mock 等規則。

圖片

2.3 自動化校驗

測試覆蓋率和效率的提升，均離不開自動化測試，因此，測試改造工作也基本圍繞 "自動化" 來展開。在基架改造、業務服務改造、壓測配置、服務部署等工作都完成後，將進入測試驗證階段。本階段主要通過自動化的手段對業務進行正確性驗證，兩套流量均需包含以下內容的檢查：

• 接口返回校驗：response 結果需符合業務預期，輸入 / 輸出參數檢驗、格式校驗、容錯處理、安全檢驗等

• 接口存儲校驗：mysql、tidb、redis 的讀寫符合業務預期

• 業務異步流程校驗：確認壓測標識全鏈路透傳，壓測流量和正常流量在異步流程下 trace 均能正常關聯，比如送禮鏈路的異步結算流程，在送禮接口調用完成後，可通過訂單 id 查詢結算表數據來驗證結算是否異步調用成功

• 鏈路完備性校驗：結合壓測控制檯規則，對接口的調用鏈路進行自動校驗

自動化實施的關鍵 key

• 自動化 case 需支持切換環境，支持正常流量和壓測流量兩套流量的構造、識別和檢測

• 數據流能自動化檢驗，保證調用鏈路各節點符合預期，包括下游接口調用、數據庫、緩存、消息隊列等節點

要實現以上功能，我們需要對已有的自動化框架進行改造，保持原自動化 case 能複用的基礎上，增加壓測流量構造、鏈路完備性檢測等功能，以下是我們團隊自動化框架的分層設計圖，紅色部分爲本次的框架改造點。

圖片

自動化框架分層設計：

通過上圖，可以看到我們的自動化測試框架分爲三層結構設計，最上層爲 case 層，按業務做單接口用例和場景用例的編排，中間層爲 invoker 層，做請求封裝 (http&grpc)、配置管理、斷言、中間件連接等基礎功能封裝和聚合，最底層 coverage 層包含 grpc 和 php 服務測試覆蓋率統計功能，本次改造在原有測試框架上進行，對框架的核心改造如下：

• 增加壓測標識 “mirror”，通過全局變量 config.mirror 控制流量入口，設計壓測標識的從上到下透傳。

• 在 invoker 層封裝鏈路檢測工具集 “trace_toolset”，進行鏈路完備性檢查。

• 在 invoker 層封裝 http/grpc 請求，request header 中增加壓測標識 mirror。

自動化框架改造 — 入口改造：

使框架能支持壓測流量的構造，在流量構造層使用全局變量控制流量入口，能一鍵切換流量指向正常環境還是全鏈路壓測環境。
改造點：在配置文件 config 中增加壓測標識：config.mirror，默認值爲空（若值爲空則識別爲正常流量）。

圖片

自動化框架改造 — 壓測數據構造

壓測寫場景，往往涉及到要對壓測的上游數據進行構造，如送禮場景，需要壓測用戶的錢包有餘額，壓測前需要在相關的影子表插入數據，這類型 case 屬於壓測前的數據準備工作，需識別並進行構造。

自動化框架改造 — 自動化鏈路完備性校驗

鏈路完備：需要確保調用鏈路完整且染色標不能中斷，保障方案分靜態收斂和動態收斂兩種策略，基於業務驗證佔據 80%+ 工作量，此驗證過程必須儘可能的自動化，爲此我們引入鏈路檢測工具集 “trace_toolset”，自動進行鏈路完備性檢查。

圖片

trace_toolset

基於接口鏈路的唯一標識 traceid，從鏈路追蹤工具中獲取鏈路的各個節點，結合壓測規則配置控制檯的配置，依次檢查調用鏈中的 mysql、tidb、redis、databus 的調用是否符合預期，分別對正常流量和壓測流量兩套規則進行檢測，對於校驗結果回傳至上層 case，輸出測試報告，以下是鏈路檢查工具與自動化框架結合下的調用流程。

圖片

自動化 case 改造複用

基於服務改造範圍大、涉及的接口多、鏈路長的特性，怎麼提升測試效率以及迴歸效率（底層 bugfix 迴歸）是需要解決的一大難題，本次方案主要採用 case 複用的思路來解決效率問題，複用已有業務沉澱的自動化 case，在此基礎上，保持 case 中間部分業務結構不變，通過 mirror 識別，僅修改頭部流量入口和尾部規則校驗方法，讓 case 能複用於壓測流量，快速將 case 翻倍。

圖片

03 案例實踐

3.1 業務場景和服務依賴梳理

梳理壓測接口的服務依賴大盤，以下是某場景的服務依賴關係圖，通過服務依賴關係確認哪些服務需要接入壓測：

圖片

根據深度遍歷：定位到某個服務依賴其他服務的接口，對鏈路上的每個接口以及接口涉及的 db、redis、databus 做確認。

圖片

3.2 服務壓測配置

基於梳理出來的鏈路關係在壓測配置控制檯進行配置，需根據實際業務場景配置透傳、鏡像、丟棄等規則。

3.3 業務自動化測試

• 正常流量自動化業務驗證

• 壓測流量自動化業務驗證

• 業務邏輯、存儲、trace 完備性檢查

3.4 問題排查與修復

對於運行失敗的自動化 case 進行排查與修復，測試過程中主要可以發現以下 4 類問題：業務涉及的服務代碼問題、配置問題、sdk & 壓測控制檯問題、基架問題等。

3.5  預發驗證，灰度部署上線

制定上線流程、進行風險評估和應急預案准備，實時監控上線過程， 確保業務安全無損上線。

圖片

3.6 線上全鏈路壓測執行，壓測結果分析

業務進行線上全鏈路壓測，通過壓測平臺進行施壓，發現潛在的業務風險。

3.7 全鏈路瓶頸分析與優化

對全鏈路壓測過程中發現的異常點逐個進行排查與分析，探索系統瓶頸和隱患，確保業務服務的穩定性。

圖片

未完待續

對於全鏈自動化測試方案的第三階段，面對未來可能出現的由業務” 常態化 “全鏈路壓測帶來的人力成本高、重複工作多等問題，我們的測試工具也在持續建設以貫穿整個壓測生命週期，第三階段的方案在後面的實踐中我們再來爲大家深度分享。

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