作者：京東物流 王江波
一、常態化壓測建設目的
爲什麼做常態化壓測？
目前面臨主要問題，性能問題滯後發現，給大促帶來不可控風險。目前日常需求頻繁迭代，系統配置的變更、上下游依賴的變化、服務器資源置換等諸多因素均會對系統性能產生一定影響；日常很難做到對所有新項目或需求上線前後都進行壓測，這就往往導致了很多性能問題推遲到大促壓測期間才被發現。
大促備戰壓測備戰時間緊、任務多，壓測備戰壓力較大， 在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 郵件發送壓測結果
設置接收人郵箱，將郵件抄送給研發和測試相關人，壓測結果郵件中會提供壓測數據彙總顯示，如果壓測結果中某一項指標不達標時（超出設定值及波動範圍）時，則此次任務視爲不達標。結合監控信息以及執行時間段的日誌與研發共同定位問題或者是性能基線指標的調整。
郵件如下：
