容量規劃

容量規劃是個資源管理的命題，其目標是解答運行中的系統須要多少容量以及在何時須要這些容量的問題，更簡單的說法就是回答咱們須要在何時加多少機器的問題。

 

容量規劃總體上是一個從上到下，再從下到上的一個過程，先是明確公司總體的目標，然後各個業務域和系統進行拆解，估算出系統的需求，然後再逐步彙總，統計出整個公司對各類機器資源的需求量和到位進度。

 

1、明確公司或系統核心指標

 

在沒有明確需求以前，不該該開始容量規劃。

 

以電商公司爲例，主要的核心指標是日活、下單、支付，直播類app的核心指標可能就是日活、視頻上傳、視頻觀看，共享單車系統的核心指標應該是日活（pv、uv）、下單這兩個，微信的主要指標是日活、我的消息的條數、公衆號文章瀏覽數等。

 

2、肯定容量的約束條件

 

就是咱們在提供這些核心指標的的約束，大致以下。

 

對於CPU密集型的集羣，咱們經常會選擇TPS(每秒處理請求書)做爲集羣的容量指標來衡量集羣的處理能力，而約束條件中則會重點關注CPU的使用率是否率先成爲瓶頸；對於存儲型的集羣，選擇流量(MB/S)做爲容量指標，存儲型的集羣TPS依賴於業務數據大小，全部流量更適合做爲表徵集羣的處理能力，而約束條件最早成爲瓶頸的是網絡流量或者IO。

 

3、推導出本身系統或業務域的主要指標

咱們負責的系統或業務做爲整個公司的一個組成部分，公司核心指標中的一個或者多個必然和咱們有關係，於是能夠經過公司的核心指標推導出咱們的系統或業務的主要指標。
預測容量是一個持續的過程，須要靠數學與直覺來進行精確的預測。好比公司今年的日活是2.5億，咱們系統主要服務的調用量是3w/s。而明年公司的日活目標是5億，咱們系統主要服務的調用量就是6w/s了，固然在實際的場景中並不徹底是線性增加的，這個時候就須要靠本身的直覺了，能夠結合本身業務的實際狀況乘以必定的係數。

 

細化到系統的話主要是tps、qps、db數據量、緩存數據量、網絡流量等。

 

4、計算單系統的需求

 

根據二和三的具體數據，估算或者通過壓測後得出單系統的具體需求

1. 應用服務器
2. 在線存儲（關係型數據庫、非關係型數據庫、緩存、文件存儲）
3. 離線存儲（數倉、離線計算、實時計算）
4. 消息
5. 其餘的監控、搜索、推薦等
6. 下游的依賴

 

最終產出大體以下的一個表格

 

預算大類	系統	規格	現有資源	新增資源	一季度	二季度	三季度	四季度	需求場景	計算邏輯
應用服務器									業務天然增加	1wtps/單機200
mysql									新項目
緩存									技術改造（提高性能、提高緩存命中率）

5、彙總&擠水分

 

將單個系統的需求彙總後獲得整個公司或者大部分的需求，一般狀況下每個系統都會給本身都申請一些資源，以避免出現資源不夠的狀況，這樣就會整體需求會比較大。對於一些增加幅度比較大或者比較貴的資源，就會出現一個review以及pk的過程，儘可能把資源用在刀刃上。這個對於大公司更爲重要，由於大公司的機器需求是以萬臺爲規模的，涉及到的就是幾億的預算，不得不慎重。

 

 

參考資料：

http://blog.csdn.net/wanglha/article/details/39135621

http://blog.csdn.net/hexieshangwang/article/details/49720343