網站架構設計參考（圖文）
來源：程序員人生 發布時間：2016-07-28 09:16:23 閱讀次數：5634次
轉載請注明出處：http://blog.csdn.net/anxpp/article/details/51614973，謝謝！
1、概述
本人并未經歷過1個網站從小到大的演變進程（這類機會本來就太小，而且愈來愈小），現在很多網站，從建立之初就搭建在大型網站提供的云計算服務之上，需要的1切資源都可以按需購買，并且極易伸縮。不過我覺得還是有必要了解1下大型網站的演變進程。下文是參考多方資料整理得出。
2、大型網站架構演變進程
下面就是本人參考多方資源總結而得。
2.1、初始階段的網站架構
網站1開始，使用的人其實不多，訪問量比較小，使用1臺服務器就已完全滿足要求的。我們的個人主頁、博客，都可使用以下架構：
利用程序、
數據庫和文件等資源，都在同1臺
服務器上。通常也使用1些開源免費的軟件來將本錢最低化。
2.2、利用服務于數據服務分離
他們根據各自的特性，對cpu、內存和硬盤等的需求也各不相同：
利用服務于數據服務分離后，不同特性的
服務器擔負不同的角色， 系統整體性能將大大提高。
2.3、使用緩存改良性能
我們很清楚，其實不是所有的資源都被平均訪問到，恰好相反，1部份資源可能會被非常頻繁的訪問，而另外1些則幾近不會被訪問。
如果我們將最常被訪問的資源直接放到內存中（或其他的緩存方式），由于不再需要從
數據庫（硬盤）中讀取，速度將會大大提高，不過也會增加對內存的需求。
而緩存1般分兩種，利用
服務器本地緩存和遠程緩存。本地緩存因內存緣由，不合適放太多，所以可以專門部署大內存的
服務器，當遠程緩存
服務器（速度比本地緩存會慢些）。而目前的緩存技術也比較多，常見的NoSQL
數據庫也常被用來當緩存工具使用，本地緩存也能借助1些框架實現，這時候的架構以下：
使用緩存后，數據訪問壓力會大大減小。
2.4、使用服務器集群
業務繼續發展后，高并發的訪問不可避免，使用
服務器集群是比較經常使用的有效手段。
這相當于將1臺利用
服務器復制多個，然后通過負載均衡
服務器，將要求分發到不同的利用
服務器，他們干的是相同的事，不過壓力會大大減小：
根據高并發的情況，可以增加或減少其中的利用
服務器，從而使系統有較好的伸縮性。
2.5、數據庫讀寫分離
雖然緩存能1定程度上優化數據訪問，但是當業務發展1定程度時，
數據庫的負載壓力可能還是會太高，從而成為瓶頸。
為了便于利用
服務器的擴大和更容易的訪問主從兩個
數據庫，通常會從利用
服務器中獨立出來1個專門用來訪問
數據庫的數據訪問模塊。
2.6、使用反向代理和CDN加速訪問
CND和反向代理都是使用緩存的原理，區分在于前者部署與網絡提供商的機房，使用戶咋要求資源時，從就近的機房獲得數據；后者部署于利用
服務器前端，用戶要求到達后，會有限返回
服務器中緩存的可用資源。
這兩種技術主要目的就是加速用戶的訪問，使數據返回更快，同時還能減輕后端
服務器的負載壓力。
2.7、散布式文件服務器和散布式數據庫
隨著業務的日趨增長，任何單個強大的
服務器都不能滿足業務的需求，這時候可使用散布式
數據庫和散布式文件
服務器。
2.8、使用NoSQL和搜索引擎
通常使用NoSQL和搜索引擎技術來處理復雜的數據存儲和檢索：
2.9、業務拆分
隨著業務的進1步發展，也使其變得更加復雜，致使全部系統難以保護。
這時候就能夠將全部業務拆分成不同的產品線，再按需將各個產品線拆分成不同的利用，并對這些利用單獨部署保護，然后以超鏈接、消息隊列數據分發和訪問統1的數據存儲系統來關聯這個完全的系統：
2.10、散布式服務
隨著業務的拆分得愈來愈小，全部系統的關聯上也變得日趨復雜，部署保護仍然是1件非常困難的事。
這時候可以將這些業務中1些通用的地方提取出來獨立部署加以復用，提供統1的服務：
3、其他
目前，實現以上架構都有大量成熟穩定的技術支持，博客后續也會陸續更新添加相干技術的文章。
對架構的選擇，不能1味尋求大而全，應當以當前業務及后續發展公道選擇，既能節儉直接本錢，還能下降開發、部署和保護的本錢。
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
