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

傳統特色及解決方案：

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 解決問題，達成績效。在解決個人問題以前，先解決你的問題；適當擱置有爭議的問題。

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