【51CTO.com 獨(dú)家特稿】目前網(wǎng)站架構(gòu)一般分成負(fù)載均衡層、WEB層和數(shù)據(jù)庫層，我其實(shí)一般還會(huì)多加一層，即文件服務(wù)器層，這樣我們?cè)诤竺娴挠懻撨^程中，我們可以依次對(duì)這四層進(jìn)行討論；這里為了更具有說服力，我將用三個(gè)并發(fā)較大的生產(chǎn)環(huán)境來說明下，一個(gè)是我現(xiàn)在維護(hù)的電子商務(wù)網(wǎng)站（并發(fā)***值 2000，日PV500萬左右，此并發(fā)并不是總這么高的，只是***峰是有2000，下面的網(wǎng)站類似）、我的一拍網(wǎng)網(wǎng)站（并發(fā)***值1500，日PV500萬左右）、以前維護(hù)的大型CDN廣告網(wǎng)站（并發(fā)***值5000，日PV 5000萬左右）。

[[36412]]

負(fù)載均衡層

首先說下負(fù)載均衡層，我們熟悉的硬件/軟件技術(shù)有F5/LVS、HAProxy，還有Nginx，它們的性能都是非常優(yōu)異的，且不說F5的抗并發(fā)能力，LVS現(xiàn)在在全世界范圍內(nèi)的應(yīng)用，而且淘寶現(xiàn)在升級(jí)架構(gòu)，也將LVS取代了F5，HAProxy可能大家不是特別熟悉，但它確實(shí)在生產(chǎn)環(huán)境下表現(xiàn)優(yōu)異，強(qiáng)大的吞吐能力，穩(wěn)定性比之硬件過尤不及。

再說下Nginx，我是將Nginx+Keepalived架構(gòu)用于了各種生產(chǎn)環(huán)境中的，經(jīng)過長時(shí)間的線上觀察，發(fā)現(xiàn)Nginx作為負(fù)載均衡器/反向代理也很穩(wěn)定，就算并發(fā)壓力過大，我們前面可以用F5/LVS來頂，而將Nginx作為中層代理，這樣的效果其實(shí)也 不差，所以負(fù)載均衡層的壓力不能算是特別大。

WEB層

WEB層這塊壓力比較大的網(wǎng)站現(xiàn)在都換成了Nginx作為WEB應(yīng)用服務(wù)器，事實(shí)上，它的抗并發(fā)能力確實(shí)超過了預(yù)期；我朋友維護(hù)的一家門戶網(wǎng)站，高峰期時(shí)某臺(tái)Nginx應(yīng)用服務(wù)器的并發(fā)達(dá)到了一萬以上，但Nginx也很負(fù)責(zé)和穩(wěn)定的提供服務(wù)，在實(shí)際的生產(chǎn)環(huán)境中，如果我們考慮到后端的數(shù)據(jù)庫服務(wù)時(shí)，一萬并發(fā)應(yīng)該也算是一個(gè)比較大的數(shù)值了。

另外，Linux集群有一個(gè)優(yōu)勢(shì)，就是它的高擴(kuò)展性，就算我們的網(wǎng)站的并發(fā)有一萬以上，我們后端的WEB服務(wù)是Apache，我們多加幾臺(tái)Apache服務(wù)器即可，在實(shí)際的線上維護(hù)時(shí)，我們發(fā)現(xiàn)，高峰期間，實(shí)際上每臺(tái)WEB的并發(fā)并不算是特別大，所以網(wǎng)站的壓力在這一層我們也能通過技術(shù)手段加以克服。

文件服務(wù)器層

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

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

數(shù)據(jù)庫層

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

◆常規(guī)復(fù)制架構(gòu)--Master-slaves，是由一個(gè)Master復(fù)制到一個(gè)或多個(gè)Salve的架構(gòu)模式，主要用于讀壓力大的應(yīng)用數(shù)據(jù)庫端廉價(jià)擴(kuò)展解決方案，讀寫分離，Master主要負(fù)責(zé)寫方面的壓力。

◆級(jí)聯(lián)復(fù)制架構(gòu)，即Master-Slaves-Slaves,這個(gè)也是為了防止Slaves的讀壓力過大，而配置一層二級(jí) Slaves，很容易解決Master端因?yàn)楦綄賡lave太多而成為瓶勁的風(fēng)險(xiǎn)。

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

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

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

【51CTO.com獨(dú)家特稿，非經(jīng)授權(quán)謝絕轉(zhuǎn)載！合作媒體轉(zhuǎn)載請(qǐng)注明原文出處及出處！】