全鏈路壓測資料彙總——業內大廠解決方案
最近忙於公司的全鏈路壓測平臺調研和技術規劃文件輸出工作,參考了全網能搜到的業內大廠的全鏈路壓測方案,這裡做個彙總,以及將個人認為可以落地的方案做一個關鍵點整理。
技術連結
滴滴全鏈路壓測解決之道
阿里巴巴的全鏈路壓測
阿里怎麼做雙11全鏈路壓測?
美團全鏈路壓測自動化實踐
全鏈路壓測平臺在美團中的實踐
餓了麼全鏈路壓測的探索與實踐
餓了麼全鏈路壓測平臺的實現與原理
有贊全鏈路壓測方案設計與實施詳解
京東全鏈路壓測系統(ForceBot)架構解密
羅輯思維在全鏈路壓測方面的實踐和工作筆記
大廠方案point整理
1、邏輯思維
定位:保障業務穩定性的核心基礎設施;
重要性:業務知名度高&技術團隊承受壓力大;
核心目標:服務可用性、穩定性、擴充套件性;
2、阿里巴巴
流程管理:有效的方案+充足的準備+靠譜穩定的平臺;
流量識別:壓測流量標記透傳落影子庫,同一API多次壓測,防止被攔截,同一IP,白名單機制;
系統改造:①.業務改造:流量識別、單一性問題、限流攔截、報表剔除、動態校驗;
資料準備:活動方案確定→業務模型評審→技術架構&壓測範圍&資料量級&資料形式;
①.業務模型資料:API&流量量級&配比&轉化漏斗→業務抽象模型(漏斗比例不變);
②.基礎資料構造:資料量級&真實性(買家&賣家、商戶&商品、價格);
系統預熱:快取準備、系統load準備;
登入準備:模擬登入場景長連結(使用者逐步登入),保護user服務;
壓測方式:0點脈衝、系統摸高、限流降級、破壞性驗證(容災恢復演練);
3、京東
場景:買家、賣家;
資料:歷史雙十一峰值流量作為基礎流量,動態增加併發壓力;
流量:日常流量、大促流量(主庫寫壓力大);
壓測引擎:jmeter/Ngrinder;
測試指令碼/資料:git/本地?
啟動模式:梯度遞增、脈衝、穩定水位驗證;
執行方式:立刻執行、定時執行;
測試場景:壓力源、虛擬使用者數、測試指令碼、執行方式、啟動模式;
壓力源:docker叢集、多組、無狀態(狀態檢查)、共享資源;
壓測資料:統一儲存(ES),合併計算(jmeter),grafana展示(需優化);
流量識別、風控放行;
4、有贊
流量模型:流量來自於買家側,正常水位-突刺-回落;
機器成本:核心鏈路按量擴容,賣家側服務按需擴容,錯峰;
核心鏈路:人多&鏈路複雜&梳理核心鏈路→彙總篩選→剔除→確認;
壓測策略:單機單鏈路基準→單機混合鏈路容量→全鏈路壓測(水位)→專項預案演練;
流量預估:監控統計-QPS、連線數、IOPS、RT、快取命中率、consumer group、topic;
datapool:基礎資料脫敏、指令碼/測試資料,統一提供儲存/下發/分割功能;
影子儲存:DB路由:①.同instance不同schema(風險大);②.不同instance同schema(安全性高,成本高);
Redis路由:①.key值加統一字首;②.Redis-client做路由;
ES路由:①.index統一加字首,提供統一ES client做資料訪問,由client做路由;
應用變更:微服務,統一隔離,流量標透傳儲存;
流量下發:資料檔案:按照場景區分(考慮漏斗模型-轉化);
壓測指令碼:①.不同場景的流量配比;②.每個場景按URL從上至下做轉化(gatling);
水位檢測:壓測過程中,①.實時採集各應用服務的資源使用情況+RT+TPS+成功率;②.流量干預,保護生產服務不受影響;
壓測實施:①.基礎中介軟體開發,路由策略,框架升級,壓測引擎選型開發除錯-基礎架構;
②.業務改造升級+線下驗證(功能驗證,手動點選,資料落影子庫)-功能測試;
③.業務改造升級+生產驗證(功能驗證,手動點選,資料落影子庫)-功能測試;
④.datapool準備:資料生成,指令碼檔案切割下發-業務開發&測試;
⑤.小流量下發驗證-測試域同學;
⑥.模擬真實場景壓測驗證-團隊協同;
壓測方式:流量遞增/爬坡(梯度增加,優化擴容);
鏈路梳理:非核心鏈路-去依賴解耦;
長期規劃:輪詢化:線時鏈路測試機器人,實時檢測;
常規化:減少人力成本投入;
日常化:儘可能少熬夜,白天完成;
圖形化:鏈路壓測規劃圖形化展示,與業務結合,一鍵完成資料準備工作;
5、美團
全鏈路壓測思路
系統總體設計
重要程度:系統穩定性建設中的核心重要位置,也是最有效的方案;
技術背景:驗證峰值流量下系統服務的伸縮性和穩定性;
驗證新上線功能的可用性、穩定性;
限流、降級、熔斷、告警燈故障演練;
線上服務容量評估
技術方案:獲取線上真實流量-流量錄製&流量回放;
快速建立壓測環境-環境/服務隔離、流量標透傳、靈活伸縮容;
支援多協議型別-http、tcp、webscoket、rpc、dubbo......
實時監控&過載保護;
必備功能:資料構造、壓測隔離、場景管理、動態調整、實時監控、壓測報告、分散式......
整體架構:web管理端:資料構造、環境準備、任務管理、場景管理、壓測動態調整、報表展示;
排程中心:壓測資源排程、任務分發、機器資源管理;
壓測引擎:流量構造、模擬;
監控元件:實施監控、壓測資料統計、聚合分析、展示;
鏈路梳理:工具化,提供自動構建壓測入口鏈路完整的依賴資訊,輔助提效手段;
擋板服務:配置化手段,完成外部依賴等相關介面的Mock配置,無需在業務程式碼中嵌入壓測判斷邏輯;
資料構造:流量複製、儲存、清洗、解析、組合展示、偏移脫敏處理;
鏈路追蹤:鏈路匹配分析定位
服務隔離:大促(業務低谷)&常規(機器隔離)
資料隔離:同庫不同表(影子表)-成本低,風險較高
機器管理:動態擴容、灰度升級、異常摘除
壓測引擎:jmeter&nGrinder&gatling
記憶體優化:記憶體管理&JVM引數
監控:秒級監控、實時展示、告警、服務保護
日誌:壓測日誌取樣、展示
服務治理:限流熔斷降級保護
注意事項:小步快跑,及時響應、專案推廣、開放生態、基礎資源&賦能;
6、餓了麼
用例管理:建立用例、檔案上傳、分類管理;
壓測執行:一鍵啟動,可指定執行緒數&預熱時間&測試周期和負載機,檔案切割分發,分散式執行;
監控資料:TPS、ART、Error%實時展示;
實時資料持久化-influxdb,設定過期時間;
冷資料持久化至MongoDB;
測試報告:用例執行完畢,自動生成測試報告;
叢集監控:壓測機使用狀態監控,作為共享資源,提示使用者可用的測試機;
安全保障:許可權管理&異常操作限制;
分散式壓測實現:二次開發;
異常干預:水位超限&服務保護&閾值告警&壓測觸發失敗(形成閉環);
influxdb輪詢:http請求輪詢頻次較高,需優化;
預配置:提前配置,時段保留,節省時間,提高效率;
服務保護
許可權分級:高峰期禁止直行;
壓測干預,隨時手動觸發禁止動作,kill所有壓測機上執行的壓測程序;
限流熔斷:根據錯誤率和告警閾值判斷,達到或超過自動熔斷;
兜底服務:系統不可用需要停止測試時,外部強制停止,過載保護;
以上內容,來自各大廠方案的彙總整理,僅供參考。。。
&n