普通一個網站剛開端樹立的時分，用戶量是很少的，大約可能就幾萬或者幾十萬的用戶量，每天活潑的用戶可能就幾百或者幾千個。

這個時分普通網站架構都是采用單體架構來設計的，總共就部署3臺效勞器，1臺應用效勞器，1臺數據庫效勞器，1臺圖片效勞器。

數據庫普通就部署在一臺獨立的效勞器上，寄存網站的全部中心數據。

然后在另外一臺獨立的效勞器上部署NFS作為圖片效勞器，寄存網站的全部圖片。應用效勞器上的代碼會銜接以及操作數據庫以及圖片效勞器。

但是這種純單塊系統架構下，有高可用問題存在，最大的問題就是應用效勞器可能會毛病，或者是數據庫可能會毛病

所以在這個時期，普通略微預算充足一點的公司，都會做一個初步的高可用架構出來。

關于數據庫效勞器而言，此時普通也會運用主從架構，部署一臺從庫來從主庫同步數據，這樣一旦主庫呈現問題，能夠疾速運用從庫繼續(xù)提供數據庫效勞，防止數據庫毛病招致整個系統都徹底毛病不可用。

千萬級用戶量的壓力預估

這個假定這個網站預估的用戶數是1000萬，那么依據28規(guī)律，每天會來訪問這個網站的用戶占到20%，也就是200萬用戶每天會過來訪問。

通常假定均勻每個用戶每次過來會有30次的點擊，那么總共就有6000萬的點擊(PV)。

每天24小時，依據28規(guī)律，每天大局部用戶最活潑的時間集中在(24小時 * 0.2)≈ 5小時內，而大局部用戶指的是(6000萬點擊 * 0.8 ≈ 5000萬點擊)

也就是說，在5小時內會有5000萬點擊進來。

換算下來，在那5小時的活潑訪問期內，大約每秒鐘會有3000左右的懇求量，然后這5小時中可能又會呈現大量用戶集中訪問的頂峰時間段。

比方在集中半個小時內大量用戶涌入構成頂峰訪問。依據線上經歷，普通頂峰訪問是活潑訪問的2~3倍。假定我們依照3倍來計算，那么5小時內可能有短暫的峰值會呈現每秒有10000左右的懇求。

(4)效勞器壓力預估

大約曉得了頂峰期每秒鐘可能會有1萬左右的懇求量之后，來看一下系統中各個效勞器的壓力預估。

普通來說一臺虛擬機部署的應用效勞器，上面放一個Tomcat，也就支撐最多每秒幾百的懇求。

按每秒支撐500的懇求來計算，那么支撐頂峰期的每秒1萬訪問量，需求部署20臺應用效勞。

而且應用效勞器對數據庫的訪問量又是要翻幾倍的，由于假定一秒鐘應用效勞器接納到1萬個懇求，但是應用效勞器為了處置每個懇求可能要觸及到均勻3~5次數據庫的訪問。

假如一切業(yè)務代碼都混合在一同部署，會招致多人協作開發(fā)時難以維護。在網站到了千萬級用戶的時分，研發(fā)團隊普通都有幾十人以至上百人。

所以這時假如還是在一個單塊系統里做開發(fā)，是一件十分痛苦的事情，此時需求做的就是停止業(yè)務的垂直拆分，把一個單塊系統拆分為多個業(yè)務系統，然后一個小團隊10個人左右就特地擔任維護一個業(yè)務系統。

也就是說，每秒大約6000寫懇求是進入主庫，大約還有4000個讀懇求是在從庫上去讀，這樣就能夠把1萬讀寫懇求壓力分攤到兩臺效勞器上去。

這么分攤過后，主庫每秒最多6000寫懇求，從庫每秒最多4000讀懇求，根本上能夠勉強把壓力給抗住。