目前網(wǎng)站架構(gòu)一般分為網(wǎng)頁緩存層、負(fù)載均衡層、Web層、數(shù)據(jù)庫層、文件服務(wù)器層。我們可以依次用這五層對(duì)網(wǎng)站架構(gòu)進(jìn)行討論，為了增強(qiáng)說服力?我將用如下三個(gè)并發(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è)、價(jià)格低廉（比如：快網(wǎng)、藍(lán)訊、阿里、騰訊）而且覆蓋的城市更多，自己架設(shè)Squid/Varnish是次選。

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

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

2.負(fù)載均衡層

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

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

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

3.Web層

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

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

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

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

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

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

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

4、如果是淘寶和騰訊這種巨量級(jí)的公司，可以嘗試開發(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ù)的搞可用性，當(dāng)然了價(jià)格也是非常昂貴的（如果使用高配置的PC服務(wù)器，Oracle一般按照CPU?數(shù)收費(fèi)）；那么字啊使用免費(fèi)的MySQL數(shù)據(jù)時(shí)，面對(duì)這種并發(fā)壓力打的情況，我們應(yīng)該怎么辦？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 [文章摘自:運(yùn)維派]