2013 年小紅書成立之初，主要是讓大家分享自己所購買的商品或者是使用好的商品、好的體驗。

[[218903]]

小紅書的前世今生

很多妹子看到這口紅不錯、那個包包很好看；很多口紅是國外的，沒有地方買。由此在 2014 年構建電商平臺開始上業務。

目前小紅書已經成為國內***的社區跨境電商之一。現在在上海、鄭州、寧波和深圳有多個保稅倉，為全國提供各類全球的好商品。

快速成長的痛

記得在 2015 年的時候，阿里雙十一會場可能有上千號的人來同時進行全鏈路壓測。

小紅書因為這三年的成長非常迅速，與阿里、京東這兩個大廠曾經遇到的穩定性問題一樣，需要去面對、解決。

主要有以下三個方面要解決：

• 隨著業務增長，人員、IT 資源的擴張趕不上業務的快速發展。比如說，在負責穩定性保障這塊，我們測試團隊在構建全鏈路壓測過程中也就兩三位同學。相對于阿里、京東來說是數量級的差異。
• 以前基于單體 Python 的系統架構在大促時常常成為瓶頸。
• 缺乏有效的性能和線上穩定性保障策略和實踐。

全鏈路壓測系統架構

對于全鏈路壓測，阿里有 PDS、京東有全鏈路壓測平臺。大廠這樣的壓測系統都是經過較長的時間不斷迭代出來的。

我們怎么辦？我們沒有那么的人力和資源；最核心的就是要搞定問題。

在電商高峰期場景下，它的流量可能是平時的 10 倍甚至是幾十倍。在這種情況下流量不是均勻地打到各個業務線的。

例如，90% 流量先進到主會場；再由主會場引流到各個分會場，然后是下單等等。整個過程是一個漏斗模型；這個可以用接口的水位對比來表示。

為了保證模擬高峰期線上行為，我們需要基于水位對比對整個業務模型進行全鏈路壓測。

據此，我們的全鏈路壓測系統架構分為四大塊：

• 各個鏈路壓測腳本配置管理
• 壓測調度
• 統一壓測數據管理
• 被測業務系統狀態監控

對于壓測系統來說，最核心的就是壓測腳本；怎么能夠快速、方便的開發出來一大批鏈路的壓測腳本。

從 0 到 1 構建全鏈路壓測

從 0 開始

2017 年的 6 月 6 號大促是我們平常比較重要的三個大促之一。我們在 5 月接到需要保障今年大促的任務。

當時整個測試的同學只有兩人可以投入，運維同學只有一位可以支持。而開發的同學一直會致力于業務開發直到 6 月 4 號。同時測試系統方面基本上是白紙一張。

壓測模型

要進行全鏈路壓測需要構建壓測模型，就是要知道壓什么、怎么壓、壓到什么樣的水平：

• 首先，我們需要做鏈路的梳理。我們和開發、運維協作通過運維監控系統將線上接口所有列表獲取到。
• 然后，通過調用監控系統獲取各個鏈路之間的配比關系。同時根據去年和日常鏈路監控的配比得知各個接口平時和去年大促在什么樣的水平。
• ***，依據前面兩個步驟去計算鏈路調用、壓測腳本以及施壓機等情況。

據此，我們任何一個鏈路壓測腳本都一共有四個壓測的參數，分別為：

• 輸出壓力 qps
• 當前水位
• 施壓周期
• 壓測鏈路

密切協作

在這樣的情況下，對于我們測試的同學來說就簡單了許多；我們可以將這個工具打成一個包，方便部署。

這樣就可以和運維同學一起合作，一次性生成多臺施壓機器同時去壓一個系統。

目前，我們大概可以在五分鐘之內能夠創建出來 400 臺以上的壓測容器也就是說快速輸出 5G 以上的壓力。

為了區分壓測流量和真實線上流量，我們和開發同學全力協作對線上的每個測試數據進行打標。

這樣一來在出業務報告或數據報表的時候，我們有統一的框架將測試數據進行剝離；進而保證了測試數據不污染線上數據。

全鏈路壓測目標就是模擬真實的大促情況下，我們的各個鏈路能夠承載多大流量以及各個業務系統的瓶頸點所在。

壓測之外

除了前述的全鏈路壓測之外，我們這里還包括容量預估、降級方案、應急預案、大促演練以及值班計劃。

我們會通過流量歷史監控來做容量的預估；同時，為壓測基線和限流熔斷提供依據。

當線上業務流量水位超過我們設置的閾值的時候，為了保障線上運行穩定我們會對相關的業務進行功能降級。

另外當線上水位超過我們原來預期的時候，我們會有相應的應急預案以降低容量不足帶來的影響。

年中 66 大促全鏈路實踐

2017 年從 5 月 6 日立項，到 8 號開始***條鏈路施壓，只用了兩天我們實現了從 0 到 1 的跨越。

對于從 0 到 80% 的這個過程，大家是可以很快做到的，因為對于運維同學來說這些工具、方法基本上是每天都在做的事情。復制從 0 到 1 的構建思路，我們在人員緊缺的情況下實現了預期目標。

***，對于有興趣開展線上全鏈路壓測的同學有以下三點建議：

• 先不要想大而全的平臺化。
• 關注系統的本身，從監控和限流開始做起。
• 掌握全鏈路壓測方法，快速構建實現從 0 到 1。