處於這個網際網路開發時代，作為一名軟體工程師，我們經常會聽到大型網站架構這個字眼，那到底什麼是大型網站呢，這樣的網站又是一種什麼樣的架構設計呢？今天我們就開始談談大型網站架構設計系列，首先我們今天講講大型網站架構設計是如何演變的，跟著我一起出發吧。

一、大型網站系統的特點

• 高併發，大流量：需要面對高併發使用者，大流量訪問；

• 高可用：系統24小時不間斷的提供服務；

• 海量資料：需要儲存、管理海量的資料，需要使用大量的伺服器；

• 使用者分佈廣泛，網路情況複雜：很多大型網站都是為全球使用者服務，使用者的分佈範圍廣泛，各地網路情況差異大；

• 安全環境惡劣：網際網路的開放性，導致網站更容易受黑客的攻擊；

• 需求快速變更，釋出頻繁

  ：相比傳統軟體，網際網路產品為了快速適應市場，滿足使用者的需求，產品釋出的頻率是極高的；

• 漸進式發展：與傳統行業軟體不同，網際網路產品不是事先就規劃好了整個產品的全部功能，幾乎每個大型網際網路網站都是從一個小網站，慢慢根據市場和使用者的改變而慢慢漸進發展成大型網站的；

二、大型網站架構發展歷程

大型網站的技術挑戰主要來自三個方面：龐大的使用者體系，高併發的訪問以及海量資料的儲存管理。基於這三點，我們就來看看，整個架構設計方面是如何演變的。

初始階段：這個階段一般網站使用者量也不多，訪問量都不大，資料量也不多，因此一般一臺伺服器就能搞定，應用程式，資料庫和檔案都可以部署在一臺伺服器上，架構圖如下：

應用服務和資料服務分離階段

使用快取改善效能階段：隨著資料庫壓力越來越大，我們需要考慮從資料上優化效能，大家都知道80%的業務訪問集中在20%的資料上，既然大部分業務集中訪問這少部分資料，那為何我們不考慮把這部分資料快取在記憶體中呢，不就可以減小對資料庫訪問的壓力了嘛；

快取又分為2種，一種是本地快取（本地快取是基於記憶體的，因此資料量有限，但是訪問速度快），另一種是遠端快取（一些中介軟體快取伺服器例如redis，這部分資料理論上不限容量，而且可以做成叢集模式）。

應用伺服器叢集優化網站併發能力階段：當用戶越來越多時，對網站的訪問量也越來越多，應用伺服器處理請求越來越慢，此時我們可以考慮將應用伺服器做成叢集模式部署，再通過負載均衡排程器，將使用者的請求分發給叢集上不同的應用伺服器。

資料庫讀寫分離階段：網站在使用了快取之後，使部分資料可以不通過資料庫就能完成，但是對於資料庫的修改操作，還是需要訪問資料庫的，這個時候，資料庫的負載壓力過高，能為網站的效能瓶頸，此時我們就要考慮資料庫的讀寫分離了，資料庫的讀寫分離是建立在主從熱備的基礎上的，基本目前大多數主流資料庫都支援主從熱備，通過配置兩臺或者多臺資料庫的主從關係（1主1從，1主多從，多主多從），實現資料的讀（從庫）寫（主庫）分離，主庫主動將資料同步到從庫。

向代理和CDN加速網站響應階段：為了加快網站的訪問速度，我們主要考慮的手段為CDN和反向代理，CDN是部署在網路提供商的機房，使用者在訪問時，可以從距離自己最近的網路提供商機房獲取資料；反向代理是部署在網站自己的中心機房，當用戶請求到達機房時，優先訪問的伺服器是反向代理伺服器，如果反向代理中快取了使用者請求的資源，那麼就直接返回給使用者，加快了響應的速度，也減輕了後端負載的壓力。

分散式檔案系統和分散式資料庫系統階段：當讀寫分離之後如果還不能滿足網站的需求，那就只能考慮最後的手段了：分散式資料庫，網站常用的資料庫拆分手段是業務分庫，將不同的業務資料庫部署在不同的物理機上。

NoSQL和搜尋引擎階段：隨著網站業務越來越複雜，對資料的檢索和儲存的需求也越來越複雜，網站需要採用一些非關係型資料庫（NoSQL）和非資料庫查詢（搜尋引擎）技術。

業務拆分階段：分而治之思想，將整個網站業務劃分為不同的產品線，根據不同的產品線劃分將網站拆成不同的應用，每個應用獨立部署維護如一個電商網站可以分為：首頁，訂單，商品，活動，優惠卷，個人中心，購物車等等多個應用，應用之間可以通過訊息佇列來傳遞資料。

分散式服務階段：隨著業務複雜度提升，我們會發現很多系統之間有著共同的業務，我們可以把這部分業務抽取出來，做成一個共通的基礎服務。

三、網站架構設計的誤區

• 一味追求大公司的解決方案：大公司的架構和成功案例當然值得借鑑，但是不能盲從；

• 為了技術而技術：技術是為業務而存在的，在技術選型和架構設計中一定要結合具體業務，脫離業務的架構毫無意義；

• 企圖用技術解決所有問題：技術是用來解決業務問題的，而業務本身的問題，是可以通過業務去解決，而沒有必要企圖用技術是解決；

四、總結

設計網站架構時一定要從小開始，架構隨業務演變而演變，切記不要在業務還是0的時候去追求1的架構設計，那樣的架構只會捨本逐末，得不償失；

文章轉載自：Justin談開發！