往往程序員在面試的時候，公司的面試任職資格上，總有一個大型系統網站的開發經驗，我們先來看看幾張面試招聘信息截圖.......
大型網站定義
首先我們要思考一個問題，什么樣的網站才是大型網站，從網站的技術指標角度考慮這個問題人們很容易犯一個毛病就是認為網站的訪問量是衡量的指標，懂點 行的人也許會認為是網站在單位時間里的並發量的大小來作為指標，如果按這些標准那么像hao123這樣的網站就是大型網站了，如下圖所示：
其實這種網站訪問量非常大，並發數也非常高，但是它卻能用最為簡單的Web技術來實現：我們只要保持網站的充分的靜態化，多部署幾台服務器，那么就算地球上所有人都用它，網站也能正常運行。
大型網站是技術和業務的結合，一個滿足某些用戶需求的網站只要技術和業務二者有一方難度很大，必然會讓企業投入更多的、更優秀的人力成本實現它，那么這樣的網站就是所謂的大型網站了。0
如何逐步去構建一個大型網站系統
互聯網時代，怎么構建一個大型網站是不可缺少的技能。當然，本人目前接觸的網站都是讀遠遠大於寫。本文將一步步講訴，怎么去使用lamp構建完善一個大型網站（讀大於寫）。
網站架構，我個人認為最為重要的是兩方面的考慮：計算和存儲。有些是屬於計算密集型，有些是IO密集型。所以以下都將圍繞計算和存儲來講述問題。
1、最簡單的搭建
假設我們自己創業了，那么我們可能需要自己去搭建一個網站。
這個時候，我們需要去租借一個主機（比如阿里雲的虛擬主機等）。對於網站來說，數據是最為重要的，所以需要有一個備份。但是每天pv肯定不高，所以理論上只需要一個計算機器即可。因此，我們只需要3台機器就能完整一個完整的架構。
從上圖可以看到計算機器上主要部署2部分內容，一部分是webserver(輕量級可以考慮niginx,lighttpd等)，一個是UI邏輯處理部分，lamp架構則使用php語言來搞定這個問題。因為數據是最重要的，所以database則明顯需要2台機器，一台主機，一台做冗余備份。lamp使用mysql來存儲數據。
2 增加數據緩存
隨着我們網站知名度變高，每天pv越來越大，導致的問題是數據庫壓力越來越大。很明顯，絕大部分網站，讀流量都遠遠高於寫流量。即使我們開了mysql的query cache，它也只能在一定程度上通過減少DB機器I的操作來減少DB服務器壓力。更為靠譜的是，減少對DB服務器的請求。那么這個時候就需要使用cache.
cache為非關系型kv存儲，在使用過程中一般為內存操作。下面的架構改進如下。
可以看出ui寫數據仍然直接寫入到數據庫，但是讀則先從cache讀取，cache讀取不到再從database讀取。因為很有可能大部分數據都直接訪問cache就可以搞定，這樣就可以大大減少數據庫的壓力。
3、增加計算機器集群(計算方向)
隨着整個系統pv繼續上漲。單台的計算機器已經無法滿足要求。這個時候就需要使用增加計算機器來解決問題。為了方便起見，可以把這個機器放入一個集群進行統一管理。
這個時候，我們可能需要考慮2個問題：負載均衡、數據同步。負載均衡系統相對難度較大，但是是必不可少的，最簡單的可以通過zookkeeper等對配置文件進行統一管理。對於節點下的若干機器，可以簡單通過概率來進行請求分發。數據同步也是一個難點，比如session同步、文件操作等。
需要說明的是，好的架構結果如下：N台機器能撐住的PV為X，那么T*N台機器基本能撐住T*X pv。換句話說，架構必須能支持橫向擴展。如果機器加了一倍，但是撐住的峰值pv不能增加（接近）一倍，那個這個架構就是失敗的架構，不是可擴展性的架構。
可以看出的是在負載均衡系統下可以掛很多機器。好的擴展是，加入多少倍機器，計算能力就相應提高多少倍（暫時不考慮存儲的瓶頸）。
4、搭建簡單的數據庫集群(存儲方向)
流量上升，計算能力提升的同時，也需要提升數據庫的能力。這時候，我們可以采用讀寫分離。也就有了主從之說。主庫可以寫，當然也肯定能提供寫，從庫只能提供讀，我們目前主從延時在20ms以內。目前這種工具不少，比如mysql proxy等。(下圖應該是ui logic訪問dbproxy，圖有稍許錯誤，但是不影響理解)。
如上圖，dbproxy作用主要有3個：
1、讀寫分離。讀主要讀從庫，寫只能是寫主庫。我們在實際設計的時候需要考慮主從延時，比如事務讀必須讀主庫，寫完若干秒內最好讀主庫等等。
2、負載均衡。他能自動根據dbproxy下面掛在的db進行負載均衡。
3、dbproxy維持sql連接池，里面存在和db的長連接。請求過來之后，直接從連接池取連接即可。
5、靜態頁面跨地域緩存
很明顯，我們網站有很多靜態頁面，若干天才會更換一次。但是因為跨地域、跨機房的問題，外地用戶可能訪問較慢，所以我們可以通過cdn等技術緩存靜態頁面。這樣就可以減少對服務器的請求，同時加快外地、不同機房用戶的訪問時間。
如上圖所示，加入了靜態頁面緩存
6、跨地域跨機房設計
當我們業務進一步擴大，我們可能需要跨地域進行機器部署，目前我們主要分為華北(北京)和華東機房(杭州、南京)。跨地域部署，可以加快因為區域帶來的訪問過慢問題。比如廣州訪問北京機房數據，就不如北京訪問北京機房速度快。這個時候，還是主要分為計算和存儲兩方面進行講述。
6.1 計算方向
除了該機房的標示以外，各個機房的機器部署應該完全一致。
6.2 存儲方向
在我看來，對於讀遠遠大於寫的系統而言，最好只有一個主庫，若干個從庫。所以只需要在其他機房搭建從庫，讓從庫從主庫進行數據同步即可。當然，這樣的代價是主從時間比比較長。在數據鏈路不穩定的情況下，主從同步可能在400ms以上，所以設計需要考慮這個。
當然cache等等也需要跨地域跨機房部署。
如圖簡要勾勒出了跨地域跨機房的一個部署方案。
7、通用服務的使用
隨着業務拓寬，我們可能會有一些需要考慮新能的模塊或者業務。
如搜索業務，我們不可能直接通過數據庫的select like來實現，就需要使用C等編譯型語言來搭建其他系統。所以需要我們根據業務進行架構調整來通過http等使用一些通用的高性能計算方向的服務。
同樣，出於業務發展等因素的考慮，我們需要使用內存型的數據庫，比如redis等，這些屬於存儲方向的通用服務。
這些服務，有的可以跨機房部署，各個機房無耦合，有的則相互之間有耦合，比如類似於數據庫的主庫從庫。
8、其他考慮
除此以外，我們還需要有其他因素進行考慮。需要了解的可以加JAVA架構師學術交流群：587372254
8.1 網站數據
這個主要是比如uv/pv。這個有幾種做法，第一種是借助第三方的統計攻擊，比如百度統計、Google統計等。第二種是對我們現有系統的日志進行統計，同時可以進行深一步的數據挖掘。
8.2 安全性
這個需要考慮網站是不是存在sql注入，xss漏洞，csrf漏洞等。這個方面對於網站是非常關鍵的。一旦有黑客攻入，后果不堪設想。
對於管理員后台，最好不要開通外網權限，只能通過內網訪問。
8.3 seo等
搜索引擎優化對於網站作用不言而喻。 后續可能會專門針對百度SEO進行一些分析。