架構演化

架構的演化

• 如下參考《大型網站技術架構》
• 架構的演化是隨着業務的增加而發生變化的。架構發展到今天，已經成長了不少。可是不能盲目地採用大公司的架構模式，這會增長大量的開發和運維的工做。因此須要根據具體的業務增加採用恰當的架構
• 可是最小型的架構也至少須要兩個實例，以保證系統的穩定性

初始

應用程序、數據庫、文件等全部的資源都在一臺服務器上

應用服務和數據服務分離

• 應用服務器：須要處理大量的業務邏輯，須要更快更強大的 CPU
• 數據庫服務器：須要快速磁盤檢索和數據緩存，要更快的硬盤和更大的內存
• 文件服務器：更大的硬盤

使用緩存

數據庫訪問壓力太大，或者二八定律（80% 的業務集中在 20% 的數據上）。因此對這小部分數據進行緩存。

應用服務器集羣

單一的應用服務器處理能力不足，經過負載均衡調度

數據庫讀寫分離

讀的操做能夠訪問緩存，可是仍有一部分讀操做（緩存不命中、緩存過時）和所有的寫操做須要訪問數據庫。用戶到達必定規模，數據庫負載壓力太高，成爲瓶頸。

利用數據庫提供的主從熱備功能，配置數據庫主從關係，實現讀寫分離。

使用方向代理和 CDN 加速網站響應

CDN: 內容分發網絡

CDN 和反向代理的基本原理都是緩存。CDN 找距離最近的網絡提供商機房獲取數據；若是反向代理服務器中緩存着用戶請求的資源，就直接放回給用戶。

使用分佈式文件系統和分佈式數據庫系統

數據庫拆分手段首先考慮根據業務分庫，不得以時才使用分佈式數據庫。

NoSQL 和 搜索引擎

對數據存儲和檢索的須要愈來愈複雜，應該程序經過統一的數據訪問模塊訪問數據，減輕應用程序管理諸多數據源的麻煩。

業務拆分

根據產品線劃分，分紅許多不一樣的應用。應用之間經過連接、消息隊列和同一數據存儲系統構成一個關聯的完整系統。

分佈式服務(SOA、微服務)

將共用的業務提取出來，獨立部署。以達到複用服務的效果。