• 網頁快取層  
• 負載均衡層  
• WEB 層  
• 資料庫層 

目前網站架構一般分成網頁快取層、負載均衡層、 WEB 層和資料庫層，我其實一般還會多加一層，即檔案伺服器層，這樣我們在後面的討論過程中，我們可以依次用這五層對網站架構來進行討論；這裡為了更具有說服力，我將用三個併發較大的生產環境來說明下，一個是我現在維護的電子商務網站（併發最大峰值 2900，日 PV500 萬左右）、我目前維護的電子廣告網站（併發最大峰值 1500，日 PV150 萬左右）、以前維護的大型 CDN 門戶廣告網站（併發最大峰值 5000，日 PV5000 萬左右）。  

網頁快取層  

首先說下這個網頁快取層，比如 CDN 租賃（效果比公司自己部署 Squid/Varnish 要好，他們專業，價格低廉，比如快網/CC 等（價格 80 元/M/月不到）而且覆蓋的城市更多），自己架設 squid/Varnish 是次選。另外，很多朋友喜歡嘗試自建 CDN，這個是一個比較吃力不討好的活兒，未必能達到預期目標，這塊系統架構師在架設網站初期就有規劃好，不要等到網站流量及壓力巨大時才去規劃。事實上，這一層有很多優
秀的開源軟體都能勝利，比如傳統的 Squid Cache，另外，後起之秀 Nginx 和 Varnish 因為效能優異，越來越多的朋友嘗試在自己的網站使用他們作為自己的網頁快取，事實上，Nginx 已經具備 Squid 所擁有的 Web 快取加速功能，此外，Nginx 對多核 CPU 的利用，勝過 Squid 不少，現在越來越來的架構師都喜歡將 Nginx 同時作為“負載均衡伺服器”與“Web 快取伺服器”來使用，大家可以根據自己網站的情況，來決定究竟使用哪種軟體來作為自己網站的網頁快取。

負載均衡層  

首先說下負載均衡層，我們熟悉的硬體/軟體技術有 F5，LVS/HAProxy，還有 Nginx，它們的效能都是非常優異的，F5/LVS 現在在全世界範圍內的應用，而且淘寶現在升級架構，也將 LVS 取代了 F5，HAProxy 可能大家不是特別熟悉，但 HAproxy+Keepalived 確實在生產環境下表現優異，強大的吞吐能力，穩定性比之
硬體過尤不及，並用淘寶也在大規模的推廣使用 HAProxy，有興趣的朋友也可以關注。再說下 Nginx，我是將 Nginx+Keepalived 架構用於了各種生產環境中的，經過長時間的線上觀察，發現 Nginx 作為負載均衡器/反向代理也很穩定，如果併發壓力過大，我們前面可以用 F5/LVS 作為最前端的負載均衡，而將 Nginx 作為七層代理，這樣的效果其實也不差，所以負載均衡層的壓力不能算是特別大。

WEB 層  

WEB 層這塊壓力比較大的網站現在都換成了 Nginx 作為 WEB 應用伺服器，事實上，它的抗併發能力確實超過了預期；我現在維護的一家入口網站，高峰期時某臺 Nginx 應用伺服器的併發達到了一萬以上，但 Nginx 也很負責和穩定的提供服務，在實際的生產環境中，如果我們考慮到後端的資料庫服務時，一萬併發應該也算是一個比較大的數值了。另外，Linux 叢集有一個優勢，就是它的高擴充套件性，就算我們的網站的併發有一萬以上，我們後端的 WEB 服務是 Apache，我們多加幾臺 Apache 伺服器即可，在實際的線上維護時，我們發現，高峰期間，實際上每臺 WEB 的併發並不算是特別大，所以網站的壓力在這一層我們也能通過技術手段加以克服。

檔案伺服器層 

現在大家的生產伺服器一般是使用如下四種來作為自己的檔案伺服器層：

1）單 NFS+備份 NFS 作為檔案伺服器，這樣的好處是維護方便，但存在著單點故障，需要人為手動干預；

2）DRBD+Heartbeat+NFS 高可用檔案伺服器，維護方便，也不存在著單點故障，但隨著訪問量的增大，後期一樣存在著壓力過大的情況；

3）分散式檔案系統 MFS、Gluster，，MFS 易用，穩定，對海量小檔案很高效，而且新版的 MFS 解決了

Master Server 存在著單點故障的問題， 國內越來越多的公司在使用 MFS。事實上，分散式檔案系統是解決檔案伺服器壓力過大的最終途徑，但這個同時也有隱患，網站功能越多，攤子越大，機器越多，維護起來越複雜。

4）如果大家的公司是淘寶和騰記這種巨量級的公司，可以嘗試開發自己的分散式檔案系統了，大家可以嘗試根據自己網站的情況，來決定究竟選擇哪一種軟體來作為自己的檔案伺服器。 

資料庫層 

資料庫層的壓力，我覺得網站的 PV 和併發上去以後，資料庫這塊的壓力是最大的，CDN 大型廣告網站我們用的是 Oacle RAC 方案，它保證了資料的高可用性，當然了價格也是非常昂貴的（如果使用高配置的 PC 伺服器，Oracle 一般按照 CPU 個數收費）；那麼免費的 MySQL 資料庫，面對這種併發壓力大的情況，這個時候我們應該怎麼辦呢？首先，我們可以在資料庫加入 memcached 資料快取，在實際線上使用時，我們也發現 memcached 功能強大，效能穩定，在資料庫頻繁讀寫，壓力過大的情況下，增加一臺 memcached 資料快取伺服器的效果能超過我們的預期。資料庫的硬體方面可以考慮投入，磁碟陣列做成 RAID10，如果資金充裕，磁碟可以用固定硬碟來代替 SAS 硬碟，畢竟資料庫的壓力主要來自於磁碟 I/O 方面。合理的設計 MySQL 資料庫的架構，事實上，在生產環境下，一主多從、讀寫分離是靠譜的設計方案，從 MySQL 的負載均衡我這裡推薦大家使用 LVS，這是因為當後面的 MySQL 機器超過十臺時，HAProxy 在這方面的效能不如 LVS。如果網站的業務量過大，我們可以採用分庫的方法，比如將網站的業務量分成 Web、BBS、Blog 等幾組，每一組均採用主從架構，這樣設計的話就避免了單組資料庫壓力過大的情況。另外，我們還應該配合公司的 MySQL DBA 和開發人員，在資料庫引數優化、SQL 語句優化、資料切分上多做功夫，避免資料庫成為我們網站的瓶頸。

希望大家能夠通過以上網站的五層分解，結合自己網站的情況，瞭解每一層在網站設計中的作用和重要性，找出網站瓶頸加以優化，將自己的網站打造成高可用高可擴充套件性的網站。