網站五層架構

1、網頁緩存層

　　首先說網頁緩存層，好比CDN租憑，其效果比公司本身部署Squid/Varnish要好，它們專業、價格低廉（好比：快網、藍訊、阿里、騰訊）並且覆蓋的城市更多，本身架設Squid/Varnish是次選。不少朋友喜歡嘗試自建CDN，這是一項吃力不討好的工做，未必能達到預期的目標，系統架構師應該在架設網站初期就規劃好，不要等到網站流量及壓力巨大時纔去規劃。事實上，這一層有不少優秀的開源軟件都能勝任，好比傳統的SquidCache。另外，愈來愈多的朋友喜歡嘗試在本身的網站是用Nginx和Varnish做爲本身的網頁緩存。事實上，Nginx已經具有Squid所擁有的Web緩存加速功能。此外，Nginx對多核CPU的利用賽過Squid，如今愈來愈多的架構師都喜歡將Nginx同時做爲」負載均衡服務器」與」Web緩存服務器」來使用，你們能夠根據本身的狀況，來決定究竟使用那種軟件做爲網站的網頁緩存。

2、負載均衡層　　

　　咱們熟悉的硬件/軟件技術有F五、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大型廣告網站用的是OracleRAC方案，它保證了數據的搞可用性，固然了價格也是很是昂貴的（若是使用高配置的PC服務器，Oracle通常按照CPU個數收費）；那麼字啊使用免費的MySQL數據時，面對這種併發壓力打的狀況，咱們應該怎麼辦？
　　首先，能夠在數據庫中加入memcached數據緩存，在實際線上使用時，發現memcached功能強大、性能穩定，在數據流頻繁讀寫，壓力過大的狀況下，增長一臺memcached數據庫緩存服務器的效果能超過咱們的預期。
　　數據庫的硬件方面能夠考慮投入磁盤隊列作成RAID10，若是資金充裕，磁盤能夠用固定硬盤來代替SAS硬盤，畢竟數據庫的壓力主要來自磁盤I/O方面。
　　合理的設計MySQL數據庫的架構，事實上，在生產環境下，一主多從、讀寫分離是靠譜的設計方案，從MySQL的負載均衡推薦你們使用LVS，這是由於當後面的MySQL機器超過十臺時，HAProxy在這方面的性能不如LVS。
　　若是網站的業務量過大，能夠採用分庫的方法，好比將網站的業務量分紅Web、BBS、Blog等幾組，每一組均採用主從還夠，這樣的設計避免了單組數據庫壓力過大的狀況。
　　另外咱們應該還配合公司的MySQLDBA和開發人員，在數據庫參數優化、SQL語句優化、數據切分上多下功夫，避免數據庫成爲網站的瓶頸。

6、網站架構關注方向總結

（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負載均衡器，而它們的loadbalance可讓F5/LVS來作。Nginx在這層能夠利用其強大的正則處理能力很完美地處理客戶端對靜態文件的訪問，好比將html、jpg、png、css等交給後端的Squid/varnish集羣處理，冬天的PHP/JSP訪問請求交給後端的PHP/Tomcat集羣服務器處理，動靜分離，最大化地發揮Nginx做爲負載均衡器/反向代理的優點。若是沒有硬件的F5Big-Ip設備，咱們也能夠用軟件LVS來實現，這樣成本會至關低。Nginx則利用其強大的正則功能，並根據URL或客戶請求文件的後綴名來作動靜分離，或者輪詢不一樣的Squid/Varnish反向代理羣組。
（6）上線的項目在後期不管怎麼優化或架構，最後其壓力最大的確定是MySQL數據庫，尤爲是那些動態網站。咱們在維護時也發現，MySQL數據庫在頻繁地讀寫，如何優化MySQL數據庫及設計高性能高可用的MySQL數據庫架構一致是咱們關注和研究的方向，我也但願你們在工做中注意這個問題。
（7）系統或網站的構建、運維和調試並不僅是一我的的事情，它是整個團隊合做努力的結果，須要整個團隊的開發人員、系統工程師和DBA及測試人員共同努力，要寫出安全、效率高、優美的代碼，須要花費開發人員大量的心血。