（1）單塊架構
網站開始建立時，用戶少 , 網站架構都是用單體架構設計，共部署3台服務器，1台應用，1台數據庫，1台圖片。
1、應用服務器上發布，可能是把應用服務器上的Tomcat給關掉，替換系統的代碼war包，重新啟動Tomcat。
2、數據庫服務器，存全部核心數據。
3、網絡文件系統（NFS）作圖片服務器，存網站全部圖片。應用服務器上代碼會連接以及操作數據庫以及圖片服務器。
如下圖所示：
但是這種純單塊系統架構下，有高可用問題存在，最大的問題就是應用服務器可能會故障，或者是數據庫可能會故障
所以在這個時期，一般稍微預算充足一點的公司，都會做一個初步的高可用架構出來。
（2）初步的高可用架構
應用服務器而言，集群化部署，初期用戶量少的情況下，一般就是部署兩台應用服務器，前面會放一台服務器部署負載均衡設備，如說LVS（Linux虛擬服務器），均勻把用戶請求打到兩台應用服務器上去。
如此時某台應用服務器故障了，還有另外一台應用服務器是可以使用的，這就避免了單點故障問題。如下圖所示：
對於數據庫服務器而言，此時一般也會使用主從架構，部署一台從庫來從主庫同步數據，這樣一旦主庫出現問題，可以迅速使用從庫繼續提供數據庫服務，避免數據庫故障導致整個系統都徹底故障不可用。如下圖：
（3）千萬級用戶量的壓力預估
這個假設這個網站預估的用戶數是1000萬，那么根據28法則，每天會來訪問這個網站的用戶占到20%，也就是200萬用戶每天會過來訪問。
通常假設平均每個用戶每次過來會有30次的點擊，那么總共就有6000萬的點擊（PV）。
每天24小時，根據28法則，每天大部分用戶最活躍的時間集中在（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次數據庫的訪問。
按照3次數據庫訪問來算，那么每秒會對數據庫形成3萬次的請求。
按照一台數據庫服務器最高支撐每秒5000左右的請求量，此時需要通過6台數據庫服務器才能支撐每秒3萬左右的請求。
圖片服務器的壓力同樣會很大，因為需要大量的讀取圖片展示頁面，這個不太好估算，但是大致可以推算出來每秒至少也會有幾千次請求，因此也需要多台圖片服務器來支撐圖片訪問的請求。
（5）業務垂直拆分
一般來說在這個階段要做的第一件事兒就是業務的垂直拆分
因為如果所有業務代碼都混合在一起部署，會導致多人協作開發時難以維護。在網站到了千萬級用戶的時候，研發團隊一般都有幾十人甚至上百人。
所以這時如果還是在一個單塊系統里做開發，是一件非常痛苦的事情，此時需要做的就是進行業務的垂直拆分，把一個單塊系統拆分為多個業務系統，然后一個小團隊10個人左右就專門負責維護一個業務系統。如下圖
（6）分布式緩存扛下讀請求
這個時候應用服務器層面一般沒什么大問題，因為無非就是加機器就可以抗住更高的並發請求。
現在估算出來每秒鍾是1萬左右的請求，部署個二三十台機器就沒問題了。
但是目前上述系統架構中壓力最大的，其實是數據庫層面 ，因為估算出來可能高峰期對數據庫的讀寫並發會有3萬左右的請求。
此時就需要引入分布式緩存來抗下對數據庫的讀請求壓力了，也就是引入Redis集群。
一般來說對數據庫的讀寫請求也大致遵循28法則，所以每秒3萬的讀寫請求中，大概有2.4萬左右是讀請求
這些讀請求基本上90%都可以通過分布式緩存集群來抗下來，也就是大概2萬左右的讀請求可以通過 Redis集群來抗住。
我們完全可以把熱點的、常見的數據都在Redis集群里放一份作為緩存，然后對外提供緩存服務。
在讀數據的時候優先從緩存里讀，如果緩存里沒有，再從數據庫里讀取。這樣2萬讀請求就落到Redis上了，1萬讀寫請求繼續落在數據庫上。
Redis一般單台服務器抗每秒幾萬請求是沒問題的，所以Redis集群一般就部署3台機器，抗下每秒2萬讀請求是絕對沒問題的。如下圖所示：
（7）基於數據庫主從架構做讀寫分離
此時數據庫服務器還是存在每秒1萬的請求，對於單台服務器來說壓力還是過大。
但是數據庫一般都支持主從架構，也就是有一個從庫一直從主庫同步數據過去。此時可以基於主從架構做讀寫分離。
也就是說，每秒大概6000寫請求是進入主庫，大概還有4000個讀請求是在從庫上去讀，這樣就可以把1萬讀寫請求壓力分攤到兩台服務器上去。
這么分攤過后，主庫每秒最多6000寫請求，從庫每秒最多4000讀請求，基本上可以勉強把壓力給抗住。如下圖：
（8）總結
本文主要是探討在千萬級用戶場景下的大型網站的高並發架構設計，也就是預估出了千萬級用戶的訪問壓力以及對應的后台系統為了要抗住高並發，在業務系統、緩存、數據庫幾個層面的架構設計以及抗高並發的分析。
但是要記住，大型網站架構中共涉及的技術遠遠不止這些，還包括了MQ、CDN、靜態化、分庫分表、NoSQL、搜索、分布式文件系統、反向代理，等等很多話題，但是本文不能一一涉及，主要是在高並發這個角度分析一下系統如何抗下每秒上萬的請求。