大型網站技術架構核心原理(1)

序

• 書籍是人類進步的階梯，字里行間傳達的是作者縝密的態度、思維的火花。在此感謝《大型網站技術架構》的作者的分享。私以為，互聯網技術迭代日新月異，但核心架構理念是非常值得學習的，願好書有更多人學習參考，謹以此筆記分享 😃

一、大型網站架構技術演化

• 核心：技術的更新是因為業務的發展，技術是來解決業務問題的
• 誤區：技術不能解決所有問題，業務問題需要通過業務手段來解決
• 要素：性能、可用性、伸縮性、擴展性、安全性這五個特性間的關系需要進行平衡處理

平衡策略

性能

• 衡量性能的一般指標：
  • 響應時間
  • TPS(TransctionPerSecond，每秒系統能夠處理的交易或事務的數量)
  • 系統性能計數器

1. 客戶端：

   • 瀏覽器緩存、頁面壓縮、減少Cookie傳輸、合理布局頁面
   • 使用 CND加速，靜態資源分發至離用戶最進的網絡服務商機房，同時在網站機房部署反向代理服務器，緩存熱點文件，加快請求相應速度，減輕應用服務器負載壓力

2. 服務端：

   • 服務器本地緩存和分布式緩存
   • 異步操作，將用戶請求發送至消息隊列等待后續任務處理，當前請求直接返回響應給用戶
   • 高並發情況下，將多台應用服務器組成一個集群共同對外服務，提高整體處理能力，改善性能
   • 代碼中，使用多線程、改善內存管理等手段優化性能

3. 數據庫服務端：

   • 索引、緩存、SQL優化
   • 使用 NoSQL，通過優化數據模型、存儲結構、伸縮特性等手段

可用性

• 衡量標准：假設任意一台服務器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用

1. 應用服務器：

   • 多台服務器通過負載均衡設備組成集群，有個前提，應用服務器是不你保存會話信息 ，否則服務器宕機，即使將用戶請求轉發到其他服務器上也無法完成業務處理

2. 存儲服務器：

   • 數據冗余備份，宕機時保證數據依然可用

3. 開發階段：

   • 開發人員代碼質量保證
   • 自動化測試，自動化發布

伸縮性

• 衡量標准：是否可以用多台服務器構建集群，是否容易向集群中添加新的服務器，加入新服務器后是否可以提供與原來的服務器無差別的服務，集群中可容納的服務器數量是否有限制

1. 應用服務器集群：

   • 服務器上不保存數據，所有服務器都是對等的，可以通過使用合適負載均衡設備向集群中不斷加入服務器

2. 緩存服務器集群：

   • 加入新的服務器可能會使緩存路由失效，進而導致集群中大不符緩存數據都無法訪問，如果應用嚴重依賴緩存，需要改進緩存路由算法
   • 使用NoSQL數據庫緩存，而不是使用 關系型數據庫

擴展性

• 衡量標准：增加新業務時對現有產品基本透明無影響，或者僅需改動很少既有業務

• 實現手段：

  • 事件驅動：該類型網站使用消息隊列 實現，消息產生(生產者)和消息處理(消費者)分開，增加小的消息勝者任務或者小的消息消費者任務即可提高系統性能

  • 分布式服務：業務 和可復用服務 分離開，通過分布式服務框架調用。新增產品可以通過調用可復用的服務實現自身的業務邏輯，而對現有產品牡羊座任何影響

安全性

• 衡量標准：針對現存或潛在的各種攻擊手段與竊密手段，是否有可靠的應對策略

1. 大型網站演化歷程

思考角度：

  - 單體應用局限性
  - 數據庫分庫分表、主從復制
  - 緩存性能、時效性
  - 集群、負載均衡
  - 分布式(業務、文件系統、配置、數據一致性、調度)
  - 異步
  - 自動化
  - 安全

1.1 單服務器應用

• 特點：應用程序、數據庫、文件系統統一放在一個服務器上
• 隱患：
  • 數據庫和文件系統會隨着網站運行時間增長，存儲空間不再滿足需求，擴展困難
  • 當用戶量或並發量增大時，應用程序與數據庫間會有爭奪內存，很大概率會宕機

1.2 應用服務和數據服務分離

• 特點：應用服務、數據庫、文件系統 放在不同的服務器上

  • 應用服務器部署在CPU有強大計算能力的服務器上
  • 數據庫服務器部署在內存很大的服務器上，便於快速磁盤檢索與磁盤緩存
  • 文件系統服務器部署在有大空間的存儲硬盤上

• 隱患：解決了單服務器存儲的瓶頸

  • 用戶增多，對數據庫的訪問壓力增大，導致有延遲，影響體驗

1.3 使用緩存減小數據庫壓力

• 特點：經常訪問的數據進行緩存，用戶獲取數據時直接從緩存中獲取，減小數據庫壓力(二八定律)

  • 本地緩存：訪問速度更快，但是受本地內存限制，緩存數量有限
  • 遠程分布式緩存：集群，部署大內存的 的服務器作為專門緩存服務器，可以做到理論上不受內存容量限制的緩存服務

• 隱患：單一應用處理請求的連接數有限，應用服務器成為網站的的瓶頸

• 解決方案：增加應用服務器，通過應用服務器集群，負載均衡調度服務器來將連接分發到合適的應用服務器

1.4 解決緩存問題：主從復制，讀寫分離

• 特點：緩存過期，或緩存訪問不命中，寫操作就會請求訪問數據庫，用戶規模到某一程度時，數據庫會負載壓力過高。

• 解決方案：通過主庫寫數據 ，然后同步更新到讀數據的 從庫數據服務器，讀寫分離，降低數據庫壓力

1.5 CDN加速和反向代理加速網站響應

• 特點：基本原理都是緩存，一方面加快訪問速度，一方面降低服務端壓力
  • CDN：用戶請求服務時，從距離自己最近的網絡提供商機房獲取數據
  • 反向代理：在服務端，請求發送到服務端后，若服務端有數據則會返回數據；同時反向代理在請求量到一定規模時，也可以通過負載均衡將請求分發的合適的應用服務器上

1.6 分布式 文件系統 和 分部式 數據庫系統

• 特點：表單數量過大時采用

• 解決方案：按業務拆分數據庫

• 隱患：隨着網站用戶及業務量發展，分布式數據庫不能滿足需求，也需要使用分布式文件系統，這中情況只有在表單規模非常巨大使才使用，常用的數據庫拆分手段是將不同的業務數據庫部署在不同的服務器上

1.6 使用NoSQL 以及搜索引擎

1.7 業務拆分

• 特點：每個應用獨立部署，應用間通過超鏈接 或消息隊列 進行數據分發；或者通過訪問同一個數據存儲系統來構成一個關聯的完整系統

1.8 分布式服務

• 特點：獨立部署公用業務，由這些可復用的業務連接數據庫，提供共用業務服務。應用系統只需要管理用戶界面，通過分布式服務調用共用業務完成具體業務操作
• 解決的問題：
  • 數據庫連接有限，公用業務進行數據庫訪問，然后為應用提供數據服務即可，減小數據服務器壓力
  • 公用業務得到復用，系統更好的維護

1.9 雲計算平台

• 情景：大型網站通過上述演化，已通過組合和改進現有技術架構解決海量數據的管理 和 高並發事物的處理 。因此大公司可以將這些解決方案應用到網站以外的業務上去，中小型公司不需要關注技術架構問題，直接購買即可獲得更大的存儲空間 和更多的計算資源
• 特點：成熟的架構體系和資源，大型網站開始搭建雲計算平台 ，為中小型企業提供計算服務；一方面使大型網站本身的資源(服務器、架構方案)，充分得到再利用，另一方面使得中小型公司可以專注業務的發展，不必再架構上試錯 ，通過購買計算服務即可。

2. 大型網站架構模式

2.1 分層

• 橫向分割(邏輯分層)，也在物理層面上分層，將不同層級分別部署在不同的服務器上

  • 應用層
  • 服務層
  • 數據層

• 優點

  • 便於分工合作和維護
  • 各層之間具有一定的獨立性，只要維持調用的接口不變，各層可以根據具體問題獨立演化發展，並且不影響其他層

• 注意事項

  • 各層級不能跨層級調用
  • 必須合理規划層次邊界和接口

2.2 分割

• 層級內縱向分割。例應用層可分多個(服務層也可根據需要分層)
  • 搜索
  • 購物
  • 廣告
  • 論壇

2.3 分布式

• 基礎條件：分層 和分割 ，將不同模塊部署在不同的服務器是和，通過遠程調用協同工作
• 實現：分布式用於處理訪問量大和數據量大的應用，通過使用更多的計算機、CPU、內存、存儲空間，提高並發訪問量、負載均衡、計算及存儲性能
• 問題：
  • 宕機：一台服務器宕機，這太服務的其他子服務器也不能正常使用，資源浪費，網站可用性降低
  • 網絡：網絡波動會影響性能
  • 數據：分布式環境中數據保持一致性

2.3.1 分布式應用和服務

• 基礎條件：應用和服務模塊分層分割分布式部署，
• 優點：
  • 改善網站性能和並發性，加快開發和發布，減少數據庫連接資源損耗
  • 提高服務的復用性 ，便於業務功能的擴展

2.3.2 分布式靜態資源

• 動靜分離，靜態資源分布式部署減輕應用服務器的壓力。通過使用獨立域名，由用戶體驗部開發等措施，可以加快瀏覽器並發訪問速度

2.3.3 分布式數據和存儲

2.3.4 分布式計算

• 計算什么：搜索引擎的索引構建 和 數據倉庫的數據分析統計
• 實現：利用 Hadoop 及其MapReduce 分布式計算框架進行批處理計算，優點如下：
  • 計算：移動計算 而不是 移動數據，將計算程序分發到數據所在的位置以加速計算和分布式計算
  • 分布式配置：網站線上服務器配置實時更新 分布式配置
  • 分布式鎖：分布式環境下實現兵法和協同的分布式鎖
  • 分布式文件系統

2.3.3 集群

• 相同應用用多台服務器部署，通過網關控制實現負載均衡，當一台服務器不能使用了，不會導致應用崩潰

2.3.4 緩存

• 目的：將數據存放在離計算機最近的位置以加快處理速度。
• 使用緩存的條件：
  • 熱點數據應該放在緩存中
  • 數據不會在短期失效，否則會產生zhang讀
• 實現：
  • CDN
  • 反向代理
  • 本地緩存
  • 分布式緩存

2.3.5 異步

• 實現：

  • 單一服務器：內部通過多線程共享內存隊列 的方式實現異步，在業務操作前面的線程將輸出寫到隊列中，后面的線程從隊列中讀取數據進行處理；
  • 分布式系統中：多個服務器集群通過分布式消息隊列 實現異步，分布式消息隊列可以看作內存隊列的分布式部署

• 特點：典型的生產者和消費者模式 ，兩者不存在直接調用，只要保持數據結構不變，彼此功能實現可以隨意變化而不互相影響，這網站擴展新功能非常便利。

• 優點

  • 提高系統可用性：消費者服務器故障，生產者服務器可以繼續處理業務請求；消費者服務器恢復后，繼續處理消息隊列中的數據
  • 加快網站響應速度：生產者服務器處理完業務請求后將數據寫入消息隊列，不需要等待消費者服務器處理就可返回，響應延遲減少
  • 消除並發訪問高峰：並發高峰時，消費者訪問請求放到消息隊列中，等待消費者服務器依次處理，雖然響應可能會慢點，但是不會對網站負載造成太大的壓力

2.3.6 冗余

• 情景：網站需要 7x24 小時連續運行，服務器規模比較大時，宕機是必然事件。所以避免數據丟失，需要對數據周期進行冗余備份
• 常見方式：
  • 冷備份，數據定期備分
  • 熱備份，數據庫主從分離
  • 災備數據重心

2.3.7 自動化

• 自動化發布
• 自動化代碼管理
• 自動化測試
• 自動化安全檢測
• 自動化部署
• 自動化監控
• 自動化報警
• 自動化失效轉移
• 自動化失效恢復
• 自動化降級
• 自動化分配資源

2.3.8 安全

• 敏感信息加密
• 對於常見的攻擊網站的 XSS 攻擊、SQL 注入、進行編碼轉換等相應處理
• 對垃圾信息進行過濾
• 對交易轉賬業務進行風險控制