作為架構師，這樣的場景你是否似曾相識？

場景一

pm要做雙十一促銷活動，技術老大殺過來，問了兩個問題：

• 機器能抗住么？
• 如果扛不住，需要加多少臺機器？

場景二

新系統上線，技術老大殺過來，又問：

• 數據庫需要分庫么？
• 如果需要分庫，需要分幾個庫？

技術上來說，這些都是系統容量預估的問題，容量設計是架構師必備的技能。

常見的容量評估包括數據量、并發量、帶寬、CPU/MEM/DISK等，今天分享的內容，就以并發量為例，看看如何通過五個步驟，得到問題的答案。

步驟一：評估總訪問量。

如何知道總訪問量？

對于一個運營活動的訪問量評估，或者一個系統上線后PV的評估，有什么好的方法？

答：詢問運營同學，活動的預期訪問是什么；

詢問產品同學，產品上線后的預期訪問是什么。

栗子：

假設，58同城要做一個APP-push的運營活動，計劃在30分鐘內完成5000w用戶的push推送，預計push消息點擊率10%，如何評估push落地頁系統的總訪問量？

答：5000w*10% = 500w

步驟二：評估平均訪問量QPS。

如何知道平均訪問量QPS？

答：總量除以總時間即可，如果按照天評估，一天按照4w秒計算。

畫外音：一天86400秒，一般認為請求發生在白天，即4w秒。

栗子：

push落地頁系統30分鐘的總訪問量是500w，求平均訪問QPS？

答：500w/(30*60) = 2778，大概3000QPS。

栗子：

假設，58同城主站首頁估計日均pv 8000w，求平均訪問QPS？

答：一天按照4w秒算，8000w/4w=2000，大概2000QPS。

步驟三：評估高峰QPS。

系統容量規劃時，不能只考慮平均QPS，而是要扛住高峰的QPS，如何知道高峰QPS呢？

答：根據業務特性，通過業務訪問曲線評估。

栗子：

假設，某業務日均QPS為2000，業務訪問趨勢圖如下圖，求峰值QPS預估？

答：從圖中可以看出，峰值QPS大概是均值QPS的2.5倍，日均QPS為2000，于是評估出峰值QPS為5000。

畫外音：有一些業務例如“秒殺業務”比較難畫出業務訪問趨勢圖，這類業務的容量評估不在此列。

步驟四：評估系統、單機極限QPS。

如何評估一個業務，一個服務單機能的極限QPS呢？

答：壓力測試。

在一個服務上線前，一般來說是需要進行壓力測試，以APP-push運營活動落地頁為例（日均QPS2000，峰值QPS5000），這個系統的架構可能是這樣的：

• 訪問端是APP；
• 運營活動H5落地頁是一個web站點；
• H5落地頁由緩存cache、數據庫db中的數據拼裝而成；

通過壓力測試發現，web層是瓶頸，tomcat壓測單機只能抗住1200的QPS。

畫外音：一般來說，1%的流量到數據庫，數據庫500QPS還是能輕松抗住的，cache的話QPS能抗住，需要評估cache的帶寬，假設不是瓶頸。

我們就得到了web單機極限的QPS是1200，一般線上系統是不會跑滿，打個8折，單機線上允許跑到QPS1000。

步驟五：根據線上冗余度解題。

好了，上述步驟1-4已經得到了峰值QPS是5000，單機QPS是1000，假設線上部署了2臺服務，就能自信自如的回答技術老大提出的問題了。

技術老大問：機器能抗住么？

答：峰值5000，單機1000，線上2臺，扛不住。

如果扛不住，需要加多少臺機器？

答：需要額外3臺，給4臺更穩。

除了并發量的容量預估，數據量、帶寬、CPU/MEM/DISK等評估亦可遵循類似的步驟。

總結

互聯網架構設計如何進行容量評估：

• 評估總訪問量：詢問產品、運營；
• 評估平均訪問量：總量除以總時間，一天算4w秒；
• 評估高峰QPS：根據業務曲線圖來；
• 評估系統、單機極限QPS：壓測很重要；
• 根據線上冗余度解題：估計冗余度與線上冗余度差值；

知其然，知其所以然。

思路比結論更重要。