復雜 冗余 操作 命中 文件系統 項目組 代理服務器 變更 服務器端

傳統特點及解決方案：

1. 高並發，大流量
2. 高可用
3. 大數據
4. 用戶廣泛，網絡情況復雜
5. 需求變更頻發，發布頻繁
6. 漸進式發展
7. 1.1解決方案：
   1. 分層
   2. 業務分割，比如將論壇，購物搜索分別放在不同的服務器上，如果業務龐大，還可以繼續分割。
   3. CDN（內容分發網絡用戶請求首先到達距離終端最近的網絡服務商那裏，緩存網站的一些靜態資源或者熱點內容，以最快的速度返回給用戶）和反向代理（屬於網站前端架構的一部分，部署在前端，緩存靜態資源）
   4. 負載均衡（多臺服務器部署相同的應用構成一個集群，通過負載均衡設備共同對外提供服務）
   5. 分布式服務器，多個服務器組成集群，將多個業務拆分到不同的服務器上（1.分布式應用和服務 2.分布式靜態資源並采用獨立域名，即動靜分離，3.分布式數據和存儲，4.分布式計算）
   6. 本地緩存（直接從內存中訪問數據）和分布式緩存服務器，【緩存前提：一是數據訪問熱點不均勻，二是數據在某個時間段內不會過期】
   7. 分布式文件服務器，分布式數據庫服務器
   8. NoSQL和搜索引擎服務器
   9. 異步+消息隊列，單一服務器通過多線程共享內存隊列的方式實現異步，典型的生產者消費者模式
   10. 冗余，服務器和數據都要冗余，定期備份，主從分離，防止服務器宕機，數據丟失。
   11. 自動化 自動化代碼管理，自動化測試，自動化安全檢測（測試環境進行安全攻擊），自動化部署，自動化監控報警，自動化失效轉移和恢復，自動化降級（拒絕部分請求和關閉部分不重要的服務），自動化分配資源（將空閑資源分給重要的服務）。

大型網站架構模式:

1. 高性能：響應時間,並發數,吞吐量,性能計數器,TPS（每秒事務處理量）

2. 高可用： 主要手段是冗余，任何一臺服務器宕機，都不會影響應用的整體使用
3. 易伸縮：多臺服務器集群
4. 可擴展：事件驅動架構（消息隊列）和分布式服務
5. 安全

網站性能優化： 1. web前段性能優化： 1.1 減少http請求（合並css,js,圖片）， 1.2使用瀏覽器緩存（主要是靜態資源，可以通過設置HTTP頭的Cache-control和Expire來緩存，更新時用過改文件名更新緩存，應該批量更新，並且是一個一個更新，並有間隔時間，避免大量緩存失效，造成服務器負載驟增，網路堵塞）， 1.3啟用壓縮（會對服務器和瀏覽器產生壓力，在服務器資源不足的情況下權衡）， 1.4css在頁面上面js在下面 1.5減少cookie傳輸 1.6 CDN和反向代理 2.應用服務器性能優化:（網站優化第一定律:緩存） 2.1 分布式緩存 2.1.0(緩存本質是一個內存Hash表) , 2.1.1 緩存預熱(熱點數據，比如分類，城市等等可以在啟動是加載數據庫中的數據到緩存中進行預熱)， 2.1.2 緩存穿透(持續高並發的訪問某個不存在的數據，對數據庫造成巨大壓力，對策是將不存在的數據也緩存起來,value是null) 2.1.3 分布式緩存是指緩存部署在多個服務器組成的集群中,其架構方式有兩種: 一種是JBossCache為代表的需要更新同步的(緩存主從復制)，一種是以Memcached為代表的互不通信的 2.2 異步，包括消息隊列，集群 2.3 代碼優化 2.3.0 多線程（註意線程安全，解決方法有 1.講對象設計為無狀態對象 2.使用局部對象 3. 並發訪問資源時使用鎖） 2.3.1 資源復用(盡量減少開銷很大的系統資源的創建和銷毀,比如數據庫連接字符串，網絡連接，線程等等，實現模式有兩種 單例和對象池) 2.3.2 數據結構(不理解) 垃圾回收 2.3.4 存儲性能優化(固態硬盤代替機械硬盤) 2.3.4.1 B+樹，是一種專門針對磁盤存儲而優化的N叉排序樹（機械硬盤具有快速順序讀寫，慢速隨機讀寫的特點,文件系統或者數據庫系統會對數據進行排序後存儲(增刪改)，加快數據檢索速度） 2.3.4.2 LSM樹， 是一個N階合並樹,數據庫的寫操作(增刪改)都在內存中進行,,讀操作時先從內存的排序樹開始，找不到再從磁盤的排序樹開始找，（隨機訪問數據速度更快，常見用NoSql） 2.3.5 RAID(廉價磁盤冗余陣列) 改善磁盤的訪問延遲,增強可用性和容錯性 HDFS(Hadoop分布式文件系統) 系統在整個存儲集群的多臺服務器上進行數據並發讀寫和備份 網站的高可用架構

3.1 公共服務獨立部署：分級管理(訂單支付比評價服務的優先級更高)，超時設置，異步調用(異步+消息隊列)，服務降級(拒絕優先級低的服務或者隨機拒絕服務,或者關閉評價，確認收貨等不重要的服務),如果網站過大，發布時可以使用灰度發布，先發布一部分，沒問題再發布下一部分。 3.2 網站運行監控 3.1.1 用戶行為日誌監控，包括用戶操作系統，瀏覽器信息，IP,頁面路徑，頁面停留時間等等，這些對網站的PV/UV指標，分析用戶行為，優化網站，個性化營銷和推薦非常重要。主要有兩種，1是服務器端收集，只需要開啟日誌記錄功能即可 2瀏覽器收集，需要單寫js 3.1.2 服務器性能監控: 收集服務器性能指標，如系統Load,內存占用，磁盤IO,網絡IO等等作出及時預警，安排合理的服務器集群，改善系統性能，調整系統伸縮策略。 3.1.3 運行數據報告: 監控具體業務場景相關的技術和業務指標，比如緩沖命中率，平均響應時間，每分鐘發送郵件數，待處理的任務總數等等 網站的伸縮性架構 4.1.1 伸縮性是指不需要改變網站的軟硬件設計，僅僅通過改變服務器的數量就能擴大或者縮小網站的服務處理能力 4.1.2 物理分離實現伸縮(不同的服務器部署不同的服務) ,相當於業務拆分。 4.1.3 單一功能通過集群實現 秒殺: 技術挑戰: 1. 需要部署專門的秒殺系統,如果和原有應用部署在一起，秒殺活動短時間，大並發的特性會使網站癱瘓. 2. 高並發，數據庫負載，壓力極大 3. 突然增加的網絡及帶寬，一個頁面200K，10000人秒殺就是 200*10000=2G 4. 直接下單,必須到秒殺時間才能下單，秒殺之前只能瀏覽。 應對策略: 1. 秒殺系統獨立部署,需要的話，使用獨立的域名 2. 秒殺商品頁靜態化，不經過業務處理和數據庫處理 3. 租借秒殺活動帶寬，將秒殺商品頁面緩存在CND 4. 動態生成隨機下單頁面URL,避免用戶得到秒殺URL直接下單 5. 秒殺頁面盡量簡潔，用戶更關心快速的刷新商品頁面 6. 秒殺商品購買按鈕只有在秒殺活動開始時才能點擊 7. 秒殺下單頁也盡量簡潔，數量不能修改 8. 只有第一個訂單才能創建成功，別的只能看到活動結束的頁面 如何控制秒殺商品購買按鈕的點亮可用??? 由於秒殺頁面是靜態頁，並且緩存在CDN,反向代理服務器或者用戶瀏覽器中,用戶刷新頁面，請求不會到達服務器。解決方案是使用javascript控 制,加入是否開始的標誌和下單頁面url隨機數。秒殺開始生成新的js文件並被瀏覽器加載，控制秒殺頁面的展示.這個js文件使用隨機版本號,不會被緩存。 如何確定第一個訂單創建成功??? 每臺服務器只接受前10個請求,其它用戶進入秒殺結束頁面，即使報錯也進入秒殺結束頁面，對用戶友好。 大型網站典型故障分析 1. 寫日誌故障: 1.1 應用程序日誌和第三方日誌要分別配置 1.2 log日誌級別，至少為warn，如果是全局debug, 就會出現日誌不停創建，占用磁盤空間的bug 1.3 關閉不必要的第三方日誌，一般遇到問題時才會發現 2. 高並發情況數據庫引發下的故障: 2.1 首頁數據不應該直接調取數據庫獲取,應該從緩存服務器或者搜索引擎服務器中獲取. 2.2 首頁最好是靜態的 3. 高並發情況下鎖引發的故障 單例中多處使用了鎖，如果遠程調用也偶爾用鎖，但是調用時間長，等用完了就立即釋放鎖，服務器會出現一會報警，一會又接觸的故障，使用鎖的時候一定要謹慎。 4. 緩存： 當緩存已經不僅僅是改善性能，而是成為網站不可獲取的一部分時，對緩存的管理就要提到和其它服務器一樣的高度，避免一下子關閉全部的緩存服務器，導致網站宕機。 5. 應用啟動不同步應發的故障 接口沒完全啟動，前臺已經調用了。應該是先返回一個ok，確定程序完全啟動才能再啟動前臺. 6. 大文件讀寫獨占磁盤： 小文件和大文件應該單獨存放服務器，如果用一個服務器，大文件上傳時，如果磁盤被占用，那麽小文件就無法上傳。 架構師領導藝術 1. 關註人而不是產品，一群優秀的人做一件他們熱愛的事情，就一定會成功。找一個共同的目標，營造一個能讓大家最大限度的發揮自我價值的工作氛圍，激發員工的熱情，而不是員工為了領工資而工作。 2. 發掘人的優秀，比發掘優秀的人更有意義。 3. 共享美好藍圖： 藍圖應該是描述清晰的（產品做什麽，不做什麽，達到什麽目標）,形象的（產品能為客戶帶來什麽，實現什麽樣的市場目標，最終長成什麽樣），簡單的（不管內部還是外部，一句話就能說明白） 4. 共同參與架構，讓項目參與者都能染指架構 ，讓其他人參與維護框架和文檔（除非重大重構）， 5. 學會妥協，坦率分享自己的設計思路，讓別人理解自己的想法並且理解別人的想法。對於細節應該立即驗證而不是接著討論。項目組越需要架構師，就越表示項目架構缺陷越多。 6. 成就他人， 做項目比僅僅要給客戶創造價值，為公司盈利，還要讓項目組人員活的成長。 網站架構師職場攻略： 1. 發現問題，尋找突破 2. 提出問題，尋求支持： 2.1 把我的問題這句話，變成我們的問題； 2.2 給上司提供封閉式問題(A和B解決方案您覺得哪個更好)，給下屬提開放式問題，讓他自己找解決方案(元你怎麽看)； 2.3 指出問題而不是批評人 2.4 用贊同的方式提出意見(我同意你的方案不過我有一個小建議，您看這樣是不是更好....) 2.5 解決問題，達成績效。在解決我的問題之前，先解決你的問題；適當擱置有爭議的問題。

# 有的路，走過之後，再回頭，一覽眾山小。

大型網站技術架構-讀後感