大(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)品管理 等，可以 把這些 共用 業務 抽取 出來 ，獨立 部署 。
