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