1. 大型網站系統的特點
- 高併發、大流量
- 高可用
- 海量數據
- 用戶分佈廣泛，網絡情況複雜
- 安全環境惡劣
- 需求快速變更，迭代頻繁
- 漸進式發展
2. 大型網站架構演化歷程
2.1. 初始階段架構
問題：網站運營初期，訪問用戶少，一臺服務器綽綽有餘。
特徵：應用程序、數據庫、文件等所有的資源都在一臺服務器上。
描述：通常服務器操作系統使用 linux，應用程序使用 PHP 開發，然後部署在 Apache 上，數據庫使用 Mysql，通俗稱為 LAMP。彙集各種免費開源軟件以及一臺廉價服務器就可以開始系統的發展之路了。
2.2. 應用服務和數據服務分離
問題：越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足，一臺服務器已不足以支撐。
特徵：應用服務器、數據庫服務器、文件服務器分別獨立部署。
描述：三臺服務器對性能要求各不相同：應用服務器要處理大量業務邏輯，因此需要更快更強大的 CPU；數據庫服務器需要快速磁盤檢索和數據緩存，因此需要更快的硬盤和更大的內存；文件服務器需要存儲大量文件，因此需要更大容量的硬盤。
2.3. 使用緩存改善性能
問題：隨著用戶逐漸增多，數據庫壓力太大導致訪問延遲。
特徵：由於網站訪問和財富分配一樣遵循二八定律：80% 的業務訪問集中在 20% 的數據上。將數據庫中訪問較集中的少部分數據緩存在內存中，可以減少數據庫的訪問次數，降低數據庫的訪問壓力。
描述：緩存分為兩種：應用服務器上的本地緩存和分佈式緩存服務器上的遠程緩存，本地緩存訪問速度更快，但緩存數據量有限，同時存在與應用程序爭用內存的情況。分佈式緩存可以採用集群方式，理論上可以做到不受內存容量限制的緩存服務。
2.4. 使用應用服務器集群
問題：使用緩存後，數據庫訪問壓力得到有效緩解。但是單一應用服務器能夠處理的請求連接有限，在訪問高峰期，成為瓶頸。
特徵：多臺服務器通過負載均衡同時向外部提供服務，解決單一服務器處理能力和存儲空間不足的問題。
描述：使用集群是系統解決高併發、海量數據問題的常用手段。通過向集群中追加資源，提升系統的併發處理能力，使得服務器的負載壓力不再成為整個系統的瓶頸。
2.5. 數據庫讀寫分離
問題：網站使用緩存後，使絕大部分數據讀操作訪問都可以不通過數據庫就能完成，但是仍有一部分讀操作和全部的寫操作需要訪問數據庫，在網站的用戶達到一定規模後，數據庫因為負載壓力過高而成為網站的瓶頸。
特徵：目前大部分的主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到一臺服務器上。網站利用數據庫的主從熱備功能，實現數據庫讀寫分離，從而改善數據庫負載壓力。
描述：應用服務器在寫操作的時候，訪問主數據庫，主數據庫通過主從複製機制將數據更新同步到從數據庫。這樣當應用服務器在讀操作的時候，訪問從數據庫獲得數據。為了便於應用程序訪問讀寫分離後的數據庫，通常在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離的對應用透明。
2.6. 反向代理和 CDN 加速
問題：中國網絡環境複雜，不同地區的用戶訪問網站時，速度差別也極大。
特徵：採用 CDN 和反向代理加快系統的靜態資源訪問速度。
描述：CDN 和反向代理的基本原理都是緩存，區別在於 CDN 部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器時反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶。
2.7. 分佈式文件系統和分佈式數據庫
問題：隨著大型網站業務持續增長，數據庫經過讀寫分離，從一臺服務器拆分為兩臺服務器，依然不能滿足需求。
特徵：數據庫採用分佈式數據庫，文件系統採用分佈式文件系統。
描述：分佈式數據庫是數據庫拆分的最後方法，只有在單表數據規模非常龐大的時候才使用。不到不得已時，更常用的數據庫拆分手段是業務分庫，將不同的業務數據庫部署在不同的物理服務器上。
2.8. 使用 NoSQL 和搜索引擎
問題：隨著網站業務越來越複雜，對數據存儲和檢索的需求也越來越複雜。
特徵：系統引入 NoSQL 數據庫及搜索引擎。
描述：NoSQL 數據庫及搜索引擎對可伸縮的分佈式特性具有更好的支持。應用服務器通過統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。
2.9. 業務拆分
問題：大型網站的業務場景日益複雜，分為多個產品線。
特徵：採用分而治之的手段將整個網站業務分成不同的產品線。系統上按照業務進行拆分改造，應用服務器按照業務區分進行分別部署。
描述：應用之間可以通過超鏈接建立關係，也可以通過消息隊列進行數據分發，當然更多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。
縱向拆分：將一個大應用拆分為多個小應用，如果新業務較為獨立，那麼就直接將其設計部署為一個獨立的 Web 應用系統。縱向拆分相對較為簡單，通過梳理業務，將較少相關的業務剝離即可。
橫向拆分：將複用的業務拆分出來，獨立部署為分佈式服務，新增業務只需要調用這些分佈式服務橫向拆分需要識別可複用的業務，設計服務接口，規範服務依賴關係。
2.10. 分佈式服務
問題：隨著業務越拆越小，存儲系統越來越龐大，應用系統整體複雜程度呈指數級上升，部署維護越來越困難。由於所有應用要和所有數據庫系統連接，最終導致數據庫連接資源不足，拒絕服務。
特徵：公共業務提取出來，獨立部署。由這些可複用的業務連接數據庫，通過分佈式服務提供共用業務服務。
3. 大型網站架構模式
3.1. 分層
大型網站架構中常採用分層結構，將軟件系統分為應用層、服務層、數據層：
- 應用層 - 負責具體業務和視圖展示。如網站首頁及搜索輸入和結果展示。
- 服務層 - 為應用層提供服務支持。如用戶管理服務、購物車服務等。
- 應用層 - 提供數據存儲訪問服務。如數據庫、緩存、文件、搜索引擎等。
分層架構的約束：禁止跨層次的調用（應用層直接調用數據層）及逆向調用（數據層調用服務層，或者服務層調用應用層）。
分層結構內部還可以繼續分層，如應用可以再細分為視圖層和業務邏輯層；服務層也可以細分為數據接口層和邏輯處理層。
3.2. 分割
將不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元。這有助於軟件的開發和維護，便於不同模塊的分佈式部署，提高網站的併發處理能力和功能擴展能力。
3.3. 分佈式
大於大型網站，分層和分割的一個主要目的是為了切分後的模塊便於分佈式部署，即將不同模塊部署在不同的服務器上，通過遠程調用協同工作。
分佈式意味可以用更多的機器工作，那麼 CPU、內存、存儲資源也就更豐富，能夠處理的併發訪問和數據量就越大，進而能夠為更多的用戶提供服務。
分佈式也引入了一些問題：
- 服務調用必須通過網絡，網絡延遲會影響性能
- 服務器越多，宕機概率也越大，是可用性降低
- 數據一致性非常困難，分佈式事務也難以保證
- 網站依賴錯綜複雜，開發管理維護困難
常用的分佈式方案：
- 分佈式應用和服務
- 分佈式靜態資源
- 分佈式數據和存儲
- 分佈式計算
3.4. 集群
集群即多臺服務器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。
集群需要具備伸縮性和故障轉移機制：伸縮性是指可以根據用戶訪問量向集群添加或減少機器；故障轉移是指，當某臺機器出現故障時，負載均衡設備或失效轉移機制將請求轉發到集群中的其他機器上，從而不影響用戶使用。
3.5. 緩存
緩存就是將數據存放在距離最近的位置以加快處理速度。緩存是改善軟件性能的第一手段。
網站應用中，緩存除了可以加快數據訪問速度以外，還可以減輕後端應用和數據存儲的負載壓力。
常見緩存手段：
- CDN
- 反向代理
- 本地緩存
- 分佈式緩存
使用緩存有兩個前提：
- 數據訪問熱點不均勻，頻繁訪問的數據應該放在緩存中
- 數據在某個時間段有效，不過很快過期，否則緩存數據會因已經失效而產生髒讀
3.6. 異步
軟件發展的一個重要目標和驅動力是降低軟件耦合性。事物之間直接關係越少，彼此影響就越小，也就更容易獨立發展。
大型網站架構中，系統解耦的手段除了分層、分割、分佈式等，還有一個重要手段——異步。
業務間的消息傳遞不是同步調用，而是將一個業務操作拆分成多階段，每個階段間通過共享數據的方式異步執行進行協作。
- 在單一服務器內部可通過多線程共享內存隊列的方式實現異步，處在業務操作前面的線程將操作輸出到隊列，後面的線程從隊列中讀取數據進行處理；
- 在分佈式系統中，多個服務器集群通過分佈式消息隊列實現異步。
異步架構是典型的生產者消費模式，二者不存在直接調用。異步消息隊列還有如下特性：
- 提高系統可用性
- 加快響應速度
- 消除併發訪問高峰
3.7. 冗餘
大型網站，出現服務器宕機是必然事件。要保證部分服務器宕機的情況下網站依然可以繼續服務，不丟失數據，就需要一定程度的服務器冗餘運行，數據冗餘備份。這樣當某臺服務器宕機是，可以將其上的服務和數據訪問轉移到其他機器上。
訪問和負載很小的服務也必須部署 至少兩臺服務器構成一個集群，目的就是通過冗餘實現服務高可用。數據除了定期備份，存檔保存，實現 冷備份 外；為了保證在線業務高可用，還需要對數據庫進行主從分離，實時同步實現 熱備份。
為了抵禦地震、海嘯等不可抗因素導致的網站完全癱瘓，某些大型網站會對整個數據中心進行備份，全球範圍內部署 災備數據中心。網站程序和數據實時同步到多個災備數據中心。
3.8. 自動化
大型網站架構的自動化架構設計主要集中在發佈運維方面：
- 發佈過程自動化
- 自動化代碼管理
- 自動化測試
- 自動化安全監測
- 自動化部署
- 運維自動化
- 自動化監控
- 自動化報警
- 自動化失效轉移
- 自動化失效恢復
- 自動化降級
- 自動化分配資源
3.9. 安全
- 密碼 和 手機校驗碼 進行身份認證
- 登錄、交易等重要操作需要對網絡通信進行 加密，存儲的敏感數據如用戶信息等也進行加密處理
- 防止機器人程序攻擊網站，使用 驗證碼 進行識別
- 對常見用於 攻擊 網站的 XSS 攻擊、SQL 注入、進行編碼轉換等相應處理
- 對垃圾信息、敏感信息進行 過濾
- 對交易轉賬等重要操作根據交易模式和交易信息進行 風險控制
4. 大型網站核心架構要素
架構 的一種通俗說法是：最高層次的規劃，難以改變的決定。
除了系統功能需求外，架構還需要關注以下架構要素：
4.1. 性能
性能問題無處不在，所以網站性能優化手段也十分繁多：
- 前端
- 瀏覽器緩存
- 靜態資源壓縮
- 合理佈局頁面
- 減少 cookie 傳輸
- CDN
- 應用服務器
- 本地緩存
- 分佈式緩存
- 異步消息隊列
- 集群
- 代碼層面：使用多線程、改善內存管理
- 數據庫
- 索引
- 數據庫緩存
- SQL 優化
4.2. 可用性
可用性指部分服務器出現故障時，還能否對用戶提供服務
- 冗餘自動化：通過預發佈驗證、自動化測試、自動化發佈、灰度發佈等手段，減少將故障引入線上環境的可能
- 通過負載均衡設備建立集群共同對外提供服務
- 數據存儲在多臺服務器，互相備份
4.3. 伸縮性
衡量伸縮的標準就是是否可以用多臺服務器構建集群，是否容易向集群中增刪服務器節點。增刪服務器節點後是否可以提供和之前無差別的服務。集群中可容納的總服務器數是否有限制。
- 應用服務器集群 - 只要服務器上保存數據，則所有服務器都是對等的，通過負載均衡設備向集群中不斷加入服務器即可
- 緩存服務器集群 - 加入新的服務器可能會導致緩存路由失效，進而導致集群中的大部分緩存數據都無法訪問。雖然緩存數據可以通過數據庫重新加載，但是如果應用嚴重依賴緩存，可能會導致網站崩潰。需要改進緩存路由算法保證緩存數據的可訪問性。
- 關係型數據庫集群 - 關係型數據庫雖然支持數據複製，主從熱備等機制，但是很難做到大規模集群的可伸縮性，因此關係型數據庫的集群伸縮性方案必須在數據庫之外實現，通過路由分區等手段將部署有多個數據庫的服務器組成一個集群。
- NOSql 數據庫集群 - 由於先天就是為了應對海量數據而產生，因此對伸縮性的支持通常都非常好。
4.4. 擴展性
衡量擴展性的標準就是增加新的業務產品時，是否可以實現對現有產品透明無影響，不需要任何改動或很少改動，既有功能就可以上線新產品。主要手段有：事件驅動架構和分佈式服務。
4.5. 安全性
安全性保護網站不受惡意攻擊，保護網站重要數據不被竊取。
歡迎工作一到五年的Java工程師朋友們加入Java程序員開發： 721575865
群內提供免費的Java架構學習資料（裡面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！
閱讀更多 JAVA柯尼塞克丶 的文章
