大型互聯網架構概述，看完文章又漲知識了

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. 安全性

安全性保護網站不受惡意攻擊，保護網站重要數據不被竊取。