在軟件領(lǐng)域，無論是開發(fā)、測試、運維都對一個詞不會陌生，那就是：壓測。在百度百科里是這么定義壓測的：

壓測，即壓力測試，是確立系統(tǒng)穩(wěn)定性的一種測試方法，通常在系統(tǒng)正常運作范圍之外進行，以考察其功能極限和隱患。

本來是件很有意義的事，可是現(xiàn)實中往往尷尬的事就那么自然的發(fā)生了：明明幾輪壓測下來沒啥問題，但是業(yè)務(wù)高峰一來系統(tǒng)還是扛不住。故事通常會這樣繼續(xù)——就在研發(fā)同事一籌莫展的時候，運維同事及時的請出了三大法寶：擴容、限流與降級，問題迎刃而解。

讓人不得不感慨：姜還是老的辣，坑還是運維踩的多！

感慨之余，我們不禁要問，與其這樣是不是說壓測就沒有用了呢？其實不然。

我們知道，對于壓測這件事其實每個人或角色理解的都不見得完全準確，讓我們先從壓測的目的說起。

有一些人認為壓測就是在測試系統(tǒng)或資源的極限，所以對應(yīng)的壓測方案也是有著鬼斧神工的亮點：

• 把這兩臺F5設(shè)備連接數(shù)打滿
• 運營商有4個G的帶寬，壓測得能跑滿
• 服務(wù)器集群每臺機器CPU、內(nèi)存利用率都得能到95%
• ……

以上只是舉例，請各位無需對號入座。其實想表達的是，我們是不是該靜下心來問下自己，到底為什么要做壓測呢？這里找到一張圖片，從用戶角度和技術(shù)角度講了我們做壓測的目的是什么。

（圖片來自極客時間）

所以，到此還需要引入另外一個概念，我們的壓測其實核心做的事叫：容量保障。它有兩個最關(guān)鍵的點：

1. 以盡可能小的成本確保系統(tǒng)當前和未來的容量充足，即容量規(guī)劃
2. 解決已知的容量問題，預(yù)防未知的容量問題，即容量治理

談到這里有人可能會說是不是有點跑題了，并且這個問題貌似也有點多余，答案當然是做好容量測試也即壓測唄。嗯，回答正確，但是問題就在于知易行難呀。

阿里前任 CTO 行癲在 2018 年雙 11 啟動會上說過一句話：“容量測試是驗證手段，不是測試手段”。

換句話說，我們應(yīng)該先努力設(shè)計和建造出滿足容量要求的服務(wù)，再通過容量測試去驗證它，而不是靠容量測試去反復(fù)探測服務(wù)容量瓶頸，再去不停地優(yōu)化服務(wù)或擴容。我認為這才是對容量測試的現(xiàn)代化理解。

是不是有種醍醐灌頂?shù)母杏X，原來之前提到的壓測方案從根本上就是有問題的。問題的盡頭會是答案么？我們該如何設(shè)計一個好的壓測方案呢？其實理論上并不復(fù)雜。

通常來講，一次正確的壓測需要我們得確認好壓測范圍、制定壓測方案、實施壓測、最后進行數(shù)據(jù)分析。我們一步步來講，先確認測試范圍，這里還是一張圖來說清楚這件事：

（圖片來自極客時間）

總結(jié)一下，最重要的服務(wù)主要有以下四個：

• 關(guān)鍵路徑上的核心服務(wù)
• 有明顯流量峰值特征的服務(wù)
• 對響應(yīng)時間敏感的服務(wù)
• 占用資源大的服務(wù)

服務(wù)有了，剩下的就是確認怎么來測了？幸好，基調(diào)聽云在這塊有著自己的見解。

根據(jù)我們一些行業(yè)客戶的經(jīng)驗來看，對未來可能產(chǎn)生的流量峰值而言，任何預(yù)防性的穩(wěn)定性保障手段，都不如把實際峰值場景模擬出來“看一看” 來的有效。這就好比建造一座大壩，預(yù)計能抵擋千年一遇的洪水，但是否能達到這個目標，還是需要經(jīng)歷多次洪水考驗才能證明的。全鏈路壓測就是通過模擬這場千年一遇的洪水，來驗證服務(wù)系統(tǒng)是否能承載預(yù)估的流量峰值。

為什么單鏈路壓測無法排除系統(tǒng)整體容量風(fēng)險呢，因為整體系統(tǒng)的容量不是由多條“單鏈路”的容量簡單相加而得的。我們看一下下面這張圖，它表達的含義是，應(yīng)用服務(wù)的容量除了受自身影響，還受依賴服務(wù)的影響，而依賴服務(wù)又可能有其他調(diào)用方，甚至是一些外部服務(wù)，這些影響經(jīng)過幾層累積后，最終的影響面極難判斷。

（圖片來自極客時間）

而全鏈路壓測直接從全局視角出發(fā)，它的本質(zhì)是基于線上真實環(huán)境和實際業(yè)務(wù)場景，通過模擬海量的用戶請求，來對整個系統(tǒng)的容量進行評估的手段。

說白了，不能真實模擬業(yè)務(wù)場景有數(shù)據(jù)的壓測，某種程度上都可以說成是“偽”壓測。

壓測具有天然的結(jié)果不可預(yù)見性，再好的壓測方案如果不能得到有效的數(shù)據(jù)來分析都會使效果大打折扣。尤其是在復(fù)雜的、深度的系統(tǒng)環(huán)境下，通過獲取全鏈路的追蹤數(shù)據(jù)及指標數(shù)據(jù)實現(xiàn)整個壓測過程的可觀測性顯得尤為重要。

傳統(tǒng)壓測中，我們的監(jiān)控手段比較有限，一般多集中在對基礎(chǔ)資源層的監(jiān)控上，最多也就是加上開源的APM監(jiān)控，但對于真實用戶端和真實網(wǎng)絡(luò)情況是缺乏必要的監(jiān)控手段的。

基調(diào)聽云通過多年APM行業(yè)的積累，借助多維遙測技術(shù)及問題定位能力實現(xiàn)了具備可觀測性的全鏈路混合壓測方案。

東西看著不少，我們來關(guān)注重點好了。

可觀測性：通過端到端的遙測數(shù)據(jù)實現(xiàn)可觀測性。

全鏈路：提供從真實用戶體驗操作，到應(yīng)用、組件、基礎(chǔ)資源的壓力以及Trace可全量進行追蹤的能力。

混合：JMeter的接口壓測+真實用戶體驗?zāi)M瀏覽器的壓力形成混合壓力。

某省考試院重要考試報名前，使用基調(diào)聽云壓測服務(wù)對系統(tǒng)進行了多輪壓測，其中最高模擬用戶數(shù)達到了11萬/分鐘，基本上高度模擬了真實流量高峰場景。

在全棧監(jiān)控下，問題基本上無處藏身：

發(fā)現(xiàn)連接池問題，優(yōu)化才是王道：

讓結(jié)果來說明一切吧：

似乎該做個總結(jié)才好，就算不是老王面對這么好的瓜不自夸也挺難的。

如果您對基調(diào)聽云的具備可觀測性的全鏈路混合壓測方案感興趣，隨時點擊右下角“聯(lián)系我們”吧。