作者:京東物流 王江波
一、常態化壓測建設目的
為什么做常態化壓測?
目前面臨主要問題,性能問題滯后發現,給大促帶來不可控風險,目前日常需求頻繁迭代,系統配置的變更、上下游依賴的變化、服務器資源置換等諸多因素均會對系統性能產生一定影響;日常很難做到對所有新專案或需求上線前后都進行壓測,這就往往導致了很多性能問題推遲到大促壓測期間才被發現,
大促備戰壓測備戰時間緊、任務多,壓測備戰壓力較大, 在11.11復盤中,有些部門工時統計中,壓測占了較大一部分作業量,而且性能問題相較于其他問題,優化難度大、修復周期長,在大促備戰多專項并行資源緊張情況下,頻繁的系統調優給整個大促帶來不可控的風險因素,
基于此,引入常態化壓測的手段,通過每周或每月的定期壓測行為,持續把控系統性能表現,保證服務穩定性;同時將需求上線引起的性能問題前置暴露,及時定位優化問題;減輕備戰壓力,提升壓測效率,
二、常態化壓測實施流程
2.1 常態化壓測
常態化壓測是按照一定周期或特定觸發條件而進行的自動化壓測行為,通過在單容器/集群的周期性壓測,從而達到監控性能指標變動、及時發現服務性能衰減風險的目標,
2.2 實施策略
通過三步走的方式,由淺入深,逐步在平臺技術部落地常態化壓測:
第一步 單機試點: 由于初次使用常態化壓測,通過隔離單機環境的方式,了解了常態化壓測的壓測思路、執行流程、壓測平臺能力支持及風險點摸排;
第二步 集群試點:在履約、基礎平臺選擇星級核心服務, 在線上環境試點小集群(2-3臺)常態化壓測任務執行,從線上業務影響、上下游依賴影響、壓測平臺能力支持、線上壓測風險管控等多方面評估常態化壓測在線上集群落地的可行性;
第三步 全面展開: 根據履約、基礎平臺的線上常態化壓測集群實踐,推廣至全平臺技術部,并結合Kit壓測工具,建立核心服務性能資料看板,統計匯總壓測結果性能報表,使服務性能趨勢可視化展現;開通大促壓測綠色通道,常態化壓測達標的服務,大促壓測綠通,
2.3 實施流程
常態化壓測介面:優先選擇覆寫業務主流程的核心介面,ops-review的核心服務中星級認證的介面,
壓測模版任務選擇基準:
1)根據大促生產峰值流量模型結合服務器資源使用情況設定壓測模版任務;
2)梳理鏈路依賴介面呼叫,按照最差下游依賴的承載上限并結合自身介面性能從呼叫量的角度設立壓測模板;
3)對于沒有下游依賴的服務,按照系統自身最佳處理能力,從吞吐量或cpu角度設立壓測模版;
壓測頻率:鏈路長復雜介面,建議每天執行;自倍訓的系統推薦按照上線頻率執行,
壓測視窗期: 和產研確認業務低峰期間,指定常態化壓測任務的執行時間,
壓測環境: 生產環境單機或者小集群進行常態化壓測,
壓測資料: 建議使用R2錄制線上的真實流量作為常態化壓測的入參,保證壓測結果的有效性,
壓測結果: 每次壓測結果測驗同學值班跟進,對不達標的介面,行云bug持續跟蹤,協同研發進行性能分析、問題排查、壓測任務維護,
壓測工具:forcebot常態化壓測及R2
三、常態化計劃
?2023-Q1在履約、基礎進行常態化壓測驗點,形成最佳實踐,并進行技術賦能分享,
?2023-Q2季度推廣至平臺技術部-配運和交易條線,618大促前平臺技術部完成核心0級讀服務125個基于jdos3.0的常態化壓測建設,
四、基于流量錄制的高保真壓測
雙十一大促剛過,在大促備戰時很重要的一個環節是對各大核心服務系統進行壓測,以保證系統在大促期間的穩定性,同時根據壓測結果為大促擴容提供資料支持,那么如何進行高保真壓測,使壓測結果更接近于線上真實性能表現?在整個壓測程序中,壓測資料的準備是其中非常重要的環節,很大程度上決定了壓測結果是否真實可靠;
隨著業務的不斷發展,不僅用戶流量、業務場景越來越復雜,服務的呼叫關系和模塊也越來越繁多,資料構造越來越困難,簡單的資料集無法模擬線上真實的業務流量,流量配比不真實容易導致壓測結果失真,
目前各大公司進行模塊級壓測或者全鏈路壓測基本都是采用流量錄制的方式,先對錄制的流量進行存盤,然后對流量進行編輯、過濾后通過壓測引擎向被測服務發壓;本章結合Forcebot壓測平臺,詳細介紹如何使用R2平臺錄制線上流量進行高保真壓測,
4.1 流量錄制壓測
利用R2平臺錄制線上流量進行壓測的基本框架圖如下所示:
1、用戶訪問線上服務,產生基于用戶的真實流量;
2、測驗人員在泰山平臺R2工具管理端創建錄制任務,任務啟動時下發操作指令到ducc,再通過ducc下發錄制指令到線上服務端(線上服務已經開啟pfinder并接入R2平臺),開始錄制線上流量;
3、錄制的流量會上報至R2工具端,并且將采用資料進行存盤;
4、流量錄制完成后,可以在Forcebot壓測工具平臺創建壓測腳本,Forcebot平臺已經和R2平臺對接,請求R2服務端獲取回放流量地址,進行錄制流量裝載;
5、Forcebot平臺獲取到流量后,即可以正常通過壓力機向被測服務發壓,執行壓測任務,
4.2 錄制壓測流量
根據系統架構及壓測場景分析,選擇需要錄制流量的介面及場景,
?若壓測時僅考慮單個介面,那么錄制單個介面流量即可;
?而有的應用是多個核心介面,需要混合場景壓測,在錄制流量時需要同時對多個介面流量進行錄制;
?當然,你也可以在錄制任務中設定僅錄制請求或回應符合某種特定業務場景的流量;
① 創建壓測流量錄制任務:選擇入口應用,設定錄制任務的名稱及檔案大小,注意:一般在進行壓測流量錄制時,建議錄制所有場景流量,盡可能地高保真生產實際流量;在創建錄制任務時,建議錄制檔案大小不高于2G;
流量錄制策略包含了手動錄制、定時錄制及周期性錄制,在進行常態化壓測時,為了避免流量過于老舊與當前生產流量偏差較大,可以在R2平臺上創建一個周期錄制流量的任務,按天或按周錄制一遍生產流量,以保證壓測資料的即時性,
② 選擇要錄制的起始服務,可以選擇多個介面同時錄制,平臺會展示出介面呼叫鏈路,可以針對呼叫鏈路上的服務或中間件等同時開啟錄制,然后選擇錄制的實體,設定后任務之后就可以開始執行錄制,
流量錄制完成后,即可在forcebot壓測平臺創建壓測腳本;
4.3 壓測腳本創建
4.3.1 單介面壓測腳本
在腳本管理中創建一個JSF回放腳本,編輯錄制資訊配置,選擇要壓測的應用、對應的R2錄制流量任務,Forcebot支持在京東私服平臺上搜索或者手動上傳JSF檔案(jar包),平臺會自動然后決議jar包中的類和方法,呼叫jsfOpenApi獲取介面別名和直連的ipPort,通過以上方式獲取介面服務相關資訊,快速搭建jsf介面的環境,選擇要壓測的介面、jsf別名以及壓測的方法后自動會生成壓測腳本;生成的腳本中默認關聯了選擇的R2錄制任務中的錄制請求,可以直接進行壓力測驗,
如下圖所示,你可以進行內網環境校驗,可以校驗腳本是否能正常獲取到流量并向對應介面發起了實際請求,這也是壓測前的必要步驟,驗證腳本通過之后進行保存,就自動生成了相應的腳本及lib檔案;如果是單介面場景壓測,到這里就可以使用該腳本去創建壓測任務了,
值得注意的是,這種方式生成的腳本是不可編輯的,需要編輯腳本得自定義創建腳本;到這里,聰明的你一定想到了,這里頁面僅能選擇一個介面的其中一個方法,如果想要對同一個介面的不同方法或不同介面進行混合壓測應該怎么辦呢?不要著急,答案已經在路上了,,
4.3.2 多介面混合壓測腳本
在實際生產中,我們的應用往往會提供多個介面,或者同一個介面上會提供不同的方法服務,我們在壓測的時候如果僅僅按照單個介面來進行壓測,這樣的壓測資料僅能反應單場景交易下系統本身的性能表現,而實際生產中,尤其是大促時,系統往往在同一時間需要處理多個介面請求,系統資源也是多個介面共享的,所以混合場景壓測更能反映系統真實處理能力;
在進行混合壓測前,需要首先明確各個介面場景在同一時間段內的呼叫量比例是多少,在創建壓測腳本的時候,需要根據這個比例來設定每個壓測場景下壓力請求占比rate;
步驟1: 生成標準的JSF回放腳本
在自定義腳本之前,先按照3.3.1所述生成一個標準的JSF回放腳本,以及依賴的lib檔案都會自動生成;
步驟2: 生成自定義腳本
在步驟1中生成的默認腳本是不可編輯的,可以查看代碼時生成自定義腳本,然后對自定義的腳本進行編輯,
① 首先定義介面路徑及其方法,對應不同介面的別名,然后是根據不同的介面進行流量加載;
其中ipList是指定被壓測的服務器ip及埠,如果介面別名下是集群部署,只想要對其中某一臺機器進行壓測的話,需要指定ip及埠;
② 針對不同的介面創建回放事務,此處介面路徑、介面的加載流量、介面別名等都需要一一對應,rate為該腳本中涉及的多個介面的呼叫量比例,比如介面1:介面2:介面3=7:8:5(可參考大促或日常呼叫峰值期間各介面的呼叫量比例),則需要在testCase中設定相應的壓力比,
③ 因為多介面涉及介面路徑、流量源以及介面別名各不相同,需要將默認的無參doReplay方法,修改為傳參方法
④ 腳本修改完成后點擊保存
⑤ 相同介面不同方法的混合壓測腳本創建同理,區別在于同一個介面,別名是一致的,不需要額外再指定其他介面別名;
步驟3: 匯入附件jtm.properties
在步驟2中自定義腳本編輯完成后,進行校驗執行時還無法成功,因為腳本還缺少流量錄制回放的附件檔案,保存腳本后,回傳上一級目錄,將步驟1中生成的標準groovy腳本中的附件jtm.properties下載到本地,然后再將該附件檔案上傳到我們自定義的腳本中,并修改腳本的附件檔案,在附件檔案末尾添加
jtm.replay.recent.record.num=1,指定每次壓測時都獲取系結周期性流量錄制任務最新錄制的流量;
4.4 雙十一大促高保真壓測實踐
有了R2流量錄制平臺提供的便捷,讓獲取線上流量不再成為難事,可以幫助我們快速的完成壓測資料的準備,同時壓測流量高保真還原實際業務場景,
在本次雙11大促,物流promise業務線全面采用R2流量錄制的方式進行大促壓測,自壓測結果更加接近線上介面性能,真實性達到90%以上;為大促資源擴容評估提供了更加精準的資料支撐,同時,通過這次高保真壓測,我們發現多個系統性能問題,其中包含極限業務場景下的可用率降低的問題,
下圖為采用R2流量錄制壓測、軍演壓測與雙十一大促開門紅的性能對比,
五、USF常態化壓測實踐
基于focebot的常態化壓測能力,選擇USF選擇3星核心服務進行常態化壓測實踐,選擇TOP4核心介面,使用R2的錄制線上流量,根據大促的流量模型進行的混合場景常態化壓測,持續監控USF的核心介面的性能情況,
forcbot常態化壓測工具支持,壓測任務復用(支持流量錄制壓測任務)、可配置性能基線包括回應時間TP99和TPS的和服務器CPU等資源指標設進行性能基線設定,并根據性能基線判斷壓測是否達標,以及可以設定不達標的壓測結果自動創建行云缺陷,進行性能問題跟蹤處理,并且還提供壓測監控對比資料以及壓測結果歷史記錄,便于對性能結果和問題進行分析,自動發送壓測郵件通知,及時同步性能壓測結果,
目前forcebot的常態化壓測支持以下功能:
?1、支持壓測任務的復用,可使用歷史的壓測任務,不用單獨創建壓測任務和腳本,支持jsf、http、自定義的jimdb、jmq以及回放腳本,
?2、可配置定時執行任務,靈活執行時間,
?3、可支持流量錄制,
?4、可自動創建行云缺陷
?5、可配置壓測的是否達標基線(生效:是否將指標用于壓測達標率統計;勾選會作為指標之一,不勾選則在達標率計算時不作為統計指標, 達標:勾線生效的指標值同時滿足時,壓測結果即為達標;反之,有任何一個指標值不滿足條件,壓測不達標,
以下為基于USF進行的常態化壓測,
5.1 壓測物料準備
壓測資料:
?選擇業務高峰期14:00-16:00 錄制線上10%對應6臺機器流量,錄制【公共集群】入參1G,(后續會考慮多個集群)
?錄制介面服務是USF3.0線上TOP4的介面,已完成星標治理,達到三星的介面,完成可用率、TP99、以及有降級和限流方案治理,
壓測場景: 混合場景設計(模型)
應用部署拓撲圖:
壓測環境:
壓測環境目前是與線上同配置的單實體的UAT環境,
?與線上的現資料庫、快取保持一致,均已同步線上資料,
?壓測環境資料庫的配置和快取服務的配置與線上保持一致,
1.線上機器配置 * 實體數60
2.應用服務器配置:4C8G
3.資料庫配置:16C64G記憶體
4.壓測機器配置
5.應用服務器配置:4C8G
6.資料庫配置:16C64G記憶體
5.2 壓測風險評估
?壓測環境選擇:
?1)先在同配置的UAT環境常態化壓測,根據性能結果不斷調整性能基線
?2)穩定后再復用生產環境的應用和中間件進行常態化壓測,
?任務執行視窗:
?選擇業務低峰期進行壓測,結合ump監控USF服務的高峰期一般在白天的上午6-9、9-11、14-17系統使用的高峰期,所以目前任務執行的視窗期是作業日17:40,目前是有人值守的報警資訊及時處理,監控應用和資料庫相關情況,
?壓測鏈路同步:
?壓測上下游鏈路梳理,確定壓測范圍、壓測量級、壓測時間,同步相關方達成共識,
5.3 常態化壓測任務創建
5.3.1 壓測模版任務選擇準則
?復用歷史的壓測任務(模版任務),直接創建常態化壓測任務,實際選用歷史的壓測任務場景時,建議根據系統的實際情況來選擇,一般可以選擇性能拐點場景或者壓到預期值的場景(如CPU60%或者TPS達標),一般建議不要壓測系統資源飽和的狀態場景,
?示例:此處USF我們選用歷史的壓測任務,是介面滿足雙十一的吞吐TPS的場景,此時服務器的CPU壓力在27%,資料庫的CPU在36%,
模版任務選擇:
查看任務,可以看到該場景下的執行的腳本,發壓相關設定并發執行緒數、執行的模式(并發模式和RPS模式)、執行時間,可根據需要進行一定的調整,
5.3.2 壓測定時任務設定
?可以通過周期或者Cron運算式指定執行周期,usf此處使用Cron :0 40 17 * * ? 每天下午5點40執行,并在此處設定目標執行緒數和執行時長,(這個會覆寫壓測任務中的執行緒數和執行時長),
?常態化壓測執行的頻率以及執行的時間參考根據代碼上線周期和業務的呼叫低峰時間段綜合定制,
1)執行模式-RPS模式
系結的是壓測任務是RPS,那么我們創建的常態化壓測任務也是RPS模式,目標QPS設定,并非腳本中所有介面的QPS的和,而是腳本中占比最大的介面對應的壓測目標值,如果配置錯誤會導致過度發壓,
2) 執行模式-并發數模式
系結的壓測任務是并發模式,那么我們創建的常態化壓測任務是并發執行模式,目標執行緒數設定,
5.3.3 壓測基線設定
?根據壓測任務對應的壓測場景,根據事務名稱(介面方法)設定合理的壓測基線,如果關聯的壓測任務是混合腳本,那么可以分步驟設定多個介面事務(事務名稱默認:forcebot.測驗方法名 )的性能基線, 一般關注的指標平均TPS、TP99、錯誤數、CPU監控,允許波動的范圍,根據介面的實際情況給一定的波動空間,若大于設定的波動范圍,并且選中設定提交行云缺陷,就會自動提交行云bug,便于bug跟蹤倍訓,
?基線指標設定注意點:如果基線值特別低的情況,那允許的波動范圍百分比需要設定的比較大才可以,否則很小的波動都會被認為壓測不通過,基線波動范圍,具體介面具體分析,研發和測驗達成共識,
1) 自定義性能基線設定
?USF的findUserInfo服務設定示例:
?TPS基準值=2700,允許波動范圍10%,(2430-2970) 上下浮動
?TP99基礎值=12ms,允許波動范圍50%,(12ms-18ms) 上浮動,時間相關的是向上浮動,
?錯誤數基準值=0,允許波動范圍0,
?CPU監控基線值=25%,允許波動范圍=20%,(20%~30%)上下 浮動
事務名稱: 目前無法自動識別,可以寫腳本的中事務名稱默認是forcebot.測驗方法名,也可以增強腳本使用自定義事務名稱就是
TestUtils.transactionBegin("findUserInfo"),即findUserInfo
性能基線設定例如:介面性能tp99在12ms左右,此時基線值設定為12ms,允許波動的范圍如果設定為10%,那允許的波動范圍就是12ms*10% = 13.2ms,超過13.2ms就認為壓測不通過,這顯然是不合理的,此時需要根據我們的介面tp99最大接受范圍來設定允許波動百分比,
2) 多介面性能基線設定
自定義基線設定中,可以添加多個介面事務,該事務就是腳本中的事務名稱,
默認事務名稱:forcebot.測驗方法名
自定義事務名稱: 如TestUtils.transactionBegin("findUserInfoByOrgCode");
5.3.4 行云缺陷跟蹤
對于不滿足性能基線設定各項指標值,常態化壓測結果就為不達標,若該任務配置開啟了自動創建行云缺陷,就會對不達標的執行結果自動提交行云缺陷,這樣可以保證bug生命周期各階段可追溯,保證問題及時處理解決,
5.3.5 監控定位問題
可以查看一段時間該服務的性能趨勢,如果介面性能波動較大,需要進一步排查介面性能下降的原因,
1) 監控資料-TPS
2) 監控資料-TP99
3) 執行記錄對比詳情PK
執行記錄中,有腳本版本和,是否達標以及bug詳情,選中達標和不達標的結果,進行PK對比,對比項中有TPS、TP99、Error Per Second等指標,
USF相關介面的壓測結果,達標和不達標的PK如下:發現是12-04存在一次錯誤呼叫,進一步跟蹤錯誤產生原因
5.3.6 郵件發送壓測結果
設定接收人郵箱,將郵件抄送給研發和測驗相關人,壓測結果郵件中會提供壓測資料匯總顯示,如果壓測結果中某一項指標不達標時(超出設定值及波動范圍)時,則此次任務視為不達標,結合監控資訊以及執行時間段的日志與研發共同定位問題或者是性能基線指標的調整,
郵件如下:
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/551615.html
標籤:其他
上一篇:阿里測驗經驗7年,從功能測驗到自動化測驗,我整理的超全學習指南
下一篇:返回列表
