讀書筆記-大型網站技術架構
1. 大型網站架構演化
1.1 大型網站軟體系統的特點
大型網際網路應用系統的特點
-高併發，大流量
-高可用
-海量資料
-使用者分佈廣泛，網路情況複雜
-完全環境惡劣
-需求快速變更，釋出頻繁
-漸進式發展
1.2 大型網站架構演化發展歷程
1） 初始階段
舉例來說： 作業系統Linux, 開發語言： PHP, Web伺服器： Apache, 資料庫： MySQL
2）應用服務和資料服務分離
改進： 網站的併發處理能力， 資料儲存空間
挑戰：資料庫壓力大導致訪問延遲
3）使用快取改善網站效能
快取在應用伺服器上的本地快取
快取在專門的分散式快取伺服器上的遠端快取
挑戰：
單一應用伺服器能夠處理的請求連線有限
4）使用應用伺服器叢集改善網站的併發處理能力
5) 資料庫讀寫分離
配置兩臺資料庫主從關係
應用程式在寫資料的時候，訪問主資料庫，主資料庫通過從複製機將資料同步到從資料庫。
6）使用反向代理和CDN加速網站響應
CDN和反向代理的基本原理都是快取，CDN部署在網站提供商的機房，使使用者在請求網站服務時，可以從距離自己最近的網路提供商機房獲取資料；反向代理部署在網站的中心機房，當使用者請求到達中心機房後，首先訪問的伺服器是反向代理伺服器，如果反向代理伺服器中快取著使用者請求的資源，則直接返回給使用者。
7）使用分散式檔案系統和分散式資料庫系統
網站常用的資料庫拆分手段是業務分庫。
8）使用NoSQL和搜尋引擎
9）業務拆分
將一個網站拆分成許多不同的應用，每個應用獨立部署維護。應用之間通過超連結建立關係，也可以通過訊息佇列進行資料分發，更多的還是通過訪問同一個資料儲存系統來構成一個關聯的完整系統。
10）分散式服務
將共用的業務提取出來，獨立部署。
1.3 大型網站架構演化的價值觀
關注網站為使用者提供什麼價值。關注能做什麼，而不在於它是怎麼做的。
1.3.1 大型網站架構技術的核心價值是隨網站所需靈活應對
1.3.2 驅動大型網站技術發展的主要力量是網站業務的發展
1.4 當中架構設計誤區
1） 一味追隨大公司的解決方案
2） 為了技術而技術
3） 企圖用技術解決所有問題
2. 大型網站架構模式
2.1 網站架構模式
1） 分層
將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和呼叫組成一個完整的系統。
一般分為：
應用層：負責具體業務和檢視展示，如網站首頁及搜尋輸入和結果展示， 還可細分為檢視層和業務邏輯層
服務層：為應用層提供服務支援，如使用者管理服務； 還可細分為資料介面層和邏輯處理層
資料層：提供資料儲存訪問服務，如資料庫、快取、檔案、
禁止跨層次呼叫和逆向呼叫
2）分割
在縱向方面對軟體進行切分
將不同的功能和服務分割開來，包裝成高內聚低耦合的模組單元。4
3）分散式
問題：
a. 服務呼叫通過網路，對效能造成影響
b.伺服器多， 當機概率增大
c.資料一致性比較困難，分散式事務的處理
d. 開發管理維護困難
常見的分散式方案：
分散式應用和服務
分散式靜態資源
分散式資料和儲存：NoSQL
分散式計算： Hadoop , MapReduce
分散式配置，分散式鎖，分散式檔案系統
4）叢集
5）快取
CDN： 快取網站的一些靜態資源
反向代理
本地快取
分散式快取
快取前提條件：
a. 資料訪問熱點不均衡
b. 資料某個時間段內有效，不會很快過期
6) 非同步
單一伺服器通過多執行緒共享記憶體佇列的方式實現非同步，在分散式系統中，多個伺服器叢集通過分散式訊息佇列實現非同步，分散式訊息佇列可以看作是記憶體佇列的分散式部署。
非同步訊息佇列的特徵：
a. 提供系統可用性
b. 加快網站響應速度
c. 消除併發訪問高峰
7）冗餘
資料冗餘備份，冷備份與主從熱備份
伺服器叢集
8）自動化
釋出運維自動化
-自動化程式碼管理
-自動化測試
-自動化安全檢測
-自動化部署
-自動化監控
-自動化報警
-自動化失效轉移
-自動化失效恢復
-自動化降級
-自動化分配資源
9）安全
密碼，手機驗證碼； 驗證碼； 過濾，風險控制
2.2 架構模式在新浪微博的應用
分為三個層次
最下層是基礎服務層，提供資料庫、快取、儲存、搜尋等資料服務，和其他一些基礎技術服務，這些服務支撐了海量資料和高併發訪問， 是整個系統的技術基礎
中間是平臺服務和應用服務層，這些服務被分割為獨立的服務模組，通過依賴呼叫和共享基礎資料構成業務基礎
最上層是API和業務層，各種客戶端和第三方應用，通過呼叫API整合到系統，組成一個生態系統。
3. 大型網站核心架構要素
架構 - 最高層次的規劃，難以改變的決定
軟體架構 - 有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計
需要考慮要素： 系統功能需求， 效能，可用性，伸縮性，擴充套件性和安全性
3.1 效能
效能優化手段
在瀏覽器端-通過瀏覽器快取、頁面壓縮、合理佈局頁面、減少Cookie傳輸等
使用CDN,將網站靜態內容分發至離使用者最近的網路服務商機房，使使用者通過最短訪問路徑獲取資料。在網站機房部署反向代理伺服器，快取熱點檔案，加快請求響應速度，減輕應用伺服器負載壓力。
在應用伺服器端-使用伺服器本地快取和分散式快取，通過快取在記憶體中的熱點資料處理使用者請求，加快請求處理過程，減輕資料庫負載壓力。
通過非同步操作將使用者請求傳送至訊息佇列等待後續任務處理， 當前請求直接返回響應給使用者
將多臺應用伺服器組成一個叢集共同對外服務，提高整理處理能力，改善效能。
在程式碼層面，通過使用多執行緒，改善記憶體管理等手段優化效能。
在資料庫伺服器端，- 索引，快取，SQL優化。 NoSQL資料庫優化資料模型、儲存結構，伸縮特性
衡量網站的效能指標： 響應時間， 系統效能計數器等。高併發訪問
３.２ 可用性
＞ ９９９．９９％
高可用設計的目標是當伺服器當機的時候， 服務或者應用依然可用。
網站高可用的主要手段是冗餘，應用部署在多臺伺服器上同時提供訪問， 資料儲存在多臺伺服器上相互備份。
多臺應用伺服器通過負載均衡組成叢集，任何一臺當機，把請求切換到其他伺服器，前提條件是應用伺服器不能儲存請求的會話資訊。
儲存伺服器，實時備份。
除了執行環境， 軟體開發過程的質量保證， 通過預釋出驗證、自動化測試、自動化釋出、灰度釋出等手段，減少將故障引入線上環境的可能，避免故障範圍擴大。
３.３ 伸縮性
所謂伸縮性是指通過不斷向叢集中加入伺服器的手段來緩解不斷上升的使用者併發訪問壓力和不斷增長的資料儲存需求。
衡量架構伸縮性的主要標準就是是否可以用多臺伺服器構建叢集，是否容易向叢集中新增新的伺服器。加入新的伺服器後是否可以提供和原來的伺服器無差別的服務。叢集中可容納的總的伺服器數量是否有限制。
應用伺服器叢集，通過使用合適的負載均衡裝置就可以向叢集中不斷加入伺服器。
快取伺服器叢集，加入新的服務可能會導致快取路由失效，進而導致叢集中大部分快取資料都無法訪問。雖然可以通過資料庫重新載入，但如果應用嚴重依賴快取，可能會導致整個網站崩潰。需要改進快取路由演算法保證快取資料的可訪問性。
關聯式資料庫的叢集伸縮方案必須在資料庫之外實現，通過路由分割槽等手段將部署有多個伺服器的資料庫組成一個叢集。
3.4 擴充套件性
網站的擴充套件性架構直接關注網站的功能。
主要手段是事件驅動架構和分散式服務。
事件驅動架構通常利用訊息佇列實現。
分散式服務則是將業務和可複用分離開來，通過分散式服務框架呼叫。
3.5 安全性
4. 瞬時響應-網站的高效能架構
網站效能指標：
客觀指標：響應時間、吞吐量 等
主觀指標：使用者的感受
4.1 網站效能測試
4.1.1 不同視角下的網站效能
1.使用者視角的網站效能
計算機效能差異、瀏覽器解析HTML速度、不同網路運營商提供的網際網路寬頻服務都會產生影響。
前端優化手段：優化頁面HTML樣式、利用瀏覽器端的併發和非同步特性、調整瀏覽器快取策略、使用CDN服務、反向代理等手段。
2. 開發人員視角的網站效能
響應時間、系統吞吐量、併發處理能力、系統穩定性。
優化手段： 快取加速資料讀取，叢集提高吞吐能力，使用非同步訊息加快請求響應及實現削峰，使用程式碼優化手段改善效能。
3. 運維人員視角的網站效能
關注基礎設施效能和資源利用率， 如網路運營商的頻寬能力、伺服器硬體配置、資料中心網路架構、伺服器和網路頻寬的資源利用率。
優化手段： 建設優化骨幹網、使用高價效比定製伺服器、利用虛擬化技術優化資源利用。
4.1.2 效能測試指標
從開發和測試人員的角度：
1.響應時間
發出請求到最後響應資料所需要的時間
常用系統操作響應時間表：
重複請求的方式進行測試。
2. 併發數
網站併發使用者數，同時提交請求的使用者資料數目。
通過多執行緒模擬併發使用者的方法來測試。
3.吞吐量
單位時間內系統處理的請求數量，體現系統的整體處理能力。
衡量指標：
請求數/秒； 頁面數/秒； 訪問人數/天； 處理的業務數/小時
TPS-每秒事務數， HPS-每秒HTTP請求數，QPS-每秒查詢數。
場景模擬：
在系統併發數由小逐漸增大的過程中， 系統資源消耗逐漸增大，系統吞吐量先是逐漸增加，達到一個極限後， 隨著併發數的增加反而下降，達到系統崩潰點後，系統資源耗盡，吞吐量為0.
在此過程中，響應時間則是先保持小幅上升，到達吞吐量極限後，快速上升，到達系統崩潰點後，系統失去響應。
形象比喻一下：
吞吐量是每天高速收費站通過的車輛數目，併發是正在行駛的車輛數目，響應時間是車速。
網站效能優化的目的，除了改善使用者體驗的響應時間，還要儘量提高系統吞吐量，最大限度利用伺服器資源。
4.效能計數器
是描述伺服器或作業系統的一些資料指標， 包括：
System Load; 物件與執行緒數； 記憶體使用； CPU使用； 磁碟與網路I/O等指標
4.1.3 效能測試方法
效能測試； 負載測試 ； 壓力測試； 穩定性測試
4.1.4 效能測試報告
一個例子：
4.1.5 效能優化策略
1.效能分析
2.效能優化： Web前段效能優化， 應用伺服器效能優化， 儲存伺服器效能優化
4.2 Web前端效能優化
Web前端功能： 瀏覽器載入；網站檢視模型；圖片服務； CDN服務等
主要優化手段： 優化瀏覽器訪問；使用反向代理、CDN等
4.2.1 瀏覽器訪問優化
1. 減少http請求
HTTP協議是無狀態的應用層協議，每次HTTP請求都要建立通訊鏈路、進行資料傳輸
在服務端， 每個HTTP都需要啟動獨立的執行緒去處理。
2.使用瀏覽器快取
設定HTTP頭中的Cache-Control和Expires.
更新靜態資源時，採取批量更新的方法。
3.啟用壓縮
Gzip 壓縮。 壓縮對伺服器和瀏覽器會產生一定的壓力，在通訊頻寬良好，而伺服器資源不足的情況下要權衡考慮。
4. CSS放在頁面 最上面， JavaScript放在頁面最下面。
瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染。
瀏覽器再載入JavaScript後立即執行，有可能阻塞整個頁面，造成頁面顯示緩慢。但如果頁面解析時就需要用到Javascript,放在底部就不合適了。
5.減少Cookie傳輸
可以考慮靜態資源使用獨立域名訪問，避免請求靜態資源時傳送Cookie,減少Cookie傳輸的次數。
4.2.2 CDN加速
CDN- Content Distribute Network,內容分發網路。
本質仍然是一個快取，將資料快取在離使用者最近的地方。
CDN能夠快取的一般是靜態資源。
4.2.3 反向代理
傳統代理伺服器位於瀏覽器一側，反向代理伺服器位於網站機房一側。
作用： 保護網站， 通過配置快取加速Web請求，負載均衡。
4.3 應用伺服器效能優化
4.3.1 分散式快取
網站效能優化第一定律： 優先考慮使用快取優化效能。
合理使用， 不合理使用快取非但不能提高系統的效能，還會成為系統的累贅，甚至風險。
頻繁修改的資料、沒有熱點的訪問等狀況不適合使用快取。
快取預熱： 熱點資料是計算出來的，新啟動的快取系統沒有任何資料，在重建快取資料的過程中，系統的效能和資料庫負載都不太好，在快取系統啟動時就把熱點資料載入好。
快取穿透：將不存在的資料也快取起來（value值為null）
分散式快取架構
在多個伺服器組成的叢集中， 以叢集方式提供快取服務。
一種是以JBoss Cache為代表的需要更新同步的分散式快取。
一種是以Memcache為代表的不相互通訊的分散式快取。
JBoss Cache, 將應用程式和快取部署在同一臺伺服器上，應用程式從本地快速獲取快取資料。
缺點: 受限於單一伺服器的記憶體空間，當叢集規模很大時，快取更新資訊需同步到叢集所有機器，代價驚人。
多用於企業應用系統中， 大型網站較少使用。
大型網站快取量一般很龐大， 需要數TB的記憶體作快取。
Memcache採用一種集中式的快取叢集管理， 也稱作互不通訊的分散式架構方式。
快取系統部署在一組專門的伺服器上， 應用程式通過一致性Hash等路由演算法選擇快取伺服器遠端訪問快取資料，快取伺服器之間不通訊，快取叢集的規模很容易實現擴容， 具有良好的可伸縮性。
Memcached記憶體管理方式：
4.3.2 非同步操作
使用訊息佇列呼叫非同步化， 可改善網站的擴充套件性 和網站系統的效能。
4.3.3 使用叢集
負載均衡技術
4.3.4 程式碼優化手段
1. 多執行緒
解決執行緒安全的主要手段：
1） 將物件設計為無狀態物件。物件本身不儲存狀態資訊（物件無成員變數，或者成員變數也是無狀態物件）。比如： Servlet物件，貧血模型物件。不過從物件導向設計角度看，無狀態物件是一種不良設計。
2）使用區域性物件。
3） 併發訪問資源時使用鎖。鎖會導致現場同步執行，可能會對系統效能產生嚴重影響。
2. 資源複用
減少開銷很大的資源的建立和銷燬，比如資料庫連線、網路通訊連線、執行緒、複雜物件等。從變成角度，資源複用主要有兩種模式：單例和物件池。
3. 資料結構
Time33 演算法- Hash雜湊演算法， 對字串逐字元迭代乘以33， 減少Hash表的衝突。
Time33 雖然可以很好地解決衝突，但是有可能相似字串的HashCode也比較接近，一個可行的方案是對字串取資訊指紋，再對資訊指紋求HashCode.
4.垃圾回收
減少Full GC
4.4 儲存效能優化
4.4.1 機械硬碟 VS. 固態硬碟
4.4.2 B+樹 VS. LSM樹
傳統關係型資料庫使用B+樹對資料排序儲存，加快資料檢索速度，保證資料在不斷更新、插入、刪除後依舊有序。B+樹是一種專門針對磁碟儲存而優化的N叉排序樹，以樹節點為單位儲存在磁碟中，從根節點開始查詢所需資料所在的節點編號和磁碟位置，將其載入到記憶體後繼續查詢，直到找到所需資料。
許多NoSQL產品採用LSM樹作為主要資料結構：
4.4.3 RAID vs. HDFS
RAID-廉價磁碟冗餘陣列。實現資料在多塊磁碟上的併發讀寫和資料備份。
HDFS - Hadoop 分散式檔案系統。
HDFS以塊（Block）為單位管理檔案內容， 一個檔案被分割成若干個Block,當應用程式寫檔案時，每寫完一個Block,HDFS就將其自動複製到另外兩臺機器上，保證每個Block有三個副本，即使有兩臺伺服器當機，資料依然可以訪問，相當於實現了RAID1的資料複製功能。
1.1 大型網站軟體系統的特點
大型網際網路應用系統的特點
-高併發，大流量
-高可用
-海量資料
-使用者分佈廣泛，網路情況複雜
-完全環境惡劣
-需求快速變更，釋出頻繁
-漸進式發展
1.2 大型網站架構演化發展歷程
1） 初始階段
舉例來說： 作業系統Linux, 開發語言： PHP, Web伺服器： Apache, 資料庫： MySQL
2）應用服務和資料服務分離
改進： 網站的併發處理能力， 資料儲存空間
挑戰：資料庫壓力大導致訪問延遲
3）使用快取改善網站效能
快取在應用伺服器上的本地快取
快取在專門的分散式快取伺服器上的遠端快取
挑戰：
單一應用伺服器能夠處理的請求連線有限
4）使用應用伺服器叢集改善網站的併發處理能力
5) 資料庫讀寫分離
配置兩臺資料庫主從關係
應用程式在寫資料的時候，訪問主資料庫，主資料庫通過從複製機將資料同步到從資料庫。
6）使用反向代理和CDN加速網站響應
CDN和反向代理的基本原理都是快取，CDN部署在網站提供商的機房，使使用者在請求網站服務時，可以從距離自己最近的網路提供商機房獲取資料；反向代理部署在網站的中心機房，當使用者請求到達中心機房後，首先訪問的伺服器是反向代理伺服器，如果反向代理伺服器中快取著使用者請求的資源，則直接返回給使用者。
7）使用分散式檔案系統和分散式資料庫系統
網站常用的資料庫拆分手段是業務分庫。
8）使用NoSQL和搜尋引擎
9）業務拆分
將一個網站拆分成許多不同的應用，每個應用獨立部署維護。應用之間通過超連結建立關係，也可以通過訊息佇列進行資料分發，更多的還是通過訪問同一個資料儲存系統來構成一個關聯的完整系統。
10）分散式服務
將共用的業務提取出來，獨立部署。
1.3 大型網站架構演化的價值觀
關注網站為使用者提供什麼價值。關注能做什麼，而不在於它是怎麼做的。
1.3.1 大型網站架構技術的核心價值是隨網站所需靈活應對
1.3.2 驅動大型網站技術發展的主要力量是網站業務的發展
1.4 當中架構設計誤區
1） 一味追隨大公司的解決方案
2） 為了技術而技術
3） 企圖用技術解決所有問題
2. 大型網站架構模式
2.1 網站架構模式
1） 分層
將系統在橫向維度上切分成幾個部分，每個部分負責一部分相對比較單一的職責，然後通過上層對下層的依賴和呼叫組成一個完整的系統。
一般分為：
應用層：負責具體業務和檢視展示，如網站首頁及搜尋輸入和結果展示， 還可細分為檢視層和業務邏輯層
服務層：為應用層提供服務支援，如使用者管理服務； 還可細分為資料介面層和邏輯處理層
資料層：提供資料儲存訪問服務，如資料庫、快取、檔案、
禁止跨層次呼叫和逆向呼叫
2）分割
在縱向方面對軟體進行切分
將不同的功能和服務分割開來，包裝成高內聚低耦合的模組單元。4
3）分散式
問題：
a. 服務呼叫通過網路，對效能造成影響
b.伺服器多， 當機概率增大
c.資料一致性比較困難，分散式事務的處理
d. 開發管理維護困難
常見的分散式方案：
分散式應用和服務
分散式靜態資源
分散式資料和儲存：NoSQL
分散式計算： Hadoop , MapReduce
分散式配置，分散式鎖，分散式檔案系統
4）叢集
5）快取
CDN： 快取網站的一些靜態資源
反向代理
本地快取
分散式快取
快取前提條件：
a. 資料訪問熱點不均衡
b. 資料某個時間段內有效，不會很快過期
6) 非同步
單一伺服器通過多執行緒共享記憶體佇列的方式實現非同步，在分散式系統中，多個伺服器叢集通過分散式訊息佇列實現非同步，分散式訊息佇列可以看作是記憶體佇列的分散式部署。
非同步訊息佇列的特徵：
a. 提供系統可用性
b. 加快網站響應速度
c. 消除併發訪問高峰
7）冗餘
資料冗餘備份，冷備份與主從熱備份
伺服器叢集
8）自動化
釋出運維自動化
-自動化程式碼管理
-自動化測試
-自動化安全檢測
-自動化部署
-自動化監控
-自動化報警
-自動化失效轉移
-自動化失效恢復
-自動化降級
-自動化分配資源
9）安全
密碼，手機驗證碼； 驗證碼； 過濾，風險控制
2.2 架構模式在新浪微博的應用
分為三個層次
最下層是基礎服務層，提供資料庫、快取、儲存、搜尋等資料服務，和其他一些基礎技術服務，這些服務支撐了海量資料和高併發訪問， 是整個系統的技術基礎
中間是平臺服務和應用服務層，這些服務被分割為獨立的服務模組，通過依賴呼叫和共享基礎資料構成業務基礎
最上層是API和業務層，各種客戶端和第三方應用，通過呼叫API整合到系統，組成一個生態系統。
3. 大型網站核心架構要素
架構 - 最高層次的規劃，難以改變的決定
軟體架構 - 有關軟體整體結構與元件的抽象描述，用於指導大型軟體系統各個方面的設計
需要考慮要素： 系統功能需求， 效能，可用性，伸縮性，擴充套件性和安全性
3.1 效能
效能優化手段
在瀏覽器端-通過瀏覽器快取、頁面壓縮、合理佈局頁面、減少Cookie傳輸等
使用CDN,將網站靜態內容分發至離使用者最近的網路服務商機房，使使用者通過最短訪問路徑獲取資料。在網站機房部署反向代理伺服器，快取熱點檔案，加快請求響應速度，減輕應用伺服器負載壓力。
在應用伺服器端-使用伺服器本地快取和分散式快取，通過快取在記憶體中的熱點資料處理使用者請求，加快請求處理過程，減輕資料庫負載壓力。
通過非同步操作將使用者請求傳送至訊息佇列等待後續任務處理， 當前請求直接返回響應給使用者
將多臺應用伺服器組成一個叢集共同對外服務，提高整理處理能力，改善效能。
在程式碼層面，通過使用多執行緒，改善記憶體管理等手段優化效能。
在資料庫伺服器端，- 索引，快取，SQL優化。 NoSQL資料庫優化資料模型、儲存結構，伸縮特性
衡量網站的效能指標： 響應時間， 系統效能計數器等。高併發訪問
３.２ 可用性
＞ ９９９．９９％
高可用設計的目標是當伺服器當機的時候， 服務或者應用依然可用。
網站高可用的主要手段是冗餘，應用部署在多臺伺服器上同時提供訪問， 資料儲存在多臺伺服器上相互備份。
多臺應用伺服器通過負載均衡組成叢集，任何一臺當機，把請求切換到其他伺服器，前提條件是應用伺服器不能儲存請求的會話資訊。
儲存伺服器，實時備份。
除了執行環境， 軟體開發過程的質量保證， 通過預釋出驗證、自動化測試、自動化釋出、灰度釋出等手段，減少將故障引入線上環境的可能，避免故障範圍擴大。
３.３ 伸縮性
所謂伸縮性是指通過不斷向叢集中加入伺服器的手段來緩解不斷上升的使用者併發訪問壓力和不斷增長的資料儲存需求。
衡量架構伸縮性的主要標準就是是否可以用多臺伺服器構建叢集，是否容易向叢集中新增新的伺服器。加入新的伺服器後是否可以提供和原來的伺服器無差別的服務。叢集中可容納的總的伺服器數量是否有限制。
應用伺服器叢集，通過使用合適的負載均衡裝置就可以向叢集中不斷加入伺服器。
快取伺服器叢集，加入新的服務可能會導致快取路由失效，進而導致叢集中大部分快取資料都無法訪問。雖然可以通過資料庫重新載入，但如果應用嚴重依賴快取，可能會導致整個網站崩潰。需要改進快取路由演算法保證快取資料的可訪問性。
關聯式資料庫的叢集伸縮方案必須在資料庫之外實現，通過路由分割槽等手段將部署有多個伺服器的資料庫組成一個叢集。
3.4 擴充套件性
網站的擴充套件性架構直接關注網站的功能。
主要手段是事件驅動架構和分散式服務。
事件驅動架構通常利用訊息佇列實現。
分散式服務則是將業務和可複用分離開來，通過分散式服務框架呼叫。
3.5 安全性
4. 瞬時響應-網站的高效能架構
網站效能指標：
客觀指標：響應時間、吞吐量 等
主觀指標：使用者的感受
4.1 網站效能測試
4.1.1 不同視角下的網站效能
1.使用者視角的網站效能
計算機效能差異、瀏覽器解析HTML速度、不同網路運營商提供的網際網路寬頻服務都會產生影響。
前端優化手段：優化頁面HTML樣式、利用瀏覽器端的併發和非同步特性、調整瀏覽器快取策略、使用CDN服務、反向代理等手段。
2. 開發人員視角的網站效能
響應時間、系統吞吐量、併發處理能力、系統穩定性。
優化手段： 快取加速資料讀取，叢集提高吞吐能力，使用非同步訊息加快請求響應及實現削峰，使用程式碼優化手段改善效能。
3. 運維人員視角的網站效能
關注基礎設施效能和資源利用率， 如網路運營商的頻寬能力、伺服器硬體配置、資料中心網路架構、伺服器和網路頻寬的資源利用率。
優化手段： 建設優化骨幹網、使用高價效比定製伺服器、利用虛擬化技術優化資源利用。
4.1.2 效能測試指標
從開發和測試人員的角度：
1.響應時間
發出請求到最後響應資料所需要的時間
常用系統操作響應時間表：
重複請求的方式進行測試。
2. 併發數
網站併發使用者數，同時提交請求的使用者資料數目。
通過多執行緒模擬併發使用者的方法來測試。
3.吞吐量
單位時間內系統處理的請求數量，體現系統的整體處理能力。
衡量指標：
請求數/秒； 頁面數/秒； 訪問人數/天； 處理的業務數/小時
TPS-每秒事務數， HPS-每秒HTTP請求數，QPS-每秒查詢數。
場景模擬：
在系統併發數由小逐漸增大的過程中， 系統資源消耗逐漸增大，系統吞吐量先是逐漸增加，達到一個極限後， 隨著併發數的增加反而下降，達到系統崩潰點後，系統資源耗盡，吞吐量為0.
在此過程中，響應時間則是先保持小幅上升，到達吞吐量極限後，快速上升，到達系統崩潰點後，系統失去響應。
形象比喻一下：
吞吐量是每天高速收費站通過的車輛數目，併發是正在行駛的車輛數目，響應時間是車速。
網站效能優化的目的，除了改善使用者體驗的響應時間，還要儘量提高系統吞吐量，最大限度利用伺服器資源。
4.效能計數器
是描述伺服器或作業系統的一些資料指標， 包括：
System Load; 物件與執行緒數； 記憶體使用； CPU使用； 磁碟與網路I/O等指標
4.1.3 效能測試方法
效能測試； 負載測試 ； 壓力測試； 穩定性測試
4.1.4 效能測試報告
一個例子：
4.1.5 效能優化策略
1.效能分析
2.效能優化： Web前段效能優化， 應用伺服器效能優化， 儲存伺服器效能優化
4.2 Web前端效能優化
Web前端功能： 瀏覽器載入；網站檢視模型；圖片服務； CDN服務等
主要優化手段： 優化瀏覽器訪問；使用反向代理、CDN等
4.2.1 瀏覽器訪問優化
1. 減少http請求
HTTP協議是無狀態的應用層協議，每次HTTP請求都要建立通訊鏈路、進行資料傳輸
在服務端， 每個HTTP都需要啟動獨立的執行緒去處理。
2.使用瀏覽器快取
設定HTTP頭中的Cache-Control和Expires.
更新靜態資源時，採取批量更新的方法。
3.啟用壓縮
Gzip 壓縮。 壓縮對伺服器和瀏覽器會產生一定的壓力，在通訊頻寬良好，而伺服器資源不足的情況下要權衡考慮。
4. CSS放在頁面 最上面， JavaScript放在頁面最下面。
瀏覽器會在下載完全部CSS之後才對整個頁面進行渲染。
瀏覽器再載入JavaScript後立即執行，有可能阻塞整個頁面，造成頁面顯示緩慢。但如果頁面解析時就需要用到Javascript,放在底部就不合適了。
5.減少Cookie傳輸
可以考慮靜態資源使用獨立域名訪問，避免請求靜態資源時傳送Cookie,減少Cookie傳輸的次數。
4.2.2 CDN加速
CDN- Content Distribute Network,內容分發網路。
本質仍然是一個快取，將資料快取在離使用者最近的地方。
CDN能夠快取的一般是靜態資源。
4.2.3 反向代理
傳統代理伺服器位於瀏覽器一側，反向代理伺服器位於網站機房一側。
作用： 保護網站， 通過配置快取加速Web請求，負載均衡。
4.3 應用伺服器效能優化
4.3.1 分散式快取
網站效能優化第一定律： 優先考慮使用快取優化效能。
合理使用， 不合理使用快取非但不能提高系統的效能，還會成為系統的累贅，甚至風險。
頻繁修改的資料、沒有熱點的訪問等狀況不適合使用快取。
快取預熱： 熱點資料是計算出來的，新啟動的快取系統沒有任何資料，在重建快取資料的過程中，系統的效能和資料庫負載都不太好，在快取系統啟動時就把熱點資料載入好。
快取穿透：將不存在的資料也快取起來（value值為null）
分散式快取架構
在多個伺服器組成的叢集中， 以叢集方式提供快取服務。
一種是以JBoss Cache為代表的需要更新同步的分散式快取。
一種是以Memcache為代表的不相互通訊的分散式快取。
JBoss Cache, 將應用程式和快取部署在同一臺伺服器上，應用程式從本地快速獲取快取資料。
缺點: 受限於單一伺服器的記憶體空間，當叢集規模很大時，快取更新資訊需同步到叢集所有機器，代價驚人。
多用於企業應用系統中， 大型網站較少使用。
大型網站快取量一般很龐大， 需要數TB的記憶體作快取。
Memcache採用一種集中式的快取叢集管理， 也稱作互不通訊的分散式架構方式。
快取系統部署在一組專門的伺服器上， 應用程式通過一致性Hash等路由演算法選擇快取伺服器遠端訪問快取資料，快取伺服器之間不通訊，快取叢集的規模很容易實現擴容， 具有良好的可伸縮性。
Memcached記憶體管理方式：
4.3.2 非同步操作
使用訊息佇列呼叫非同步化， 可改善網站的擴充套件性 和網站系統的效能。
4.3.3 使用叢集
負載均衡技術
4.3.4 程式碼優化手段
1. 多執行緒
解決執行緒安全的主要手段：
1） 將物件設計為無狀態物件。物件本身不儲存狀態資訊（物件無成員變數，或者成員變數也是無狀態物件）。比如： Servlet物件，貧血模型物件。不過從物件導向設計角度看，無狀態物件是一種不良設計。
2）使用區域性物件。
3） 併發訪問資源時使用鎖。鎖會導致現場同步執行，可能會對系統效能產生嚴重影響。
2. 資源複用
減少開銷很大的資源的建立和銷燬，比如資料庫連線、網路通訊連線、執行緒、複雜物件等。從變成角度，資源複用主要有兩種模式：單例和物件池。
3. 資料結構
Time33 演算法- Hash雜湊演算法， 對字串逐字元迭代乘以33， 減少Hash表的衝突。
Time33 雖然可以很好地解決衝突，但是有可能相似字串的HashCode也比較接近，一個可行的方案是對字串取資訊指紋，再對資訊指紋求HashCode.
4.垃圾回收
減少Full GC
4.4 儲存效能優化
4.4.1 機械硬碟 VS. 固態硬碟
4.4.2 B+樹 VS. LSM樹
傳統關係型資料庫使用B+樹對資料排序儲存，加快資料檢索速度，保證資料在不斷更新、插入、刪除後依舊有序。B+樹是一種專門針對磁碟儲存而優化的N叉排序樹，以樹節點為單位儲存在磁碟中，從根節點開始查詢所需資料所在的節點編號和磁碟位置，將其載入到記憶體後繼續查詢，直到找到所需資料。
許多NoSQL產品採用LSM樹作為主要資料結構：
4.4.3 RAID vs. HDFS
RAID-廉價磁碟冗餘陣列。實現資料在多塊磁碟上的併發讀寫和資料備份。
HDFS - Hadoop 分散式檔案系統。
HDFS以塊（Block）為單位管理檔案內容， 一個檔案被分割成若干個Block,當應用程式寫檔案時，每寫完一個Block,HDFS就將其自動複製到另外兩臺機器上，保證每個Block有三個副本，即使有兩臺伺服器當機，資料依然可以訪問，相當於實現了RAID1的資料複製功能。
當對檔案進行處理計算時，通過MapReduce併發計算任務框架，可以啟動多個計運算元任務(MapReduce Task), 同時讀取檔案的多個Block,併發處理，相當於實現了RAID0的併發訪問功能。
相關文章
- 《大型網站技術架構》讀書筆記網站架構筆記
- 《大型網站技術架構:核心原理與案例分析》讀書筆記網站架構筆記
- 《大型網站技術架構：核心原理與案例分析》讀書筆記 - 第4篇 架構師（附 大型網站架構技術一覽）網站架構筆記
- 《大型網站技術架構核心原理與案例分析》讀書筆記（二）網站架構筆記
- 《大型網站技術架構:核心原理與案例分析》讀書筆記系列網站架構筆記
- 《大型網站技術架構：核心原理與案例分析》讀書筆記 - 第2篇 架構網站架構筆記
- 讀書筆記 之《軟體架構設計: 大型網站技術架構與業務架構融合之道》筆記架構網站
- 《大型網站技術架構：核心原理與案例分析》讀書筆記 - 第3篇 案例網站架構筆記
- 《大型網站技術架構：核心原理與案例分析》讀書筆記 - 第1篇 概述網站架構筆記
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 大型網站技術架構（一）--大型網站架構演化網站架構
- 大型網站技術架構：核心原理與案例分析筆記網站架構筆記
- 大型網站架構模式筆記網站架構模式筆記
- 大型網站技術架構(三)--架構模式網站架構模式
- 大型網站技術架構（二）--架構模式網站架構模式
- 大型網站技術架構——2. 網站架構模式網站架構模式
- 大型網站技術架構（五）--網站高可用架構網站架構
- 大型網站架構利器－CDN技術網站架構
- 大型網站架構技術一覽網站架構
- 大型網站技術架構（八）--網站的安全架構網站架構
- 大型網站技術架構(四)--核心架構要素網站架構
- 大型網站架構學習筆記網站架構筆記
- 大型網站架構系列：20本技術書籍推薦網站架構
- 大型網站技術架構（四）--網站的高效能架構網站架構
- 大型網站技術架構（六）--網站的伸縮性架構網站架構
- 《大型網際網路企業安全架構》讀書筆記架構筆記
- 大型網站技術架構核心原理(1)網站架構
- 一張圖看懂大型網站技術架構網站架構
- 大型網站技術架構-入門梳理網站架構
- 大型網站技術架構的演進網站架構
- 大型網站技術架構（三）--架構核心要素網站架構
- 大型網站架構系列：20本技術書籍推薦(轉)網站架構
- 大型分散式網站架構技術總結分散式網站架構
- 大型網站技術架構（七）--網站的可擴充套件性架構網站架構套件
- 大型網站的技術架構演進過程網站架構
- 思維導圖形式帶你讀完《大型網站技術架構》中網站架構
- 思維導圖形式帶你讀完《大型網站技術架構》上網站架構
- 乾貨 | 大型網站專案架構技術一覽網站架構