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

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

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

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

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

一、劃分流量來源

在容量評估階段，首先要做的是劃分流量來源，這點需要根據具體的業務特點來劃分。一般分為如下三種來源：

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

2、移動端：這裡的移動端包括手機、平板等各類移動裝置（目前移動端的流量也是佔比最大的一個流量來源渠道）；

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

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

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

二、確認統計型別

這裡的統計型別是從系統架構的角度來劃分的，根據不同的系統架構、技術元件來確認流量落地的比例，主要分為如下四種類型：

1、DB容量：具體來說，比如MySQL叢集中，不同業務庫最近一小時的峰值QPS（需要結合資料採集的場景以及是否進行了分庫分表、主從分離的配置）；

2、服務容量：如果是一體式服務，則無須考慮業務劃分；如果是微服務型別或SOA型別，則需要根據業務拆分的不同服務，進行容量統計（需考慮到服務依賴的情況）；

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

3、訊息容量：訊息主要指的是訊息佇列，比如MQ、kafka（同樣需要根據業務屬性來劃分）。

敲黑板：訊息容量的統計，主要統計這幾類數值：叢集型別、Topic、ConsumeGroup、訊息總量、與日常倍數、是否堆積、峰值QPS！

4、快取容量：這裡的快取指的是Redis（CDN我目前還未接觸到，這裡不做概述），同樣，需要按照不同的業務進行垂直劃分。

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

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

三、接入監控元件

1、Cat

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

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

2、Jeager

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

②、架構圖

3、Sentinel

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

②、架構圖

③、側重點

多樣化流量控制；

熔斷降級；

系統保護(LOAD，RT，執行緒數，入口QPS，CPU使用率)；

實時監控和控制檯配置；

4、Prometheus

①、簡介：開源的系統監控和報警框架，靈感源自 Google 的 Borgmon 監控系統。2012 年，SoundCloud 的 Google 前員工創造了 Prometheus，並作為社群開源專案進行開發。

2015 年，該專案正式釋出。2016 年，Prometheus 加入雲原生計算基金會（Cloud Native Computing Foundation），成為受歡迎度僅次於 Kubernetes 的專案。

②、特性

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

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

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

通過基於 HTTP 的 Pull 模型採集時間序列資料；

可利用 Pushgateway（Prometheus 的可選中介軟體）實現 Push 模式；

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

支援多種圖表和資料大盤；

四、選取採集場景

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

1、日常峰值

選取生產環境日常的峰值流量進行統計，這裡的峰值指的是區間峰值，區間一般可以選擇30min；

2、核心鏈路

關於核心鏈路梳理，可以參考上一篇部落格：效能測試從零開始實施指南——場景模型篇。示意圖如下：

3、全量推送

對於電商業務而言，經常會有一些訊息或者活動推送的玩法，建議選擇在活動推送期間的峰值流量來作為資料採集場景的流量參考；

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

五、彙總流量資料

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

1、服務容量

2、訊息容量

3、快取容量

4、DB容量

六、獲取投放引流

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

1、時段

一般來說，電商這種大促，都是從月初持續到活動當天，不斷蓄水炒氛圍，活動當天流量達到峰值，然後有2-3天的返場，總體來說時間大概為半個月左右。

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

2、型別

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

3、量級

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

問題：為什麼要獲取運營投放和引流的資料呢？——為了更精準的評估峰值流量，針對性的部署演練專項預案！

七、確定驗收水位

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

1、監控告警閾值

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

2、資源可用緩衝

服務的處理能力是有限的，而且為了保障服務的穩定可用性，不能讓伺服器持續處於高負載的狀態，因此要提前預留一定的資源可用比率，作為緩衝區。

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

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

如果沒有太精細化的控制，運維自動化程度不太高，建議以40%來作為驗收水位。

八、執行容量測試

執行容量測試，應該是執行階段要做的事情，由於容量測試測定的單機水位對容量評估和容量規劃是承上啟下的連線點，因此這裡順帶提及一下。

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

九、線上容量規劃

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

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

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

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