網站架構知識學習

看一本書就應該有所收穫，最近閱讀完一本名叫《大型網站技術架構》的書籍，趁著時間還早，寫一個人總結。本書作者李智慧，曾在阿里巴巴擔任技術專家，參與阿里巴巴基礎技術平臺開發和架構設計。本書也是以比較通俗的語言介紹網站的技術架構。本人學淺，對書中的知識點並沒有達到融會貫通的地步，只能根據自己的理解整理出此篇，以供同仁有所簡單的瞭解，並對我的輸出做出修改。縱觀本書，一句話「技術之路，道路且長」

網站架構的設計

什麼是網站架構的設計

對網站的軟體結構、邏輯結構、物理結構、層次結構、數據訪問模型、硬體配置、網路拓撲結構等等進行總體的設計。

什麼是網站的部署

網站發布。網站的開發完成後，網頁程序及相關的資料庫等發布在真實的網路及硬體環境中，並能夠正常運行。

網站架構設計與部署的目標

  • 高可用性
  • 可擴展性
  • 可視性
  • 高性能
  • 安全性

大型網站的架構

網站架構模式

所謂網站架構模式即為瞭解決大型網站面臨的高並發訪問、海量數據、高可靠運行燈一系列問題與挑戰。為此，在實踐中提出了許多解決方案，以實現網站高性能、高可靠性、易伸縮、可擴展、安全等各種技術架構目標

  • 分層 在網站的分層架構中，常見的為3層，即應用層、服務層、數據層。應用層具體負責業務和視圖的展示；服務層為應用層提供服務支持；資料庫提供數據存儲訪問服務，如資料庫、緩存、文件、搜索引擎等。
  • 分離網站越大，功能越複雜，服務和數據處理的種類也越多，將這些不同的功能和服務分隔開來，包裝成高內聚低耦合的模塊單元，不僅有助於軟體的開發維護也便於不同模塊的分散式部署，提高網站的並發處理能力和功能擴展能力。比如在應用層，將不同業務進行分隔，例如電信智能家居項目，分為網上商城和用戶系統和管理平臺。當然如果系統發展到足夠大，網上商城即可以拆分為訂單系統、支付系統、用戶系統等；而設備管理系統根據根據功能的不同，可以拆分為設備控制系統、設備管理系統、用戶信息管理系統等。
  • 分散式將一個業務分拆多個子業務，部署在不同的伺服器上，目前dubbo是使用最為廣泛的技術。相關知識見 blog.csdn.net/u01314278
  • 集羣通俗講即同一個業務，部署在多個伺服器上。伺服器集羣能夠為相同的服務提供更多的並發支持，因此當有更多的用戶訪問時，只需要向集羣中加入新的機器即可；另外可以實現當其中的某臺伺服器發生故障時，可以通過負載均衡的失效轉移機制將請求轉移至集羣中其他的伺服器上，因此可以提高系統的可用性
  • 緩存

    緩存就是將數據存放在離計算距離最近的地方以加快讀取速度。使用緩存有兩個條件：訪問數據熱點不均衡，即某些頻繁訪問的數據需要放在緩存中；數據在某個時間段內有效，具體技術有:

    ① CDN：內容分發網路，緩存網站的一些靜態資源；

② 反向代：部署在網站的前端，最先訪問到的就是反向代理伺服器；

③ 本地緩存：在應用伺服器本地緩存熱點數據，無需訪問資料庫；

　　 ④ 分散式緩存：應用程序通過網路通信訪問緩存數據；

  • 非同步業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式非同步執行進行協作。非同步消息隊列可以提高系統可用性、加快網站響應速度，消除並發訪問高峯。
  • 冗餘在集羣中機器數量達到一定數量的時候，部分機器宕機會是常態，因此需要數據冗餘備份，資料庫定期備份稱之為冷備份，主從分離實時同步稱之為熱備份
  • 自動化發布過程自動化、代碼管理自動化、自動化測試、自動化安全掃描、自動化低級bug掃描、自動化監控、自動化報警、自動化失效轉移、自動化降級。
  • 安全

網站架構的核心要素

軟體架構即「有關軟體整體結構與組件的抽象描述，用於指導大型軟體系統各方面的設計」。一般來說軟體架構需要關注性能、可用性、伸縮性、擴展性和安全性這5個架構要素。

性能

響應時間、並發訪問數量、訪問吞吐量來衡量一個網站的性能指標。所以優化網站性能的手段有:

Web前端性能優化

可以通過瀏覽器緩存、頁面壓縮傳輸、合理佈局頁面等手段；CDN加速，反向代理等手段。

應用伺服器性能優化可以使用伺服器本地緩存和分散式緩存，也可以通過非同步操作方式來加快響應，高並發問題可以使用集羣方式。資料庫服務端可用使用索引、緩存、SQL語句優化等手段。
  • 思維導圖

高可用

衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一臺或者多臺伺服器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。

  • 高可用架構設計的目的是為了保證伺服器硬體故障服務依然可用，數據依然保存並能夠被訪問。採用的手段有：數據和服務的冗餘備份+失效轉移機制。
  • 高可用服務通過負載均衡進行無狀態服務的失效轉移
  • 思維導圖

網站伸縮性

所謂伸縮性是指不需要改變網站的軟硬體設計，僅僅通過改變部署的伺服器數量就可以擴大或者縮小網站的服務處理能力。在整個互聯網行業的發展漸進演化中，最重要的技術就是伺服器集羣，通過不斷地向集羣中添加伺服器來增強整個集羣的處理能力。

衡量架構伸縮性的主要標準就是是否可用多臺伺服器構建集羣，是否容易向集羣中添加新的伺服器。加入新的伺服器後是否可以提供和原來的伺服器無差別的服務。集羣中可容納的總伺服器數量是否有限制。
  • 網站架構的伸縮性設計可分為: ① 不同功能進行物理分離實現伸縮; ② 單一功通過集羣規模實現伸縮
  • 應用伺服器集羣的伸縮性設計使用負載均衡手段實現伸縮，有關負載均衡的知識詳見：blog.csdn.net/zhoudaxia
  • 分散式緩存集羣的伸縮性設計分散式緩存集羣伸縮性設計的目標：讓新上線的緩存伺服器對整個分散式緩存集羣影響最小，也就是說新加入緩存伺服器後應使整個緩存伺服器集羣中已經緩存的數據儘可能還被訪問到。
  • 數據存儲伺服器集羣的伸縮性設計關係資料庫集羣的伸縮性設計：主從讀寫分離
  • 思維導圖

擴展性

即項目之間的耦合性，指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。

  • 思維導圖

安全性

  • 思維導圖

站從小到大演變過程中的技術升級路線；

  • （1） 初始階段網站架構： 一臺Server就剛需—應用程序、資料庫、文件等所有資源都集中在一臺Server上，典型案例：基於LAMP架構的網站

  • （2） 應用和數據服務分離： 隨著用戶數量的增多，可以將應用服務與數據服務分離以提高性能。三臺Server平天下—業務發展，單臺不再適應業務的發展，將應用和數據分離後成三臺Sever（應用伺服器、文件伺服器與資料庫伺服器）。分離後三臺Server對硬體資源的需求各不相同：應用伺服器需要更快更強大的CPU，而資料庫伺服器需要更快的硬碟和更大的內存，文件伺服器則需要更大的硬碟；

  • （3） 使用緩存改善網站性能： 用戶繼續增多，資料庫的壓力太大，此時考慮使用緩存。3+X的Server模式—減少資料庫訪問壓力，提高網站的數據訪問速度。緩存又可以分為：本地緩存和遠程緩存（可以是分散式的），本地緩存訪問速度快，但數據量有限；遠程分散式緩存可以集羣，因此容量不受限制；

  • （4） 使用應用伺服器集羣改善網站並發處理能力：

    增加緩存的做法緩解了數據伺服器的壓力，接著考慮緩解應用伺服器的壓力，將應用部署到集羣中。在這個集羣的前端添加負載均衡伺服器以進行負載均衡

  • （5） 資料庫讀寫分離： 使用緩存後絕大部分都可以不通過DB就能完成，但仍有一部分（緩存訪問不命中、緩存過期）和全部的寫操作需要訪問DB，在網站的用戶達到一定規模後，DB因為負載壓力過高成為網站的瓶頸。大部分主流DB都提供主從熱備功能，利用這一功能就可以配置兩臺DB主從關係，一臺數據更新同步到另一臺Server上。網站利用DB的這一功能，實現DB讀寫分離，從而改善DB負載壓力。

  • （6） 使用反向代理和CDN加速網站響應： 資料庫讀寫分離緩解了數據伺服器的壓力，接下來考慮解決應用伺服器的壓力。在負載均很伺服器加入反向代理伺服器和CDN伺服器。CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網路提供商的機房，而反向代理則部署在網站的中心機房。使用CDN和反向代理的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕後端伺服器的負載壓力。

  • （7） 使用分散式文件系統和分散式資料庫系統： CDN和反向代理緩解了應用伺服器的壓力，接著又得解決數據伺服器的壓力。隨著網站業務的不斷增長，資料庫雖然採用了讀寫分離機制，仍然不能滿足性能需要。考慮使用分散式文件系統和分散式資料庫系統

  • （8） 使用NoSQL和搜索引擎： NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分散式特性具有更好的支持。應用伺服器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。

  • （9） 業務拆分： 通過分而治之的手段將整個網站業務分成不同的產品線，如淘寶將首頁、商鋪、訂單、賣家、買家等拆分成不同的產品線，分歸不同的業務團隊負責。各個應用之間可以通過建立一個超鏈接建立關係，也可以通過消息隊列進行數據分發。

  • （10） 分散式服務：

    既然每一個應用系統都需要執行許多相通的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。

經典語錄

  • 尋找最合適的，慎防過度設計
  • 網站的業務發展—業務成就了技術，事業成就了人，而不是相反
  • 隨網站所需靈活應對，大型網站不是從無到有一步就搭建好一個大型網站，而是能夠伴隨小型網站業務的漸進發展，慢慢地演化成一個大型網站。
  • 技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段來解決。這句話我的理解，架構沒有好壞之分，適合業務的就是最好的，同時在設計架構時不要侷限於技術。

推薦閱讀：

查看原文 >>
相關文章