??????? 很多大型網站都是從小型網站發展而來，一開始的架構都比較簡單，隨著業務復雜和用戶量的激增，才開始做很多架構上的改進。當它還是小型網站的時候，沒有太多訪客，一般來講只需要一臺服務器就夠了，這時應用程序、數據庫、文件等所有資源都在一臺服務器上，具體架構如下圖所示：
?????? 隨著網站業務的發展和用戶量的增加，單臺服務器就無法再滿足需求了。大量用戶訪問導致訪問速度越來越慢，而逐漸增加的數據也會導致存儲空間不足。
這時就需要將應用和數據分離，應用和數據分離后整個網站使用四臺服務器：應用服務器一臺、文件服務器一臺和數據庫服務器二臺、用于做主從同步，使數據讀寫分離，同時可以做災備處理。這四臺服務器對硬件資源的要求各不相同：
應用服務器業務邏輯，需要強大的CPU
數據庫服務器對磁盤讀寫操作很多，需要更快的磁盤和更大的內存
文件服務器存儲用戶上傳的文件，因此需要更大的磁盤空間
具體架構如下圖所示：
??????? 隨著用戶再增加，網站又會一次面臨挑戰：數據庫壓力太大導致整站訪問效率再此下降，用戶體驗受到影響。一個網站，往往 80% 的業務訪問集中在20% 的數據上，既然大部分業務訪問集中在一小部分數據上，那就把這一小部分數據先提前緩存在內存中，而不是每次都去數據庫讀取，這樣就可以減少數據庫的訪問壓力，從而提高整個網站的訪問速度。
具體架構如下圖所示：
?????? 使用緩存后，數據訪問壓力得到了緩解，但是單一應用服務器能夠處理的請求連接有限，在網站訪問高峰期，應用服務器就成了整個網站的效率瓶頸。使用分布式集群是網站解決高并發、海量數據問題的常用手段。當一臺服務器的處理能力和存儲空間不足時，不要嘗試去更換更強大的服務器，對大型網站而言，多么強大的服務器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一臺服務器分擔原有服務器的訪問及存儲壓力。
具體架構如下圖所示：
隨著網站業務越來越復雜，對數據檢索的需求也越來越復雜，網站需要采用一些搜索引擎，如elasticsearch。
具體架構如下圖所示：
? ? ? 大型網站為了應對日益復雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。
? ? ? 具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，同時不同的應用也對應不同的數據庫，將之同的大而統的業務數據進行解藕，拆分成多個數據，每個應用獨立部署。應用后臺通過http restful類的接口進行數據的處理，應用前臺可以通過一個超鏈接建立關系（在首頁上的導航鏈接每個都指向不同的應用地址），也可以通過消息隊列進行數據分發，報表類的系統建立獨立數據倉庫，具體架構如下圖所示：
?????? 在上圖的網絡架構，經常會遇到某個應用不可用導致整個系統不可用而出現雪崩，或者緩存服務器出現故障，導致數據庫壓力激增而出現雪崩，面對雪崩的應對策略大致如下：
1. 流量控制；
?????? 流量控制分為網關限流與用戶交互限流，網關限流可以采用nginx進行配置限流，用戶交互限流采用加載動畫,提高用戶的忍耐等待時間或提交按鈕添加強制等待時間機制
2. 改進緩存模式；
????? 同步改為異步刷新
3. 服務自動擴容；
????? AWS的auto scaling
4. 服務調用者降級服務；
????? 對調用服務與被調用的服務進行隔離
? ? ? 我們根據具體業務,將依賴服務分為: 強依賴和若依賴. 強依賴服務不可用會導致當前業務中止,而弱依賴服務的不可用不會導致當前業務的中止.
? ? 不可用服務的調用快速失敗一般通過超時機制來實現
