◆大型網站 的特點 :
高并發 、大流量:需要 面對 高并發 用戶 ,大流量訪問 。
高可用 :需要 7x24 小時 不間斷 服務 。
海量數據 :數據 需要 存儲 、管理 ,需要 大量 服務器 。
用戶 分步 廣泛 、網絡 情況 復雜 :全球 網絡 復雜 ,像國內 還有 各個 運營商網絡互通 難的問題 。
安全 環境惡劣 :互聯網 開放性 ,使得 網站 易受到 攻擊 。
需求 快速 變更 ,發布 頻繁 :快速迭代。
漸進式 發展 :從小 網站 開始 ,逐漸 發展 成大 站點 。
◆大型網站 的主要 技術 挑戰
龐大 的用戶 ,高并發 的訪問 和海量數據 。
任何 簡單 業務 在處理 PB級數據 或數以億計的用戶 時,問題 就會 變得 棘手 。
◆大型 網站架構 的演化過程
◆初始 階段 的網站架構
大多數 小項目 的初期 架構 都是 這樣 。
隨著 網站 業務發展 ,1臺服務器 無法 滿足需求:用戶 越來越多 ,網站 性能 越來越 差,越來越多 的數據 導致 存儲空間 不足 。
◆應用 、數據庫 、文件 分離
應用服務 與數據服務 分離 :提高 性能 ,解決 存儲 問題 。
【服務器 專用化】
應用服務器 :處理 業務 ,要求 CPU 強
文件服務器 :存儲 文件 ,要求 存儲容量 大
數據庫 服務器 :存儲 數據 、緩存 、磁盤 檢索 ,要求 內存 、硬盤速度快
隨著 用戶量 增多 ,數據庫 壓力大 ,會成為 系統 瓶頸 。
◆用緩存 改善 網站 性能
二八定律 :80 %的業務 訪問 20 %的數據 。
所以 常用 數據 放入 緩存 ,可以 減少 數據庫 的壓力 。
緩存 分為 兩種 :
本地 緩存 :訪問 更快,但受應用服務器 內存 限制 ,且會出現 和應用程序 爭用內存 的情況 。
分布式緩存:集群 方式 ,專用 服務器 作為 緩存服務器 ,理論上不受 內存容量 限制 。
目前 只有 單個 應用服務器 ,且只部署 了一個 實例 ,其能夠 處理 的連接數 有限 ,在網站訪問 高峰期 時,應用服務器 會變成 瓶頸 。
◆使用 應用 集群 改善 網站 的并發 能力
一臺 服務器 的處理 能力不足時,不要 考慮 去換更強大 的服務器 ,對于 大型網站 而言 ,不管 多么 強大 的服務器 ,都滿足 不了 網站 持續增長 的業務 需求 。
最好 的方式 是添加 更多 的服務器 來分擔 原有 服務器 的訪問 。
◆數據庫 讀寫分離
數據庫 還存在 的的問題 :使用 緩存 后,依然 會有 部分 讀操作 (緩存 沒有 命中 ,緩存 過期 等)和所有 的寫操作 需要 訪問 數據庫 。
在網站 用戶 達到 一定 規模 后,數據庫 依然 會因為 負載 較高成為 系統 瓶頸 。
解決辦法 :采用 數據庫 讀寫分離,兩臺 數據庫 配置 主從關系 ,從主庫 寫數據 ,從從 庫讀數據 ,主庫 的數據 會同步 到從庫中。
為了 便于 應用程序 能夠 透明 地訪問 讀寫分離的數據庫 ,所以 在應用程序 中使用 專門 的數據 訪問 模塊 。
◆使用 反向代理 緩存 和CDN 加速 網站 響應 :網絡環境 復雜 ,緩存 前端 靜態 資源
請求 訪問 存在的問題 :隨著 網站 持續 的發展 ,發現 不同 網絡環境 的用戶 訪問速度 不同 。
解決辦法 :使用 反向代理 緩存 和CDN 加速 網站 響應 。
CDN 和反向代理 的基本原理 :都是 緩存 ,區別 在于 CDN 部署 在網絡 提供商 的機房 ,使用戶 在請求 網站服務 時,可以 從距離 自己 最近 的網絡 提供商 機房 獲取數據 ;而反向代理 則部署 在網站 的中心 機房 中,從用戶 請求 達到 中心 機房 后,首先 訪問 的服務器 是反向代理 服務器 ,如果 反向代理 服務器 中緩存 著用戶 請求 的資源 ,就將其直接 返回 給用戶 。
CDN 和反向代理 的目的 :盡早 返回 數據 給用戶 ,一方面 加快 用戶 訪問速度 ,另一方面 減輕 應用服務器 的負載 壓力 。
◆使用 分布式文件系統 和分布式 數據庫系統
隨著 網站 業務發展 ,原有 讀寫分離的數據庫 也不能 支撐 。
另外 ,原有 的文件服務器 也無法 滿足需求了。
這時 ,需要 使用 分布式 數據庫 和分布式文件系統 。
分布式 數據庫 是網站 數據庫 拆分 的最后 手段 ,只有 在單表 數據 規模 非常 龐大 時才使用 。
網站 更常用 的數據庫 拆分 手段 是業務 分庫 ,將不同 的業務 數據 部署 在不同 的物理服務器上。
◆使用 NoSQL和搜索引擎
隨著 業務 越來越 復雜 ,對數據存儲 和檢索 的需求 也越來越 復雜 ,網站 需要 采用 NoSQL和非數據庫查詢 技術 比如 搜索引擎 。
◆業務 拆分 (分治 )
網站 過于 復雜 ,將業務 拆分 。
比如 商城 拆分為 首頁 、店鋪 、訂單 、買家 、賣家 等產品線 ,歸不同 的業務 團隊 負責 。
具體 到技術 ,也會根據 產品線 劃分 ,將一個網站 拆分為 多個 應用 ,每個 應用 獨立 部署 維護 。
應用 之間 可以 通過 一個 超鏈接 建立 關系 (在首頁 的導航 鏈接 指向 不同 的應用 地址 ),也可以 通過 消息隊列 進行 數據 分發 ,當然 最多 的還是 通過 訪問 同一個 數據 存儲系統 來構成 一個 關聯 的完整 系統 。
◆分布式服務
業務 拆分 越來越 小,存儲系統 越來越大,應用系統 整體 復雜度 呈指數型增加 ,部署 維護 越來越 困難 。
由于 所有 應用 都需要 連接數據庫 ,在數萬 臺服務器 的情況 下,數據庫連接 會資源 不足 。
既然 每個 應用系統 都需要 相同 的業務 操作 ,比如 用戶管理 、商品管理 等,可以 把這些 共用 業務 抽取 出來 ,獨立 部署 。