《大型網站技術架構：核心原理與案例分析》筆記
· 大型網站軟體系統的特點
· 大型網站架構演化發展歷程
· 初始階段的網站架構
· 需求/解決問題
· 架構
· 應用服務和資料服務分離
· 需求/解決問題
· 架構
· 使用快取改善網站效能
· 需求/解決問題
· 架構
· 使用應用伺服器叢集改善網站的併發處理能力
· 需求/解決問題
· 架構
· 資料庫讀寫分離
· 需求/解決問題
· 架構
· 使用反向代理和CDN加速網站響應
· 需求/解決問題
· 架構
· 使用分散式檔案系統和分散式資料庫系統
· 需求/解決問題
· 架構
· 使用NoSQL和搜尋引擎
· 需求/解決問題
· 架構
· 業務拆分
· 需求/解決問題
· 架構
· 分散式服務
· 需求/解決問題
· 架構
· 大型網站架構演化心得
· 大型網站架構模式
· 綜述
· 分層
· 概念
· 目的
· 舉例
· 分割
· 概念
· 目的
· 舉例
· 分散式
· 概念
· 目的
· 缺點
· 舉例
· 叢集
· 概念
· 目的
· 快取
· 概念
· 目的
· 舉例
· 非同步
· 概念
· 目的
· 冗餘
· 概念
· 目的
· 舉例
· 自動化
· 目的
· 舉例
· 安全
· 舉例
· 大型網站核心架構要素
· 效能
· 網站效能測試
· 不同視角下的網站效能
· 效能測試指標
· 效能測試方法
· 效能測試報告
· Web前端效能優化
· 瀏覽器訪問優化
· CDN加速
· 反向代理
· 應用伺服器效能優化
· 分散式快取
· 非同步操作
· 使用叢集
· 程式碼優化
· 儲存效能優化
· 可用性
· 網站可用性的度量與考核
· 度量
· 考核
· 網站架構高可用（總述）
· 應用層高可用
· 通過負載均衡進行無狀態服務失效轉移
· 應用伺服器叢集的Session管理
· 服務層高可用
· 資料層高可用
· CAP原理
· 資料備份
· 失效轉移
· 高可用網站軟體質量保證
· 網站釋出
· 自動化測試
· 預釋出驗證
· 程式碼控制
· 自動化釋出
· 灰度釋出
· 網站執行監控
· 監控資料採集
· 監控管理
· 伸縮性
· 網站架構的伸縮性設計
· 不同功能進行物理分離實現伸縮
· 單一功能通過叢集規模實現伸縮
· 應用伺服器叢集的伸縮性設計
· HTTP重定向負載均衡
· DNS域名解析負載均衡
· 反向代理負載均衡
· IP負載均衡
· 資料鏈路層負載均衡
· 負載均衡演算法
· 分散式快取叢集的伸縮性設計
· 資料儲存服務叢集的伸縮性設計
· 關係資料庫叢集的伸縮性設計
· NoSQL資料庫叢集的伸縮性設計
· 擴充套件性
· 擴充套件性與伸縮性
· 構建可擴充套件的網站架構
· 利用分散式訊息佇列降低系統耦合性
· 利用分散式服務打造可複用的業務平臺
· 安全性
· 網站應用攻擊與防禦
· XSS攻擊
· 注入攻擊
· CSRF攻擊
· Web應用防火牆
· 網站安全漏洞掃描
· 資訊加密技術及金鑰安全管理
· 單向雜湊加密
· 對稱加密
· 非對稱加密
· 金鑰安全管理
· 網購秒殺系統架構設計案例分析
· 秒殺活動的技術挑戰
· 秒殺系統架構設計
大型網站軟體系統的特點
與傳統企業應用相比，大型網際網路應用系統有以下特點：
1. 高併發，大流量；
2. 高可用：系統7×24小時不間斷服務；
3. 海量資料：需要儲存、管理海量資料，需要使用大量伺服器；
4. 使用者分佈廣泛，網路情況複雜：許多大型網際網路都是為全球使用者提供服務的，使用者分佈範圍廣，各地網路情況千差萬別；
5. 安全環境惡劣：由於網際網路的開放性，使得網際網路更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊；
6. 需求快速變更，釋出頻繁：和傳統軟體的版本釋出頻率不同，網際網路產品為快速適應市場，滿足使用者需求，其產品釋出頻率是極高的；
7. 漸進式發展：與傳統軟體產品或企業應用系統一開始就規劃好全部的功能和非功能需求不同，幾乎所有的大型網際網路網站都是從一個小網站開始，漸進地發展起來的。
大型網站架構演化發展歷程
初始階段的網站架構
需求/解決問題
小網站最開始沒有太多人訪問。
架構
應用程式、資料庫、檔案等所有的資源都在一臺伺服器上。
應用服務和資料服務分離
需求/解決問題
隨著網站業務的發展，越來越多的使用者訪問導致效能越來越差，越來越多的資料導致儲存空間不足。
架構
應用和資料分離後整個網站使用三臺伺服器，其對硬體資源的要求各不相同：應用伺服器處理大量業務邏輯，需要更快更強大的CPU；資料庫伺服器快速磁碟檢索和資料
快取，需要更快的磁碟和更大的記憶體；檔案伺服器儲存大量使用者上傳的檔案，需要更大的磁碟。
使用快取改善網站效能
需求/解決問題
使用者逐漸增多，資料庫壓力太大導致訪問延遲。
架構
根據二八定律：80%的業務訪問集中在20%的資料上，把小部分資料快取在記憶體中，可減少資料庫訪問壓力。
| 型別 |
原理 |
優點 |
缺點 |
| 本地快取 |
快取在應用伺服器 |
訪問速度更快 |
受應用伺服器記憶體限制 |
| 分散式快取 |
部署大記憶體快取伺服器叢集 |
理論上不受記憶體容量限制 |
-- |
使用應用伺服器叢集改善網站的併發處理能力
需求/解決問題
單一應用伺服器能夠處理的請求連線有限。
架構
Scale up有限，Scale out無限，所以應用伺服器要Scale out。
資料庫讀寫分離
需求/解決問題
一部分讀操作（快取訪問不命中、快取過期）和全部的寫操作需要訪問資料庫。
架構
應用伺服器寫資料時，訪問主資料庫，主資料庫通過主從複製機制將資料更新同步到從資料庫；當應用伺服器讀資料時，可通過從資料庫獲得資料。通常在應用伺服器端使用專門的資料訪問模組，使資料庫讀寫分離對應用透明。
使用反向代理和CDN加速網站響應
需求/解決問題
中國網路環境複雜，不同地區的使用者訪問網站時，速度差別極大，網站訪問延遲導致使用者流失率提高。
架構
CDN和反向代理目的都是儘早返回資料、加快訪問速度、減輕後端伺服器負載壓力。
1. CDN：部署在網路提供商機房。使用者請求網站服務時，可從距離自己最近的網路提供商機房獲取資料。
2. 反向代理：部署在網站中心機房。使用者請求到達中心機房後，首先訪問反向代理伺服器，如果反向代理伺服器快取著使用者請求的資源，就將其直接返回給使用者。
使用分散式檔案系統和分散式資料庫系統
需求/解決問題
讀寫分離伸縮性有限。
架構
只有在單表資料規模非常龐大的時候（不到萬不得已）才資料庫拆分，按業務分庫，不同的業務資料部署在不同的物理伺服器上。
使用NoSQL和搜尋引擎
需求/解決問題
隨著網站業務越來越複雜，對資料儲存和檢索的需求也越來越複雜。
架構
1. NoSQL和搜尋引擎都是源自網際網路的技術手段，可伸縮的分散式特性更好；
2. 應用伺服器通過一個統一資料訪問模組訪問各種資料。
業務拆分
需求/解決問題
業務場景日益複雜。
架構
1. 將整個網站業務分成不同產品線（如大型購物交易網站拆分為首頁、商鋪、訂單、買家、賣家），分歸不同業務團隊負責。
2. 根據產品線劃分，將網站拆分成不同應用，每個應用獨立部署維護。應用間關聯方式：
a) 超連結（首頁上導航連結每個應用地址）；
b) 通過訊息佇列進行資料分發；
c) 通過同一資料儲存系統構成一個關聯的完整系統（最多）。
分散式服務
需求/解決問題
所有應用要和所有資料庫系統連結，在數萬臺伺服器規模的網站中，連線數目時伺服器規模的平方，導致資料庫連線資源不足，拒絕服務。
架構
將共用的業務提取出服務，獨立部署。
大型網站架構演化心得
1. 大型網站架構技術的核心價值不是從無到有搭建一個大型網站，而是能夠伴隨小型網站業務的逐步發展，慢慢地演化成一個大型網站。
2. 驅動大型網站技術發展的主要力量時網站的業務發展。
3. 技術是用來解決業務問題的，而業務問題，也可以通過業務手段去解決。
a) 12306的問題不在於技術架構，而在於業務架構：幾億中國一票難求的情況下，零點開始出售若干天后的車票；
b) 解決：售票方式上引入排隊機制、整點售票調整為分時段售票。
大型網站架構模式
綜述
1. 模式：每一個模式描述了一個在我們周圍不斷重複發生的問題及該問題解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複工作。
2. 網站架構模式：大型網際網路公司在實踐中提出了許多解決方案，以實現網站高效能、高可用、易伸縮、可擴充套件、安全等各種技術框架目標。這些解決方案又被更多網站重複使用，從而逐漸形成大型網站架構模式。
分層
概念
1. 將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和呼叫組成一個完整的系統。
2. 實踐中，大的分層結構內部還可以繼續分層。
目的
1. 便於分工合作開發和維護；
2. 各層獨立，只要維持呼叫介面不變，各層可根據具體問題獨立演化發展而無需其他層必須相應調整；
3. 物理部署上，三層結構可部署在同一物理機器上，隨著網站業務發展，必然要分離部署，其三層結構分別部署在不同伺服器，使網站擁有更多計算資源應對更多使用者訪
問。
舉例
| 應用層 |
負責具體業務和檢視展示，如網站首頁及搜尋輸入和結果展示 |
| 服務層 |
為應用層提供服務支援，如使用者管理服務，購物車服務等 |
| 資料層 |
提供資料儲存訪問服務，如資料庫、快取、檔案、搜尋引擎等 |
分割
概念
1. 從縱向方面對軟體進行切分，將不同功能和服務分割開來，包裝成高內聚低耦合的模組單元。
2. 大型網站分割粒度可能會很小。
目的
1. 有助於軟體開發和維護；
2. 便於不同模組的分散式部署，提供網站的併發處理能力和功能擴充套件能力。
舉例
1. 在應用層，按業務分割為購物、論壇、搜尋、廣告不同的應用，獨立團隊負責，部署在不同伺服器；
2. 同一應用內部，如果規模龐大業務複雜，會繼續分割，比如購物業務分割為機票酒店業務、3C業務、小商品業務等更細小的粒度。
分散式
概念
分層和分割的一個主要目的是為了切分後的模組便於分散式部署，即不同模組部署在不同伺服器上，通過遠端呼叫協同工作。
目的
可使用更多的計算機完成同樣的功能，計算機越多，CPU、記憶體、儲存資源也越多，處理併發訪問和資料兩就越大。
缺點
1. 分散式服務呼叫必須通過網路，可能會影響效能；
2. 伺服器越多，伺服器宕機概率就越大；
3. 分散式環境資料一致性非常困難，分散式事務也難以保證；
4. 分散式導致網站依賴錯綜複雜，開發管理維護困難。
舉例
1. 分散式應用和服務：將分層和分割後的應用和服務模組分散式部署。
2. 分散式靜態資源：網站的靜態資源如JS、CSS、Logo圖片等資源獨立分散式部署，並採用獨立域名，即動靜分離。
3. 分散式資料和儲存：大型網站需處理以P為單位的海量資料，單臺計算機無法提供如此大的儲存空間，此時需分散式儲存。
4. 分散式計算：嚴格來說，應用、服務、實時資料處理都是計算，網站除了要處理這些線上業務，還有很大一部分後臺業務，包括搜尋引擎的索引構建、資料倉庫的資料分析統計等。
叢集
概念
通過負載均衡技術為一個應用構建一個多臺伺服器組成的叢集，共同對外提供服務。
目的
提高系統可用性。
快取
概念
將資料存放在距離計算最近的位置。
目的
加快處理速度。
舉例
1. CDN。
2. 反向代理。
3. 本地快取。
4. 分散式快取。
5. 以上4個都在前面章節已說明，不再贅述。
非同步
概念
1. 單一伺服器內部可通過多執行緒共享內部佇列方式實現非同步，業務操作前面的執行緒將輸出寫入佇列，後面的執行緒從佇列讀取資料處理。
2. 分散式系統中，多個伺服器叢集通過分散式訊息佇列實現非同步。
目的
1. 提高系統可用性：消費者伺服器發生故障，資料會在訊息佇列伺服器儲存堆積，生產伺服器可以繼續處理業務請求，系統整體表現無故障。消費者伺服器恢復正常後，繼續處理訊息佇列中的資料。
2. 加快網站響應速度：業務處理前端的生產著伺服器將資料寫入訊息佇列，無需等待消費者伺服器處理就可以返回，響應延遲減少。
3. 消除併發訪問高峰：使用者訪問網站是隨機的，雖然存在高峰和低谷，但突發事件（促銷活動、微博熱點事件）會造成網站併發訪問突然增大。使用訊息佇列將突然增加的訪問請求資料放入訊息佇列，等待消費者伺服器依次處理，減小網站負載壓力。
4. 解耦，提升擴充套件性。
5. 缺點：消費者伺服器處理（如業務校驗、寫資料庫）失敗，以訂單提交為例，可在成功提交後Email或簡訊通知使用者訂單成功，避免交易糾紛。
冗餘
概念
任何服務都必須部署至少兩臺伺服器構成的一個叢集。
目的
實現服務高可用。
舉例
1. 冷備份：定期備份，存檔儲存。
2. 熱備份：主從分離，實時同步。
自動化
目的
減少人為干預，減少故障。
舉例
1. 自動化釋出。
a) 自動化程式碼管理：程式碼版本控制、程式碼分支建立合併等過程自動化，開發工程師只要提交自己參與開發的產品代號，系統自動為其建立開發分支，後期自動合併程式碼。
b) 自動化測試：程式碼開發完成，提交測試後，系統自動將程式碼部署到測試環境，啟動自動化測試用例測試，向相關人員傳送測試報告，向系統反饋測試結果。
c) 自動化安全檢測：安全檢測工具對程式碼靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估安全性。
d) 自動化部署：將工程程式碼自動部署到線上生產環境。
2. 自動化監控。
a) 自動化報警：對線上生產環境自動化監控，對伺服器心跳檢測，及各項效能指標和應用程式的關鍵資料指標。如果發現異常、超出預設閥值，自動化向相關人員傳送報警，警告故障可能發生。
b) 自動化失效轉移：檢測到故障發生後，系統自動化將失效伺服器從叢集隔離，不再處理請求。
c) 自動化失效恢復：待故障消除後，系統自動化重新啟動服務，同步資料保證資料一致性。
d) 自動化降級：網站遇到訪問高峰，超出網站最大處理能力時，為保證整個網站安全可用，會自動化拒絕部分請求及關閉部分不重要服務將系統負載降至安全水平。
e) 自動化分配資源：將空閒資源分配給重要服務，擴大部署規模。
安全
舉例
1. 通過密碼和手機驗證碼身份認證。
2. 登入、交易等操作需網路通訊加密，網站伺服器上儲存的敏感資料也加密處理。
3. 使用驗證碼識別，防止機器人程式濫用網路資源攻擊網站。
4. 對常見的用於攻擊網站的XSS攻擊、SQL注入進行編碼轉換等處理。
5. 對垃圾資訊、敏感資訊過濾。
6. 對交易轉賬等重要操作根據交易模式和交易資訊進行風險控制。
大型網站核心架構要素
效能
網站效能測試
不同視角下的網站效能
1. 使用者視角：使用者在瀏覽器上直觀感受到的網站相應速度，包括使用者計算機和網站伺服器通訊的速度、網站伺服器處理的速度、使用者計算機瀏覽器構造請求解析響應資料的速度。
2. 開發人員視角：應用程式本身及其相關子系統的效能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。
3. 運維人員視角：基礎設施效能和資源利用率，如網路運營商的頻寬、伺服器硬體的配置、資料中心網路架構、伺服器和網路頻寬的資源利用率等。
效能測試指標
1. 響應時間
a) 解釋：從發出請求開始到收到最後響應資料所需要的時間。
b) 意義：系統最重要的效能指標。
c) 測試方法：測試程式通過模擬應用程式，記錄收到響應和發出請求之間的時間差；通常重複請求，取平均值。
d) 常用系統操作響應時間表。
| 操作 |
響應時間 |
| 開啟一個網站 |
幾秒 |
| 在資料庫中查詢一條記錄（有索引） |
十幾毫秒 |
| 機械磁碟一次定址定位 |
4毫秒 |
| 從機械磁碟順序讀取1MB資料 |
2毫秒 |
| 從SSD磁碟順序讀取1MB資料 |
0.3毫秒 |
| 從遠端分散式快取Redis讀取一個數據 |
0.5毫秒 |
| 從記憶體中讀取1MB資料 |
十幾微妙 |
| Java程式本地方法呼叫 |
幾微妙 |
| 網路傳輸2KB資料 |
1微妙 |
2. 併發數
a) 解釋：同時處理請求的數目，反映了系統的負載特性。網站併發數指“併發使用者數”。
b) 併發使用者數：同時提交請求的使用者數目。
c) 線上使用者數：當前登入網站的使用者數目。
d) 系統使用者數：可能訪問系統的總使用者數，對多數網站而言就是註冊使用者數。
e) 三者數量比較關係：系統使用者數>>線上使用者數>>併發使用者數。
f) 意義：網站產品設計初期，產品經理和運營人員要規劃不同發展階段網站系統使用者數，以此為基礎，推算線上使用者數和併發使用者數，這些指標是非功能設計的重要依據。
g) 測試方法：測試程式多執行緒模擬併發使用者測試併發處理能力；測試程式並不多執行緒不停傳送請求，而是兩次請求間加隨機等待時間，模擬使用者思考時間。
3. 吞吐量
a) 解釋：單位時間內系統處理的請求數量。
b) 常用量化指標：“請求數/秒”或“頁面數/秒”、“訪問人數/天”或“處理的業務數/小時”、TPS（每秒事務數）、HPS（每秒HTTP請求數）、QPS（每秒查詢數）。
c) 三者關係：併發數由小逐增過程中，伺服器資源消耗逐增，吞吐量逐增，響應時間小幅上升；達到吞吐量極限後，併發數增加反而下降，響應時間快速上升；達到系統崩潰點後，系統資源耗盡，吞吐量為零，失去響應。
4. 效能計數器
a) 解釋：描述伺服器或作業系統效能一些資料指標，包括System Load、物件與執行緒數、記憶體使用、CPU使用、磁碟與網路IO等。
b) 意義：系統監控的重要引數，監控系統發現效能計數器超過閥值時，向運維人員報警，及時發現處理異常。
c) System Load（系統負載）：當前正在被CPU執行和等待被CPU執行的程序數目總和，反映系統閒忙程度的重要指標。多核CPU情況下，Load值等於CPU數目時，說明所有CPU都在使用，沒有CPU不足和空閒；Load值大於CPU數目時，說明程序排隊等待CPU排程，資源不足；Load值小於CPU數目時，說明CPU空閒。Linux的“top”命令可查詢最近1分鐘、10分鐘、15分鐘的執行佇列平均程序數。
效能測試方法
1. 效能測試是總稱，細分為：
a) 效能測試：以系統設計初期規劃的效能指標為預期目標，不斷施加壓力（增加併發請求），驗證系統在資源可接受範圍，可否達到預期。
b) 負載測試：不斷施加壓力（增加併發請求），直到某項或多項效能指標達到安全臨界值（比如資源已飽和）。此時繼續加壓，系統處理能力會下降。
c) 壓力測試：超過安全負載情況下，不斷施加壓力（增加併發請求），直到系統崩潰或無法處理任何請求，依此獲得系統最大壓力承受能力。
d) 穩定性測試：被測試系統在特定硬體、軟體、網路環境下，載入一定業務壓力（模擬生產環境不同時間點、不均勻請求，呈波浪特性）執行一段較長時間，以此檢測系統是否穩定。
2. 效能測試曲線：橫座標為消耗的系統資源，縱座標為吞吐量。a~b為網站日常執行區間，c為系統最大負載點，d為系統崩潰點。
效能測試報告
| 併發數 |
響應時間（ms） |
TPS |
錯誤率（%） |
Load |
記憶體（GB） |
備註 |
| 10 |
500 |
20 |
0 |
5 |
8 |
效能測試 |
| 20 |
800 |
30 |
0 |
10 |
10 |
效能測試 |
| 30 |
1000 |
40 |
2 |
15 |
14 |
效能測試 |
| 40 |
1200 |
45 |
20 |
30 |
16 |
負載測試 |
| 60 |
2000 |
30 |
40 |
50 |
16 |
壓力測試 |
| 80 |
超市 |
0 |
100 |
不詳 |
不詳 |
壓力測試 |
Web前端效能優化
瀏覽器訪問優化
1. 減少HTTP請求：合併CSS、合併JavaScript、合併圖片。
2. 使用瀏覽器快取：CSS、JavaScript、Logo、圖示等靜態資原始檔更新頻率較低，通過HTTP頭Cache-Control和Expires設定快取數天，甚至幾個月。更新此類檔案時，不更新內容，而是修改檔名，生成新檔案並更新HTML引用。當有一批此類檔案要更新時，不宜一次全部更新，而是逐個更新，並有時間間隔，以免瀏覽器大量快取失效，集中更新快取，伺服器負載劇增。
3. 啟用壓縮：文字檔案（如HTML、CSS、JavaScript）GZip壓縮率可達80%以上，有效減少通訊傳輸資料量。但伺服器、瀏覽器壓力上升，所以要權衡。
4. CSS放在頁面最上面，JavaScript放在頁面最下面：瀏覽器下載全部CSS後才渲染頁面，而在載入JavaScript後立即執行，可能會阻塞頁面，渲染緩慢。
5. 減少Cookie傳輸：每次請求和響應都會包含Cookie，影響資料傳輸；靜態資源訪問（如CSS、JavaScript）傳送Cookie無意義。可靜態資源使用獨立域名，避免請求靜態資源時傳送Cookie。
CDN加速
前面章節已說明，不再贅述。
反向代理
前面章節已說明，不再贅述。
應用伺服器效能優化
分散式快取
1. 網站效能優化第一定律：優先考慮使用快取優化效能。
2. 快取有點：快取訪問速度快，減少資料訪問時間；如果快取的資料是經過計算得到的，則此類資料無需重複計算可直接使用。
3. 快取本質：以一對Key、Value形式儲存在記憶體的Hash表，讀寫時間複雜度O(1)。
4. 使用快取注意事項。
a) 頻繁修改的資料：如果快取頻繁修改的資料，會造成寫入快取後來不及讀取已失效。一般資料讀寫比應在2:1以上，甚至更高。
b) 沒有熱點的訪問：快取使用記憶體，資源寶貴，應遵循二八定律，即快取20%熱點資料。
c) 資料不一致與髒讀：一般設定快取失效時間，失效後從資料庫載入，因此要容忍一定時間的資料不一致。也可資料更新時立即更新快取，但會帶來更多系統開銷和事務一致性問題。
d) 快取可用性：為避免快取雪崩（快取不可用造成資料庫無法承受壓力而宕機），可將快取資料分佈到叢集多臺伺服器，宕機時只有部分快取資料丟失。
e) 快取預熱（warn up）：熱點資料是通過LRU（最近最久未用演算法）淘汰生成的，需較長時間。
f) 快取穿透：快取不存在的資料（其值為null），避免不恰當業務或惡意攻擊高併發請求某個不存在資料，造成資料庫壓力而崩潰。
非同步操作
前面章節已說明，不再贅述。
使用叢集
前面章節已說明，不再贅述。
程式碼優化
1. 多執行緒
a) 目的：利用多執行緒IO阻塞與執行交替進行，最大限度利用CPU資源；多執行緒最大限度利用多核CPU。
b) Web容器執行緒數設定：如果都是CPU計算型任務，則執行緒數最多不超過CPU核心數（更多執行緒CPU來不及排程）；如果都是等待磁碟IO、網路IO的任務，則多啟動執行緒有助於提高任務併發度，提高吞吐能力。
2. 資源複用：單例（Singleton）、物件池（Object Pool）。
3. 資料結構。
4. 垃圾回收：即優化JVM。
儲存效能優化
可能暫時不重要，以後需要時在看書。
可用性
網站可用性的度量與考核
度量
1. 業界通常用多少個9來衡量網站可用性。
2. 網站不可用也稱網站故障。
3. 網站不可用時間公式：
網站不可用時間（故障時間）= 故障修復時間點-故障發現（報告）時間點
4. 網站年度可用性指標公式：
網站年度可用性指標 =（1-網站不可用時間/年度總時間）×100%
5. 常見可用性：
| 可用性（9） |
可用性（百分比） |
網站不可用時間 |
說明 |
| 2個9 |
99% |
小於88小時 |
|
| 3個9 |
99.9% |
小於9小時 |
|
| 4個9 |
99.99% |
小於53分鐘 |
具有自動恢復能力 |
| 5個9 |
99.999% |
小於5分鐘 |
可用性極高 |
考核
1. 故障分：對網站故障進行分類加權計算故障責任的方法。
2. 網站故障分類權重表（示例）
| 分類 |
描述 |
權重 |
| 事故級故障 |
嚴重故障，網站整體不可用 |
100 |
| A類故障 |
網站訪問不順暢或核心功能不可用 |
20 |
| B類故障 |
非核心功能不可用，或核心功能少數使用者不可用 |
5 |
| C類故障 |
以上故障以外的其他故障 |
1 |
3. 故障分公式：
故障分=故障時間（分鐘）×故障權重
4. 考核過程：年初或考核季度開始時，根據網站產品可用性指標計算總的故障分，然後根據團隊和個人職責角色分攤故障分，這個可用性指標和故障分是管理預期；故障發生後，根據故障分類和責任劃分給故障產生的故障分分配給責任者承擔；年末或考核季度末時，個人及團隊實際承擔的故障分如果超過年度分攤的故障分，績效考核受到影響。
網站架構高可用（總述）
1. 以百度為例。
a) 應用層：文庫、貼吧、百科等屬不同產品，各自獨立部署叢集。
b) 服務層：應用層產品依賴共同的複用業務，這些業務服務各自部署叢集。
c) 資料層：各自部署叢集。
2. 實現高可用架構主要手段：資料和服務的冗餘備份及失效轉移。
3. 應用層高可用：通過負載均衡裝置將一組伺服器組成一個叢集對外處理高併發請求，負載均衡裝置通過心跳檢測等手段監控到應用伺服器不可用時，將其從叢集列表剔除，請求分發到叢集其他可用伺服器上。
4. 服務層高可用：也是通過叢集實現高可用。服務層被應用層通過分散式服務呼叫框架訪問，分散式服務呼叫框架在應用層客戶端中實現負載均衡，服務註冊中心獲取服務層伺服器心跳檢測，發現不可用伺服器，立即通知客戶端修改服務層訪問列表，剔除不可用伺服器（說的就是Dubbo）。
5. 資料層高可用：比較特殊，資料伺服器儲存了資料。資料寫入時同步複製資料到多臺伺服器上，實現資料冗餘備份；資料伺服器宕機時，資料訪問切換到備份資料伺服器上。
6. 網站升級釋出可能引起故障。
應用層高可用
通過負載均衡進行無狀態服務失效轉移
無狀態應用：應用伺服器不儲存業務的上下文資訊，而僅根據每次請求提交的資料處理業務邏輯，多臺伺服器之間完全對等，請求提交到任意伺服器結果一樣。是應用層高可用的基礎。
應用伺服器叢集的Session管理
事實上業務總是有狀態的（Session），負載均衡叢集環境下，負載均衡伺服器可能會將請求分發到叢集任何依他應用伺服器上，所以每次請求獲取正確的Session要比單機複雜。幾種手段：
1. Session複製：叢集各臺伺服器間同步Session物件，每臺伺服器都儲存所有使用者的Session資訊。伺服器記憶體無法儲存大量Session，不適合大型網站。
2. Session繫結：利用負載均衡的源地址Hash演算法，負載均衡伺服器總是將源於同一IP的請求分發到同一伺服器。伺服器宕機Session丟失，無法高可用，不適合大型網站。
3. 利用Cookie記錄Session：Cookie大小限制；每次請求響應都傳輸Cookie，影響效能；使用者關閉Cookie將不正常。Cookie簡單易用，可用性高，支援應用伺服器線性伸縮，許多網站或多或少都使用Cookie記錄Session。
4. Session伺服器：利用分散式快取、資料庫等存取Session，實現應用伺服器的狀態分離。可用性高、伸縮性好、效能不錯，適合大型網站。
服務層高可用
1. 分級管理。
a) 核心應用和服務優先使用更好的硬體和更快的運維響應速度。
b) 部署隔離，避免故障連鎖反應：低優先順序服務啟動不同執行緒或部署在不同虛擬機器上隔離；高優先順序服務部署在不同物理機上；核心服務和資料甚至部署在不同地域的資料中心。
2. 超時設定：在應用程式設定服務呼叫超時時間，超時後通訊框架丟擲異常，避免因伺服器宕機、執行緒死鎖導致應用程式對服務端呼叫失去響應，進而使用者請求長時間得不到響應，同時佔用應用程式資源。
3. 非同步呼叫：前面章節已說明，不再贅述。
4. 服務降級：有兩種手段。
a) 拒絕服務：拒絕低優先順序應用的呼叫，減少併發數，確保核心應用正常呼叫；隨機拒絕部分請求呼叫，讓另一部分請求成功，避免大家一起死的餐具。
b) 關閉服務：關閉部分不重要服務或服務內部關閉部分不重要功能，節約開銷。
5. 冪等性設計：應用層只要未收到呼叫成功的響應，都認為呼叫服務失敗，並重試服務呼叫，因此服務層必須保證服務重複呼叫和呼叫一次的結果相同，即服務具有冪等性。
資料層高可用
CAP原理
1. 資料高可用含義。
a) 資料永續性：在各種情況下都不會出現資料丟失問題。
b) 資料可訪問性：多資料副本分別存放在不同儲存裝置情況下，失效轉移能很快完成（終端使用者幾乎沒有感知）。
c) 資料一致性：多資料副本情況下，各副本之間資料一致。
2. CAP原理：一個提供資料服務的儲存系統無法同時滿足資料一致性（Consistency）、資料可用性（Availability）、分割槽耐受性（Partition Tolerance）這三個條件。
3. 大型網站實踐：通常選擇強化分散式儲存系統的可用性（A）和伸縮性（P），而在某種程度上放棄一致性（C）。一般資料不一致出現在系統高併發寫操作或叢集狀態不穩定（故障恢復、叢集擴容等）時，應用系統要對分散式資料處理系統的資料不一致性有了解並進行某種意義上的補償和糾錯，以保證最終一致性。
4. 舉例：2012年淘寶“雙十一”，活動開始第一分鐘就湧入1000萬獨立使用者訪問，極端的高併發對資料處理系統造成巨大壓力，儲存系統較弱的資料一致性導致部分商品超賣。
資料備份
1. 冷備。
a) 優點：簡單、廉價，成本和技術難度都較低。
b) 缺點：無法保證資料一致性（備份裝置中的資料比系統中的資料陳舊）。
c) 現狀：作為傳統的資料保護手段依然在運維中使用。
2. 熱備。
a) 非同步熱備：多份資料副本的寫入操作非同步完成，即應用程式收到資料服務系統的寫操作成功響應時，只寫成功了一份，儲存系統將非同步地寫其他副本（該過程可能失敗）。
b) 同步熱備：多份資料副本的寫入操作同步完成，即應用程式收到資料服務系統的寫成功響應時，多份資料都已經寫操作成功。
3. 同步熱備優化：應用程式客戶端併發向多個儲存伺服器同時寫入資料，所有寫操作成功響應後，再通知應用程式成功。優點：儲存伺服器無主從之分，完全對等，便於管理維護；併發寫操作意味著多份資料的總寫操作延時是響應最慢的那臺儲存服務響應。
4. 實際：通常使用讀寫分離，寫操作只訪問Master資料庫，讀操作只訪問Slave資料庫。
失效轉移
1. 失效確認：有心跳檢測和應用程式訪問失敗報告兩種手段。對於後者，控制中心還要再一次傳送心跳檢測確認，以免錯誤判斷伺服器宕機。
2. 訪問轉移：將資料讀寫訪問重新路由到其他伺服器上。
3. 資料恢復：資料副本數目已減少，必須將副本數目恢復到系統設定的值，否則再有宕機可能無法訪問轉移（所有副本伺服器宕機）。
高可用網站軟體質量保證
網站釋出
1. 網站釋出是一次提前預知的伺服器宕機，過程可以更柔和，對使用者影響更小。
2. 通常使用釋出指令碼完成釋出。
自動化測試
1. 目的：迴歸測試，以保證沒有引入未預料的Bug；測試瀏覽器相容性。
2. 實際：大部分網站採用Web自動化測試，使用自動化測試工具或指令碼完成測試。如Selenium。
預釋出驗證
1. 原因：測試環境和線上環境不同，特別是應用依賴的服務（如資料庫、快取、功用業務服務、電信簡訊閘道器、銀行網銀介面等）。
2. 方法：先發布到預釋出上，工程師在預釋出伺服器上驗證（如執行典型業務流程）後，確認無誤才正式釋出。預釋出伺服器與線上正式伺服器唯一的區別是沒有配置在負載均衡伺服器上，外部使用者無法訪問。
程式碼控制
1. 主幹開發、分支釋出：在主幹上修改程式碼，釋出時，從主幹拉一個分支釋出；如果發現Bug，繼續在該分支上修改釋出，並將修改合併回主幹。
a) 優點：主幹程式碼反映整個應用的狀態，一目瞭然，便於管理，也利於持續整合。
b) 缺點：A功能釋出的時候，B功能時半成品，導致A無法釋出。
2. 分支釋出、主幹釋出：不得在主幹上直接修改，開發新功能或修復Bug時，從主幹拉一個分支開發，完成且測試通過後，合併回主幹，然後從主幹釋出，主幹上程式碼永遠是最新發布的版本。
a) 優點：各分支獨立，互不干擾，使不同釋出週期的開發在同一應用進行。
b) 網站開發主要使用該方式。
自動化釋出
1. 固定釋出日期：很多網站選擇週四作為釋出日，這樣一週前面有三天時間準備釋出，後面還有一天時間可以挽回錯誤。如果選擇週五釋出，發現問題就必須要週末加班了。
2. 火車釋出模型：每個應用釋出過程看作一次火車旅行，火車定點執行，期間有若干站點，每一站都例行檢查，不通過的專案下車，剩下的下專案繼續坐火車旅行，直到火車到到終點（釋出成功）。有可能所有專案都下車，那麼空車前進是沒意義的，火車要回到起點，等待問題解決再重來。還有可能車上有重點專案，他出了錯，大家都跟著重來。
3. 火車釋出模型基於規則驅動流程，所以可以自動化。
灰度釋出
1. 目的：大型網站叢集規模非常龐大，故障發生後回滾需要很長時間完成。
2. 方法：將叢集伺服器分為若干部分，每天只發布其中一部分，觀察穩定無故障後，持續幾天才把整個叢集全部發布完畢，期間發現問題，只要回滾已釋出的一部分伺服器。
網站執行監控
監控資料採集
廣義上網站監控涵蓋所有非直接業務行為的資料採集和管理，包括資料分析師和產品設計師的網站使用者行為日誌、業務執行資料，運維工程師和開發工程師使用的系統性能資料等。
1. 使用者行為日誌收集：使用者在瀏覽器上的所有操作及其操作環境，包括作業系統、瀏覽器版本、IP地址、頁面訪問路徑、網頁停留時間等，對統計網站PV/UV、分析使用者行為、優化網站設計、個性營銷與推薦非常重要。
a) 伺服器端日誌收集：優點是簡單，Web伺服器都支援；缺點是失真（如代理伺服器IP非真實IP），無法識別訪問路徑。
b) 瀏覽器日誌收集：優點是精準；缺點是比較麻煩，在頁面嵌入JavaScript收集。
c) 日誌處理：資料量驚人，儲存和計算壓力大，許多網站基於實時計算框架Storm日誌統計與分析。
2. 伺服器效能監控：收集伺服器效能指標，如系統Load、記憶體佔用、磁碟IO、網路IO等。
a) 目的：儘早故障預警，防患於未然；合理安排叢集規模、改善效能和調整伸縮性的依據。
b) 工具：Zabbix、Ganglia、Nagios。
監控管理
1. 系統預警：超過預設閥值意味著可能出現故障，此時通過郵件、簡訊等方式報警。
2. 失效轉移：除應用程式訪問時失效轉移，監控系統在發現故障時主動通知應用失效轉移。
3. 自動優雅降級：前面章節已說明，不再贅述。
伸縮性
網站架構的伸縮性設計
不同功能進行物理分離實現伸縮
1. 方法：不同伺服器部署不同服務，提供不同功能。
2. 縱向分離（分層後分離）：將業務處理流程上的不同部分分離部署，實現伸縮性。
3. 橫向分離（業務分割後分離）：將不同的業務模組分離部署，實現伸縮性。
單一功能通過叢集規模實現伸縮
方法：叢集內的多臺伺服器部署相同服務，提供相同功能。
應用伺服器叢集的伸縮性設計
1. 負載均衡器：HTTP請求分發裝置。
2. 負載均衡：同時實現伸縮性和可用性，可謂網站的殺手鐗。
HTTP重定向負載均衡
1. 原理：HTTP重定向伺服器根據使用者的HTTP請求計算一臺真實Web伺服器地址，將該地址寫入HTTP重定向響應（狀態碼302）返回使用者瀏覽器。
2. 優點：簡單。
3. 缺點：瀏覽器兩次請求伺服器才能完成一次訪問；302狀態碼重定向可能使搜尋引擎判斷為SEO作弊，降低搜尋排名。
4. 實際：不多見。
DNS域名解析負載均衡
1. 原理：DNS伺服器中配置多個A記錄（如www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3），每次域名解析請求都會根據負載均衡演算法計算一個IP地址返回。
2. 優點：負載均衡交給DNS，省去維護負載均衡伺服器的麻煩；DNS支援基於地理位置的解析，即解析距離使用者最近的伺服器地址。
3. 缺點：伺服器下線時，更新DNS解析生效時間較長；DNS負載均衡控制權在域名服務商，無法對其更多改善和管理。
4. 實際：大型網站使用DNS解析作為第一級負載均衡，即解析得到的一組伺服器是內部負載均衡伺服器，再由內部負載均衡伺服器分發到真是Web伺服器。
反向代理負載均衡
1. 原理：反向代理同時實現了快取和負載均衡功能；Web伺服器不使用外部IP地址，由反向代理伺服器配置雙網絡卡和內外兩套IP地址。
2. 優點：反向代理伺服器功能集中，部署簡單。
3. 缺點：反向代理伺服器是所有請求的響應的中轉站，效能可能成為瓶頸。
IP負載均衡
1. 原理：負載均衡伺服器114.10.80.10在作業系統核心程序獲取網路資料包，根據負載均衡演算法計算得到一臺Web伺服器10.0.0.1，再將資料目的IP地址修改為10.0.0.1，無需使用者程序處理；Web伺服器10.0.0.1響應後，負載均衡伺服器再將資料包源地址修改為自身IP地址114.10.80.10，傳送給瀏覽器。
2. 優點：在核心程序完成資料分發，較反向代理負載均衡（應用程式分發）效能更好。
3. 缺點：與反向代理負載均衡相同。
資料鏈路層負載均衡
1. 原理：三角傳輸模式；直接路由方式（DR）；負載均衡伺服器只在資料鏈路層修改目的MAC地址，配置真實物理伺服器所有機器虛擬IP與負載均衡伺服器IP地址一致，即可不修改資料包源地址和目的地址進行分發；真實物理伺服器IP與資料請求目的IP一致，無需通過負載均衡伺服器就可響應資料返回瀏覽器。
2. 優點：避免負載均衡伺服器成為瓶頸。
3. 實際：大型網站使用最廣的負載均衡。Linux上最好的開源產品是LVS（Linux Virtual Server）。
負載均衡演算法
1. 輪詢（Round Robin，RR）：所有請求依次分發到每臺伺服器，適合所有伺服器硬體都相同的場景。
2. 加權輪詢（Weight Round Robin，WRR）：輪詢基礎上，按照配置的權重將請求分發到每臺伺服器，高效能的伺服器分配更多請求。
3. 隨機（Random）：請求隨機分發到每臺伺服器，也可加權隨機。
4. 最少連線（Least Connections）：記錄每臺伺服器正在處理請求（連線）數，將新請求分發到最少連線伺服器，最符合負載均衡定義，也可加權最少連線。
5. 源地址雜湊（Source Hashing）：根據請求來源IP地址的Hash值，得到伺服器，同一IP地址請求總在一臺伺服器上處理。
分散式快取叢集的伸縮性設計
1. 分散式快取叢集特點：叢集中各伺服器資料不同，快取訪問請求不可以在任意一臺處理，必須先找到有快取資料的伺服器才能訪問。
2. 分散式快取叢集訪問原理：以寫快取Memcached為例，應用程式輸入資料<'BEIJING',DATA>，API將KEY('BEIJING')輸入路由演算法模組，路由演算法根據KEY和叢集伺服器列表計算得到一臺伺服器編號NODE1和IP地址、埠；API呼叫通訊模組將資料寫入伺服器NODE1。
3. 分散式快取的一致性Hash演算法：可解決伸縮性問題，但演算法介紹Memcached且複雜，可能會使用Redis代替，以後再看。
資料儲存服務叢集的伸縮性設計
關係資料庫叢集的伸縮性設計
1. 主從複製：利用關係資料庫資料複製功能，進行簡單伸縮。
2. 分庫：不同業務資料表部署在不同資料庫叢集上。制約條件是跨庫不能join操作。
3. 分片：對某些單表資料量大的表（如Facebook使用者表、淘寶商品表），將一張表拆分儲存在多個數據庫。
a) 比較成熟的支援資料分片的開源分散式關係資料庫產品：Amoeba、Cobar。
b) 分散式關係資料庫特點：限制了關係資料庫某些功能；海量資料壓力不得不利用分散式關係資料庫伸縮。
c) 分散式關係資料庫注意：避免事務或利用事務補償機制代替資料庫事務；分解資料訪問邏輯避免join操作。
NoSQL資料庫叢集的伸縮性設計
NoSQL特點：放棄了關係資料庫的以關係代數為基礎的結構化查詢語言（SQL）和事務一致性保證（ACID），而強化大型網站關注的高可用性和可伸縮性。
擴充套件性
擴充套件性與伸縮性
1. 擴充套件性（Extensibility）：對現有系統影響最小的情況下，系統功能可持續擴充套件或提升的能力。
2. 伸縮性（Scalability）：系統能夠通過增加（減少）自身資源規模的方式增強（減少）自己計算處理事務的能力。
構建可擴充套件的網站架構
1. 設計網站可擴充套件架構的核心思想是模組化，並在此基礎上降低模組間的耦合性，提高模組複用性。
2. 模組化的重要手段：分層和分割，分層、分割為若干個低耦合的獨立元件模組（模組可分散式部署，從物理上分離模組間耦合），各模組以訊息傳遞及依賴呼叫方式聚合