【51CTO.com獨(dú)家特稿】前言：從以前維護(hù)大型的CDN廣告網(wǎng)站，然后獨(dú)立做股票類(lèi)的資訊網(wǎng)站，再到維護(hù)目前公司的電子商務(wù)網(wǎng)站，網(wǎng)站的架構(gòu)或多或少的接觸了不少；很多同學(xué)或同行也在向我咨詢(xún)網(wǎng)站架構(gòu)的事，所以我將維護(hù)過(guò)的網(wǎng)站架構(gòu)稍為整理下，希望能給大家?guī)?lái)幫助，了解網(wǎng)架構(gòu)到底是怎么一回事。

眾所周知，大家習(xí)慣將網(wǎng)站分成三層：即負(fù)載均衡層、web層、數(shù)據(jù)庫(kù)層，但我根據(jù)線上的實(shí)際壓力情況，強(qiáng)烈建議分成五層，即硬件防護(hù)層、負(fù)載均衡層、web層、文件服務(wù)器層(圖片)、數(shù)據(jù)庫(kù)層，這樣大家理解一個(gè)簡(jiǎn)單的網(wǎng)站可能更容易。理解了最基礎(chǔ)的網(wǎng)站后，再理解大型網(wǎng)站架構(gòu)可能就更容易了。

硬件防火墻層：

這一層最重要的是安全防護(hù)，最基本的是要防止DDOS攻擊及應(yīng)用層的防護(hù)等。我目前應(yīng)用得比較好的是華賽的三層防火墻+天泰七層應(yīng)用防火墻，具體實(shí)施案例請(qǐng)參考我在51cto.com的文章，這里限于篇幅我就不詳細(xì)說(shuō)明了；如果成本預(yù)算不是太高的話，可考慮Juniper系統(tǒng)的防火墻，效果也不錯(cuò)。

負(fù)載均衡層

這一層要考慮的東西其實(shí)很多，包括：

一、你考慮布署的網(wǎng)站到底要承受多大的并發(fā)量；

二、負(fù)載均衡層是否能穩(wěn)定，存在單點(diǎn)故障嗎；

三、成本的考慮有時(shí)要高于技術(shù)的；

四、網(wǎng)絡(luò)的情況也決定了你到底要考慮哪種負(fù)載均衡器。

基于以上幾點(diǎn)情況，我拿實(shí)際情況分明下：

我最早之前維護(hù)的CDN廣告網(wǎng)站，并發(fā)長(zhǎng)期在6000以上，所以只能考慮F5，而又要做到高可用，此時(shí)不是單F5了，所以上了二臺(tái)F5，當(dāng)然成本也非常的高；公司光在F5上的投入，大約應(yīng)該在60-80萬(wàn)之間，相信這樣的投入，未必會(huì)被你所在公司的決策層所接受；而我后期維護(hù)及布署的證券類(lèi)資訊網(wǎng)站，并發(fā)比較小，大約在200之間，所以我用了二臺(tái)Linux機(jī)器作的LVS+Keepalived，效果也不錯(cuò)，相當(dāng)穩(wěn)定；而現(xiàn)在維護(hù)的公司的電子商務(wù)網(wǎng)站，并發(fā)大約在1.1K左右，初期我們其時(shí)也考慮的是LVS+Keepalived，但上上去就發(fā)現(xiàn)公司的網(wǎng)絡(luò)情況非常亂，每臺(tái)服務(wù)器至少有六七條靜態(tài)路由，lvs上上去根本就發(fā)揮不了作用，所以換上了Nginx+keepalived，我也編寫(xiě)了shell監(jiān)控nginx服務(wù)進(jìn)程，實(shí)現(xiàn)真正意義上的負(fù)載高可用。這一層我總結(jié)了下，其時(shí)考慮以下幾點(diǎn)情況，即成本、網(wǎng)絡(luò)、并發(fā)、高可用。

web集群層

這一層為了避免單點(diǎn)故障，大家都用的是Apache、Nginx或tomcat集群，其好處也很明顯：①避免單點(diǎn)故障；②負(fù)載客戶(hù)端的高并發(fā)請(qǐng)求。Apache是LAMP架構(gòu)最核心的WebServer，開(kāi)源、穩(wěn)定、模塊豐富是Apache的優(yōu)勢(shì)。但Apache的缺點(diǎn)是有些臃腫，內(nèi)存和CPU開(kāi)銷(xiāo)大，性能上有損耗，不如一些輕量級(jí)的Web服務(wù)器(例如Nginx)高效，輕量級(jí)的Web服務(wù)器對(duì)于靜態(tài)文件的響應(yīng)能力來(lái)說(shuō)遠(yuǎn)高于Apache服務(wù)器。而且現(xiàn)在根據(jù)實(shí)際的線上環(huán)境，Nginx服務(wù)器抗并發(fā)確實(shí)高于Apache，這一點(diǎn)張宴的博客已作了大量詳細(xì)敘述，但在Apache在高內(nèi)存(>=16G)的情況下，單Apache的抗并發(fā)能力也是很強(qiáng)的，高于6000。我現(xiàn)在的做法是，如果是生級(jí)現(xiàn)有的以Apache作為webserver的網(wǎng)站，我單純只是考慮加上Nginx作負(fù)載均衡，不會(huì)動(dòng)原有網(wǎng)站的架構(gòu)；如果是架構(gòu)新網(wǎng)站，我會(huì)采用Nginx作為webserver。

文件服務(wù)器層

這一層的作用容易被人忽視，其實(shí)現(xiàn)在服務(wù)器的性能都上上去了，并發(fā)情況也都被大家重視，但服務(wù)器層的壓力卻甚少有人關(guān)心，在大規(guī)劃的頻繁的訪問(wèn)過(guò)程中，單NFS越來(lái)越不能滿足網(wǎng)站的需求了，我們有時(shí)接到用戶(hù)反映網(wǎng)站慢的情況，結(jié)果采用故障排查才發(fā)現(xiàn)，居然是NFS不堪重負(fù)，針對(duì)于這種情況，目前采用的方案有：

①可采用田逸推薦的分布式文件系統(tǒng)MFS(moosefs)實(shí)現(xiàn)存儲(chǔ)共享，他目前將此系統(tǒng)應(yīng)用于遨游，線上用的東西畢竟比較有說(shuō)服力；

②直接用NEC的存儲(chǔ)，雖然強(qiáng)悍，但增加了網(wǎng)站的實(shí)施成本及復(fù)雜度；

③用DRDB+Heartbeat+NFS組建NFS集群，效果也很穩(wěn)定，但也要注意Heartbeat的腦裂問(wèn)題。

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

為了更好的說(shuō)明力，我這里用的網(wǎng)站都以電子商務(wù)和廣告網(wǎng)站，這些對(duì)數(shù)據(jù)庫(kù)要求嚴(yán)苛的網(wǎng)站來(lái)說(shuō)明，這些網(wǎng)站對(duì)數(shù)據(jù)庫(kù)的要求是很高的，在數(shù)據(jù)庫(kù)并發(fā)、穩(wěn)定及延時(shí)性方面均有要求，MySQL在性能、穩(wěn)定性和功能上是首選，可以達(dá)到百萬(wàn)級(jí)別的數(shù)據(jù)存儲(chǔ)。目前采用的方案有：

①目前多采用MySQL的主從方案，實(shí)際讀寫(xiě)都采用單一服務(wù)器，服務(wù)器采用公司性能最好的服務(wù)器充當(dāng)(MySQL的cluster暫時(shí)不敢用于線上環(huán)境)；

②采用oracle的RAC雙機(jī)方案，在實(shí)際高并發(fā)的數(shù)據(jù)庫(kù)需求下，效果還是相當(dāng)不錯(cuò)。

加速緩存層

PHP的負(fù)載采用Apache集群，使用squid進(jìn)行緩存，html或圖片的請(qǐng)求可以直接由squid返回給用戶(hù)。這一層可以根據(jù)你的網(wǎng)站情況來(lái)考慮，現(xiàn)在由于Nginx的反向代理越做越好，我們其實(shí)可以用最前端的Nginx來(lái)充當(dāng)反向代理，這時(shí)的Nginx服務(wù)器，充當(dāng)?shù)淖饔檬秦?fù)載均衡器/反向代理；張宴已將其用于了生產(chǎn)環(huán)境，具體可參考他的相關(guān)文檔.

網(wǎng)站架構(gòu)是一個(gè)藝術(shù)活，責(zé)任重大；系統(tǒng)架構(gòu)師不等于系統(tǒng)工程師，要想從系統(tǒng)工程師到系統(tǒng)架構(gòu)師，不僅需要許多多年的運(yùn)維經(jīng)驗(yàn)和廣泛的運(yùn)維知識(shí)，還需要付出大量的努力，希望大家都成為未來(lái)的系統(tǒng)架構(gòu)師，最后祝大家工作愉快!

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