【51CTO.com 獨家特稿】目前網站架構一般分成負載均衡層、WEB層和數據庫層，我其實一般還會多加一層，即文件服務器層，這樣我們在后面的討論過程中，我們可以依次對這四層進行討論；這里為了更具有說服力，我將用三個并發較大的生產環境來說明下，一個是我現在維護的電子商務網站（并發***值 2000，日PV500萬左右，此并發并不是總這么高的，只是***峰是有2000，下面的網站類似）、我的一拍網網站（并發***值1500，日PV500萬左右）、以前維護的大型CDN廣告網站（并發***值5000，日PV 5000萬左右）。

[[36412]]

負載均衡層

首先說下負載均衡層，我們熟悉的硬件/軟件技術有F5/LVS、HAProxy，還有Nginx，它們的性能都是非常優異的，且不說F5的抗并發能力，LVS現在在全世界范圍內的應用，而且淘寶現在升級架構，也將LVS取代了F5，HAProxy可能大家不是特別熟悉，但它確實在生產環境下表現優異，強大的吞吐能力，穩定性比之硬件過尤不及。

再說下Nginx，我是將Nginx+Keepalived架構用于了各種生產環境中的，經過長時間的線上觀察，發現Nginx作為負載均衡器/反向代理也很穩定，就算并發壓力過大，我們前面可以用F5/LVS來頂，而將Nginx作為中層代理，這樣的效果其實也 不差，所以負載均衡層的壓力不能算是特別大。

WEB層

WEB層這塊壓力比較大的網站現在都換成了Nginx作為WEB應用服務器，事實上，它的抗并發能力確實超過了預期；我朋友維護的一家門戶網站，高峰期時某臺Nginx應用服務器的并發達到了一萬以上，但Nginx也很負責和穩定的提供服務，在實際的生產環境中，如果我們考慮到后端的數據庫服務時，一萬并發應該也算是一個比較大的數值了。

另外，Linux集群有一個優勢，就是它的高擴展性，就算我們的網站的并發有一萬以上，我們后端的WEB服務是Apache，我們多加幾臺Apache服務器即可，在實際的線上維護時，我們發現，高峰期間，實際上每臺WEB的并發并不算是特別大，所以網站的壓力在這一層我們也能通過技術手段加以克服。

文件服務器層

文件服務器層，由于網站的后期宣傳策話，名氣也越來越大，PV值也越來越高，原先的DRBD+Heartbeat+NFS（這個其實也只是單NFS，只不過我們利用DRBD來保證NFS的高可用而已）已經越來越頂不住壓力了，這個時候我們想到了分布式文件系統，我測試的的是MooseFS，在內網測試了很長時間還是沒敢用到生產環境下面，googel的分布式文件系統還是很成熟的，推薦大家學習；***還是用采用以前的CDN傳統的方法解決這個問題，即用了squid反向代理加速器來解決小文件過多的問題，Nginx強大的正則處理分發能力，也讓后端的NFS壓力變得很小；另外，我還用采用域名的分散策略例如使用pics.xxx.com/pdf.xxx.com...來區分標記為a或b的一系列文件，這些文件存儲的時候，依然按照標記，存到pics或pdf的服務器上。這個策略將區分機器的任務交由dns服務器來執行，擴容時會相應輕松。

這需要web項目初期就規劃好這些東東，后期才轉用域名策略的成本比較高甚至不可以實現，大家可以注意下，其實這一層如果網站是專業的圖片服務器網站時壓力還是很大的，我們需要在這個上面投入足夠多的硬件資源。

數據庫層

數據庫層的壓力，我覺得網站的PV和并發上去以后，數據庫這塊的壓力是***的，CDN大型廣告網站我們用的是oracle RAC方案，它保證了數據的高可用性，當然了價格也是非常昂貴的（如果使用高配置的PC服務器，Oracle一般按照CPU個數收費）；那么免費的MySQL數據庫，面對這種并發壓力大的情況，又用哪些方法呢？首先，我們說下傳統的MySQL主從方案，配置簡單，單機MySQL優化做好事性能也不弱，如果這種架構解決不了數據庫的壓力情況，我們可以考慮以下幾種方案：

◆常規復制架構--Master-slaves，是由一個Master復制到一個或多個Salve的架構模式，主要用于讀壓力大的應用數據庫端廉價擴展解決方案，讀寫分離，Master主要負責寫方面的壓力。

◆級聯復制架構，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風險。

◆Dual Master與級聯復制結合架構，即Master-Master-Slaves，***的好處是既可以避免主Master的寫操作受到Slave集群的復制帶來的影響，而且保證了主Master的單點故障。

◆MySQL的數據庫切分，我們可以通過數據切恰好技術將一個大的MySQL Server切分成多個小的MySQL Server，既解了寫入性能瓶頸問題，同時也一次提升了整個數據庫集群的擴展性，從而解決了數據庫壓力過大的問題，這個現在也是我在生產環境中比較推薦的做法之一。

以上的觀點僅僅只代表個人的一些想法，本人在51cot.com的ID為撫琴煮酒，歡迎大家就這個問題跟我研究討論，謝謝。

【51CTO.com獨家特稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】