細說五層網站架構

目前網站架構一般分為網頁快取層、負載均衡層、Web層、資料庫層、檔案伺服器層

。我們可以依次用這五層對網站架構進行討論，為了增強說服力，我將用如下三個併發較大的生產環境來說明。

q   電子商務網站（併發最大峰值2900，日PV500萬左右）

q   電子廣告網站（併發最大峰值1500，日PV150萬左右）

q   大型CDN門戶廣告網站（併發最大峰值5000，日PV5000萬左右）

筆者聯絡QQ：572891887   也可以加入架構師交流群:471443208

1.網頁快取層

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

很多朋友喜歡嘗試自建CDN，這是一項吃力不討好的工作，未必能達到預期的目標，系統架構師應該在架設網站初期就規劃好，不要等到網站流量及壓力巨大時才去規劃。事實上，這一層有很多優秀的開源軟體都能勝任，比如傳統的Squid
Cache。另外，越來越多的朋友喜歡嘗試在自己的網站是用Nginx和Varnish作為自己的網頁快取。事實上，Nginx已經具備Squid所擁有的Web快取加速功能。此外，Nginx對多核CPU的利用勝過Squid，現在越來越多的架構師都喜歡將Nginx同時作為”負載均衡伺服器”與”Web快取伺服器”來使用，大家可以根據自己的情況，來決定究竟使用那種軟體作為網站的網頁快取。

2.負載均衡層

我們熟悉的硬體/軟體技術有F5、LVS/HAProxy，還有Nginx，它們的效能都是非常優異的，現在F5/LVS在全世界範圍內應用，而且淘寶現在升級架構，也用了LVS取代了F5。

HAProxy可能大家不是特別熟悉，單HAProxy+Keepalived確實在生產環境下表現優異，強大的吞吐能力，穩定效能比之硬體過猶不及，並且淘寶也在大規模地推廣使用HAProxy，有興趣的朋友也可以關注。

再來聊聊Nginx，我已經將Nginx+Keepalived架構用於各種生產環境，經過長期的線上觀察，發現Nginx作為負載均衡器/反向代理也很穩定，如果兵發壓力過大，我們前面可以用F5/LVS作為最前端的負載均衡，而將Nginx作為七層代理，這樣的效果其實也不差，所以說負載層壓力不算特別大。

3.Web層

Web層壓力比較大的網站現在都換成了Nginx作為Web應用伺服器，事實上，它的抗併發能力確實超過了預期。我現在維護的一家入口網站，高峰期時某臺Nginx應用伺服器的併發達到了一萬以上，但是Nginx也很穩定地提供服務。在實際的生產環境中，如果我們考慮到後端的資料庫服務時，一萬兵法應該也算是一個比較大的數值了。

另外，Linux叢集有一個優勢，就是它的高擴充套件性，就算網站的併發有一萬以上，後端的Web服務是Nginx，我們多加幾臺Nginx伺服器即可。在實際的線上維護時發現，高峰期間，實際上每臺Web的併發不算是特別大，所以我們也能通過技術手段對這一層的網站的壓力加以克服。

4.檔案伺服器層

現在大家生產伺服器一般是使用如下四種作為自己的檔案伺服器層：

1、單NFS+備份NFS作為檔案伺服器，這樣做的好處是維護方便，但存在單點故障，需要人手動干預。

2、DRBD+HeartBeat+NFS高可用檔案伺服器，維護方便，也不存在單點故障，單隨著訪問量的增大，後期一樣存在壓力過大的情況。

3、分散式檔案系統MFS、Glustr。MFS易用、穩定、對海量小檔案很高效，而且新版的MFS解決了MasterServer存在單點故障的問題，國內越來越多的公司在使用MFS。事實上，分散式檔案系統是解決檔案伺服器壓力過大的最終途徑，但也存在隱患，網站功能越多，攤子越大，機器越多，維護起來越複雜。

4、如果是淘寶和騰訊這種巨量級的公司，可以嘗試開發自己的分散式檔案系統了。大家可以嘗試根據自己網站的情況，來決定究竟選擇哪一種如那件作為自己的檔案伺服器。

5.資料庫層

資料庫層的壓力，我覺得網站的PV和併發上去以後，資料庫這塊的壓力是最大的，CND大型廣告網站用的是Oracle
RAC方案，它保證了資料的搞可用性，當然了價格也是非常昂貴的（如果使用高配置的PC伺服器，Oracle一般按照CPU個數收費）；那麼字啊使用免費的MySQL資料時，面對這種併發壓力打的情況，我們應該怎麼辦？

首先，可以在資料庫中加入memcached資料快取，在實際線上使用時，發現memcached功能強大、效能穩定，在資料流頻繁讀寫，壓力過大的情況下，增加一臺memcached資料庫快取伺服器的效果能超過我們的預期。

資料庫的硬體方面可以考慮投入磁碟佇列做成RAID10，如果資金充裕，磁碟可以用固定硬碟來代替SAS硬碟，畢竟資料庫的壓力主要來自磁碟I/O方面。

合理的設計MySQL資料庫的架構，事實上，在生產環境下，一主多從、讀寫分離是靠譜的設計方案，從MySQL的負載均衡推薦大家使用LVS，這是因為當後面的MySQL機器超過十臺時，HAProxy在這方面的效能不如LVS。

如果網站的業務量過大，可以採用分庫的方法，比如將網站的業務量分成Web、BBS、Blog等幾組，每一組均採用主從還夠，這樣的設計避免了單組資料庫壓力過大的情況。

另外我們應該還配合公司的MySQL
DBA和開發人員，在資料庫引數優化、SQL語句優化、資料切分上多下功夫，避免資料庫成為網站的瓶頸。

後續我會發布如何優化MySQL，從硬體–安裝方式–配置檔案優化-SQL優化-status狀態優化–慢查詢優化–表優化-MySQL高可用的擴充套件。

網站架構關注方向小結

1、我們的網站放在IDC機房內，首選考慮的就應該是如何防止DDOS/CC攻擊。DDOS攻擊雖然沒什麼技術含量，但真正攻擊過來還是很讓人煩躁的。在搭建網站或系統時，我們應該儘可能地瞭解和熟悉各種防火牆的技術指標引數，為客戶提供價效比最好的防火牆方案也是保證整套系統或網站成功的因素之一。

2、業務邏輯設計要合理，尤其是程式程式碼層的相關設計，如果程式應用架構和業務實現不夠優化，一個本來很簡單的實現卻繞了很多彎路才實現，那麼多強的硬體也沒有用。

3、也許是受張宴先生的影響，現在越來越多的朋友把注意力放在Nginx上了。其實Apache的抗併發能力並不弱。在生產環境下，如果我們的網站不是廣告型網站、門戶型網站或遊戲型網站，2000併發已經是一個很驚人的數字。另外這個僅僅是一臺Apache的併發，一箇中等規模的網站，後端至少會有3~4臺Apache的Web應用程式，所以，全部加起來我們的網站差不多可以頂住上萬的併發，上萬的併發量對網站根本沒有什麼大的影響。當然，如果換作Nginx作為Web應用伺服器更沒問題了。另外，就算併發量非常大，我們最前端的F5/LVS還是頂得住的，無非是在後端多加幾臺Web應用伺服器。所以說，併發量大不可能成為Web應用伺服器的瓶頸。

4、DRBD+HeartBeat+NFS檔案伺服器在初期沒什麼壓力，但隨著網站的使用者數和流量越來越大，它可能會感覺有些頂不住了，特別是使用者頻繁訪問圖片檔案時。我們在公司內部也測試郭Google的分散式檔案系統，但是一直沒敢用於生產環境中，最後還是決定採用Nginx作為中層代理，增加Squid反向代理伺服器叢集的方法來解決檔案伺服器的壓力問題。另外，如果資金充裕，最前端也應該租售CDN用於網站加速。

5、將Nginx作為中層代理使用是一件價效比非常高的事情。如果擔心單點Nginx故障，我們可以設定3臺以上的Nginx負載均衡器，而它們的load
balance可以讓F5/LVS來做。Nginx在這層可以利用其強大的正則處理能力很完美地處理客戶端對靜態檔案的訪問，比如將html、jpg、png、css等交給後端的Squid/varnish叢集處理，冬天的PHP/JSP訪問請求交給後端的PHP/Tomcat叢集伺服器處理，動靜分離，最大化地發揮Nginx作為負載均衡器/反向代理的優勢。

如果沒有硬體的F5
Big-Ip裝置，我們也可以用軟體LVS來實現，這樣成本會相當低。Nginx則利用其強大的正則功能，並根據URL或客戶請求檔案的字尾名來做動靜分離，或者輪訓不同的Squid/Varnish反向代理群組。

6、上線的專案在後期無論怎麼優化或架構，最後其壓力最大的肯定是MySQL資料庫，尤其是那些動態網站。我們在維護時也發現，MySQL資料庫在頻繁地讀寫，如何優化MySQL資料庫及設計高效能高可用的MySQL資料庫架構一致是我們關注和研究的方向，我也希望大家在工作中注意這個問題。

7、系統或網站的構建、運維和除錯並不只是一個人的事情，它是整個團隊合作努力的結果，需要整個團隊的開發人員、系統工程師和DBA及測試人員共同努力，要寫出安全、效率高、優美的程式碼，需要花費開發人員大量的心血。

轉載：http://www.xuliangwei.com/xubusi/188.html