系列文章是博主對沈劍的《架構師訓練營》分享內容的個人筆記總結，原內容公衆號“成爲架構師”。
目錄
1 何時需要進行容量評估
- 容量有質變性增長
- 臨時運營活動
- 新系統上線
兩個場景例子：
- 要做雙十一促銷活動，那麼機器能不能抗住，扛不住有需要加幾臺
- 新系統上線，數據庫需不需要分庫，如果需要，那麼分幾個庫
技術上來說，這些都是系統容量預估問題，容量設計是架構師的必備技能。
2 哪些指標需要進行容量預估
看具體業務側的主要矛盾是什麼：
- 數據量 （通常有用戶發佈行爲的，如帖子）
- 併發量、吞吐量 （搶票、秒殺）
- 帶寬（音視頻）
- CPU/MEM/DISK等（計算需求、IO密集）
3 架構設計的容量評估步驟（吞吐量爲例）
1 評估總訪問量
方式： 詢問產品、運營的預期訪問量是多少
Q： 一個App-push的運營活動，計劃在30min內完成5000w用戶的push推送，預計push點擊率爲10%，那麼push落地頁的總訪問量是多少？
A： 5000w * 10% = 500w
2 評估平均訪問量
QPS的計算方式爲：總量 / 時間，若以一天計，則當作爲4w秒。
QPS、併發、吞吐等的理解可以參考這篇文章：QPS、TPS、吞吐量等性能指標的理解
Q： push落地頁系統30min的訪問量爲500w，平均QPS爲多少？
A： 500w / （30 * 60）
Q： 某信息分類網站的日均PV約8000w，平均QPS是多少？
A： 一天按照4w秒計算，8000w / 4w = 2000
3 評估高峯QPS
方式
- 根據業務的訪問曲線圖來，按照比例計算峯值QPS
- 沒有曲線圖則根據82原則計算，認爲80%的請求落在20%的時間裏，即（總量*0.8）/ （總時間*0.2）
訪問曲線圖：
若日均QPS爲2000，則根據圖中得到平均和峯值的比例關係爲1：2.5，那麼峯值的QPS可以估計爲500
4 評估系統、單機極限QPS
方式： 進行壓力測試
舉例，以App-push運營活動落地頁爲例（日均2000QPS，峯值5000QPS）假設系統的架構如下：
- 訪問端是APP
- 活動的落地頁是一個H5
- H5的數據大部分來自cache（99%），少數來自db（1%）
通過壓力測試發現，web層是瓶頸，tomcat的壓測只能抗住1200QPS
5 根據線上冗餘度做決策
經過上面4個步驟的計算，已經得到了需求的容量大小，再根據線上已經有的，就可以判斷出是否需要能夠滿足需求，以及擴容到什麼程度。
舉例： 若線上有兩臺web服務器，那麼爲了滿足需求應至少再增加三臺，四臺更爲保險。
在上述的五個步驟中，只有第四步壓力測試是需要提前準備的，其它四步驟都是臨時計算得到的。
下一篇要討論的是快速解決單機資源瓶頸的實踐方案，僞分佈式與垂直拆分，以及它們又引入了什麼新問題。
上一篇回顧：【成爲架構師1-2】技術選型：框架組件要不要自研，何時自研
下一篇更精彩：【成爲架構師2-2】僞分佈式與垂直拆分：快速解決單機性能問題的實踐方案