目前網站架構一般分爲網頁緩存層、負載均衡層、Web層和數據庫層、文件服務器層。我們可以依次用這五層對網站架構進行討論，爲了增強說服力，我將用如下三個併發較大的生產環境來說明。
q 電子商務網站（併發最大峯值2900，日PV500萬左右）
q 電子廣告網站（併發最大峯值1500，日PV150萬左右）
q 大型CDN門戶廣告網站（併發最大峯值5000，日PV5000萬左右）
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及測試人員共同努力，要寫出安全、效率高、優美的代碼，需要花費開發人員大量的心血。
（至於MySQL的優化，請繼續關注我的博客）