一直都對海量服務後臺架構很感興趣，最近看完了《大型網站技術架構 & 核心原理與案例分析（李智慧 著）》一書，涵蓋了大型網站架構的很多技術細節，寫得極其贊！這裡結合自己的一些見解，整理一個筆記出來。

// =======================================================================================

單伺服器LAMP

* 大學時期常搞的LAMP，Linux+Apache+Mysql+php，接入、應用程式、資料庫、檔案都在一臺伺服器。流量小，一臺機器綽綽有餘

* 增長瓶頸：機器功能耦合

PS：架構設計一個核心原則就是高內聚低耦合，將網站的接入、邏輯、儲存分開到專門的伺服器是首先考慮的

應用邏輯和儲存分離

* 3臺伺服器各司其職：應用伺服器（CPU），檔案伺服器（磁碟容量），資料庫伺服器（磁碟IO）

* 增長瓶頸：資料庫訪問壓力大

PS：資料庫最終會讀寫磁碟檔案，受到磁碟IO限制會首先成為瓶頸

引入快取減少資料庫讀寫

* 快取是後臺開發一種重要的方法，其背後遵循的是“區域性性原理”，也稱“28定律”：即日常80%的訪問會集中在20%的資料上。將這小部分“熱點”資料快取在記憶體中，就可以大大降低資料庫的訪問次數

* 快取分為2種，本地快取和分散式快取

1 本地快取：資料快取在應用伺服器上。優點是本地記憶體讀寫操作（納秒級），速度最快；缺點是記憶體大小受限，擴充套件性較差

2 分散式快取：資料快取在專用的快取伺服器上。優點是應用和儲存低耦合，專門伺服器維護，易擴充套件；缺點是讀寫需網路開銷（毫秒級）

* 快取資料更新：應用程式首先讀快取，讀不到資料時再訪問資料庫，並將讀到的資料寫入快取。如果這時快取是滿的，就必須淘汰一些已有資料，常用的淘汰演算法是LRU，即最近最少使用

* 增長瓶頸：應用伺服器併發處理能力

使用應用伺服器叢集提高網站併發處理能力

* “網站撐不住了，就拿機器頂！”，叢集是海量服務中解決高併發的常用手段

* 負載均衡：多臺應用伺服器，如何將前端請求均勻分發到各臺機器上，這就需要前端加一個負載均衡伺服器做請求分發。nginx簡單靈活的負載均衡策略被廣泛使用，常見的負載均衡演算法有輪詢、隨機、加權、來源地址hash等

增長瓶頸：資料庫負載過高

PS：當網站訪問量繼續上升，雖然加了快取，但是快取不命中及應用寫操作（當然也有隻寫快取的策略）還是需要訪問資料庫

資料庫讀寫分離

* 資料庫伺服器主從分離：一臺主資料庫伺服器（Master）負責寫操作，多臺從資料庫伺服器（Slave）負責讀操作，主伺服器被寫之後會同步資料變更到從伺服器

* 資料庫訪問模組封裝：將應用程式對資料庫的操作封裝成模組，使得後端資料庫讀寫分離等變更對應用程式透明（高內聚低耦合）

到目前為止，網站總體架構如下圖所示，已經能支撐起大部分網站的訪問需求了。當然，不單單是網站，這些架構關鍵點對任何海量服務的後臺開發都是相通的

當網站訪問繼續增加，有日均PV過億的趨勢，這時網站其實還有很多關鍵點可以繼續優化：

使用反向代理和CDN做網站檔案快取

* 將網站一些靜態檔案，如圖片、html頁面等快取在反向代理伺服器或者CDN伺服器，使用者的請求可以不用到達應用伺服器就返回資料給使用者。是網站加速、提高使用者體驗的2種常用手段

1 反向代理：部署在網站中心機房

2 CDN，即內容釋出系統：部署在網路提供商各地的機房，常用於視訊和圖片檔案的快取

使用分散式檔案系統

* 當一臺檔案伺服器滿足不了網站檔案儲存需求時，接下來應考慮的就是使用分散式檔案系統。HDFS、HBase等是當前海量檔案儲存比較熱門的方案

使用分散式資料庫和NoSQL

* 關係型資料庫的分散式是大型網站業務持續增長的最後手段，可通過不同業務模組分庫，相同業務模組分表等方法實現資料庫的分散式部署

* NoSQL相對於關係型資料庫有更簡單的資料結構，更高的效能及更好的可擴充套件性。但對業務需求的支援也相對有限。

應用邏輯的業務模組拆分

* 一個網站必定有多種業務模組，比如購物網站都有使用者模組、商品模組、訂單模組等等，將這些業務模組拆分並獨立維護。保證各業務模組高內聚低耦合，利於開發上團隊分工，也利於後期獨立部署運營

// =======================================================================================

大型網站架構設計的一些價值觀：

* 大道至簡。簡單的設計使開發和維護變得清晰有序

* 業務和功能的劃分和模組化。各業務模組，各功能模組（接入-邏輯-儲存）劃分清晰，高內聚低耦合，塵歸塵土歸土

* 架構來源於需求，而不是技術。架構設計衡量標準是滿足使用者的產品需求，而不是為了技術而技術

* 架構是演化而來的。別追求有完美的架構設計後再上線，好的架構往往都是不斷修改甚至推翻之後慢慢演化而來的

* 不要所有問題都用技術來解決。有些技術上難以解決的問題，往往可以用業務手段來解決，如12306的整點售票改為分時段售票，從業務上來平攤使用者請求量

* 衡量指標：效能、可用性、伸縮性、擴充套件性、安全性。