目前網(wǎng)站架構(gòu)一般分成負(fù)載均衡層、WEB層和數(shù)據(jù)庫層，我其實一般還會多加一層，即文件服務(wù)器層，這樣我們在后面的討論過程中，我們可以依次對這四層進行討論；這里為了更具有說服力，我將用三個并發(fā)較大的生產(chǎn)環(huán)境來說明下，一個是我現(xiàn)在維護的電子商務(wù)網(wǎng)站（并發(fā)最大值2000，日PV500萬左右，此并發(fā)并不是總這么高的，只是最高峰是有2900，下面的網(wǎng)站類似）、我的一拍網(wǎng)網(wǎng)站（并發(fā)最大值500，日PV50萬左右）、以前維護的大型CDN廣告網(wǎng)站（并發(fā)最大值5000，日PV5000萬左右）。

首先說下負(fù)載均衡層，我們熟悉的硬件/軟件技術(shù)有F5/LVS、HAProxy，還有Nginx，它們的性能都是非常優(yōu)異的，且不說F5的抗并發(fā)能力，LVS現(xiàn)在在全世界范圍內(nèi)的應(yīng)用，而且淘寶現(xiàn)在升級架構(gòu)，也將LVS取代了F5，HAProxy可能大家不是特別熟悉，但它確實在生產(chǎn)環(huán)境下表現(xiàn)優(yōu)異，強大的吞吐能力，穩(wěn)定性比之硬件過尤不及，再說下Nginx，我是將Nginx/HAProxy+Keepalived架構(gòu)用于了各種生產(chǎn)環(huán)境中的，經(jīng)過長時間的線上觀察，發(fā)現(xiàn)Nginx/HAProxy作為負(fù)載均衡器/反向代理也很穩(wěn)定，就算并發(fā)壓力過大，我們前面可以用F5/LVS來頂，而將Nginx作為中層代理，這樣的效果其實也不差，所以負(fù)載均衡層的壓力不能算是特別大。

WEB層這塊壓力比較大的網(wǎng)站現(xiàn)在都換成了Nginx作為WEB應(yīng)用服務(wù)器，事實上，它的抗并發(fā)能力確實超過了預(yù)期；我朋友維護的一家門戶網(wǎng)站，高峰期時某臺Nginx應(yīng)用服務(wù)器的并發(fā)達(dá)到了一萬以上，但Nginx也很負(fù)責(zé)和穩(wěn)定的提供服務(wù)，在實際的生產(chǎn)環(huán)境中，如果我們考慮到后端的數(shù)據(jù)庫服務(wù)時，一萬并發(fā)應(yīng)該也算是一個比較大的數(shù)值了；另外，Linux集群有一個優(yōu)勢，就是它的高擴展性，就算我們的網(wǎng)站的并發(fā)有一萬以上，我們后端的WEB服務(wù)是Apache，我們多加幾臺Apache服務(wù)器即可，在實際的線上維護時，我們發(fā)現(xiàn)，高峰期間，實際上每臺WEB的并發(fā)并不算是特別大，所以網(wǎng)站的壓力在這一層我們也能通過技術(shù)手段加以克服。

再說下文件服務(wù)器層，由于網(wǎng)站的后期宣傳策話，名氣也越來越大，PV值也越來越高，原先的DRBD+Heartbeat+NFS（這個其實也只是單NFS，只不過我們利用DRBD來保證NFS的高可用而已）已經(jīng)越來越頂不住壓力了，這個時候我們想到了分布式文件系統(tǒng)，我測試的的是MooseFS，在內(nèi)網(wǎng)測試了很長時間還是沒敢用到生產(chǎn)環(huán)境下面，googel的分布式文件系統(tǒng)還是很成熟的，推薦大家學(xué)習(xí)；最后還是用采用以前的CDN傳統(tǒng)的方法解決這個問題，即用了squid反向代理加速器來解決小文件過多的問題，Nginx強大的正則處理分發(fā)能力，也讓后端的NFS壓力變得很小；另外，我還用采用域名的分散策略例如使用pics.xxx.com/pdf.xxx.com...來區(qū)分標(biāo)記為a或b的一系列文件，這些文件存儲的時候，依然按照標(biāo)記，存到pics或pdf的服務(wù)器上。這個策略將區(qū)分機器的任務(wù)交由dns服務(wù)器來執(zhí)行，擴容時會相應(yīng)輕松。這需要web項目初期就規(guī)劃好這些東東，后期才轉(zhuǎn)用域名策略的成本比較高甚至不可以實現(xiàn)，大家可以注意下，其實這一層如果網(wǎng)站是專業(yè)的圖片服務(wù)器網(wǎng)站時壓力還是很大的，我們需要在這個上面投入足夠多的硬件資源。

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

常規(guī)復(fù)制架構(gòu)--Master-slaves，是由一個Master復(fù)制到一個或多個Salve的架構(gòu)模式，主要用于讀壓力大的應(yīng)用數(shù)據(jù)庫端廉價擴展解決方案，讀寫分離，Master主要負(fù)責(zé)寫方面的壓力。級聯(lián)復(fù)制架構(gòu)，即Master-Slaves-Slaves,這個也是為了防止Slaves的讀壓力過大，而配置一層二級 Slaves，很容易解決Master端因為附屬slave太多而成為瓶勁的風(fēng)險。

Dual Master與級聯(lián)復(fù)制結(jié)合架構(gòu)，即Master-Master-Slaves，最大的好處是既可以避免主Master的寫操作受到Slave集群的復(fù)制帶來的影響，而且保證了主Master的單點故障。

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

事實上我也跟許多系統(tǒng)維護人員和MySQL DBA線下交流過，現(xiàn)在生產(chǎn)環(huán)境下用得比較多的MySQL架構(gòu)有：一、MySQL一主一從(這個優(yōu)化得好，百多萬PV的網(wǎng)站完全沒問題)；二、DRBD+Heartbeat+MySQL（MySQL官方推薦）；三、MySQL一主多從，讀寫分離，LVS或HAProxy作讀的LB。

這段時間一直跟老男孩前輩交流千萬級PV的網(wǎng)站架構(gòu)，系統(tǒng)架構(gòu)其實是件藝術(shù)活兒，我們應(yīng)該盡量做到以下幾點:一、保證高可用；二、保證高可擴展性；三、盡量把用戶往外面推(老男孩語)，足矣。