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

[[36412]]

負(fù)載均衡層

首先說(shuō)下負(fù)載均衡層，我們熟悉的硬件/軟件技術(shù)有F5/LVS、HAProxy，還有Nginx，它們的性能都是非常優(yōu)異的，且不說(shuō)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)定性比之硬件過(guò)尤不及。

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

WEB層

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

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

文件服務(wù)器層

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

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

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

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

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

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

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

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