第2篇 架構
4 瞬時響應：網站的高效能架構 34
4.1 網站效能測試 35
效能測試是效能優化的前提和基礎，也是效能優化結果的檢查和度量標準。
4.1.1 不同視角下的網站效能 35
- 使用者：直觀感受到的快慢
- 開發：應用程式本身
- 運維：基礎設施效能和資源利用率
4.1.2 效能測試指標 36
1.響應時間：發出請求-->接收響應
2.併發數：同時處理請求的數目，反映了網站的負載特性。多執行緒模擬併發，執行緒間增加隨機等待時間（思考時間）
3.吞吐量：單位時間內系統處理的請求數，體現整體處理能力。TPS（每秒事物數）、HPS（每秒HTTP請求數）、QPS（每秒查詢數）等
4.效能計數器：System Load(系統負載：正在被CPU執行和等待執行的程式數目總和)、物件與執行緒數、記憶體使用、CPU使用、磁碟與網路I/O等指標。
對這些指標設定報警閾值。
4.1.3 效能測試方法 39
1.效能測試：以系統設計初期的效能指標為預期目標，不斷施壓驗證
2.負載測試：不斷增加併發請求，直到達到臨界值
3.壓力測試：超過安全負載情況下，繼續施壓，直至系統崩潰或不能處理任何請求，以此獲得系統最大壓力承受能力
4.穩定性測試：長時間、不均勻的對系統施壓
4.1.4 效能測試報告 41
4.1.5 效能優化策略 41
尋找瓶頸，分而治之，逐步優化
1.效能分析：記憶體、CPU、磁碟、網路、程式碼、架構設計、資源不足等。
2.效能優化：WEB、伺服器、儲存，3大類
4.2 Web前端效能優化 42
4.2.1 瀏覽器訪問優化 42
1.減少HTTP請求：HTTP請求是無狀態的應用層協議，每次請求都需要建立通訊鏈路，服務區端都需要獨立啟動新執行緒。
手段：合併css、合併js、合併圖片
2.使用瀏覽器快取：靜態資原始檔（CSS、js、Logo、圖示等）快取。
手段：設定HTTP投中的Cache-Control和Expires屬性，數天甚至幾個月。
注意：檔案變化需及時通知瀏覽器，
3.啟用壓縮：使用GZip在伺服器端對檔案壓縮，瀏覽器解壓。
注意：壓縮會有一定的壓力，在通訊頻寬良好，伺服器資源不足情況下要權衡考慮。
4.CSS放在頁面最上邊，JS放在頁面最下邊
CSS放在頁面最上邊：瀏覽器會在下載完全部CSS後對頁面渲染
JS放在頁面最下邊：瀏覽器載入JS後立即執行，有可能阻塞整個頁面，造成頁面顯示緩慢（除非頁面解析時用到JS）
5.減少Cookie傳遞Cookie包含在每次請求和響應中，太大的Cookie會嚴重影響資料傳輸。
4.2.2 CDN加速 43
CDN（Content Distribute Network，內容分發網路），本質是快取，而且是資料快取在距使用者最近的地方，部署在網路運營商的機房。
4.2.3 反向代理 44
位於網站機房一側，
1.保護網路安全：增加一層
2.加速Web請求：第一次使用者訪問載入靜態資源快取，其它使用者訪問直接從反向代理伺服器返回
3.負載均衡：構建應用叢集提高系統總處理能力
4.3 應用伺服器效能優化 45
4.3.1 分散式快取 45
網站效能優化第一定律：優先考慮使用快取優化效能
1.快取的基本原理
定義：快取是指將資料儲存在相對較高訪問速度的儲存介質中，以供系統處理。
作用：減少訪問時間，減少計算時間
原理：記憶體Hash表
2.合理使用快取
a.頻繁修改的資料：寫入一次快取，至少讀兩次以上，快取才有意義
b.沒有熱點的訪問：大部分資料訪問集中在小部分資料上
c.資料不一致與髒讀：應用要容忍一定時間的資料不一致
d.快取可用性：分散式快取伺服器叢集
e.快取預熱：系統啟動時把熱點資料載入好
f.快取穿透:不恰當的業務或惡意攻擊持續高併發的請求某個不存在的快取，所有請求落到資料庫上，造成很大壓力甚至雪崩。
對策：不存在的資料也快取起來，value值為null。
3.分散式快取架構
快取部署在多個伺服器組成的急群中，以叢集方式提供服務。JBoss Cache：同步更新的分散式快取
4.Memcached
簡單的通訊協議：TCP（UDP也支援）協議通訊
豐富的客戶端程式：幾乎支援所有主流的網站程式語言
高效能的網路通訊：服務端通訊模組基於Libevent，是一個支援事件觸發的網路通訊庫。穩定的長連線
高效的記憶體管理：固定空間分配
互不通訊的伺服器叢集架構：幾乎無限制的線性伸縮
4.3.2 非同步操作 52
使用訊息佇列將訊息非同步化，可改善網站的擴充套件性，還可改善網站的效能，起到削峰作用。
4.3.3 使用叢集 53
4.3.4 程式碼優化 54
1.多執行緒：最大限度的使用CPU。
解決執行緒安全的主要手段：
將物件設計為無狀態物件：物件本身不儲存狀態資訊（物件無成員變數）
使用區域性物件：方法內部建立物件，只會被進入該方法的執行緒建立
併發訪問資源時使用鎖：可能影響效能
2.資源複用：減少開銷大的系統資源的建立與銷燬，如資料庫連線、網路通訊連線、執行緒、複雜物件等。
程式設計角度有兩種模式：單利（Singleton）和物件池（Object Pool）
3.資料結構：靈活組合各種資料結構改善資料讀寫和計算
4.垃圾回收
4.4 儲存效能優化 58
4.4.1 機械硬碟vs. 固態硬碟 58
機械硬碟：最常用，快速順序讀寫，慢速隨機讀寫。通過馬達驅動磁頭臂，帶動磁頭到指定的磁碟位置訪問資料
固態硬碟：又稱SSD或Flash硬碟；資料儲存再可持久記憶的矽晶體上。可以快速隨機訪問。
4.4.2 B+樹vs. LSM樹 59
B+樹：專門針對磁碟儲存而優化的N叉排序樹
LSM樹：N階合併樹。
4.4.3 RAID vs. HDFS 61
RAID：廉價磁碟冗餘陣列，改善磁碟訪問延遲，增加磁碟可用性和容錯能力。
HDFS：Hadoop分散式檔案系統，對資料儲存空間的管理以塊（Block）為單位，預設64M，
4.5 小結 64
效能優化的最終目的是改善使用者體驗，使他們感覺網站很快。
5 萬無一失：網站的高可用架構 66
5.1 網站可用性的度量與考核 67
5.1.1 網站可用性度量 67
業界通常用多少個9來衡量網站的可用性，如QQ是99.99%
2個9是基本可用：網站年度不可用時間小於88小時
3個9是較高可用：網站年度不可用時間小於9小時
4個9是高可用性：網站年度不可用時間小於53分鐘
5個9是極高可用：網站年度不可用時間小於5分鐘
5.1.2 網站可用性考核 67
可用性指標是網站設計的重要指標，對外是服務承諾，對內是考核指標
故障分 = 故障時間（分鐘）* 故障權重
5.2 高可用的網站架構 69
目的：保證伺服器硬體故障時伺服器依然可用，資料依然儲存並能夠被訪問。
手段：資料和服務的冗餘備份及失效轉移。
注意：升級釋出引起的當機
5.3 高可用的應用 71
業務邏輯層，無狀態的
5.3.1 通過負載均衡進行無狀態服務的失效轉移 72
心跳機制檢測機器是否可用。
5.3.2 應用伺服器叢集的Session管理 73
Session（會話）：多次請求修改使用的上下文物件。如購物車
叢集環境下，管理Session的手段
1.Session複製：只適用於小規模叢集，佔用大量資源
2.Session繫結：會話黏滯，Session繫結在特定機器上，一旦當機Session不存在了。
3.利用Cookie記錄Session：受Cookie大小限制，影響效能，使用者可以關閉Cookie
4.Session伺服器：利用分散式快取，資料庫等。
5.4 高可用的服務 76
也是無狀態的，也可以使用負載均衡失效轉移策略實現高可用的服務。
此外，還有以下幾種：
- 分級管理：核心應用和服務使用更好的硬體，部署隔離，低優先順序部署在虛擬機器上，高優先順序不同物理機上。
- 超時設定：呼叫超時重試或者請求轉移其他機器上
- 非同步呼叫：訊息佇列，不需要確認服務呼叫成功才能進行下一步操作的呼叫。
- 服務降級：拒絕低優先順序服務及關閉部分服務不重要服務，確保核心應用和功能正常執行
- 冪等性設計：服務層保證服務重新呼叫和第一次呼叫產生的結果相同。
5.5 高可用的資料 78
5.5.1 CAP原理 79
資料高可用有以下幾個層面的含義：資料永續性、資料可訪問性、資料一致性。
CAP原理認為，一個提供資料服務的儲存系統無法同時滿足資料一致性（Consistency）、資料可用性（Availability）、分割槽耐受性（Patition Tolerance，系統具有跨網路分割槽的特性）這三個條件。
強化分散式系統的可用性（A）和伸縮性（P）,某種程度上放棄一致性（C）
一致性又可分為：
資料強一致：各個副本的資料在物理儲存中總是一致的。（難以滿足）
資料使用者一致：資料在物理儲存中可能不一致，使用者訪問時通過糾錯校驗保證一致。（可以達到）
資料最終一致：資料在物理儲存中可能不一致，使用者訪問時可能不一致，經過一段時間修復，達到一致。
5.5.2 資料備份 82
資料冷備：定期將資料複製到某種儲存介質上，優點：簡單廉價、技術成本低，缺點：不能保證資料最終一致。
資料熱備：非同步熱備方式&同步熱備方式，Master-Slave同步機制，實現讀寫分離
5.5.3 失效轉移 84
由三部分組成：
1.失效確認：確認伺服器是否當機由兩種手段：心跳檢測和應用程式訪問失效報告（需心跳檢測確認）
2.訪問轉移：資料讀寫訪問到其他服務其上。
3.資料恢復：資料儲存的副本恢復通過從健康的服務區複製資料恢復到設定值，防止再次當機無法轉移。
5.6 高可用網站的軟體質量保證 85
網站為了保證線上系統的可用性而採取的一些與傳統軟體開發不同的質量保證手段。
5.6.1 網站釋出 85
每次關閉的伺服器都是叢集中的一小部分，並在釋出立即可以訪問，整個釋出過程不影響使用者使用。
5.6.2 自動化測試 86
Thoughts Works開發的Selenium[səˈli:niəm]，執行在瀏覽器中，模擬使用者操作，可以完成功能測試和相容性測試。
5.6.3 預釋出驗證 87
跟正式伺服器唯一的區別是不在配置負載均衡服務區上。注意：所有操作都是真實的。
5.6.4 程式碼控制 88
SVN&GIT
5.6.5 自動化釋出 90
Jenkins
5.6.6 灰度釋出 91
5.7 網站執行監控 91
不允許沒有監控的系統上線。
5.7.1 監控資料採集 92
1.使用者行為日誌收集：使用者所有操作及操作環境、頁面訪問路徑、頁面訪問時間等，對統計網站PV/UV，分析使用者行為、個性化營銷、推薦等非常重要。
手段：伺服器端日誌收集（log4j）、瀏覽器日誌收集（頁面嵌入JS指令碼）
注意：伺服器端收集IP可能使用者使用代理，無瀏覽器端準確，但是相對簡單。
考慮使用Storm進行日誌統計分析
2.伺服器效能監控：系統負載、記憶體佔用、磁碟IO、網路IO等，做到防患於未然，合理安排叢集規模，改善效能
工具：Ganglia
3.執行資料包告：具體業務場景相關的指標，如待處理任務總數、每分鐘發郵件數等。
5.7.2 監控管理 93
系統報警：超過閾值簡訊郵件報警
失效轉移：
自動優雅降級：為了應付突然爆發的訪問高峰，主動關閉部分功能
5.8 小結 94
先求生存，再求發展。
6 永無止境：網站的伸縮性架構 95
不需改變網站的軟硬體設計，僅通過改變部署的伺服器的數量就可以擴大或縮小網站的服務處理能力。
6.1 網站架構的伸縮性設計 97
6.1.1 不同功能進行物理分離實現伸縮 97
6.1.2 單一功能通過叢集規模實現伸縮 98
相同服務部署在多臺伺服器上構成叢集。
叢集伸縮性分為：應用伺服器叢集的伸縮性、資料服務叢集的伸縮性。
資料服務叢集的伸縮性分為：分散式快取叢集、資料儲存伺服器叢集。
6.2 應用伺服器叢集的伸縮性設計 99
6.2.1 HTTP重定向負載均衡 100
請求兩次完成一次訪問，效能較差，不建議使用。
6.2.2 DNS域名解析負載均衡 101
DNS域名解析得到內部提供負載均衡的伺服器。與下圖有出入。
6.2.3 反向代理負載均衡 102
優點：通過快取提高效能、負載均衡；缺點：代理伺服器是所有請求響應中轉站，可能有效能瓶頸。
6.2.4 IP負載均衡 103
效能優於反向代理，但是對於提供視訊、下載服務的網站，吞吐量受限於網路頻寬，難以滿足。
6.2.5 資料鏈路層負載均衡 104
修改mac地址，不需修改IP，稱三角傳輸模式。避免網路卡頻寬成為伺服器瓶頸，也稱直接路由方式（DR），使用最廣。
LVS（Linux Virtual Server）：Linux平臺最好的開源產品。
6.2.6 負載均衡演算法 105
負載均衡伺服器實現可以分為兩部分：
1.根據負載均衡演算法和Web伺服器列表計算得到叢集中一臺Web伺服器的地址。
2.將請求資料傳送到該地址對應的Web伺服器上。
負載均衡演算法通常有以下一種：
輪詢（Round Robin，RR）：所有請求依次傳送到每臺伺服器上，適用於每臺伺服器硬體相同的場景。
加權輪詢（Round Robin，RR）：高效能的伺服器分配更多請求。
隨機（Random）：簡單，好的隨機數本身就很均衡，也可以加權。
最少連線（Least Connections）：計算每個伺服器處理的連線數，請求傳送到連線數最少的機器上。
源地址雜湊（Source Hashing）：根據IP進行Hash計算，來自同一IP的請求總是落在同一伺服器上。
6.3 分散式快取叢集的伸縮性設計 106
新上線的快取伺服器對整個分散式叢集的影響最小。
6.3.1 Memcached分散式快取叢集的訪問模型 107
6.3.2 Memcached分散式快取叢集的伸縮性挑戰 107
餘數Hash：擴容導致命中率降低，比如3臺擴容至4臺，約有3/4的資料不能命中，只能訪問量小的時候預熱，晚上加班。比較流行的辦法是一致性Hash演算法。
6.3.3 分散式快取的一致性Hash演算法 109
通過一個叫做一致性Hash環的資料結構實現Key到快取伺服器的Hash對映。順時針查詢離整個Key的Hash值最近的快取伺服器節點，新增節點隻影響一小段
問題：新增NODE3節點後支隊NODE1有影響，NODE0、NODE2負載壓力是NODE1、NODE3的2倍。
解決：虛擬節點加入環中，分攤負載，經驗是一個物理伺服器虛擬150個節點。
6.4 資料儲存伺服器叢集的伸縮性設計 112
6.4.1 關聯式資料庫叢集的伸縮性設計 113
分庫、讀寫分離外，還可以使用地方放元件，如Sharding-JDBC
6.4.2 NoSQL資料庫的伸縮性設計 117
NoSQL：非關係的，分散式的設計模式，應用最廣泛的是Apache 的HBase。
6.5 小結 119
必備能力。
7 隨需應變：網站的可擴充套件架構 121
對現有系統影響最小的情況下，系統功能可持續擴充套件或提升的能力。開閉原則。
7.1 構建可擴充套件的網站架構 122
架構師最大的價值：將一個大系統切分成N個低耦合的子模組的能力，包括橫向的業務模組（分層），也包括縱向的基礎技術模組（分割）。
網站可擴充套件架構設計的核心思想：模組化，並降低模組間的耦合性，提高模組的複用性。以訊息佇列及依賴呼叫的方式聚合成一個完整的系統。
模組分散式部署主要分為：分散式訊息佇列（訊息）、分散式服務（介面）。
7.2 利用分散式訊息佇列降低系統耦合性 123
7.2.1 事件驅動架構 123
事件驅動架構（Event Driven Architecture，EDA）：通過在低耦合的模組之間傳遞訊息，以保證模組的鬆散耦合，並藉助事件訊息的通訊完成模組間合作，生產者消費者模式。
好處：傳送者不需等待接收者返回，更好的延遲；網站訪問高峰，接收者可以可以根據自身負載處理能力控制訊息處理速度，減輕資料庫等後端儲存的負載壓力。
7.2.2 分散式訊息佇列 124
AvtiveMQ、kafaka
7.3 利用分散式服務打造可複用的業務平臺 126
7.3.1 Web Service與企業級分散式服務 128
缺點：
1.臃腫的註冊和發現機制
2.低效的XML序列化手段
3.開銷相對較高的HTTP通訊
4.複雜的部署和維護手段。
7.3.2 大型網站分散式服務的需求與特點 129
負載均衡、失效轉移、高效的遠端通訊、整合異構系統、對應用最少侵入、版本管理、實時監控。
7.3.3 分散式服務框架設計 130
Dubbo：是一個分散式服務框架，致力於提供高效能和透明化的 RPC 遠端服務呼叫方案，以及 SOA 服務治理方案。簡單的說，Dubbo 就是個服務框架，說白了就是個遠端服務呼叫的分散式框架。
Spring Cloud：基於 Spring Boot，為微服務體系開發中的架構問題，提供了一整套的解決方案——服務註冊與發現，服務消費，服務保護與熔斷，閘道器，分散式呼叫追蹤，分散式配置管理等。
Spring Boot：是 Spring 的一套快速配置腳手架，使用預設大於配置的理念，用於快速開發單個微服務。
Dubbo 和 Spring Cloud 對比
7.4 可擴充套件的資料結構 131
HBase，列族（ColumnFamily），解決關係型資料庫資料結構難以面對需求變更帶來的挑戰。
7.5 利用開放平臺建設網站生態圈 132
7.6 小結 134
8 固若金湯：網站的安全架構 135
8.1 道高一尺魔高一丈的網站應用攻擊與防禦 136
全球約70%的Web應用攻擊都來自XSS攻擊和SQL隱碼攻擊。
8.1.1 XSS攻擊 136
XSS攻擊（Cross Site Script）：跨站點指令碼攻擊，指黑客通過篡改網頁，注入惡意HTML指令碼，在使用者瀏覽完網頁時，控制使用者瀏覽器進行惡意操作的一種攻擊方式。
XSS攻擊型別有兩種：反射型、持久型。
防攻擊手段：
消毒：對危險html轉義，如">"轉義">"，"<"轉義"<"等
HttpOnly：防止XSS攻擊竊取使用者Cookie，對Cookie新增HttpOnly屬性。
8.1.2 注入攻擊 138
主要有兩種形式：SQL隱碼攻擊、OS注入攻擊。
攻擊者獲取表結果手段：
開源：網站才用開源軟體搭建。
錯誤回顯：錯誤回顯到瀏覽器上。（重點）
盲注：根據頁面變化判斷SQL執行情況。
防止SQL隱碼攻擊方式：
消毒：簡單粗暴，通過正則過濾請求中可能的SQL隱碼攻擊。
引數繫結：最好方式，通過預編譯，攻擊者的SQL當做引數而不是SQL。
8.1.3 CSRF攻擊 139
CSRF攻擊（Cross Site Request Forgery）：跨站點請求偽造，
CSRF攻擊防禦手段主要是識別使用者身份
表單Tonken：頁面引數中增加一個隨機數作為token，每次響應頁面的token都不相同。
驗證碼：體驗糟糕，如支付頁面可以使用。
Referer check：圖片防盜鏈。
String referer = request.getHeader("Referer");
if(referer == null || !referer.startsWith("http://localhost:8080/fancy")) {
Response.sendRedirect("/servletPro/Error");//轉到錯誤頁面
return;
}
8.1.4 其他攻擊和漏洞 140
Error Code：500（伺服器內部錯誤）配置錯誤頁面。
HTML註釋：JSP、HTML註釋會顯示在客戶端瀏覽器。
檔案上傳：只允許上傳可靠型別的檔案。
路徑遍歷：JS、CSS等資原始檔部署在獨立伺服器，使用獨立域名。
8.1.5 Web應用防火牆 141
Model Security：開源Web應用防火牆，探測攻擊並保護Web應用程式。
8.1.6 網站安全漏洞掃描 142
模擬攻擊行為，發現網站安全漏洞
8.2 資訊加密技術及金鑰安全管理 142
資訊加密技術分類：單向雜湊加密、對稱加密、非對稱加密。
8.2.1 單向雜湊加密 143
單向雜湊加密：對不同長度的信心進行雜湊加密，得到固定長度得輸出，單向的，如MD5、SHA等。
8.2.2 對稱加密 144
對稱加密：加密解密使用的金鑰是同一個（或者可以相互推算），用在資訊互動的場合。如DES演算法、RC演算法等。
8.2.3 非對稱加密 144
非對稱加密：加密解密使用的金鑰不是同一個，在用資訊保安傳輸、數字簽名等場合。如RSA演算法。
8.2.4 金鑰安全管理 145
金鑰切分，分別管理。
8.3 資訊過濾與反垃圾 146
8.3.1 文字匹配 147
文字匹配：解決敏感詞過濾的問題，正則效率較差，
雙陣列Trie[t'ri:]演算法：優化了Trie演算法，利用兩個稀疏陣列儲存樹結構，base資料儲存Trie樹的節點，check陣列進行狀態檢查。
構造多級Hash表：更簡單，逐字順序在過濾樹中匹配，浪費部分記憶體空間
注意：需要對資訊降噪預處理，如”阿_富_汗“。
8.3.2 分類演算法 148
垃圾郵件識別：貝葉斯分類演算法，可以用sklean實現。
8.3.3 黑名單 149
也是垃圾郵件識別手段，加入黑名單過濾。
8.4 電子商務風險控制 150
電子商務具有多種形式：B2B、B2C、C2C.
8.4.1 風險 151
賬戶風險：盜用，惡意註冊等。
買家風險：惡意下單佔用庫存、利用促銷搶購低價商品、欺詐退款等。
賣家風險：虛假髮貨、炒作新用、出售圍巾商品等。
交易風險：信用卡盜刷、支付欺詐、洗錢套現等。
8.4.2 風控 151
風控手段有自動、人工兩種。機器識別高風險交易資訊傳送給人工稽核，機器自動風控的技術也通過人工發現新風險型別逐步完善。
機器自動風控的手段主要有規則引擎（簡單，規則越多效能越差）和統計模型（機器學習）。
8.5 小結 153
沒有絕對的安全，就像沒有絕對的自由。