我們都知道業務發展有可能是非常快速的，系統爆發性增長的時候，是會很開心，但也會遇到很多的挑戰和問題。比如數據庫崩了，比如緩存被擊穿了，比如服務器cpu已經滿負載了，比如網卡被打穿了。
這時候很多沒實戰經驗的所謂的架構師和鍵盤俠會跳出來說：這有什麼？擴容就好了呀。但是很遺憾，實際情況中很多場景下擴容並解決不了問題，或者說我們完全不知道應該針對哪些組件進行擴容。
所以我們不能聽鍵盤俠的，測試研發同學對於系統水位還是得有非常清晰的評估，以及對於即將到來的爆發性增長有着胸有成竹的信心。基於這個，我們今天聊聊系統容量評估以及系統壓測這個事情什麼時候應該做，應該怎麼做，成本在哪裏，會有什麼收益。
希望你們都能在遇到真正的爆發增長的時候，能夠像題圖一樣，睡個安穩覺。要是你面對業務爆發性增長心理完全沒有任何壓力，那你可以關閉這篇文章了。可能你的層次已經超過這篇文章的受衆，也可能，你完全沒有意識到可能會有什麼問題，就等着出問題背鍋就好了。
什麼叫壓測呢？就是我們不知道功夫和尚是不是頭鐵，頭究竟有多鐵。我們先搞10塊磚頭一起砸下去。咦居然沒事。那我們再搞20塊磚頭一起砸下去看看有沒有事。看看和尚啥時候被砸暈。慢慢施壓，這就是壓測。
壓測什麼時候應該做
壓測是一件不便宜的事情，費人費時間費錢。所以我們應該在做壓測之前要評估一下，我們爲什麼要做壓測，爲什麼要在現在做，要什麼樣的範圍內做。沒有針對壓測清晰認識和評估的時候，先不要搞壓測這個事情了。
一般來說，我們會選擇在 大促這種爆發性流量前，或者在業務已經規劃好要開始擴展之前 ，根據不同的範圍，完成一到三輪的壓測。
壓測之前要界定範圍，本次是針對單模塊單接口的壓測，還是針對單系統的壓測，還是針對單業務鏈路的壓測，還是針對複雜業務的全鏈路壓測。每個範圍需要付出的成本基本都是指數級增長的，所以一定要考慮清楚，究竟是需要什麼範圍的壓測。
即使是需要全鏈路壓測，也會提前針對更低一級壓測的容量的評估以及壓測，因爲如果低一級都不能壓測通過，高一級很可能也是一開始就拉稀，浪費時間。
壓測應該怎麼做
壓測也算是一個工程問題，可以分爲以下五個階段，我一個一個講。
1、壓測方案評估。
當前系統的負載是怎樣的？
qps(每秒查詢數) 是多少，基礎數據量是多少？
預估的目標qps和基礎數據量分別是多少？
我們有多少接口需要壓測？涉及哪些團隊？
目標接口是否具有可壓測性？
以怎樣的方案進行壓測？是http接口還是rpc接口還是消息隊列？
使用什麼工具進行壓測？(比如jmeter)
怎麼觀察目標系統？(比如kibana看板或者collectd + InfluxDB + Grafana)
最終產出完整的壓測方案，與關聯的同學一起評估整個方案，不要只跟兄弟團隊說啊我們要壓測，手上沒方案就不要說話了。
2、壓測系統改造。
怎麼識別壓測流量？(一般使用 OpenTracing 框架進行全鏈路壓測標記傳遞)
壓測數據怎麼與線上數據隔離？（根據流量標記，引流到單獨庫或引流到同結構的影子表）
壓測是否可重複跑？（壓測一般需要重複執行，所以要把系統改造成可重複執行）
是否需要針對壓測流量進行特殊邏輯改造？（比如不發消息隊列，比如關閉緩存）
3、壓測數據準備。
針對所有準備的接口以及評估的數據量集，進行接口請求數據響應數據，以及基礎數據量的準備。接口參數比較好理解，基礎數據量怎麼理解？比如現有客戶10萬，目標是200萬用戶，那我們就需要在我們的目標查詢庫裏，按照正常的流程創建出200萬個用戶，以達到基礎量已經有200萬的規模。這樣系統和數據庫纔會有比較可靠的表現。
4、壓測試運行。
方案做好了，系統改好了，數據也準備好了。嘗試小量級先嚐試一下下，看看整個壓測的請求、鏈路、結果是否符合預期。
5、壓測記錄及覆盤。
全部準備好就可以使用各種工具進行壓測了，一般會根據目標系統容量進行均勻或者快速的步進，這個自己把握。比較重要的是在每個步進的時候都要等到系統表現比較穩定的時候對系統狀態進行記錄，並評估是否要繼續對系統進行施壓。如果系統負載已經比較高了，但是並沒有發生錯誤，可以嘗試持續觀察一下。在壓測完成後，對壓測結果進行評估和驗收，確定是否符合預期。並對整個壓測過程遇到的問題進行記錄，對下一次的壓測進行指導。
壓測的成本在哪裏
比較清晰的成本有這麼三個。
1、人力，至少需要佔用一個開發一個測試的全部時間。
2、時間，這個過程系統不可以進行大改造，大改造壓測等於白壓。
3、機器，施壓機器以及目標機器都需要佔用一大段時間。
壓測會有什麼收益
1、心裏踏實，在預估範圍內，基本不會出什麼大問題。
2、針對系統所需要的資源有更清晰的評估，對於成本覈算來說有輔助性作用。
3、針對系統隱患有非常高發現作用，鏈路上任何一個脆弱的環節都會在壓測中暴露出來。
4、所有的結論比較科學，不是拍腦袋拍出來的，牛逼也比較好吹。
其實主要還是希望心理踏實。希望你們都能在穩定的系統裏翱翔，不要像我之前，整宿整宿睡不着覺，系統水位不清晰，不知道能不能支持到業務的擴展。我心裏慌啊。就這樣，如果喜歡就點贊轉發吧，有不同的意見也請留言告訴我，技術文可千萬不要再0回覆0轉發0點讚了，好難過的喲。
長按關注大蕉喔
【軟件質量系列】