三，總結
在競爭激烈的電商公司中，會經常有這樣的業務場景：
場景一：市場部策劃要做乙個很大的運營活動，技術負責人衝過來，拋下兩個問題：
（1）伺服器效能怎樣，是否能抗住麼？
（2）如果扛不住，需要加多少伺服器？
場景二：系統設計階段，技術負責人衝過來，又問了兩個問題：
（1）資料庫需要分庫分表麼？
（2）如果需要分庫分表，需要分幾個庫幾個表？
技術上來說，這些都是系統容量預估的問題，容量設計是架構師必備的技能之一。常見的容量評估包括資料量、併發量、頻寬、cpu/mem/disk等，今天分享的內容，就以【併發量】為例，看看如何回答好這兩個問題。
如何知道總訪問量？對於乙個運營活動的訪問量評估，或者乙個系統上線後pv的評估，有什麼好的方法？
答案是：詢問業務方，詢問運營同學，詢問產品同學，看對運營活動或者產品上線後的預期是什麼。
如何知道平均訪問量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為2000，業務訪問趨勢圖如下圖，求峰值qps預估？
回答：從圖中可以看出，峰值qps大概是均值qps的2.5倍，日均qps為2000，於是評估出峰值qps為5000。
說明：有一些業務例如「秒殺業務」比較難畫出業務訪問趨勢圖，這類業務的容量評估不在此列。
如何評估乙個業務，乙個服務單機能的極限qps呢？
答案是：壓力測試
通過壓力測試發現，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】 -> 壓測很重要
【步驟五：根據線上冗餘度回答兩個問題】 -> 估計冗餘度與線上冗餘度差值
傳統軟體 Vs 網際網路軟體
傳統軟體 vs 網際網路軟體 2009 01 21 13 54 對比項傳統軟體 網際網路軟體 價值評估 軟體的複雜度，開發成本 使用者人群數 使用者價值 只有收費的使用者才是有價值的 免費使用者價值同樣巨大 傳播視角 操作手冊 厚厚一沓，生怕哪個細節考慮不到 部分還要給予操作使用培訓。必須讓使用者不...
網際網路架構，如何進行容量設計？
網際網路公司，這樣的場景是否似曾相識 場景一 pm要做乙個很大的運營活動，技術老大殺過來，問了兩個問題 1 機器能抗住麼？2 如果扛不住，需要加多少臺機器？場景二 系統設計階段，技術老大殺過來，又問了兩個問題 1 資料庫需要分庫麼？2 如果需要分庫，需要分幾個庫？技術上來說，這些都是系統容量預估的問...
網際網路軟體如何防破解
國內推廣軟體，你要面對的最大問題莫過於軟體被破解了。很多軟體作者反映說，原來軟體在被破解前交費註冊的人還不少，但被破解後收入就直線下降，連成本都收不回來。您想，有了免費的東西人們還交那個錢幹什麼？在這裡，我借鑑了乙個軟體作者的防破解經驗 發行1.0版時2.0版已經寫的差不多的。發行1.0版時要把1....