大型網站技術架構核心原理與案例分析

大型網站技術架構 核心原理與案例分析 閱讀筆記

1.大型互聯網應用系統特色

• 高併發，大流量： 高併發用戶，大流量訪問。
• 高可用： 系統7*24小時不間斷服務。
• 海量數據： 存儲管理海量數據，須要使用大量服務器。
• 用戶分佈普遍，網絡狀況複雜： 大型互聯網爲全球用戶提供服務。
• 安全環境惡劣： 互聯網的開放性，更容易受到攻擊。
• 需求快速變動，發佈頻繁： 互聯網產品爲快速適應市場，知足用戶需求，產品發佈頻率極高。
• 漸進式發展： 大型互聯網站幾乎都是從一個小網站開始，漸進的發展起來的。

2.大型網站架構模式

• 2.1. 分層
  • 概念： 系統在橫向緯度上切分紅幾個部分，每一個部分負責相對單一的職責，而後經過上下層依賴和調用組成一個完整系統。(應用層、服務層、數據層)
  • 目的： 規劃軟件清晰的邏輯結構便於開發維護；分層結構對網站支持高併發向分佈式方向發展相當重要。
• 2.2. 分割
  • 概念： 縱向方面對軟件進行切分。網站越大，功能越複雜，服務和數據處理的種類也就越多。將這些不一樣的功能和服務分割開來，包裝成高內聚低耦合的模塊單元。
  • 目的： 有助於軟件的開發和維護，便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展能力。
• 2.3. 分佈式
  • 概念： 不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做。分佈式意味着可使用更多的計算機來完成一樣的功能。可以處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。
  • 缺點：
  • 分佈式意味着服務調用必須通過網絡，可能對性能形成比較嚴重的影響。
  • 服務器越多，服務器宕機的機率也就越大，網站可用性會下降。
  • 分佈式環境下數據保持一致性也很是困難，分佈式事務難以保障，對業務正確性和業務流程可能形成影響。
  • 分佈式致使網站依賴錯綜複雜，開發管理維護困難。
  • 分佈式方案(經常使用)：
  • 分佈式應用和服務： 分層和分割後的應用和服務模塊分佈式部署，改善網站性能和併發性便於業務功能擴展。
  • 分佈式靜態資源： 靜態資源獨立分佈式部署(減輕應用服務器的負載壓力)，並採用獨立的域名(加快瀏覽器併發加載速度)。
  • 分佈式數據和存儲： 海量數據須要分佈式部署，除了對傳統關係型數據庫分佈式部署，各類NOSQL產品幾乎都是分佈式。
  • 分佈式計算： Hadoop及其MapReduce分佈式計算框架。
• 2.4. 集羣
  • 描述： 分佈式已經將分層和分割後的模塊獨立部署，可是對於用戶訪問集中的模塊(門戶首頁)，須要將獨立部署的服務器集羣化。即多臺服務器部署相同的應用構成一個集羣，經過負載均衡設備對外提供服務。
  • 優勢： 服務器集羣有更多的服務器提供相同的服務，能夠提供更好的併發特性，增長訪問只須要向集羣中添加機器。當某臺服務器發生故障，負載均衡設備或系統的實效轉移機制會將請求轉發到集羣中的其餘服務器上。
• 2.5. 緩存
  • 概念： 緩存就是將數據存放在距離計算機最近的位置以加快處理速度。緩存是改善軟件性能第一手段。
  • 分類：
  • CDN： 內容分發網絡，部署在距離終端用戶最近的網絡服務商。用戶網絡請求最早到達網絡服務商那裏。
  • 反向代理： 網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的數據中心時，最早訪問的就是反向代理服務器。(這裏緩存着網站的靜態資源)
  • 本地緩存： 應用服務器本地緩存着熱點數據，能夠直接在本機內存訪問數據，無需訪問數據庫。
  • 分佈式緩存： 大型網站數據量很是龐大，須要分佈式緩存，應用程序經過網絡通訊訪問緩存數據。
  • 條件：
  • 數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這些數據應放在緩存中。
  • 數據在某個時間段內有效，不會很快過時，不然數據會由於失效而引發髒讀，影響結果正確性。
  • 緩存除了能夠加快數據訪問速度，還能夠減輕後端應用和數據存儲的負載壓力。網站數據庫幾乎都是按照有緩存的前提進行負載能力設計。
• 2.6. 異步
  • 概念： 異步下降軟件耦合性，業務之間的消息傳遞不是同步調用，而是將一個業務操做分紅多個階段，每一個階段間經過共享數據的方式異步執行進行協助。在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步，分佈式消息隊列能夠看做是內存隊列的分佈式部署。
    異步架構是典型的生產者消費者模式，二者不存在直接調用，只要保持數據結構不變，彼此功能實現能夠隨意變化而不互相影響，對網站擴展新功能很是便利。
  • 異步消息隊列特性：
  • 提升系統可用性： 消費者服務器發生故障，數據會在消息隊列服務器中存儲堆積，生產者服務器能夠繼續處理業務請求，系統總體表現無端障。消費者服務器恢復正常，繼續處理消息隊列中的數據。
  • 加快網站響應速度： 業務處理前端的生產者服務器在處理完業務請求後，將數據寫入消息隊列。不須要等待消費者服務器處理就能夠返回，響應延遲減少。
  • 消除併發訪問高峯： 使用消息隊列將忽然增長的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，就不會對整個網站負載形成太大壓力。
• 2.7. 冗餘：
  • 描述： 保證服務器在宕機的狀況下網站依然能夠繼續服務，不丟失數據，就須要必定程度的服務器冗餘運行，數據冗餘備份，當某臺服務器宕機時，能夠將其上的數據和服務轉移到其餘機器上。
• 2.8. 自動化：
  • 發佈： 自動化代碼管理，自動化測試，自動化安全監測，自動化部署
  • 運維： 自動化監控，自動化報警，自動化失效轉移， 自動化失效恢復， 自動化降級， 自動化分配資源
• 2.9. 安全： 互聯網的開放特性使得其從誕生起就面對巨大的安全挑戰，網站在安全架構方面也積累了許多模式。

3.大型網站核心架構要素

架構： 最高層次的規劃，難以改變的決定

• 3.1. 瞬時響應：網站的高性能架構(性能)
  • 1 ）.網站性能測試
  • 性能測試指標
    • 響應時間： 執行一個操做須要的時間，從發出請求到收到最後響應數據所須要的時間。
    • 併發數： 系統可以同時處理的請求數目(同時提交請求的用戶數目)。
    • 吞吐量： 單位時間內系統處理的請求數量，體現系統的總體處理能力。
    • 性能計數器： 服務器或操做系統的一些數據指標。
  • 性能測試方法
    • 性能測試
    • 負載測試
    • 壓力測試
    • 穩定性測試
  • 性能測試報告
  • 性能優化策略
    • 性能分析： 對請求經歷的各個環節進行分析。
    • 性能優化： 根據網站分層架構 Web前端性能優化、應用服務器性能優化、存儲服務器性能優化
  • 2 ）.Web前端性能優化
  • 瀏覽器訪問優化
    • 減小http請求： http協議是無狀態的應用層協議，意味着每次http請求都須要創建通訊鏈路，進行數據傳輸。而在服務器端，每一個http都須要啓動獨立的線程去處理。這些通訊和服務的開銷都很貴，減小http請求數目可有效提升訪問系能(合併CSS，合併Javascript，合併圖片)。
    • 使用瀏覽器緩存： 靜態資源緩存到瀏覽器中(Http頭中的Cache-Control和Expires)。
    • 啓用壓縮： 服務器端對文件壓縮，瀏覽器端對文件解壓縮。減小通訊傳輸數據量。
    • CSS放在頁面最上面，JavaScript放在頁面最下面 ： 若是頁面解析須要用到JavaScript除外。
    • 減小Cookie傳輸： Cookie包含在每次請求響應中，太大的Cookie會嚴重影響數據傳輸。靜態資源使用獨立的域名訪問，避免請求靜態資源時發送Cookie。
  • CDN加速 (內容分發網絡) 將數據緩存在離用戶最近的地方(部署在網絡運營商機房)，使用戶以最快的速度獲取數據。(CDN能緩存的通常是靜態資源)
  • 反向代理 反向代理服務器位於網站機房一側，代理網站Web服務器接受http請求。
    • 保護網站安全，來自互聯網的請求必須通過代理服務器，服務器和可能的網絡攻擊間創建一個屏障
    • 緩存功能加速Web請求，靜態內容和部分動態內容緩存。
    • 負載均衡功能，提升系統總體處理能力，改善網站高併發狀況下的性能。
  • 3 ）. 應用服務器性能優化
  • 分佈式緩存
    • 緩存的基本原理 ： 緩存是指將數據存儲在相對較高訪問速度的存儲介質中，以供系統處理。一方面緩存訪問速度快，能夠減小數據訪問時間，另外一方面緩存起到減小計算時間的做用。
      緩存的本質是一個內存Hash表，網站應用中，數據緩存以一對Key、Value形式存儲在內存Hash表中。
    • 合理使用緩存
    • 頻繁修改的數據： 數據寫入緩存後，應用還來不及讀取緩存，數據就已經失效，徒增系統負擔。
    • 沒有熱點的訪問： 若是應用系統訪問數據沒有熱點(二八定律)。那緩存就沒有意義，緩存數據還有被再次訪問就已經被擠出緩存。
    • 數據不一致與髒讀： 緩存數據設置失效時間，一旦超過失效時間，就要從數據庫中從新加載。
    • 緩存可用性： 經過分佈式緩存服務器集羣，將緩存數據分佈到集羣多臺服務器上可在必定程度上改善緩存的可用性。
    • 緩存預熱： 系統啓動時就把熱點數據加載好。
    • 緩存穿透： 因不恰當的業務或者惡意攻擊持續高併發的請求某個不存在的數據(對策是將不存在的數據也緩存起來)。
    • 分佈式緩存架構： 緩存部署在多個服務器組成的集羣中，以集羣的方式提供緩存服務。
  • 異步操做
    • 描述： 使用消息隊列將調用異步化，可改善網站的擴展性和網站系統性能。
  • 使用集羣
    • 描述： 網站高併發訪問場景下，負載均衡技術構建一個由多臺服務器組成的服務器集羣，將併發訪問請求分發到多臺服務器上處理，避免單一服務器因負載壓力過大而響應緩慢。
  • 代碼優化
    • 多線程
    • 公式： 啓動線程數 = [任務執行時間/(任務執行時間-IO等待時間)] * CPU內核數
    • 線程安全解決手段：
      • 對象設置爲無狀態對象： 即對象自己不存儲狀態信息(對象無成員變量或成員變量也是無狀態對象)，Web開發中經常使用的貧血模型對象都是無狀態對象。(面向對象的設計角度看無狀態對象是不良設計)
      • 使用局部對象： 方法內部建立對象
      • 併發訪問資源時使用鎖： 多線程訪問資源的時候，經過鎖的方式使多線程併發操做轉化爲順序操做，從而避免資源被併發修改。
    • 資源複用
    • 單例(Singleton)： Web開發中使用的貧血模式；Spring默認構造的對象都是單例。
    • 對象池(Object Pool)： 經過複用對象實例，減小對象的建立和資源消耗。(鏈接池、線程池)
    • 數據結構
    • 描述： 靈活組合各類數據結構改善數據讀寫和計算特性可極大優化程序性能。
    • 垃圾回收
    • 棧(Stack)： JVM內存指令區，存儲線程上下文信息。如方法參數、局部變量。
    • 堆(Heap)： JVM內存數據區，存儲對象內存空間。對象的建立和釋放，垃圾回收都在這裏進行。
  • 4 ）. 存儲性能優化
  • 機械硬盤 vs. 固態硬盤
    • 機械硬盤： 快速順序讀寫，慢速隨機讀寫。
    • 固態硬盤： 隨機讀寫性能高，但不太成熟；可靠性，性價比有待提高。
  • B+樹 vs. LSM樹
  • RAID vs. HDFS

• 3.2. 萬無一失：網站的高可用架構(可用性)

  • 網站可用性的度量

    網站不可用時間(故障時間) = 故障修復時間點 - 故障發現(報告)時間點
    網站年度可用性指標 = (1 - 網站不可用時間/年度總時間) * 100%

  • 高可用網站架構
  • 目的： 保證服務器硬件故障時服務依然可用、數據依然保存並可以被訪問。
  • 手段： 數據和服務的冗餘備份及失效轉移。
  • 高可用的應用
  • 經過負載均衡進行無狀態服務的實效轉移
  • 應用服務器集羣的Session管理
    • Session複製
    • Session綁定
    • 利用Cookie記錄Session
    • Session服務器
  • 高可用的服務
  • 分級管理
  • 超時設置
  • 異步調用
  • 服務降級(拒絕服務、關閉功能)
  • 冪等性設計
  • 高可用的數據
  • CAP原理： 一個提供數據服務的存儲系統沒法同時知足數據一致性(Consistency)、數據可用性(Availibility)、分區耐受性(Patition Tolerance 系統具備誇網絡分區的伸縮性)這三個條件。
  • 數據備份： 冷備和熱備(異步熱備和同步熱備)
  • 失效轉移： 失效確認(心跳監測、失敗報告)、訪問轉移、數據恢復
  • 高可用網站的軟件質量保證
  • 網站發佈： 每次發佈關閉服務都是集羣中的一小部分，並在發佈完成後可當即訪問。
  • 自動化測試： ThoughtWorks開發的Selenium
  • 預發佈驗證： 預發佈服務器和線上正式服務器都部署在相同的物理環境中，相同的線上配置，依賴相同的外部服務。

    網站應用中一個處理錯誤的理念：快速失敗(fast failed)，即若是系統在啓動時發現問題就馬上拋出異常，中止啓動排查錯誤，而不是啓動後執行錯誤操做。

  • 代碼控制： 主幹開發、分支發佈(SVN)； 分支開發、主幹發佈(Git)
  • 自動化發佈：
  • 灰度發佈： 將集羣服務器分紅若干部分，每次只發布一部分服務器，觀察運行穩定再繼續發佈。

  • 網站運行監控

    不容許沒有監控的系統上線

  • 監控數據採集

    • 用戶日誌採集
      • 服務器端日誌收集 ： Web服務器日誌記錄。
      • 客戶端瀏覽器日誌收集： JavaScript腳本、基於實時計算框架Storm的日誌統計與分析工具。
    • 服務器性能監控： 收集服務器性能指標，開源服務器性能監測工具 Ganglia
    • 運行數據報告： 運行數據須要在具體程序中採集並報告
  • 監控管理 ： 系統報警、失效轉移、自動優雅降級

• 3.3. 永無止境：網站的伸縮性架構(伸縮性)

  • 網站架構的伸縮性設計
  • 不一樣功能進行物理分離實現
  • 單一功能經過集羣規模實現

  • 應用服務器集羣的伸縮性設計

    Http請求分發裝置能夠感知或者能夠配置集羣的服務器數量，能夠及時發現集羣中新上線或新下線的服務器，並能向新上線的服務器分發請求，中止向已下線的服務器分發請求，實現應用服務器集羣的伸縮性

  • HTTP重定向負載均衡： 利用HTTP重定向協議實現負載均衡。

  • DNS域名解析負載均衡： 利用DNS處理域名解析請求的同時進行負載均衡處理。
  • 反向代理負載均衡： Squid：基於Linux的開源反向代理服務器
  • IP負載均衡： 網絡層經過修改請求目標地址

  • 數據鏈路層負載均衡： 在通訊協議的數據鏈路層修改mac地址進行負載均衡。
    Linux平臺最好的鏈路層負載均衡開源產品是LVS(Linux Virtual Server)

  • 分佈式緩存集羣的伸縮性設計

    計算機的任何問題均可以經過增長一個虛擬層來解決。

  • 分佈式緩存的一致性hash算法 ： hash環 + 虛擬層

  • 數據存儲服務器集羣的伸縮性設計
  • 關係數據庫集羣的伸縮性設計 ： 主從複製、分庫、分片
  • NOSQL數據庫集羣的伸縮性設計
    • NOSQL： 主要指非關係的，分佈式的數據庫設計模式。(Not Only SQL觀點 只是關係數據庫的補充，而不是替代方案。) NOSQL數據庫產品放棄了關係數據庫的兩大重要基礎：以關係代數爲基礎的結構化查詢語言(SQL)和事務一致性保證(ACID)。而強化了高可用性和伸縮性。

  擴展性(Extensibility)： 對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。表如今系統基礎設施穩定不須要常常變動，應用之間較少依賴和耦合，對需求變動能夠敏捷響應。是系統架構設計層面的開閉原則(擴展開放，修改關閉)，架構設計考慮將來功能擴展，當系統增長新功能時，不須要對現有系統的結構和代碼進行修改。
  伸縮性(Scalability)： 系統可以經過增長(減小)自身資源規模的方式加強(減小)本身計算處理事務的能力。若是這種增減是成比例的，即做線性伸縮性。網站架構中，一般指利用集羣方式增長服務器數量，提升系統的總體事務吞吐能力。

• 3.4. 隨需應變：網站的可擴展架構(擴展性)

  • 構建可擴展的網站架構

    低耦合是軟件設計的終極目標之一，低耦合的系統更容易擴展，低耦合的模塊更容易複用，低耦合的設計讓開發過程和維護變得更輕鬆和容易管理。
    設計網站可擴展架構的核心思想是模塊化，並在此基礎之上，下降模塊間的耦合性，提升模塊的複用性。
    模塊分佈式部署之後具體聚合方式主要有分佈式消息隊列和分佈式服務 。

  • 利用分佈式消息隊列下降系統耦合性

  • 事件驅動架構
    • 概念： 在低耦合的模塊之間傳輸事件消息，以保持模塊的鬆散耦合，並藉助事件消息的通訊完成模塊間合做。(生產者消費者模式)

  • 分佈式消息隊列

    • 描述： 分佈式消息隊列能夠看做將這種數據結構部署到獨立的服務器上，應用程序能夠經過遠程訪問接口使用分佈式消息隊列，進行消息存取操做，進而實現分佈式異步調用。(ESB、 SOA 、 MySQL)

    分佈式消息隊列經過消息對象分解系統耦合性，不一樣子系統處理同一個消息；
    分佈式服務則經過接口分解系統耦合性，不一樣子系統經過相同的接口描述進行服務調用。

  • 利用分佈式服務打造可複用的業務平臺

  • WebService與企業級分佈式服務

    WebService缺點：

    • 臃腫的註冊與發現機制
    • 低效的XML序列化手段
    • 開銷相對較高的HTTP遠程通訊
    • 複雜的部署與維護手段

    難以知足大型網站對系統高性能、高可用、易部署、易維護的要求。

  • 大型網站分佈式服務的需求與特色
    • 分佈式服務框架支持特性：
    • 負載均衡： 支持服務請求者使用可配置的負載均衡算法訪問服務，使服務提供者集羣實現負載均衡。
    • 失效轉移： 當某個服務實例不可用，將訪問切換到其餘服務實例上，以實現服務總體高可用。
    • 高效的遠程通訊： 核心服務的調用次數會達到數以億計。
    • 整合異構系統： 網站服務可能會使用不一樣的語言開發並部署不一樣的平臺，分佈式服務架構須要整合這些異構系統。
    • 對應用最少侵入： 服務模塊自己須要支持可集中式部署，也可分佈式部署。
    • 版本管理： 分佈式服務框架須要支持服務多版本發佈，服務提供者先升級接口發佈新版本的服務，並同時提供舊版本的服務供請求者調用，當請求者調用接口升級後才能夠關閉舊版本服務。
    • 實時監控： 監控服務提供者和調用者的各項指標，提供運維和運營支持。
  • 分佈式服務框架設計 (參考 Thrift、Dubbo)
• 3.5. 固若金湯：網站的安全架構(安全性)
  • 網站應用的攻擊與防護
  • XSS攻擊
    • 概念： 跨站點腳本攻擊(Cross Site Script) 黑客經過篡改網頁，注入惡意HTML腳本，在用戶瀏覽網頁時，控制用戶瀏覽器進行惡意操做的一種攻擊方式。
    • 類型：
    • 反射型，攻擊者誘使用戶點擊一個嵌入惡意腳本的連接，達到攻擊目的。
    • 持久型，黑客提交含有惡意腳本的請求，保存在被攻擊的Web站點的數據庫中，用戶瀏覽網頁時，惡意腳本被包含在正常頁面中，達到攻擊目的。
  • 注入攻擊
    使用預編譯手段，綁定參數是最好的防SQL注入方法。
  • CSRF攻擊
    • 描述：CSRF(Cross Site Request Forgery，跨站點請求僞造)，攻擊者經過跨站請求，以合法的用戶身份進行非法操做。其核心是利用了瀏覽器Cookie或服務器Session策略，盜取用戶身份。
  • 信息加密技術及密鑰安全管理
  • 信息過濾及反垃圾
  • 電子商務風險控制