電商大促，性能測試都在作什麼？

自從09年阿里開啓了雙十一活動，近幾年各大電商平臺的促銷活動如火如荼。電商大促期間劇增的流量，對電商平臺相關的軟件系統也帶來了更嚴峻的挑戰。

好比秒殺搶購活動要求高併發處理能力，核心業務流程要求更好的可用性以及穩定性，爲了大促須要精確的對線上服務擴容作容量規劃等等。

對於性能測試工程師來講，不管是前期的核心業務梳理、線上流量評估、場景建模，仍是測試實施階段的監控分析、調優驗證，乃至線上的容量規劃，每一個環節都須要作不少工做。

且這些工做都須要運維、開發、產品甚至BI團隊的協同配合，才能保質高效的完成。這篇博客，來聊聊電商大促期間，性能測試工程師都在作哪些事情。。。

PS：因爲某些緣由，這篇博客延期了將近一個月才發佈，不過即將爲雙十一作準備，到時候會更一篇更詳細的博客來講明具體的細節。。。

 

1、核心業務梳理

電商業務相對來講比較複雜，以我司來講，今年618是第一次大規模的進行促銷活動。因爲時間緊任務重，爲了保證在大促期間系統能穩定運行，須要梳理出核心的業務。以下圖：

 固然，這裏須要注意的的有兩個方面：

①、電商業務核心業務流程，在大促期間的流量相較於平常時間段，是相對較高的，且持續時間在一週到半個月不等。所以在業務梳理時，就該考慮到這部分的高可用和穩定性。

②、除了核心業務流程，還有大促時會有一些搶購秒殺抽獎等活動，這類型的業務通常具備短期內流量劇增，商品優惠券數量有限下的超賣現象，所以須要考慮高併發和超賣問題。

PS：在梳理核心業務流程時能夠遵循這三點來梳理：核心業務、高頻業務、基礎業務。

 

2、線上流量評估

只有精確合理的對線上的訪問流量進行監控評估，才能計算出較有參考意義的預期性能指標。以我司來講，全部的流量都來自於移動端APP，所以流量評估方式採用了以下方式：

一、聽雲監控

根據聽雲監控獲取各核心業務功能對應服務/接口的調用次數（rpm），獲取維度爲近一週平均rpm以及峯值rmp，而後以計算出的數據擴容3-10倍；

二、BI埋點監控

經過BI部門同事提供的埋點監控數據，獲得DAU、高峯時間段內的流量佔比，一樣，根據本次大促的力度，進行流量倍增；

三、往期活動峯值流量

像淘寶天貓，由於已經舉辦過屢次的相似活動，所以有較爲豐富的往期數據作參考。對於我司來講，第一次大力度的大促，只能經過高峯流量來進行倍增預估，而後作好隨時擴容的準備。

四、渠道引流轉化量

鑑於業務特性以及商務合做方面，有時候會有其餘合做渠道的引流。關於這點，基於我的認知以及和業務運營同事討論後，根據合做方提供的引流量及轉化率，能夠計算得出新增流量。

 

3、場景建模

經過上面的核心業務梳理結合流量評估，進行場景建模，這樣能夠在壓測前明確要作哪些準備工做。場景建模思路以下：

一、業務場景建模

什麼是業務場景？簡單來講就是什麼人（用戶）在何時（活動期間）作什麼事情（商品搜索、添加購物車、下單支付、搶券抽獎）。

業務場景建模的目的是儘量將不一樣的業務作拆分解耦，這樣能方便壓測的實施以及性能瓶頸的分析監控。

關於業務配比，首先要儘量排除非核心低頻業務，交易配比模型的創建，能夠參考以下幾點：

模型事項	說明
交易佔比	測試交易筆數佔總業務量的比例（可忽略佔比不多的交易數據）
選取思路	1.1選取交易量最高時間段；1.2每種交易進行單獨的數據統計
異常選擇	1.1若是交易比例相似，則按生產配比進行轉化； 1.2如比例差距大，則獨立統計
交易配比	單交易統計後，基於各交易的RT，結合併發用戶數，使總交易數達到交易佔比數

二、壓測場景建模

完成業務場景建模後，基於其進行壓測場景建模，這裏要考慮到採用的測試策略，固然，測試策略的制定須要結合系統架構（須要梳理清各服務間的依賴和調用關係）和業務特色來講。

好比抽獎搶券秒殺場景，就須要採用併發測試以及超賣驗證等測試策略。

考慮到業務配比的狀況，咱們還須要進行單接口的基準測試以及單機混合場景容量測試。

核心業務流程，其特性要求系統具有高可用和穩定性，那麼測試策略就須要採用高可用測試和穩定性測試。

三、數據場景建模

數據場景建模，不少時候每每被忽視，但實際上數據場景建模更加劇要。若是測試過程當中所採用的數據不完整不許確，那麼測試結果每每出現較大的誤差。關於測試所需數據，可參考以下幾點：

數據信息	說明
限制條件	用戶操做權限、數據引用次數、數據過時設定（次數、絕對時間）
數據量	實際生產環境的數據量爲多少，在性能測試環境如何等量代換
數據類型	基礎數據、熱點數據、緩存數據、特殊數據
數據特色	是否能夠複用、是否具備惟一性、自增、加密、拼接、轉義等
準備方式	copy真實環境數據、預埋鋪底數據、脫敏生成數據
隔離方案	如何避免測試數據的污染？影子庫？環境隔離？標記區分？

關於幾種數據類型的說明：

基礎數據：也能夠稱之爲鋪底數據，鋪底數據目的是讓性能測試環境與線上保持一致（至少數量級一致），再結合線上數據增加率（半年&一年的數據量級），確認預埋數據量級及預埋方式；

        涉及到壓測時須要校驗的數據，須要在鋪底的時候就要精細化的設計，包括數據大小，數量，分佈等。

熱點數據：須要瞭解被測接口的實現邏輯，確認如下信息：

　　　　 是否有熱點數據相關的操做：好比說全部用戶秒殺同一件商品；

　　　　 不一樣類型數據處理邏輯有差別時，需經過測試數據多樣化提升性能測試代碼覆蓋率；

緩存數據：要確認是否有緩存，緩存大小爲多少（排除大key，通常來講142W的key佔Redis一個G的內存）；

      　秒殺搶購相關數據，通常來講都是進行隊列處理，將該類型數據放入緩存中進行處理來應對高併發。

 

4、準備工做

準備工做在性能測試中，是最爲耗時以及麻煩的，不只須要各個團隊協同配合，還須要不斷驗證，以確保相關的準備事項不會對性能測試結果形成較大影響。

以我司的性能測試流程來講，準備階段的各事項以及對應責任人，以下圖：

在準備階段，性能測試童鞋（好比我），要儘量承擔起PM這一角色的職責，跨部門溝通，協調資源以及推進準備工做的快速落地，這樣才能在有限時間內完成準備事項，爲壓測預留足夠的時間。

 

5、壓測監控

完成了前面的幾項工做，就能夠進入壓測階段了，這一階段，能夠分爲兩部分，壓測+監控。

一、壓測

壓測工做主要有以下幾種情景，按照預先制定的測試策略執行便可（不排除臨時特殊狀況，這裏需靈活調整）。

①、單機單接口測試：該策略主要是爲了驗證單接口的性能基準，避免整個調用鏈路過程當中某個服務/接口成爲瓶頸；

②、單機多接口測試：相較於微服務架構的服務解耦，有時候某些服務間互相調用依賴的強關係可能會形成資源競爭等狀況，須要經過這種方式來排查驗證；

③、單機混合場景測試：這種測試方式的主要做用是獲得一個單機混合場景下的最優性能表現，爲服務擴容和線上容量規劃提供參考數據；

④、多節點測試：如今大多數的互聯網企業都採用的集羣/分佈式/微服務架構，在多節點部署時候，考慮到SLB的邊際遞減效應，須要進行多節點測試；

　　經過該種方式，來驗證負載均衡遞減比率，爲生產擴容提供精確的參考依據；

⑤、高可用測試：高可用主要驗證2點：服務異常/宕機是否能夠恢復以及恢復到正常水平所耗費的時間（越短越好）。

⑥、穩定性測試：前面提到了核心業務流程必須保證穩定性，穩定性測試通常根據系統特色和業務類型，分爲兩類：5d*12h、7d*24h。

　　通常來講，穩定性測試的執行時間，12h便可（固然，24h或者更長也能夠，根據具體狀況靈活調整）。

二、監控

性能測試過程當中，監控是很重要的一環，它能夠幫助咱們驗證測試的結果是否知足預期指標，以及協助咱們發現系統存在的問題。常見的監控指標以下：

那麼如何監控這些指標呢？

若是採用的雲服務器（好比阿里雲），如今國內的雲廠商都提供了監控大盤以及各類監控服務（好比阿里雲的APM、ARMS、AHAS）。

若是是自建服務機房，能夠藉助運維搭建的監控體系，好比全鏈路追蹤（pinpoint、cat、zipkin、skywalking），專業的監控工具好比Nmon、Zabbix等。

測試指標的監控，能夠搭建基於開源組件的Grafana+InfluxDB+Jmeter+Nmon2influxdb，或者ELK等監控體系。

限於篇幅，這裏就不一一贅述，感興趣的童鞋能夠自行搜索相關資料或參考我以前寫的關於監控部分的文章。

 

6、分析調優

一、性能分析

性能分析是一個複雜的話題，不一樣的系統架構設計、應用場景、業務邏輯、編程語言及採用的框架，都有必定的差別。抽象來講，有以下三種分析思路：

①、自上而下：即經過生成負載來觀察被測系統的性能表現，好比經過對TPS、RT等指標的監控，從請求發起端到OS端層層剖析，從而找到系統性能瓶頸。

②、自下而上：經過監控各硬件及操做系統相關指標（CPU、Memory、磁盤I/O、網絡）來分析性能瓶頸。

③、從局部到總體：即經過性能表象結合工做經驗作快速排除，肯定可能存在瓶頸的局部所在，快速修改驗證，避免大而全的全面分析帶來的耗時，提升效率。

二、性能調優

性能調優主要關注三個方面：下降響應時間、提升系統吞吐量、提升服務的可用性。

性能優化的目的是：在保持和下降系統99%RT的前提下，不斷提升系統吞吐量以及流量高峯時期的服務可用性。

性能調優建議遵循以下幾點原則：

①、Gustafson定律：系統優化某組件所得到的系統性能的改善程度，取決於該部件被使用的頻率，或所佔總執行時間的比例。

②、Amdahl定律：S=1/(1-a+a/n)

　　其中，a爲並行計算部分所佔比例，n爲並行處理結點個數。這樣，當1-a=0時，(沒有串行，只有並行)最大加速比s=n；

　　當a=0時（只有串行，沒有並行），最小加速比s=1；當n→∞時，極限加速比s→ 1/（1-a），這也就是加速比的上限。

③、最小可用原則：通常狀況下，系統的代碼量會隨着功能的增長而變多，健壯性有時候也須要經過編寫異常處理代碼來實現，異常考慮越全面，異常處理的代碼量就越大。

　　隨着代碼量的增大，引入BUG的機率也越大，系統也就越不健壯。從另外一個方面來講，異常流程處理代碼也要考慮健壯性的問題，這就造成了無限循環。

　　所以在系統設計和代碼編寫過程當中，要求：一個功能模塊如非必要，就不要；一段代碼如非必寫，則不寫。

固然，具體的調優要根據性能瓶頸的具體表現來分析調優，更多調優方法，可參考個人另外一篇文章：性能測試常見瓶頸分析及調優方法

 

7、容量規劃

性能測試的最終目的是保證線上服務的可用性，及時響應並知足業務需求。而容量規劃，是對線上服務在峯值流量衝擊下穩定運行的最佳保障。這裏提供以下幾種容量規劃時的思路：

一、單機混合容量

這裏的容量指的是在單臺服務器下，混合場景壓測的最優性能表現（而不是最高）。好比一臺4C8G的服務器，對核心業務場景進行按業務配比混合壓測，示例以下圖：

獲得單機最優容量數值，而後能夠經過增長被測系統的服務節點，來驗證容量是否隨着服務節點的增長而線性增加。

二、多節點SLB容量

以上面的示例圖來講，單機最優TPS≈450，而後經過增長服務節點數量，再次壓測，經過擴容後的壓測數值除以服務節點數量，而後和單機混合容量對比，就能夠獲得多節點SLB的遞減比率。

舉例：擴容後的壓測數值爲R，服務節點數量爲N，單機混合容量爲D，那麼多節點SLB的遞減比率計算公式爲：SLB%=(R/N)/D。

之前面的例子來講，單機混合容量爲450，服務節點擴展到2臺，獲得測試結果爲750，那麼SLB%=(750/2)/450≈83.33%。

以此類推，若是預期線上性能指標要求TPS≥5000，那麼經過計算，咱們能夠獲得線上服務節點最少須要擴容到14臺，才能知足須要。

PS：服務節點數量越多，那麼遞減效應越明顯，建議經過測試多個服務節點的遞減比率，來獲得一個區間數。

三、告警閾值

這裏的告警閾值，指的是運維同事對各個服務狀態及相關資源指標進行監控時，設定的提醒和告警閾值。

前面所說的單機混合容量的最優值，建議結合運維設定的閾值來綜合評估（好比運維告警設定的閾值是CPU使用率達到80%，那麼就以單機CPU80%耗用下的容量數值做爲計算基準）。

四、Buffer機

文章的開頭已經說過，系統不只要具備高可用和穩定性，還要具備容災機制。好比某個或某部分服務不可用，服務器宕機，須要預留的機器來隨時補上來。

本文所說的Buffer機，即做爲預留容災的機器。按照我我的的實踐經驗來講，以線上擴容機器數量的30%來做爲預留Buffer機，已經能知足絕大部分狀況（適合中小型團隊）。

固然，有些特殊場景（好比2019年春節聯歡晚會，百度承包的口令紅包場景），就須要綜合考慮更多的影響因素。

除了容量規劃，咱們還能夠經過服務降級、網關限流甚至熔斷等機制，來保證系統在峯值流量的衝擊下保持服務可用。

 

以上內容，即爲我本人在本次618大促期間，所作的一些工做，限於篇幅，有些內容沒法詳細描述，感興趣的童鞋，可關注我博客或者公衆號，有更多相關資料。。。