《大型網站技術架構：核心原理與案例分析》筆記

目錄

· 大型網站軟件系統的特色

· 大型網站架構演化發展歷程

    · 初始階段的網站架構

        · 需求/解決問題

        · 架構

    · 應用服務和數據服務分離

        · 需求/解決問題

        · 架構

    · 使用緩存改善網站性能

        · 需求/解決問題

        · 架構

    · 使用應用服務器集羣改善網站的併發處理能力

        · 需求/解決問題

        · 架構

    · 數據庫讀寫分離

        · 需求/解決問題

        · 架構

    · 使用反向代理和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.一、www.mysite.com IN A 114.100.80.二、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. 模塊化的重要手段：分層和分割，分層、分割爲若干個低耦合的獨立組件模塊（模塊可分佈式部署，從物理上分離模塊間耦合），各模塊以消息傳遞及依賴調用方式聚合成完整系統。

利用分佈式消息隊列下降系統耦合性

1. 事件驅動架構（Event Driven Architecture）：經過在低耦合的模塊之間傳輸事件消息，以保持模塊的鬆散耦合，並藉助事件消息的通訊完成模塊間合做。典型的EDA架構就是生產者消費者模式。大型網站最多見是分佈式消息隊列，利用發佈/訂閱模式工做。

2. 分佈式消息隊列。

    a) 原理：前面章節已說明，再也不贅述。

    b) 伸縮性：新服務器加入消息隊列集羣事，修改生產者服務器的消息隊列服務器列表便可。

    c) 可用性：爲避免消費者進程處理緩慢、消息隊列服務器內存不足等問題，若是內存隊列已滿，消息會被寫入磁盤；爲避免消息隊列服務器宕機，生產者服務器會保存消息直至消息真正被消費者服務器處理後才刪除，若是消息隊列服務器宕機，生產者服務器會選擇分佈式消息隊列集羣中其餘服務器發送。

    d) 開源Apache ActiveMQ實現了可用性、伸縮性、數據一致性、性能和可管理性等。

利用分佈式服務打造可複用的業務平臺

1. 縱向拆分：將一個大應用拆分爲多個小應用，若是新增業務較爲獨立，那麼直接部署爲一個獨立的Web應用。

2. 橫向拆分：將複用的業務拆分，獨立部署爲分佈式服務，新增業務只須要調用這些分佈式服務，無需依賴具體模塊代碼。

3. 不使用WebServices的理由：

    a) 臃腫的註冊與發現機制；

    b) 低效的XML序列化手段；

    c) 開銷較高的HTTP遠程通訊；

    d) 複雜的部署和維護手段；

    e) 沒法解決大型網站高性能、高可用、易部署、易維護的要求。

4. 大型網站分佈式服務的需求與特色：

    a) 註冊與發現；

    b) 負載均衡

    c) 失效轉移；

    d) 高效的遠程通訊：核心服務天天調用次數數以億計；

    e) 整合異構系統：服務可能使用不一樣語言開發並部署不一樣平臺；

    f) 對應用最小侵入；

    g) 版本管理：支持服務接口的多版本發佈，方便服務調用者使用未升級的舊接口；

    h) 實時監控。

5. 開源分佈式服務框架：阿里巴巴Dubbo、Facebook Thrift。

安全性

網站應用攻擊與防護

XSS攻擊

1. 攻擊：即跨站腳本攻擊（Cross Site Script），攻擊者經過篡改網頁，注入惡意HTML腳本，在用戶瀏覽器網頁時，控制用戶瀏覽器進行惡意操做。

    a) 反射型：攻擊者誘使用戶點擊一個嵌入惡意腳本的鏈接，達到攻擊目的。

    b) 持久型：攻擊者提交含有惡意腳本的請求，保存在被攻擊的Web站點的數據庫，用戶瀏覽網頁時，惡意腳本被包含在正常網頁中，達到攻擊目的。

2. 防護。

    a) 消毒：對某些HTML危險字符轉義，如「>」轉義爲「&gt;」、「<」轉義爲「&lt;」。

    b) HttpOnly：瀏覽器禁止JavaScript訪問帶有HttpOnly屬性的Cookie。沒法防護XSS，但可防止XSS攻擊者竊取Cookie。

注入攻擊

1. SQL攻擊：攻擊者在HTTP請求中注入惡意SQL（如drop table users），服務器用請求參數構造數據庫SQL時，惡意SQL被一塊兒執行。

2. 獲取數據庫表結構的手段。

    a) 開源：網站採用開源軟件（如Discuz!）搭建，已公開。

    b) 錯誤回顯：若是網站開啓錯誤（服務器內部500）回顯，攻擊者構造非法參數，使異常信息輸出到瀏覽器。

    c) 盲注：若是網站關閉錯誤回顯，攻擊者根據頁面變化判斷SQL執行狀況，猜想表結構。

3. 防護：使用預編譯，綁定參數。

4. 其餘注入攻擊：OS命令、編程語言代碼。

CSRF攻擊

1. 攻擊：跨站請求僞造（Cross Site Request Forgery），攻擊者經過跨站請求，以合法用戶身份進行非法操做。核心是利用瀏覽器Cookie或服務器Session盜取用戶身份。

2. 防護。

    a) 表單Token：頁面表單增長一個隨機數做爲Token，每次響應頁面Token都不一樣，僞造的請求沒法得到Token，服務器檢查該Token合法性。

    b) 驗證碼：請求提交時，需用戶輸入驗證碼，但驗證碼用戶體驗變差。

    c) Referer check：HTTP請求頭Referer記錄請求來源，驗證其合法性。不少網站利用該功能實現圖片防盜鏈。

Web應用防火牆

ModSecurity是一個開源Web應用防火牆，既可嵌入Web應用服務器，也可獨立部署。最先是Apache一個模塊，支持Nginx。

網站安全漏洞掃描

安全漏洞掃描工具根據內置規則，構造具備攻擊性的URL請求，模擬攻擊者攻擊行爲，以發現漏洞。

信息加密技術及密鑰安全管理

單向散列加密

1. 解釋：經過對不一樣輸入長度的信息進行散列計算，獲得固定長度的輸出，散列計算過程是單向的，即不能對固定長度輸出進行計算得到輸入信息。

2. 場景：密碼加密保存。

3. 常見算法：MD五、SHA。

對稱加密

1. 解釋：加密和解密使用的密鑰是同一個密鑰（或者能夠相互推算）。

2. 場景：信息需安全交換或存儲的場合，如Cookie加密、通訊加密。

3. 優勢：加解密效率高，系統開銷小，適合大量數據加密。

4. 常見算法：DES、RC。

非對稱加密

1. 解釋：加密和解密使用的密鑰不是同一密鑰，一個公鑰，一個私鑰。

2. 場景：信息安全傳輸，數字簽名場合。

3. 常見算法：RSA。

密鑰安全管理

1. 應用程序調用加解密服務接口對信息加解密。

2. 加解密服務接口經過密鑰服務器獲取加解密密鑰，並緩存在本地（定時更新）。

3. 密鑰服務器中的密鑰來自多個密鑰存儲服務器，一個密鑰分片後存儲在多個存儲服務器。

4. 密鑰申請者、密鑰管理者、安全審覈人員經過密鑰管理控制檯管理更新密鑰，沒有人能查看完整的密鑰。

網購秒殺系統架構設計案例分析

秒殺活動的技術挑戰

1. 對現有網站業務形成衝擊：活動時間短、併發訪問量大，若是和網站原有應用部署在一塊兒，必然對現有業務衝擊。

2. 高併發下的應用、數據庫負載：秒殺開始前，用戶不斷刷新瀏覽器頁面保證不錯過，請求若是按通常網站應用架構，會對應用服務器、數據庫服務器形成極大負載。

3. 忽然增長的網絡及服務器帶寬：假設秒殺頁面大小200KB（主要是商品圖片），那麼所需帶寬是200KB×10000=2GB。

4. 直接下單：秒殺開始前，只能瀏覽，不容許下單。

秒殺系統架構設計

 

1. 秒殺系統獨立部署：獨立部署，甚至獨立域名，使其與網站徹底隔離，即便秒殺系統奔潰，也不影響網站。

2. 秒殺頁面靜態化：將商品描述、商品參數、成交記錄和用戶評價所有寫入靜態頁面，請求無需訪問應用服務器和數據庫服務器。

3. 秒殺頁面儘可能簡單：節約帶寬；用戶關心可否進入下單頁面，而不是商品詳情等用戶體驗細節。

4. 租借秒殺網絡帶寬：向運營商從新購買或租借帶寬；秒殺頁面緩存在CDN，需向CDN服務商臨時租借新增出口帶寬。

5. 動態生成隨機下單頁面URL：爲避免用戶直接訪問下單頁面URL，該URL必須動態化，在下單頁面URL加入服務器生成的隨機數做爲參數，秒殺開始時才能得到。

6. 控制秒殺頁面購買按鈕點亮：該頁面引用包含是否開始和下單頁面URL隨機數的JavaScript文件，秒殺開始時才生成該文件被瀏覽器加載。爲避開緩存，該文件在CDN、反向代理服務器緩存，並使用隨機版本號。

7. 只容許第一個提交的訂單被髮送到訂單子系統：秒殺最終只有一個訂單提交成功，爲減輕服務器負載，可控制只有少數用戶（根據集羣處理能力肯定個數）能進入下單頁面，其餘用戶直接進入秒殺結束頁面。