很多大型網站都是從小型網站發展而來，一開始的架構都比較簡單，隨著業務複雜和使用者量的激增，才開始做很多架構上的改進。當它還是小型網站的時候，沒有太多訪客，一般來講只需要一臺伺服器就夠了，這時應用程式、資料庫、檔案等所有資源都在一臺伺服器上，具體架構如下圖所示：

       隨著網站業務的發展和使用者量的增加，單臺伺服器就無法再滿足需求了。大量使用者訪問導致訪問速度越來越慢，而逐漸增加的資料也會導致儲存空間不足。

這時就需要將應用和資料分離，應用和資料分離後整個網站使用四臺伺服器：應用伺服器一臺、檔案伺服器一臺和資料庫伺服器二臺、用於做主從同步，使資料讀寫分離，同時可以做災備處理。這四臺伺服器對硬體資源的要求各不相同：

應用伺服器業務邏輯，需要強大的CPU

資料庫伺服器對磁碟讀寫操作很多，需要更快的磁碟和更大的記憶體

檔案伺服器儲存使用者上傳的檔案，因此需要更大的磁碟空間

具體架構如下圖所示：

        隨著使用者再增加，網站又會一次面臨挑戰：資料庫壓力太大導致整站訪問效率再此下降，使用者體驗受到影響。一個網站，往往 80% 的業務訪問集中在20% 的資料上，既然大部分業務訪問集中在一小部分資料上，那就把這一小部分資料先提前快取在記憶體中，而不是每次都去資料庫讀取，這樣就可以減少資料庫的訪問壓力，從而提高整個網站的訪問速度。

具體架構如下圖所示：

       使用快取後，資料訪問壓力得到了緩解，但是單一應用伺服器能夠處理的請求連線有限，在網站訪問高峰期，應用伺服器就成了整個網站的效率瓶頸。使用分散式叢集是網站解決高併發、海量資料問題的常用手段。當一臺伺服器的處理能力和儲存空間不足時，不要嘗試去更換更強大的伺服器，對大型網站而言，多麼強大的伺服器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一臺伺服器分擔原有伺服器的訪問及儲存壓力。

具體架構如下圖所示：

隨著網站業務越來越複雜，對資料檢索的需求也越來越複雜，網站需要採用一些搜尋引擎，如elasticsearch。

具體架構如下圖所示：

      大型網站為了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。
      具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，同時不同的應用也對應不同的資料庫，將之同的大而統的業務資料進行解藕，拆分成多個數據，每個應用獨立部署。應用後臺通過http restful類的介面進行資料的處理，應用前臺可以通過一個超連結建立關係（在首頁上的導航連結每個都指向不同的應用地址），也可以通過訊息佇列進行資料分發，報表類的系統建立獨立資料倉庫，具體架構如下圖所示：

       在上圖的網路架構，經常會遇到某個應用不可用導致整個系統不可用而出現雪崩，或者快取伺服器出現故障，導致資料庫壓力激增而出現雪崩，面對雪崩的應對策略大致如下：

1. 流量控制；

       流量控制分為閘道器限流與使用者互動限流，閘道器限流可以採用nginx進行配置限流，使用者互動限流採用載入動畫,提高使用者的忍耐等待時間或提交按鈕新增強制等待時間機制

2. 改進快取模式；

      同步改為非同步重新整理

3. 服務自動擴容；

      AWS的auto scaling

4. 服務呼叫者降級服務；

      對呼叫服務與被呼叫的服務進行隔離

      我們根據具體業務,將依賴服務分為: 強依賴和若依賴. 強依賴服務不可用會導致當前業務中止,而弱依賴服務的不可用不會導致當前業務的中止.

    不可用服務的呼叫快速失敗一般通過超時機制來實現