互聯(lián)網架構，如何進行容量設計？
一、需求緣起
互聯(lián)網公司，這樣的場景是否似曾相識：
場景一：pm要做一個很大的運營活動，技術老大殺過來，問了兩個問題：
(1)機器能抗住么?
(2)如果扛不住，需要加多少臺機器?
場景二：系統(tǒng)設計階段，技術老大殺過來，又問了兩個問題：
(1)數(shù)據(jù)庫需要分庫么?
(2)如果需要分庫，需要分幾個庫?
技術上來說，這些都是系統(tǒng)容量預估的問題，容量設計是架構師必備的技能之一。常見的容量評估包括數(shù)據(jù)量、并發(fā)量、帶寬、CPU/MEM/DISK等，今天分享的內容，就以【并發(fā)量】為例，看看如何回答好這兩個問題。
二、容量評估的步驟與方法
【步驟一：評估總訪問量】
如何知道總訪問量?對于一個運營活動的訪問量評估，或者一個系統(tǒng)上線后PV的評估，有什么好的方法?
答案是：詢問業(yè)務方，詢問運營同學，詢問產品同學，看對運營活動或者產品上線后的預期是什么。
舉例：58要做一個APP-push的運營活動，計劃在30分鐘內完成5000w用戶的push推送，預計push消息點擊率10%，求push落地頁系統(tǒng)的總訪問量?
回答：5000w*10% = 500w
【步驟二：評估平均訪問量QPS】
如何知道平均訪問量QPS?
答案是：有了總量，除以總時間即可，如果按照天評估，一天按照4w秒計算。
舉例1：push落地頁系統(tǒng)30分鐘的總訪問量是500w，求平均訪問量QPS
回答：500w/(30*60) = 2778，大概3000QPS
舉例2：主站首頁估計日均pv 8000w，求平均訪問QPS
回答：一天按照4w秒算，8000w/4w=2000，大概2000QPS
提問：為什么一天按照4w秒計算?
回答：一天共24小時*60分鐘*60秒=8w秒，一般假設所有請求都發(fā)生在白天，所以一般來說一天只按照4w秒評估
【步驟三：評估高峰QPS】
系統(tǒng)容量規(guī)劃時，不能只考慮平均QPS，而是要抗住高峰的QPS，如何知道高峰QPS呢?
答案是：根據(jù)業(yè)務特性，通過業(yè)務訪問曲線評估
舉例：日均QPS為2000，業(yè)務訪問趨勢圖如下圖，求峰值QPS預估?
回答：從圖中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS為2000，于是評估出峰值QPS為5000。
說明：有一些業(yè)務例如“秒殺業(yè)務”比較難畫出業(yè)務訪問趨勢圖，這類業(yè)務的容量評估不在此列。
【步驟四：評估系統(tǒng)、單機極限QPS】
如何評估一個業(yè)務，一個服務單機能的極限QPS呢?
答案是：壓力測試
在一個服務上線前，一般來說是需要進行壓力測試的(很多創(chuàng)業(yè)型公司，業(yè)務迭代很快的系統(tǒng)可能沒有這一步，那就悲劇了)，以APP-push運營活動落地頁為例(日均QPS2000，峰值QPS5000)，這個系統(tǒng)的架構可能是這樣的：
（1)訪問端是APP
（2)運營活動H5落地頁是一個web站點
（3)H5落地頁由緩存cache、數(shù)據(jù)庫db中的數(shù)據(jù)拼裝而成
通過壓力測試發(fā)現(xiàn)，web層是瓶頸，tomcat壓測單機只能抗住1200的QPS(一般來說，1%的流量到數(shù)據(jù)庫，數(shù)據(jù)庫500QPS還是能輕松抗住的，cache的話QPS能抗住，需要評估cache的帶寬，假設不是瓶頸)，我們就得到了web單機極限的QPS是1200。一般來說，線上系統(tǒng)是不會跑滿到極限的，打個8折，單機線上允許跑到QPS1000。
【步驟五：根據(jù)線上冗余度回答兩個問題】
好了，上述步驟1-4已經得到了峰值QPS是5000，單機QPS是1000，假設線上部署了2臺服務，就能自信自如的回答技術老大提出的問題了：
(1)機器能抗住么? -> 峰值5000，單機1000，線上2臺，扛不住
(2)如果扛不住，需要加多少臺機器? -> 需要額外3臺，提前預留1臺更好，給4臺更穩(wěn)
除了并發(fā)量的容量預估，數(shù)據(jù)量、帶寬、CPU/MEM/DISK等評估亦可遵循類似的步驟。
三，總結
互聯(lián)網架構設計如何進行容量評估：
【步驟一：評估總訪問量】 -> 詢問業(yè)務、產品、運營
【步驟二：評估平均訪問量QPS】-> 除以時間，一天算4w秒
【步驟三：評估高峰QPS】 -> 根據(jù)業(yè)務曲線圖來
【步驟四：評估系統(tǒng)、單機極限QPS】 -> 壓測很重要
【步驟五：根據(jù)線上冗余度回答兩個問題】 -> 估計冗余度與線上冗余度差值
個人一些經驗分享，大伙輕拍，有更好的建議歡迎回復，下篇文章會將好的經驗share給更多的同學。
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯(lián)系原作者】
