前言
上篇文章主要介紹了在全鏈路壓測准備階段，最核心的一點：核心鏈路相關的知識。
梳理核心鏈路的一個重要目的是獲得流量模型。但在全鏈路壓測中，除了流量模型，業務模型和數據模型一樣重要。
這篇文章，為大家介紹如何構建這三大模型。
業務場景模型
前文中有提到：核心業務對應的核心應用中，保證達成企業利潤實現的最主要請求流量經過的路徑，即是核心鏈路。
理解這句話之后，就能很好的理解業務場景模型了。下圖是一個常見的電商雙11大促時候的業務場景模型圖，我以這個思維導圖為例來做分析說明。
一般來說梳理業務場景模型大概有如下幾個步驟：
- 根據業務特性和業務確定本次大促主要涉及的業務范圍（如電商一般是交易、活動和庫存業務）；
- 確定大促涉及的業務范圍中，對應的核心業務各有哪些（這里要對業務進一步的細化，如上圖）；
- 根據梳理出來的核心業務場景，進一步的進行打標賦權（假設流量過高或特殊情況，哪些可以放棄）；
PS：上面提到的細化業務場景以及打標簽賦予權重，是為了更明確的知道，哪些是最核心不能出問題的場景；
峰值流量模型
預估的流量模型要以峰值流量場景來預估，否則很可能由於錯誤的預估導致准備不足而致使大促期間線上出現問題。
峰值流量模型的預估，不僅是一個技術和監控的問題，還要綜合考慮本次大促期間業務目標以及業務轉化率的因素。舉個例子：
業務目標：雙11當天，預估平均客單價為500，單日GMV為10億，那么支付訂單量為10億/500=200W；
轉化技術指標：
1）假設日常支付訂單量為50W，支付轉化率為40%，訂單支付QPS峰值為200。預估大促時的支付轉化率為60%，
則可得：大促峰值訂單支付QPS為（200/40%）*60%*（200W/50W）=1200QPS。這個1200QPS是個保底數值，一般為了留有一定冗余空間，會上浮30%，即訂單支付的QPS預估為1500；
2）電商的導購瀏覽下單支付轉化鏈路一般為：首頁→商品詳情→創建訂單→訂單支付→支付成功，這個過程是類似漏斗的一個轉化邏輯。
假設首頁→商品詳情轉化率為40%，商品詳情→創建訂單轉化率為40%，創建訂單→訂單支付轉化率為40%，那么可得：創建訂單QPS為1500/40%=3750，商品詳情QPS為3750/40%=9375，首頁QPS為9375/40%=23437；
3）按照核心鏈路之間的依賴調用關系，借助監控和trace追蹤，最終得到本次大促期間，所有涉及的核心應用及核心鏈路的QPS數值。
最終我們會得到類似如下的一個流量模型圖：
壓測數據模型
關於壓測數據模型，實際上可以分為2個部分：壓測模型和數據模型。
壓測模型
以我個人經驗，壓測模型主要可以從如下幾個維度去划分：
1.單機單接口基准（接口級別）
單機單接口的壓測，可以通過梯度增加請求的方式，觀察隨着請求的增加，其性能表現&資源損耗的變化。
在目前的微服務架構下，整體鏈路的性能瓶頸，取決於短板（木桶原理）。因此，單機單鏈路基准測試的目的，是在全鏈路壓測開始前進行性能摸底，定位排查鏈路瓶頸。
2.單機混合鏈路場景（服務級別）
單機混合場景，大多還是通過梯度增加請求的方式，觀察服務級別的性能表現。
單機混合鏈路壓測的目的，是排查上下游調用依賴的瓶頸，並以此測試結果作為限流預案的基准值。
重點關注3個指標：
- 安全水位（CPU50%）
- 告警水位（CPU70%）
- 最大水位（CPU≥90%&Load5≥150%）
3.生產全鏈路壓測場景（生產集群）
針對生產集群的全鏈路壓測，需要涉及的壓測模型較多，一般有如下幾種：
①.梯度加壓模型：主要為了探測集群模式下系統的最大吞吐量（也避免壓垮服務，造成事故）；
②.固定並發模型：驗證系統長期處於負載下的穩定性；
③.脈沖並發模型：探測系統的健壯性、驗證限流熔斷等服務保護措施的正確性&可用性；
④.超賣驗證模型：對電商業務來說，主要針對一些限時搶購&秒殺的場景；一般這種場景，會涉及到分布式鎖、
緩存、數據一致性等技術點；玩不好的話，容易造成客訴、資損、甚至服務異常宕機！
數據模型
聊完了壓測模型，接着聊聊數據模型。數據場景，很多時候往往被忽視，但實際上數據場景更加重要。
如果測試過程中采用的數據不准確，那測試結果往往出現較大偏差。關於測試所需數據，可參考如下幾點：
| 數據信息 |
說明 |
| 限制條件 |
用戶操作權限、數據引用次數、數據過期設定（次數、絕對時間） |
| 數據量 |
實際生產環境的數據量為多少，在性能測試環境如何等量代換 |
| 數據類型 |
基礎數據、熱點數據、緩存數據、特殊數據 |
| 數據特點 |
是否可以復用、是否具有唯一性、自增、加密、拼接、轉義等 |
| 准備方式 |
copy真實環境數據、預埋鋪底數據、脫敏生成數據 |
| 隔離方案 |
如何避免測試數據的污染？影子庫？環境隔離？標記區分？ |
以我個人經驗，數據模型中測試數據主要分為如下幾種類型：
基礎數據：也稱之為鋪底數據，鋪底數據目的是與線上保持一致（至少數量級一致），再結合線上增長率，確認預埋數據量級及預埋方式。
涉及到壓測時需要校驗的數據，需要在鋪底的時候就要精細化的設計，包括數據大小，數量，分布等。
熱點數據：需要了解被測接口的實現邏輯，確認以下信息：
是否有熱點數據相關的操作：比如說所有用戶秒殺同一件商品；
不同類型數據處理邏輯有差異時，需通過測試數據多樣化提高性能測試代碼覆蓋率；
緩存數據：要確認是否有緩存，緩存大小為多少（排除大key，一般來說142W的key占Redis一個G的內存）；
秒殺搶購相關數據，一般來說都是進行隊列處理，將該類型數據放入緩存中進行處理來應對高並發。
再比如用戶登錄所需的token等數據，在生產壓測時，需要提前將其預熱到緩存中，避免壓測時用戶服務成為瓶頸；