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

序

• 書籍是人類進步的階梯，字裏行間傳達的是做者縝密的態度、思惟的火花。盛世繁華之下，太多的人都伴隨着有生活的窘迫、工做的無奈以及情感的羈絆，煩躁之餘不妨讀一本書，放下不快，或許能給你帶來思惟的拓展、情感的愉悅以及心裏的寧靜，在此感謝《大型網站技術架構》的做者的分享。私覺得，互聯網技術迭代突飛猛進，但核心架構理念是很是值得學習的，願好書有更多人學習參考，謹以此筆記分享 😃

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 注入、進行編碼轉換等相應處理
• 對垃圾信息進行過濾
• 對交易轉帳業務進行風險控制