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