出處：http://blog.csdn.net/anxpp/article/details/51614973
大型網站架構演化過程
1、初始階段的網站架構
網站一開始，使用的人並不多，訪問量比較小，使用一臺服務器就已經完全滿足要求的。我們的個人主頁、博客，都可以使用如下架構：
01
應用程序、數據庫和文件等資源，都在同一臺服務器上。通常也使用一些開源免費的軟件來將成本最低化。
2.2、應用服務於數據服務分離
隨着業務的發展，一臺服務器終將不能滿足需求。這是，可以按需將應用服務和數據服務分離：應用服務器、數據庫服務器和文件服務器。
他們根據各自的特性，對cpu、內存和硬盤等的需求也各不相同：
02
應用服務於數據服務分離後，不同特性的服務器擔任不同的角色， 系統整體性能將大大提高。
2.3、使用緩存改善性能
我們很清楚，並不是所有的資源都被平均訪問到，剛好相反，一部分資源可能會被非常頻繁的訪問，而另外一些則幾乎不會被訪問。
如果我們將最常被訪問的資源直接放到內存中（或其他的緩存方式），由於不再需要從數據庫（硬盤）中讀取，速度將會大大提高，不過也會增加對內存的需求。
而緩存一般分兩種，應用服務器本地緩存和遠程緩存。本地緩存因內存原因，不適合放太多，所以可以專門部署大內存的服務器，當遠程緩存服務器（速度比本地緩存會慢些）。而目前的緩存技術也比較多，常見的NoSQL數據庫也常被用來當緩存工具使用，本地緩存也能借助一些框架實現，這時的架構如下：
03
使用緩存後，數據訪問壓力會大大減小。
2.4、使用服務器集羣
業務繼續發展後，高併發的訪問不可避免，使用服務器集羣是比較常用的有效手段。
這相當於將一臺應用服務器複製多個，然後通過負載均衡服務器，將請求分發到不同的應用服務器，他們乾的是相同的事，不過壓力會大大減小：
04
根據高併發的情況，可以增加或者減少其中的應用服務器，從而使系統有較好的伸縮性。
2.5、數據庫讀寫分離
雖然緩存能一定程度上優化數據訪問，但是當業務發展一定程度時，數據庫的負載壓力可能還是會過高，從而成爲瓶頸。
目前主流的數據庫，都支持配置主從數據庫，利用這一特性，我們可以部署兩臺數據庫服務器，一臺用於寫操作，這是主數據庫，而從數據庫用於讀，主數據庫會將數據以數據庫提供的機制，增量同步到從數據庫，這樣就改善了數據庫的負載壓力：
06
爲了便於應用服務器的擴展以及更容易的訪問主從兩個數據庫，通常會從應用服務器中獨立出來一個專門用來訪問數據庫的數據訪問模塊。
2.6、使用反向代理和CDN加速訪問
CND和反向代理都是使用緩存的原理，區別在於前者部署與網絡提供商的機房，使用戶咋請求資源時，從就近的機房獲取數據；後者部署於應用服務器前端，用戶請求到達後，會有限返回服務器中緩存的可用資源。
07
這兩種技術主要目的就是加速用戶的訪問，使數據返回更快，同時還能減輕後端服務器的負載壓力。
2.7、分佈式文件服務器和分佈式數據庫
隨着業務的日益增長，任何單個強大的服務器都不能滿足業務的需求，這時可以使用分佈式數據庫和分佈式文件服務器。
在數據已經達到服務器不能支持的時候，就可以拆分業務，讓他們使用的數據庫服務器部署在不同的物理服務器上：
09
2.8、使用NoSQL和搜索引擎
通常使用NoSQL和搜索引擎技術來處理複雜的數據存儲和檢索：
10
2.9、業務拆分
隨着業務的進一步發展，也使其變得更加複雜，導致整個系統難以維護。
這時就可以將整個業務拆分成不同的產品線，再按需將各個產品線拆分成不同的應用，並對這些應用單獨部署維護，然後以超鏈接、消息隊列數據分發和訪問統一的數據存儲系統來關聯這個完整的系統：
09
2.10、分佈式服務
隨着業務的拆分得越來越小，整個系統的關聯上也變得日益複雜，部署維護依然是一件非常困難的事。
這時可以將這些業務中一些通用的地方提取出來獨立部署加以複用，提供統一的服務：