讀-李智慧-大型網站技術架構：核心原理與案例分析
先寫了大型網站的架構演化路線，給出相關的架構模式，提出從幾個方面關注架構的要素，後面給出了一些案例。這本書的名字，我覺得改成架構最佳實踐可能更為合適一點。
之前讀過這本書，當時沒帶著自己的想法，走馬觀花，沒有體會到這本書的妙處。這次帶著問題，結合所經歷的已有系統的架構模式，與書中所寫相互印證，獲益良多。
總之，這本書時一本好書，可以買本實體書。
網站構架演進
大型網站的特點
- 高併發、大流量；
- 高可用；
- 海量資料；
- 使用者分佈廣泛、網路情況複雜；
- 安全環境惡劣；
- 需求快速變更，釋出頻繁；
- 漸進式發展：大型網站的發展是從小網站發展而來。
今年看雙11晚會，外行看明星，內行看門道，想想一過12點的流量，能抗住這衝擊，保證大部分人都能正常下單購物，就感覺ztm牛。再想想之前搞的抽獎活動，就那麼點人，怎麼就不能分點流量給我們了。
架構演化歷程
初始階段
應用和資料伺服器分離
這一步主要還是把資料庫伺服器獨立出去。
- 使用快取
本地快取和分散式快取，這一步主要還是使用本地快取的多點，一般不會一下子就用到分散式快取，當然有些系統會直接使用分散式快取。將一些配置資訊、熱點資料快取本地，降低資料庫壓力。
引申：快取穿透、雪崩，快取失效，一致性hash。
- 叢集
使用負載均衡通過叢集減輕應用伺服器的訪問壓力。
引申：會話管理。需要關注session是統一管理還是分配到叢集中的某臺機器。如果是某臺那就可能有會話粘滯，如果隨機一臺，就可能需要需要會話統一管理。
- 資料庫讀寫分離
這一步應該細分下為主備-分離，我們現在的系統就是也只是主從備份，沒做分離。現在的系統開發，上面這幾步都會一步到位，不會慢慢來了。
引申：分離後資料的一致性。
cdn和反向代理
做這一步主要還是把一些請求資源如圖片和js往客戶端推。緩解後端壓力的同時，加速客戶端響應。使用分散式檔案系統和分散式資料庫系統
感覺使用分散式檔案系統主要是處理一些小檔案儲存。資料庫資料量大了後一般都會對業務分庫，伺服器獨立部署，各業務庫再獨立演化拆分分庫分表等。
引申：資料庫分散式後，就需要統一的資料訪問元件隔離底層，其實在資料庫主從後就需要，只是到這一步後需求更迫切。
使用nosql和搜尋引擎
搜尋功能對於網際網路系統尤其電商業務重要性不言而喻。使用nosql做離線分析和日誌等，我們之前是利用hbase做訂單的二次營銷。業務拆分
不同的業務，不同產品線，然後應用的獨立部署。
從系統的新建到後期的資料庫的讀寫分離等過程，業務的拆分應該是一直都存在的，只不過到一定時期後，這個需求更加迫切而已。
引申：系統間，走訊息還是rpc等。
- 分散式服務
將一些基礎性的業務操作，提取出來獨立部署，供其他業務系統呼叫。
引申：分散式呼叫。
價值觀
- 業務發展驅動了架構技術的發展
業務驅動了架構技術的發展，而不是技術驅動業務。
架構模式
分層
邏輯分層，物理上可以集中部署也可以分散式。禁止跨層條用和反向呼叫。
1. 應用層；
2. 服務層；
3. 資料層。
分割
業務切分。
分散式
分層分割是為了更好的分散式。常用的分散式方案：
1. 分散式應用和服務；
2. 分散式靜態資源：js、css、圖片等資源獨立分散式部署，獨立域名，動靜分離；
3. 分散式資料和儲存；
4. 分散式計算；
5. 分散式配置，分散式鎖，分散式檔案等。
叢集
- 減輕負載壓力；
- 冗餘。
快取
- cdn；
- 反向代理；
- 本地快取；
- 分散式快取。
非同步
分層、分割、分散式後的不同產品線和應用間的互動，有些業務可以銅鼓非同步訊息互動，走訊息佇列非同步處理。
冗餘
資料和應用的冗餘。災備、同城雙活，異地多活。
自動化
自動化程式碼管理，自動化測試，自動化部署、監控等等吧。
安全
這個範圍太大了，風控、許可權、網路攻擊等。
效能
效能測試
效能測試時優化的基礎，對於不同人員來說，關注的視角不一樣
- 使用者來說，更多的是關注響應延遲;
- 開發人員來說，吞吐量，併發，響應延遲；
- 運維，基礎資源的利用率，網路頻寬等。
測試指標
- 響應時間；
- 併發數；
- 吞吐量：tqs、qps；
- 效能計數器：描述伺服器或作業系統效能的一些資料。
測試方法
- 效能測試；
- 負載測試；
- 壓力測試；
- 穩定性測試。
web前端效能優化
瀏覽器訪問優化
- 減少http請求：併發請求數有限，所以可以講圖片獨立域名部署，一些js壓縮合並；
- 瀏覽器快取：對一些靜態資源合理設定快取時間；
- 啟用壓縮：這個沒做過，感覺對文字檔案效果會很好；
- css放在最上面，js放在最下面；
- 減少cookie傳輸。
cdn加速
反向代理
跟正常代理的區別：正常的是幫你跳出去，反向是幫你跳進來。也可以用來快取靜態資源和熱點資料。
應用伺服器效能優化
- 分散式快取
優先使用快取優化效能。合理使用快取：
1. 頻繁修改的資料：2:1；
2. 沒有熱點的資料；
3. 資料不一致與髒讀；
4. 快取可用性；
5. 快取的預熱：LRU，最近最少使用；
6. 快取預熱；
7. 快取穿透：將不存在資料也快取起來；
快取架構：
1. JBoss Cache的分散式快取在叢集中所有伺服器儲存相同的快取；
2. Memcached：快取叢集間不相互通訊，現在比較流行這種。我們用的是redis。
- 非同步操作
感覺非同步操作需要業務的妥協，而且也不是所有業務都適合非同步操作。當然有些資料分發或者發個簡訊、郵件什麼的利用訊息佇列使用非同步操作沒什麼問題。
使用原則就是，任何可以晚點做的事情都應該晚點再做。
叢集
程式碼優化
必須瞭解jvm。
1. 多執行緒：感覺能不用就最好不用，用不好都不知道怎麼死的，有次用了執行緒池pc模式處理資料，20W資料最後老是丟幾十條，查了好久，才發現，執行緒不同步，有的執行緒沒有正確關閉；
2. 資源的複用；
3. 垃圾回收；
儲存效能優化
機械硬碟 vs 固態硬碟
B+樹 vs LSM樹
RAID vs HDFS
可用性
可用性度量和考核
- 可用性度量
最經常聽說的4個9，3個9。
網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點
網站年度可用性指標=（1-網站不可用時間/年度總時間）* 100%
- 考核
故障定級和故障分。
高可用的應用
通過負載均衡進行無狀態服務的失效轉移
應用伺服器叢集的session管理
- session複製；
- session繫結：hash，整個會話期間，由同一臺伺服器處理業務，會產生會話黏滯；
- cookie記錄session；
- session伺服器；
將應用伺服器的狀態分離，分為有狀態的session伺服器和無狀態的應用伺服器。
高可用的服務
主要是RPC的服務治理的東西，如果用過RPC的東東，應該都有所瞭解。
- 分級管理：主要是針對不同服務分級，不同優先順序不同執行緒池執行，分級主要是為了大促時做降級，隔離服務；
- 超時管理；
- 非同步呼叫：呼叫方式支援同步、非同步、回撥；
- 冪等性設計。
高可用的資料
CAP原理：傳統關係資料庫CP，犧牲A，現在網際網路應用大都為AP，犧牲部分C，利用其它補償做到資料最終一致；
資料備份：熱備，同步，非同步熱備；
- 失效轉移：流程：失效確認-轉移-資料恢復。
高可用的軟體質量保證
- 網站釋出：分批次；
- 自動化測試；
- 預釋出驗證：準生產環境驗證；
- 程式碼控制：主要是程式碼版本控制；
- 自動化釋出；
- 灰度釋出：部分發布，AB測試。
網站執行監控
- 監控資料採集：使用者日誌、伺服器效能、執行資料報告；
- 監控管理：報警，轉移，服務降級等；
伸縮性
網站伸縮性是指不需要改變網站的軟硬體的設計，僅僅通過部署伺服器的數量改變來改變處理能力。想想大促前的機器擴容。
網站架構的伸縮性設計
不同功能物理分離實現伸縮：主要是分層、分割後的業務和模組獨立部署
- 縱向分離，將業務處理上的不同部分分離部署；
- 橫向分離，將不同的業務模組分離部署。
單一功能通過叢集實現伸縮：將單一服務叢集部署提供服務
應用服務叢集的伸縮性設計
主要是通過負載均衡實現叢集的伸縮。
負載均衡技術：
http重定向
DNS解析
反向代理
IP負載
資料鏈路層負載
負載均衡演算法：
- 輪詢；
- 加權輪詢；
- 隨機；
- 最近最少連線；
- hash。
分散式快取叢集的伸縮性設計
搜尋瞭解下分散式hash演算法，的確開闊眼界。
資料儲存伺服器叢集的伸縮性
傳統資料庫叢集：搜尋mysql的叢集方案，常用的2種方式：
- client維護分片資訊；
- proxy維護資訊，client直跟proxy聯絡；
nosql，天生支援。
擴充套件性
網站架構的擴充套件性是指擴充套件系統功能時，對現有系統影響最小，主要還是降低系統應用間的耦合。通過2種方式：分散式訊息佇列降低耦合、可複用的分散式服務。
分散式訊息佇列：mq
感覺mq還是處理非實時業務或者分佈資料，其他的實時的呼叫還是算了吧。
分散式服務：rpc
分散式框架dubbo的架構原理：
安全性
網站應用的攻擊與防禦
xss指令碼攻擊：特殊字元轉義
sql注入：sql引數繫結
csfr跨站請求偽造：關鍵環節2次驗證
其他攻擊：
- 錯誤回顯：配置常用errorCode如404,500等錯誤頁面；
- html註釋：外網系統不註釋；
- 檔案上傳：檔案型別等校驗；
- 路徑遍歷：資原始檔單獨部署；
web應用防火牆；
安全掃描：有一些工具和平臺可以做漏洞掃描，最好不要對生產做一些資料清除修改的操作。有次公司的url掃描就改了使用者資料，坑爹。
加密
單向雜湊加密：md5，sha；
對稱加密：加解密同一個祕鑰，des；
非對稱加密：公私鑰（私鑰加密，公鑰解密），RSA；
祕鑰管理：作者寫的2種方式，沒見過，感覺很少這麼做，我們公司是申請伺服器資源的時候，祕鑰同時下發，然後定期更新密碼。
- 祕鑰和演算法獨立部署伺服器，申請和使用時校驗；
- 加解密演算法放在應用中，祕鑰獨立伺服器中，祕鑰切片存放。
資訊過濾與反垃圾
文字匹配：敏感詞過濾，trie演算法；
分類演算法：以反垃圾郵件為例：
黑名單：布隆過濾器；
風控
前2天剛聽的風控講座，很多內容，例如風險就可以發分為欺詐、商戶、法規、結算風險等，可以單獨搜尋學習。主要是利用規則引擎和統計模型訓練。在業務流程中將風控前置，在後期可以利用統計模型，機器學習演算法等進行風險預測。
推薦吳軍博士的《數學之美》這本書，介紹了好多分類、搜尋方面統計模型類應用。
後面還有2部分內容
- 一部分講了幾個案例，對前面架構部分做了具體的闡述，有些寬泛，案例部分，還是改天重看淘寶技術10年的時候再好好學習把；
- 另一部分講了架構師的劃分，以及作者對架構師這一工作的理解，不是架構師，雖有體會，但不深。
總結
- 業務需要推動了架構技術的演化，一個日活10來個人的網站，有必要上 一個高大全的分散式的系統嘛？非要上一個，完全自尋死路，沒那需求，也沒那必要；
- 傳道受業解惑，這本書屬於架構傳道類吧。很多公司死在了通往大型網站的路上，作者寫出這本書分享自己的經歷，讓我們能夠了解學習大型網站演化過程中的架構演進，獲益良多；
- 從效能、可用、伸縮、擴充套件性和安全性幾個方面考慮網站架構並給出了優化方案，但是因為是傳道類的書籍，所以廣度夠了，深度不夠，如果能各點都給出一個夠深度的難點，可能會更好；
- 看這本書，一定要帶著問題，結合自身的經歷去思考，如果是自己應該怎麼辦，這樣才能學有所獲，之前第一次讀的時候沒有注意，白白浪費了一次機會，幸好這次有時間重讀一次。