大促準備（七）壓測

壓測分爲全鏈路壓測和單系統服務接口壓測兩種，對於全鏈路壓測要準備的事情和要改造的東西是特別多的，是一個相對龐大的系統工程，大體業務架構以下，能夠單獨列出一個系列來說，這裏只講單系統的服務接口壓測。

壓測能夠選擇的框架有多種，能夠根據系統所採用的代碼、熟悉程度等選擇一個，更好的方式是在開源的壓測框架之上開發一個壓測平臺，下降學習成本，方便統一管控。下面的流程是假設公司內部有統一的壓測平臺展開的。

1.壓測工單申請|壓測通知

壓測時會對應用服務器、db、消息中間件、緩存、下游系統等關聯繫統形成影響，於是須要和關聯方進行告知或者申請，同步信息，獲得確認後再開始

2.壓測數據準備

在前面的壓測改造和準備小節也提到過壓測數據的準備，根據業務的需求若是能夠mock的數據必定要保證mock的數據足夠的隨機同時要保證壓測數據和線上正式數據是隔離的；對於緩存數據須要可能還須要進行預熱；對於不能mock的數據要保證脫敏而且後續的操做不會感染用戶的真實數據；

3.壓測腳本聯調

在準備好數據後，須要對壓測腳本進行聯調，確保壓測腳本符合預期：
1）業務邏輯是否符合預期
2）總調用量是否符合預期
3）db調用量是否符合預期

4.壓測預案准備

壓測預案和高峯期的預案可能相同，也可能不一樣，好比壓測時的緩存命中率就是壓測專用的，爲了方便各類開關的推送，最好把壓測相關的預案配置到一個預案中，方案統一執行和管控

5.壓測限流準備

在進行壓測時，線上仍然是有正常的流量進來的，於是對於接口的限流配置要仔細規劃。能夠針對壓測流量進行單獨的限流，也能夠對全部的流量進行限流。若是是前者，能夠保證限流只做用於壓測流量，不會影響到線上業務；若是是後者當壓測流量比較大時就會影響到正常流量，可是能夠利用這個機會驗證下限流是否生效。兩種方式各有利弊，能夠根據本身的業務狀況進行取捨。

6.壓測服務器申請

壓力測試也是由服務器發出請求的，於是要根據本身的目標請求量申請足夠的壓測服務器，不然也沒法達標。

7.肯定合適的上量速度

大促活動的上量速度一般是很是迅速的，可能在幾秒中上升到平常的十幾倍或者幾十倍，可是在壓測的時候特別是第一輪壓測時候上量須要慢些，留出比較長的觀察時間，以進行驗證，當出現異常狀況時能夠快速定位問題和快速回滾。
當壓測達標後再次進行壓測時能夠比較快的上量，儘可能模仿真實的狀況。

8.數據記錄&覆盤

將壓測達標時系統的主要數據進行記錄：cpu、load、峯值、rt、error、內存、gc等。這些數據將會對後續的壓測及平常其餘系統接入進行容量評估十分有幫助。

覆盤主要是針對壓測中預料以外的事情進行回顧，分析產生的緣由以及以後如何避免，對產生的問題可能還要去修改腳本、預案、限流、代碼等內容。