目前網(wǎng)站架構(gòu)一般分為網(wǎng)頁緩存層、負載均衡層、Web層、數(shù)據(jù)庫層、文件服務(wù)器層。我們可以依次用這五層對網(wǎng)站架構(gòu)進行討論，為了增強說服力?我將用如下三個并發(fā)較大的生產(chǎn)環(huán)境來說明。

電子商務(wù)網(wǎng)站（并發(fā)最大峰值2900，日PV500萬左右）

電子廣告網(wǎng)站（并發(fā)最大峰值1500，日PV150萬左右）

大型CDN門戶廣告網(wǎng)站（并發(fā)最大峰值5000，日PV5000萬左右）

1.網(wǎng)頁緩存層

首先說網(wǎng)頁緩存層，比如CDN租憑，其效果比公司自己部署Squid/Varnish要好，它們專業(yè)、價格低廉（比如：快網(wǎng)、藍訊、阿里、騰訊）而且覆蓋的城市更多，自己架設(shè)Squid/Varnish是次選。

很多朋友喜歡嘗試自建CDN，這是一項吃力不討好的?作，未必能達到預期的目標，系統(tǒng)架構(gòu)師應(yīng)該在架設(shè)網(wǎng)站初期就規(guī)劃好，不要等到網(wǎng)站流量及壓力巨大時才去規(guī)劃。事實上，這一層有很多優(yōu)秀的開源軟件都能勝任，比如傳統(tǒng)的SquidCache。

另外，越來越多的朋友喜歡嘗試在自己的網(wǎng)站是用Nginx和Varnish作為自己的網(wǎng)頁緩存。事實上，Nginx已經(jīng)具備Squid所擁有的Web緩存加速功能。此外，Nginx對多核CPU的利用勝過Squid，現(xiàn)在越來越多的架構(gòu)師都喜歡將Nginx同時作為”負載均衡服務(wù)器”與”Web緩存服務(wù)器”來使用，大家可以根據(jù)自己的情況，來決定究竟使用那種軟件作為網(wǎng)站的網(wǎng)頁緩存。

2.負載均衡層

我們熟悉的硬件/軟件技術(shù)有F5、LVS/HAProxy，還有Nginx，它們的性能都是非常優(yōu)異的，現(xiàn)在F5/LVS在全世界范圍內(nèi)應(yīng)用，而且淘寶現(xiàn)在升級架構(gòu)，也用了LVS取代了F5。

HAProxy可能大家不是特別熟悉，單HAProxy+Keepalived確實在生產(chǎn)環(huán)境下表現(xiàn)優(yōu)異，強大的吞吐能力，穩(wěn)定性能比之硬件過猶不及，并且淘寶也在大規(guī)模地推廣使用HAProxy，有興趣的朋友也可以關(guān)注。

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

3.Web層

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

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

4.文件服務(wù)器層

現(xiàn)在大家生產(chǎn)服務(wù)器一般是使用如下四種作為自己的文件服務(wù)器層：

1、單NFS+備份NFS作為文件服務(wù)器，這樣做的好處是維?方便，但存在單點故障，需要人手動干預。

2、DRBD+HeartBeat+NFS高可用文件服務(wù)器，維護方便，也不存在單點故障，單隨著訪問量的增大，后期一樣存在壓力過大的情況。

3、分布式文件系統(tǒng)MFS、Glustr。MFS易用、穩(wěn)定、對海量小文件很高效，而且新版的MFS解決了MasterServer存在單點故障的問題，國內(nèi)越來越多的公司在使用MFS。事實上，分布式文件系統(tǒng)是解決文件服務(wù)器壓力過大的最終途徑，但也存在隱患，網(wǎng)站功能越多，攤子越大，機器?多，維護起來越復雜。

4、如果是淘寶和騰訊這種巨量級的公司，可以嘗試開發(fā)自己的分布式文件系統(tǒng)了。大家可以嘗試根據(jù)自己網(wǎng)站的情況，來決定究竟選擇哪一種如那件作為自己的文件服務(wù)器。 

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

數(shù)據(jù)庫層的壓力，我覺得網(wǎng)站的PV和并發(fā)上去以后，數(shù)據(jù)庫這塊的壓力是最大的，CND大型廣告網(wǎng)站用的是Oracle RAC方案，它保證了數(shù)據(jù)的搞可用性，當然了價格也是非常昂貴的（如果使用高配置的PC服務(wù)器，Oracle一般按照CPU?數(shù)收費）；那么字啊使用免費的MySQL數(shù)據(jù)時，面對這種并發(fā)壓力打的情況，我們應(yīng)該怎么辦？

首先，可以在數(shù)據(jù)庫中加入memcached數(shù)據(jù)緩存，在實際線上使用時，發(fā)現(xiàn)memcached功能強大、性能穩(wěn)定，在數(shù)據(jù)流頻繁讀寫，壓力過大的情況下，增加一臺memcached數(shù)據(jù)庫緩存服務(wù)器的效果能超過我們的預期。

數(shù)據(jù)庫的硬件方面可以考慮投入磁盤隊列做成RAID10，如果資金充裕，磁盤可以用固定硬盤來代替SAS硬盤，畢竟數(shù)據(jù)庫的壓力主要來自磁盤I/O方面。

合理的設(shè)計MySQL數(shù)據(jù)庫的架構(gòu)，事實上，在生產(chǎn)環(huán)境下，一主多從、讀寫分離是靠譜的設(shè)?方案，從MySQL的負載均衡推薦大家使用LVS，這是因為當后面的MySQL機器超過十臺時，HAProxy在這方面的性能不如LVS。

如果網(wǎng)站的業(yè)務(wù)量過大，可以采用分庫的方法，比如將網(wǎng)站的業(yè)務(wù)量分成Web、BBS、Blog等幾組，每一組均采用主從還夠，這樣的設(shè)計避免了單組數(shù)據(jù)庫壓力過大的情況。

另外我們應(yīng)該還配合公司的MySQL DBA和開發(fā)人員，在數(shù)據(jù)庫參數(shù)優(yōu)化、SQL語句優(yōu)化、數(shù)據(jù)切分上多下功夫，避免數(shù)據(jù)庫成為網(wǎng)站的瓶頸。

后續(xù)我會發(fā)布如何優(yōu)化MySQL，從硬件-安裝方式-配置文件優(yōu)化-SQL優(yōu)化-status狀態(tài)優(yōu)化-慢查詢優(yōu)化-表優(yōu)化-MySQL?可用的擴展。 

網(wǎng)站架構(gòu)關(guān)注方向小結(jié)

1、我們的網(wǎng)站放在IDC機房內(nèi)，首選考慮的就應(yīng)該是如何防止DDOS/CC攻擊。DDOS攻擊雖然沒什么技術(shù)含量，但真正攻擊過來還是很讓人煩躁的。在搭建網(wǎng)站或系統(tǒng)時，我們應(yīng)該盡可能地了解和熟悉各種防火墻的技術(shù)指標參數(shù)，為客戶提供性價比最好的防火墻方案也是保證整套系統(tǒng)或網(wǎng)站成功的因素之一。

2、業(yè)務(wù)邏輯設(shè)計要合理，尤其是程序代碼層?相關(guān)設(shè)計，如果程序應(yīng)用架構(gòu)和業(yè)務(wù)實現(xiàn)不夠優(yōu)化，一個本來很簡單的實現(xiàn)卻繞了很多彎路才實現(xiàn)，那么多強的硬件也沒有用。

3、也許是受張宴先生的影響，現(xiàn)在越來越多的朋友把注意力放在Nginx上了。其實Apache的抗并發(fā)能力并不弱。在生產(chǎn)環(huán)境下，如果我們的網(wǎng)站不是廣告型網(wǎng)站、門戶型網(wǎng)站或游戲型網(wǎng)站，2000并發(fā)已經(jīng)是一個很驚人的數(shù)字。另外這個僅僅是一臺Apache的并發(fā)，一個中等規(guī)模的網(wǎng)站，后端至少會有3~4臺Apache的Web應(yīng)用程序，所以，全部加起來我們的網(wǎng)站差不多可以頂住上萬的并發(fā)?上萬的并發(fā)量對網(wǎng)站根本沒有什么大的影響。當然，如果換作Nginx作為Web應(yīng)用服務(wù)器更沒問題了。另外，就算并發(fā)量非常大，我們最前端的F5/LVS還是頂?shù)米〉?，無非是在后端多加幾臺Web應(yīng)用服務(wù)器。所以說，并發(fā)量大不可能成為Web應(yīng)用服務(wù)器的瓶頸。

4、DRBD+HeartBeat+NFS文件服務(wù)器在初期沒什么壓力，但隨著網(wǎng)站的用戶數(shù)和流量越來越大，它可能會感覺有些頂不住了，特別是用戶頻繁訪問圖片文件時。我們在公司內(nèi)部也測試郭Google的分布式文件系統(tǒng)，但是一直沒敢用于生產(chǎn)環(huán)境中，最后還是決定采用Nginx作為中層代理，增加Squid反向代理服務(wù)器集群的方法來解決文件服務(wù)器的壓力問題。另外，如果資金充裕，最前端也應(yīng)該租售CDN用于網(wǎng)站加速。

5、將Nginx作為中層代理使用是一件性價比非常高的事情。如果擔心單點Nginx故障，我們可以設(shè)置3臺以上的Nginx負載均衡器，而它們的load

balance可以讓F5/LVS來做。Nginx在這層可以利用其強大的正則處理能力很完美地處理客戶端對靜態(tài)文件的訪問，比如將html、jpg、png、css等交給后端的Squid/varnish集群處理，冬天的PHP/JSP訪問請求交給后端的PHP/Tomcat集群服務(wù)器處理，動靜分離，最大化地發(fā)揮Nginx作為負載均衡器/反向代理的優(yōu)勢。

如果沒有硬件的F5Big-Ip設(shè)備，我們也可以用軟件LVS來實現(xiàn)，這樣成本會相當?shù)?。Nginx則利用其強大的正則功能，并根據(jù)URL或客戶請求文件的后綴名來做動靜分離，或者輪訓不同的Squid/Varnish反向代理群組。

6、上線的項目在后期無論怎么優(yōu)化或架構(gòu)，最后其壓力最大的肯定是MySQL數(shù)據(jù)庫，尤其是那些動態(tài)網(wǎng)站。我們在維護時也發(fā)現(xiàn)，MySQL數(shù)據(jù)庫在頻繁地讀寫，如何優(yōu)化MySQL數(shù)據(jù)庫及設(shè)計?性能高可用的MySQL數(shù)據(jù)庫架構(gòu)一致是我們關(guān)注和研究的方向，我也希望大家在工作中注意這個問題。

7、系統(tǒng)或網(wǎng)站的構(gòu)建、運維和調(diào)試并不只是一個人的事情，它是整個團隊合作努力的結(jié)果，需要整個團隊的開發(fā)人員、系統(tǒng)工程師和DBA及測試人員共同努力，要寫出安全、效率高、優(yōu)美的代碼，需要花費開發(fā)人員大量的心血。

 [文章摘自:運維派]