《大型網站技術架構》讀書筆記

李勝攀發表於2015-04-12

大型網站架構演化


大型網站的關注指標

  • 高可用
  • 高效能
  • 易擴充套件
  • 可伸縮
  • 安全

大型網站的特點

  • 高併發,大流量
  • 高可用
  • 海量資料
  • 使用者分佈廣泛,網路情況複雜
  • 安全環境惡劣
  • 需求快速變更,釋出頻繁
  • 漸進式發展

大型網站架構演化發展過程

  • 初始階段,一般使用LAMP來搭建,所有資源存放在一臺伺服器上
  • 應用服務和資料服務分離,有獨立的資料庫伺服器
  • 使用快取改善網站效能,依據是二八定律:80%的業務訪問集中在20%的資料上
    • 這裡需要考慮哪些資料適合快取
    • 快取可以是本地快取,也可以是遠端分散式快取
  • 使用應用伺服器叢集改善網站的併發處理能力
    • 如果能通過增加一臺伺服器的方式來改善負載壓力,就可以以同樣的方式持續增加伺服器來不斷改善系統效能,從而實現系統的可伸縮性
    • 這裡需要考慮使用哪些負載均衡的策略
      *資料庫讀寫分離
    • 快取中的資料,如果更新過快,那麼會持續重新整理快取,從而降低效能
    • 可以利用主流資料庫提供的主從熱備功能,通過配置兩臺資料庫的朱從關係,將一臺資料庫伺服器上的資料同步到另外一臺上面
  • 使用反向代理和CDM加速網路響應
    • CDN和反向代理的基本原理都是快取
    • CDN部署在網路提供商的機房,使用者在請求網路服務時,可以從距離自己最近的網路提供商機房獲取資料
    • 反向代理部署在網站的中心機房,當使用者的請求到達中心機房後,首先訪問的伺服器是反向代理伺服器,如果反向代理伺服器中快取著使用者請求的資源,那麼就將其直接返回給使用者
  • 使用分散式檔案系統和分散式資料庫系統
    • 網站常用的資料庫拆分手段是業務分庫,即將不同業務的資料庫部署到不同的物理伺服器上
  • 使用NoSQL和搜尋引擎
  • 業務拆分,使用分而治之的手段將整個網站業務分成不同的產品線
  • 分散式服務

大型網站架構演化的價值觀

網站的價值在於它能為使用者提供什麼價值,在於網站能做什麼,而不在於它是怎麼做的。因此對於小型網站來說,最需要做的是位使用者提供好的服務來創造價值,得到使用者的認可,從而活下去,野蠻生長。

  • 大型網站架構技術的核心價值是隨網站所需靈活應對, 它是一個演化的過程
  • 驅動大型網站技術發展的主要力量是網站的業務發展,是業務成就了技術,而不是相反。因此要摒棄為了技術而技術的套路

大型網站架構模式


  • 分層,這是在橫向方向對系統進行切分
    • 分層的挑戰在於必須合理規劃層次邊界和介面
    • 分層包括物理分層和邏輯分層兩種
  • 分割,這是在縱向方向對系統進行切分
    • 將不同的功能和服務分割開來,包裝秤高內聚低耦合的模組單元
  • 分散式
    • 分層和分割的目的在於小模組便於分散式部署
    • 帶來的問題:1) 分散式意味著服務呼叫必須通過網路,需要考慮頻寬的影響;2) 伺服器越多,當機的概率越大
    • 常用的分散式方案:1) 分散式應用和服務; 2) 分散式靜態資源; 3) 分散式資料和儲存; 4) 分散式計算;5) 分散式配置、分散式鎖、分散式檔案系統。。。
  • 叢集,即多臺伺服器部署相同的應用,從而構成一個叢集,通過負載均衡裝置共同對外提供服務
    • 即使訪問量很小的分散式應用和服務,也至少要部署到兩臺伺服器來構成一個小叢集,這樣可以提高系統的可用性
  • 快取,即將資料放在距離計算最近的位置以加快處理速度
    • CDN
    • 反向代理
    • 本地快取
    • 分散式快取
  • 非同步,業務之間的訊息傳遞不是同步呼叫,而是將一個業務操作分成多個階段,每個階段之間通過共享資料的方法非同步進行協作
    • 通常需要使用訊息佇列
    • 帶來的好處:1) 提高系統可用性; 2) 加快網站響應速度; 3) 消除併發訪問高峰
  • 冗餘
    • 叢集帶來的必然結果
    • 安全需求的必然結果
  • 自動化,DevOps思維,儘量減少人工干預
    • 自動化釋出
    • 自動化程式碼管理
    • 自動化測試
    • 自動化安全監測
    • 自動化部署
    • 自動化監控
    • 自動化報警
    • 自動化失效轉移、恢復
    • 自動化分配資源
    • ......
  • 安全

大型網站核心架構要素


  • 效能
    • 一個效能問題可能會導致網站使用者嚴重流失
    • 衡量效能的指標:響應時間、TPS、系統效能計數器等
  • 可用性
    • 沒有網站可以完美的7*24執行
    • 網站高可用結構的前提是必然會出現伺服器當機,兒高可用設計的目標是當伺服器當機時,服務或者應用依然可用
    • 必要的手段是叢集,即冗餘
  • 伸縮性,即通過不斷向叢集中加入伺服器的手段來環節不斷上升的使用者併發訪問壓力和不斷增長的資料儲存需求
    • 衡量標準:是否可以構建叢集;是否可以方便的向叢集中新增新的伺服器
  • 擴充套件性,直接關注網站的功能,保證可以快速響應需求變更
    • 衡量標準: 網站增加新的業務產品時,是否對現有業務透明無影響
  • 安全性
    • 衡量標準: 針對現存和潛在的各種攻擊和竊密手段,是否可以有效的應對

瞬時響應 - 高效能架構


不同視角下的網站效能

  • 使用者視角
    • 主要是端到端的感覺
    • 主要通過前段優化的手段來提升使用者體驗
  • 開發人員視角
    • 主要關注應用程式本身以及相關子系統的效能,包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等
    • 主要優化手段: 使用快取加速資料讀取、使用叢集提高吞吐能力、使用非同步訊息加快請求響應、使用程式碼優化提升程式效能
  • 運維人員視角
    • 主要關注基礎設施效能和資源利用率
    • 主要優化手段: 建設優化骨幹網、使用高價效比定製伺服器、利用虛擬化技術優化資源利用率

效能測試指標

  • 響應時間,即應用執行一個操作需要的時間,包括從發出請求開始到收到最後響應資料所需要的時間
  • 併發數,即系統能夠同時處理的請求的數目,也反映了系統的負載特性
  • 吞吐量,即單位時間內系統處理的請求數量,體現系統的整理處理能力
  • 效能計數器, 描述伺服器或者作業系統效能的一些資料指標

效能測試方法

  • 效能測試,以系統設計初期規劃的效能指標為預期目標,對系統不斷增壓,驗證系統在資源可接受範圍內,是否能達到效能預期
  • 負載測試,對系統不斷的增加併發請求,知道系統的某項或者多項效能指標達到安全臨界值
  • 壓力測試,超過安全負載的情況下,繼續對系統增壓,直到系統崩潰或者不能再處理任何請求
  • 穩定性測試,在特定硬體、軟體、網路情況下,給系統載入一定壓力,是系統執行較長一段時間,來觀察系統是否穩定

Web前段優化

  • 瀏覽器訪問優化
    • 減少http請求
    • 使用瀏覽器快取
    • 啟用壓縮
    • CSS放在頁面最上面,JavaScript放在頁面最下面
    • 減少Cookie傳輸
  • CDN加速
  • 反向代理

應用伺服器效能優化

  • 分散式快取
    • 快取從本質上來說,就是一個記憶體hash表
    • 快取需要快取那些讀寫比很高、很少變化的資料,一般來說讀寫比在2:1以上時,快取才有意義
    • 應用程式讀取資料時,首先到快取中讀取,如果快取不存在或者已失效,再訪問資料庫,同時將新的資料放入快取
    • 快取也需要注意快取熱點資料
    • 快取預熱,在新啟動的快取系統中,在啟動時就載入熱點資料,這樣啟動後就可以直接使用
    • 快取穿透, 應用持續大量訪問不存在的資料,因為這類資料不存在於快取中,因此會大量訪問資料庫,從而降低效能
    • 對於分散式快取來說,目前有兩類:1) 不同的快取伺服器之間進行通訊,例如JBoss Cache;2)不同快取伺服器之間不進行通訊,例如Memcached
  • 非同步操作
    • 一般會使用訊息佇列,帶來的額外好處是會削平峰值
  • 使用叢集

程式碼優化

  • 多執行緒
    • 需要注意執行緒安全問題,方法:1) 將物件設計成無狀態物件;2) 使用區域性物件;3) 併發訪問資源時使用鎖
  • 資源複用
    • 主要是單例和資源池(物件池)
  • 資料結構,選擇合適的演算法
  • 垃圾回收
    • 合理設定垃圾回收策略

儲存效能優化

  • 機械硬碟 vs 固態硬碟
  • B+樹 vs LSM樹
  • RAID vs HDFS

萬無一失 - 高可用架構


網站的可用性描述網站可以有效訪問的特性,它不同於易用性

網站可用性度量

  • 網站不可用時間 = 故障修復時間點 - 故障發現時間點
  • 網站年度可用性指標 = (1 - 網站不可用時間/年度總時間)* 100%
    • 一般以幾個9來表示,2個9是基本可用,網站年度不可用時間小於88小時;3個9是較高可用,網站年度不可用時間小於9小時;4個9是具有自動恢復能力的高可用,網站年度不可用時間小於53分鐘;5個9是極高可用性,網站年度不可用時間小於5分鐘

網站高可用架構的設計目標是保證伺服器硬體故障時服務依然可用、資料依然儲存並能夠被訪問
網站高可用架構的主要手段:資料和服務的冗餘備份以及失效轉移,一旦伺服器當機,就將服務切換至其他可用的伺服器上。

高可用的應用

無狀態應用: 應用伺服器不儲存業務的上下文資訊,而僅根據每次請求提交的資料進行相應的業務邏輯處理,多個服務例項之間完全對等,請求提交到任何一個伺服器上,處理的結構都是相同的

  • 通過負載均衡進行無狀態服務的失效轉移
    • 負載均衡: 主要使用在業務量和資料量較高的情況下,當單臺伺服器不足以承擔所有的負載壓力時,通過負載均衡手段,將流量和資料分攤到一個叢集組成的多臺伺服器上, 以提升整體的負載處理能力
  • 應用伺服器叢集的Session管理
    • Session複製
    • Session繫結
    • 利用Cookie記錄Session
    • Session伺服器

高可用的服務

  • 分級管理
  • 超時設定
  • 非同步呼叫
  • 服務降級
  • 冪等性設計

高可用的資料

  • 主要手段:資料備份和失效轉移
  • CAP原理: 一個提供資料服務的儲存系統無法同時滿足資料一致性(Consistency)、資料可用性(Availibility)、分割槽耐受性(Parition Tolerance)這三個條件
    • 資料一致性分類: 1) 資料強一致; 2) 資料使用者一致; 3) 資料最終一致
  • 資料備份
    • 冷備的優點是簡單和鏈家,成本和技術難度較低,缺點是不能保證資料最終一致
    • 熱備分為兩種:1) 非同步熱備; 2) 同步熱備
  • 失效轉移
    • 失效確認:1) 心跳檢測;2) 應用程式訪問失敗報告
    • 訪問轉移
    • 資料恢復

高可用網站的軟體質量保證

  • 網站釋出,它的過程和伺服器當機效果箱單,其對系統可用性的影響也 類似
    • 一般採取批量更新的方式進行,不會一次關掉叢集中的全部伺服器
  • 自動化測試
    • 一般使用Selenium來進行測試
  • 預釋出驗證
    • 預釋出伺服器是一種特殊用途的伺服器,它和線上的正式伺服器唯一的區別是沒有配置在負載均衡伺服器上,外部使用者無法訪問
  • 程式碼控制
    • 主幹開發,分支釋出
    • 分支開發,主幹釋出,這是目前使用的主流方式
  • 自動化釋出
    • 火車模型:將每個應用的釋出過程看做一次火車旅程,火車定點執行,期間有若干站點,每一站都進行例行檢查,不通過的專案下車,通過的專案繼續坐著火車旅行,直到火車到達終點。
    • 實際中,可能所有專案在途中都下車了,這樣火車不得不回到原點,等待問題解決後再來一次
    • 一種可能是火車上的重點專案如果失敗,那麼整趟火車需要返回
    • 人的干預越少,自動化程度越高,引入故障的可能性就越小
  • 灰度釋出
    • 大型網站都會使用灰度釋出模式,將叢集伺服器分成若干部分,每天只發布一部分伺服器,觀察執行穩定沒有故障,第二天繼續釋出一部分伺服器,持續幾天你才把整個叢集全部發布完畢,期間如果發現問題,只需要回滾已釋出的一部分伺服器即可

網站執行監控

  • 監控資料採集
    • 使用者行為日誌收集
    • 伺服器效能監控
    • 執行資料包告
  • 監控管理
    • 系統報警
    • 失效轉移
    • 自動優雅降級

永無止境 - 可伸縮性架構


網站伸縮性: 在不需要改變網站的軟硬體設計,僅僅通過改變部署的伺服器數量就可以擴大或者縮小網站的服務處理能力

網站架構的伸縮性設計

  • 不同功能進行物理分離實現伸縮
  • 單一功能通過叢集規模實現伸縮

應用伺服器叢集的伸縮性設計

  • HTTP重定向負載均衡
  • DNS域名解析負載均衡
  • 反向代理負載均衡
  • IP負載均衡
  • 資料鏈路層負載均衡
  • 負載均衡演算法
    • 輪詢
    • 加權輪詢
    • 隨機
    • 最小連結
    • 原地址雜湊

分散式快取叢集的伸縮性設計

  • Memcached分散式快取叢集的訪問模型
    • 用用程式通過Memcached客戶端訪問Memcached伺服器叢集,Memcached客戶端主要由一組API、Memcached伺服器叢集路由演算法、Memcached伺服器叢集列表以及通訊模組構成
    • 路由演算法負責根據應用程式輸入的快取資料KEY計算得到應該將資料寫入到Memcached的哪臺伺服器(寫快取)或者應該從哪臺伺服器讀資料(讀快取)
  • Memcached分散式快取叢集的伸縮性挑戰
    • 挑戰主要針對路由演算法,當叢集擴容時,如何保證路由演算法可以得到新加入的伺服器?
    • 解決方法: 在網站訪問量最少的時候擴容,然後通過模擬請求的方法逐漸預熱快取,使得快取伺服器中的資料重新分佈
  • 分散式快取的一致性Hash演算法

資料儲存伺服器叢集的伸縮性設計

  • 資料儲存伺服器必須保證資料的可靠儲存,任何情況下都必須保證資料的可用性和正確性
  • 關聯式資料庫叢集的伸縮性設計
    • 利用主從結構實現讀寫分離
    • 根據不同業務的資料,放到不同的資料庫叢集中,即資料庫分庫
    • 對於特別大的表,進行分片處理
  • NoSQL資料庫的伸縮性設計
    • HBase

隨需應變 - 可擴充套件架構


可擴充套件性:在對現有系統影響最小的情況下,系統功能可持續擴充套件或者提升的能力
實現可擴充套件的手段:低耦合,高內聚

利用分散式訊息佇列降低系統耦合性

  • 事件驅動架構(Event Driven Architecture)

    • 定義:通過在低耦合的模組之間傳輸事件訊息,以保持模組的鬆散耦合,並藉助事件訊息的通訊完成模組間合作。典型的場景是生產著消費者模型
  • 分散式訊息佇列

利用分散式服務打造可服用的業務平臺

  • 需要將超大型的、複雜系統查分成可獨立部署的模組,從而降低耦合性
  • Web Service與企業分散式服務
    • Web Service比較臃腫,可以考慮使用REST
    • 或者使用開源的解決方案,例如Dubbo

可擴充套件的資料結構

固若金湯 - 安全架構


典型攻擊方式

  • XSS攻擊(跨站指令碼攻擊)
    • 黑客通過篡改網頁,注入惡意HTML指令碼,在使用者瀏覽網頁時,控制使用者瀏覽器進行惡意操作的一種攻擊方式
    • 分類: 1) 反射型; 2) 持久型
    • 解決方法:1) 消毒; 2) HttpOnly
  • 注入攻擊
    • 分類: 1) SQL隱碼攻擊; 2) OS注入攻擊
    • 解決方法:1) 消毒; 2) 引數繫結
  • CSRF攻擊(跨站點請求偽造)
    • 攻擊者通過跨站請求,以合法使用者的身份進行非法操作
    • 解決方法: 識別請求者身份:1) 表單Token; 2) 驗證碼; 3) Referer check
  • 其他攻擊方式
    • Error Code,可能顯示異常堆疊,從而暴露危險資訊,解決方法:使用統一的500頁面
    • HTML註釋,註釋可能會暴露危險資訊,解決方法:code review或者自動掃描
    • 檔案上傳,可能上傳病毒檔案,解決方法:設定上傳檔案白名單,只允許上傳指定型別的檔案
    • 路徑遍歷, 在URL中使用相對路徑,遍歷系統未開放的目錄和檔案,解決方法: 將資原始檔部署在獨立的伺服器上,使用獨立域名

資訊加密技術以及金鑰管理

    • 單項雜湊加密,包括MD5、SHA等
    • 對稱加密, 包括DES演算法、RC演算法等
    • 非對稱加密, 包括RSA演算法等
    • 金鑰安全管理
      • 將金鑰和演算法放在一個獨立的伺服器上,甚至做成一個專用的硬體設定,對外提供加密和解密服務
      • 將加解密演算法放在應用系統中,金鑰則放在獨立伺服器中,在儲存時,將金鑰切分成數片,分別儲存在不同的介質中

相關文章