性能測試從零開始實施指南——容量評估篇

大概去年這時候，寫過一篇博客：淺談容量測試與容量規劃，裏面聊了一些我我的對於容量測試和容量規劃的一些瞭解以及想法。

因爲今年我司要搞雙十一大促，所以全鏈路壓測中很重要的一環——容量測試和容量規劃被列入了待辦事項。

與之相對的，想正確的進行容量測試，對線上容量規劃提供重要的參考依據，容量評估，就是咱們在準備階段須要作好的事情。如何作呢？？？

這篇博客，簡述一下我在準備階段，是如何開展容量評估工做以及遇到的一些問題，以及解決方案。。。

 

容量評估九步走——流程圖

 

1、劃分流量來源

在容量評估階段，首先要作的是劃分流量來源，這點須要根據具體的業務特色來劃分。通常分爲以下三種來源：

一、PC端：以電商平臺爲例（淘寶、京東、拼多多......），指的是從PC端發起的用戶請求流量；

二、移動端：這裏的移動端包括手機、平板等各種移動設備（目前移動端的流量也是佔比最大的一個流量來源渠道）；

三、小程序：近幾年隨着小程序的興起，來源於小程序以及H5的流量也是不可忽視的一部分流量渠道；

敲黑板：若是爲了更精確細化的進行流量劃分，還能夠根據流量來源的區域（國內/國外、包郵區/偏遠地區）來劃分，這樣作的目的是能夠根據地區來進行機房分配以及DNS網絡配置！

問題：如何監控不一樣區域的流量？專業解決方案提供商（監控寶）、根據請求地址相關數據進行日誌解析，生成監控熱點圖（grafana監控大盤）；

 

2、確認統計類型

這裏的統計類型是從系統架構的角度來劃分的，根據不一樣的系統架構、技術組件來確認流量落地的比例，主要分爲以下四種類型：

一、DB容量：具體來講，好比MySQL集羣中，不一樣業務庫最近一小時的峯值QPS（須要結合數據採集的場景以及是否進行了分庫分表、主從分離的配置）；

二、服務容量：若是是一體式服務，則無須考慮業務劃分；若是是微服務類型或SOA類型，則須要根據業務拆分的不一樣服務，進行容量統計（需考慮到服務依賴的狀況）；

敲黑板：服務容量的評估（指標仍是QPS），還須要統計單機服務實例的配置、目前生產環境的機器數量！

三、消息容量：消息主要指的是消息隊列，好比MQ、kafka（一樣須要根據業務屬性來劃分）。

敲黑板：消息容量的統計，主要統計這幾類數值：集羣類型、Topic、ConsumeGroup、消息總量、與平常倍數、是否堆積、峯值QPS！

四、緩存容量：這裏的緩存指的是Redis（CDN我目前還未接觸到，這裏不作概述），一樣，須要按照不一樣的業務進行垂直劃分。

敲黑板：容量評估時，需考慮到Redis的實例配置、模式（哨兵/集羣）、峯值QPS、存儲容量、機器數量、可用區（容災）！

問題：涉及到熱Key、大Key問題，建議提早進行大Key治理，熱Key散列分佈（記得檢查會話保持策略）！

 

3、接入監控組件

一、Cat

①、簡介：CAT是基於Java開發的實時監控平臺，主要包括移動端監控，應用側監控，核心網絡層監控，系統層監控等。提供實時監控報警，應用性能分析診斷的工具。

②、功能特性：可參考這裏：大衆點評CAT開源監控系統剖析

二、Jeager

①、簡介：open source, end-to-end distributed tracing.

②、架構圖

三、Sentinel

①、簡介：阿里中間件團隊開源，面向分佈式服務架構的輕量級高可用流量控制組件，主要以流量爲切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助用戶保護服務的穩定性。

②、架構圖

③、側重點

多樣化流量控制；

熔斷降級；

系統保護(LOAD，RT，線程數，入口QPS，CPU使用率)；

實時監控和控制檯配置；

四、Prometheus

①、簡介：開源的系統監控和報警框架，靈感源自 Google 的 Borgmon 監控系統。2012 年，SoundCloud 的 Google 前員工創造了 Prometheus，並做爲社區開源項目進行開發。

2015 年，該項目正式發佈。2016 年，Prometheus 加入雲原生計算基金會（Cloud Native Computing Foundation），成爲受歡迎度僅次於 Kubernetes 的項目。

②、特性

多維的數據模型（基於時間序列的 Key/Value 鍵值對）；

靈活的查詢和聚合語言 PromQL；

提供本地存儲和分佈式存儲；

經過基於 HTTP 的 Pull 模型採集時間序列數據；

可利用 Pushgateway（Prometheus 的可選中間件）實現 Push 模式；

可經過動態服務發現或靜態配置發現目標機器；

支持多種圖表和數據大盤；

 

4、選取採集場景

數據採集場景的選取，與核心鏈路梳理有強依賴關係，建議按照以下三種方式進行。

一、平常峯值

選取生產環境平常的峯值流量進行統計，這裏的峯值指的是區間峯值，區間通常能夠選擇30min；

二、核心鏈路

關於核心鏈路梳理，能夠參考上一篇博客：性能測試從零開始實施指南——場景模型篇。示意圖以下：

三、全量推送

對於電商業務而言，常常會有一些消息或者活動推送的玩法，建議選擇在活動推送期間的峯值流量來做爲數據採集場景的流量參考；

敲黑板：全量推送後會有一小段的高峯流量涌入，會對整個系統服務產生必定的影響！

 

5、彙總流量數據

流量統計表格Mode以下，僅供參考：

一、服務容量

二、消息容量

三、緩存容量

四、DB容量

 

6、獲取投放引流

運營投放引流的渠道、力度以及轉化率是很重要的一個參考指標，可讓咱們對大促時期的預期流量有更準確的預估。主要從以下三點來考慮：

一、時段

通常來講，電商這種大促，都是從月初持續到活動當天，不斷蓄水炒氛圍，活動當天流量達到峯值，而後有2-3天的返場，整體來講時間大概爲半個月左右。

獲取到整個活動期間每一個時間段有哪些活動，目的是肯定峯值流量衝擊的時間段，重點關注監控；

二、類型

主要是上述的時間段內，有哪些運營活動，好比：秒殺（超賣場景）、搶購（熱點key的問題）、簽到、抽獎、分享等；

三、量級

量級主要分爲全量推送、特定用戶推送、推送觸達率、返場轉化率等指標，這樣方便咱們更好的評估實時的流量峯值；

問題：爲何要獲取運營投放和引流的數據呢？——爲了更精準的評估峯值流量，針對性的部署演練專項預案！

 

7、肯定驗收水位

驗收水位的做用，主要從如下兩方面考慮：

一、監控告警閾值

肯定運維保障的線上監控告警閾值，針對流量衝擊，進行鍼對性的自動擴容；

二、資源可用緩衝

服務的處理能力是有限的，並且爲了保障服務的穩定可用性，不能讓服務器持續處於高負載的狀態，所以要提早預留必定的資源可用比率，做爲緩衝區。

達到或超過運維的告警監控閾值，則自動擴容或者觸發限流策略。所以最終的性能驗收水位，要結合上述兩點來綜合考慮。

若是能對流量作到精準控制，運維的自動化程度比較高的話，能夠以單機的50%資源使用率做爲擴容依據（淘寶貌似就是這個值）。

若是沒有太精細化的控制，運維自動化程度不過高，建議以40%來做爲驗收水位。

 

8、執行容量測試

執行容量測試，應該是執行階段要作的事情，因爲容量測試測定的單機水位對容量評估和容量規劃是承上啓下的鏈接點，所以這裏順帶說起一下。

容量測試的目的，就是獲取單機容量（什麼狀態什麼閾值下的容量，和上述第七點結合）！

 

9、線上容量規劃

前面作了這麼多準備工做，最終的目的是對線上容量規劃有準確的參考和實施依據。容量規劃常規的計算公式以下：

A服務單機容量在50%水位時，TPS=200，設定爲T；線上流量轉化預估TPS爲3000，設定爲S；爲保障服務高可用，預留30%機器資源作擴容buffer，設定爲B；

那麼A服務最終線上須要部署的機器數量的計算公式爲：Count（A）= (1+30%)*(S/T）= 19.5臺機器；取整，那麼服務A線上容量規劃時，須要部署20臺機器。

 

最後，別忘了在線上針對性的進行高可用驗證！！！