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

第1篇

1. 大型網站架構演化

大型網站系統的特色

  • 高併發,大流量:
  • 高可用:7×24小時不間斷服務。
  • 海量數據:使用大量服務器存儲、管理海量數據。
  • 用戶分佈普遍,網絡狀況複雜:
  • 安全環境惡劣:
  • 需求快速變動,發佈頻繁:
  • 漸進式發展:

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

  • 初始階段:應用程序、數據庫、文件等全部資源部署在一臺服務器上。
  • 應用服務和數據服務分離:網站使用多臺服務器,應用服務器、數據庫服務器和文件服務器。
  • 引入緩存:二八定律。可使用兩種:本地緩存(緩存在應用服務器上)和遠程緩存(緩存在分佈式緩存服務器上)。
  • 應用服務器集羣化:前端使用負載均衡服務器分發用戶請求到應用服務器集羣中任意一臺。
  • DB讀寫分離:此時會在應用服務器端引入專門的數據訪問模塊,使數據讀寫分離對應用透明。
  • 使用反向代理和CDN:二者的基本原理都是緩存,區別在於CDN部署在網絡提供商的機房,而反向代理部署在網站的中心機房。目的:加快用戶訪問速度、減輕後端服務器壓力。
  • 使用分佈式文件系統和分佈式數據庫系統:
  • 使用NOSQL和搜索引擎:
  • 業務拆分:將整個網站業務拆分紅多個產品線,分歸不一樣的業務團隊負責。技術上會將整個網站應用拆分紅多個獨立部署的子應用。
  • 分佈式服務:當單個網站應用拆分紅多個獨立部署的子應用後,可能每一個子應用都會有一些相同的業務操做,將這些共同的業務操做提取出來獨立部署,以服務的形式供各個應用共享。

2. 大型網站架構模式

模式的我的理解:解決問題的套路,是可重複性的。html

網站架構模式(大型網站的架構的通常思路和解決方案)

  • 分層:對系統進行橫向切分,造成上下層調用和依賴關係(如應用層→ 服務層 → 數據層)。層內可繼續分層。分層架構是邏輯上的,物理上可部署在同一臺物理機上,隨着網站發展,也能夠部署在不一樣機器上。
  • 分割:對系統進行縱向劃分,將不一樣的功能和服務分開,包裝成高內聚低耦合的模塊,便於維護和分佈式部署。
  • 分佈式:分層和分割的目的是便於分佈式部署(不一樣模塊部署在不一樣的機器上),經過遠程調用協做。分佈式在解決網站高併發的同時也會帶來其餘問題(如性能、可用性、一致性等問題)。在網站中經常使用的分佈式方案有:集羣:多臺機器部署相同的應用構成一個集羣,經過負載均衡設備共同對外提供服務。目的是爲了提升系統的可用性。
    • 分佈式應用和服務:將分層和分割後的應用和服務分佈式部署。
    • 分佈式靜態資源:將靜態資源分佈式部署。
    • 分佈式數據和存儲:
    • 分佈式計算:
    • 分佈式配置、分佈式鎖、分佈式文件系統等。
  • 緩存:CND、反向代理;本地緩存、遠程緩存。使用緩存的兩個前提:
    • 數據訪問熱點不均勻。
    • 數據在某個時間段內有效,不會很快過時。
  • 異步:解耦,生產者消費者模式。單一服務器中經過共享內存隊列的方式實現異步,分佈式系統中公共分佈式消息隊列實現異步。異步消息隊列的特性:冗餘:服務器冗餘備份,數據冗餘備份。
    • 提升系統可用性:消費者發生故障,生產者可繼續處理業務請求。
    • 加快網站響應速度
    • 消除併發訪問高峯:請求排隊,減輕負載。
  • 自動化:自動化代碼管理、自動化測試、自動化部署、自動化監控、自動化報警、自動化失效轉移、自動化失效恢復、自動化降級、自動化資源分配等。
  • 安全:加密、驗證碼、過濾、風險控制。

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

要素:性能、可用性、伸縮性、擴展性、安全性。前端

性能

  • 性能指標:響應時間、TPS等。
  • 性能優化手段(從瀏覽器到數據庫的全部環節均可以優化):
    • 瀏覽器端:瀏覽器緩存、頁面壓縮、合理佈局頁面、減小cookie傳輸。
    • 使用CDN、反向代理
    • 應用服務器端使用本地緩存或者分佈式緩存
    • 經過異步操做快遞響應用戶請求
    • 數據庫層面的優化:索引,SQL優化等
    • 代碼層面的優化

可用性

目標是當服務器宕機的時候,應用或者服務仍然可用。主要手段是冗餘。對應用服務器而言,不能保存請求的會話信息,不然即便切換到另外一臺應用服務器上,也沒法完成業務處理。web

伸縮性

經過不斷向集羣中加入服務器的來緩解併發訪問壓力和數據存儲需求。
對應用服務器集羣而言:只要服務器上不保存數據,全部服務器都是對等的,經過使用合適的負載均衡設備能夠向集羣中不斷加入服務器。
對於緩存服務器集羣:須要在緩存路由算法上下功夫,以保證不會由於新加入服務器致使既有的緩存路由無效,尤爲是對於嚴重依賴緩存的網站應用,可能致使網站崩潰。
對於關係數據庫服務器集羣:在數據庫以外經過路由分區等手段來實現。算法

擴展性

和伸縮性不一樣,這裏是指新增業務產品時,是否能夠實現對現有產品透明無影響。
主要手段是事件驅動架構和分佈式服務。
事件驅動架構利用消息隊列來實現。
分佈式服務則是將業務和可複用服務分離開來,經過分佈式服務框架調用。數據庫

安全性

對各類可能的攻擊提供可靠的應對策略。後端

第2篇 

4. 網站的高性能架構

性能測試指標

響應時間:發請求 到 收到影響 所需的時間。《Latency Numbers Every Programmer Should Know》瀏覽器

併發數:系統可以同時處理請求的數目。對網站而言就是網站併發用戶數,網站系統用戶數>網站在線用戶數>網站併發用戶數。緩存

吞吐量:單位時間內系統處理的請求數量。經常使用量化指標有TPS(每秒事務數)、QPS(每秒查詢數)、HPS(每秒HTTP請求數)。三者關係類比:系統吞吐量(天天經過收費站的車輛數目)、系統併發數(高速路上正在行駛的車輛數目)和響應時間(車速)。安全

性能計數器:反映服務器或者OS的一些數據指標。如系統負載System Load(當前正在被CPU執行和等待被CPU執行的進程數目總和)、內存使用、網絡與磁盤IO等指標。性能優化

性能測試方法

性能測試是一個總稱,具體可細分爲性能測試、負載測試、壓力測試、穩定性測試。

性能分析

如何排查一個網站的性能瓶頸?檢查請求處理的各個環節的日誌,分析哪一個環節響應時間不合理;檢查監控數,分析影響性能的主要因素是內存,磁盤,網絡仍是CPU,是代碼問題仍是架構設計不合理,或是系統資源確實不足。

性能優化

分爲三大類:web前端性能優化、應用服務器性能優化、存儲服務器性能優化。

1. web前端性能優化

  • 瀏覽器訪問優化:減小http請求(如多個js放在同一文件);使用瀏覽器緩存;啓用壓縮;CSS放在最前面,JS放在頁面最後面;減小cookie傳輸。
  • CDN加速
  • 反向代理

2. 應用服務器性能優化

  • 分佈式緩存:注意合理使用緩存。分佈式緩存有兩種架構方式:一種是以JBoss Cache爲表明的須要更新同步的分佈式緩存,一種是以Memcached爲表明的不互相通訊的分佈式緩存。
  • 異步操做: 使用消息隊列將調用異步化。
  • 使用集羣:經過服務器集羣+負載均衡服務器能夠分發高併發請求,提升響應。
  • 代碼優化:
    • 多線程:解決線程安全的手段:無狀態對象,使用局部對象,鎖。
    • 資源複用:資源複用主要有兩種模式:單例(Singleton)和對象池(Object Pool)。鏈接池和線程池本質上都是對象池。
    • 數據結構:
    • 垃圾回收:

3. 存儲服務器性能優化

機械硬盤 VS. 固態硬盤

B+樹 VS. LSM樹

RAID VS. HDFS

 

5. 網站的高可用架構

網站可用性度量

指標 年度不可用時間
2個9 <88小時
3個9 <9小時 
4個9 <53分鐘 
 5個9  <5分鐘

網站可用性考覈

根據故障等級和故障持續時間計算故障分,進行績效考覈。

故障分=故障時間(分鐘)×故障權重

高可用網站架構

典型的分層模型是三層,即應用層,服務層和數據層;應用層負責業務邏輯處理,服務層提供可複用的服務,數據層負責數據的存儲和訪問。

大型網站的分層架構以及物理服務器的分佈式部署使得位於不一樣層次的服務器具備不一樣的可用性特色,宕機時產生的影響也不一樣,對應的解決方案也不一樣。

實現高可用的手段就是冗餘,集羣化部署,因此會涉及到負載均衡。

應用層的服務器:負載均衡會和應用服務器保持心跳,刪除不可用的。

服務層的服務器:通常會使用分佈式服務調用框架,分佈式服務調用框架的客戶端會實現軟件負載均衡。

高可用的應用

應用層的顯著特色是應用的無狀態性。即應用服務器不保存業務的上下文信息,使得多個服務實例之間徹底對等,請求提交到任意服務器,處理結果徹底同樣。

  • 經過負載均衡實現無狀態服務的失效轉移。
  • 應用服務器集羣的session管理:應用服務器的高可用架構設計主要基於服務無狀態這一特性。遇到有狀態的狀況怎麼辦呢?將這些狀態信息稱爲Session,集羣環境下,Session的管理手段有:
    • Session複製:集羣中個服務器之間同步session對象,每臺機器都保存全部的session信息。
    • Session綁定:利用負載均衡的源地址Hash算法,未來源於同一IP的請求分發到同一臺服務器上。即Session綁定在某臺特定的服務器上,又稱做會話黏滯。
    • 利用cookie記錄Session:大小受限、不安全
    • Session服務器:利用獨立部署的Session服務器(集羣)統一管理Session,應用服務器每次讀寫Session時,都訪問Session服務器。本質是將應用服務器的狀態分離,分爲無狀態的應用服務器和有狀態的Session服務器,而後針對這兩種服務器的不一樣特性分別設計其架構。

高可用的服務

可複用的服務和應用同樣,也是無狀態的服務,可使用相似負載均衡的失效轉移策略。實踐中的一些好的策略:

  • 分級管理:核心應用和服務使用好的硬件
  • 超時設置:
  • 異步調用:
  • 服務降級:避免高併發使得性能降低乃至宕機。降級有兩種手段:拒絕服務及關閉服務。
  • 冪等性設計:

高可用的數據

保證數據存儲高可用的手段主要是數據備份和失效轉移機制。

CAP理論《參考》

爲了保證數據的高可用,網站一般會犧牲另外一個也很重要的指標:數據一致性。

高可用數據的幾層含義:數據持久性、數據可訪問性、數據一致性。

數據備份

  • 數據冷備:按期將數據複製到某種存儲介質(磁帶、光盤...)上並物理存檔保存。優勢是簡單和廉價,缺點是不能保證數據最終一致,也不能保證數據可用性。
  • 數據熱備:分爲兩種:異步熱備方式和同步熱備方式。
    • 異步熱備:多份數據副本的寫入操做異步完成,應用收到寫入成功的響應時,只寫成功了一份,存儲系統會異步地寫其餘副本。異步方式下,存儲服務器分爲Master和Slave。當寫入Master成功後,當即返回寫入成功,而後由Master異步寫入到Slave。
    • 同步熱備:多份數據副本的寫入操做同步完成,當收到寫入成功的消息時,多份數據都已經寫操做成功。當應用收到寫入失敗的消息時,可能部分或者所有副本都已寫入成功了。存儲服務器無主從之分,徹底對等。

失效轉移

失效轉移操做由三部分組成:失效確認、訪問轉移、數據恢復。
判斷一臺服務器是否宕機的手段有兩種:心跳檢測和應用程序訪問失敗報告。

6. 網站的伸縮性架構

網站架構的伸縮性設計

能夠分爲兩類,一類是根據功能進行物理分離實現伸縮,一類是單一功能經過集羣實現伸縮。前者是不一樣的服務器部署不一樣的服務,提供不一樣的功能;後者是集羣內的多臺服務器部署相同的服務,提供相同的功能。

不一樣功能進行物理分離實現伸縮

具體能夠分爲縱向分離(分層)和橫向分離(業務分割)。

單一功能經過集羣規模實現伸縮

即便拆分到最小粒度進行獨立部署,單一服務器也有可能沒法知足業務發展。此時須要使用服務器集羣。將相同的服務部署在多臺服務器上構成一個總體對外提供服務。

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

核心關鍵點:應用服務器設計成無狀態的;加上負載均衡服務器。

實現負載均衡的基礎技術有:

  • HTTP重定向負載均衡:優勢是簡單,缺點是瀏覽器須要兩次請求服務器才能完成一次訪問,性能較差。
  • DNS域名解析負載均衡:
  • 反向代理負載均衡:
  • IP負載均衡:
  • 數據鏈路層負載均衡:三角傳輸模式、直接路由(DR),產品有LVS等。

負載均衡算法有:

  • 輪詢(Round Robin,RR):全部請求被依次分發到每臺應用服務器上。
  • 加權輪詢(Weighted Round Robin,WRR):
  • 隨機(Random):
  • 最少鏈接(Least Connections):記錄每一個應用服務器正在處理的鏈接數(請求數),將請求分發到最少的那個。
  • 源地址散列(Source Hashing):計算請求來源IP地址的hash值來獲得應用服務器,同一IP分配到同一應用服務器。

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

如何避免以下問題:加入新的服務器 → 路由的結果改變(好比Hash後求模)→ 緩存失效→ 大量請求走DB → 數據庫宕機。

解決方案:改進路由算法,好比一致性Hash算法。

數據存儲服務器集羣的伸縮性設計

關注點:如何保證數據的持久性和可用性。必須保證數據的可靠存儲,任何狀況下都必須保證數據的可用性和正確性。

具體分爲兩類來分析,關係型的和NOSQL。

關係數據庫集羣的伸縮性設計

多臺服務器部署MySQL實例,有主從之分,寫在主服務器,讀在從服務器。

根據業務分庫,不一樣業務的數據庫表部署在不一樣的數據庫集羣上。

單表過大就分表。

關鍵詞:主從複製、分庫、分表。

NoSQL數據庫集羣的伸縮性設計

做爲讀關係數據庫的補充,NoSQL放棄了關係數據庫的兩大基礎:SQL和事務。而強化了大型網站更關注的一些特性:伸縮性和高可用性。

 

7. 網站的可擴展架構

概念澄清

  • 擴展性(Extensibility):對現有系統影響最小的狀況下,系統功能可持續擴展或提高的能力。表如今系統基礎設施穩定不須要常常變動,應用之間較少依賴和耦合,對需求變動能夠敏捷響應。
  • 伸縮性(Scalability):系統可以經過增長(減小)自身資源規模的方式加強(減小)本身計算處理事務的能力。若是這種增減是成比例的,就被稱做線性伸縮性。在網絡架構中,一般利用集羣的方式增長服務器數量、提升系統的總體事務吞吐能力。

設計網站可拓展架構的核心思想是模塊化,並在此基礎之上,下降模塊間的耦合性,提升模塊的複用性。

主要手段是分層和分割爲若干個低耦合的獨立的模塊,這些組件模塊以消息傳遞及依賴調用的方式聚合成一個完整的系統。

模塊分佈式部署後具體聚合方式主要有分佈式消息隊列和分佈式服務。

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

事件驅動架構
經過在低耦合的模塊之間傳輸事件消息完成模塊間合做。具體實現手段不少,典型的是分佈式消息隊列。

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

大型網站分佈式服務的需求和特色:服務註冊和發現、負載均衡、失效轉移、高效的遠程通訊、整合異構系統、對應用最少侵入、版本管理、實時監控。

利用開放平臺建設網站生態圈

開放平臺的一些功能點:API接口、協議轉換、安全、審計、路由、流程。

8. 網站的安全架構

常見的網站應用攻擊

XSS攻擊

跨站點腳本攻擊。常見的XSS攻擊類型有兩種,一種是反射型的,一種是持久型的。
防護手段:消毒(將「<」轉義爲「&lt」等)、HttpOnly(瀏覽器禁止頁面js訪問帶有HttpOnly屬性的Cookie)

注入攻擊

主要有兩種形式,SQL注入攻擊和OS注入攻擊。
防護手段:避免表結構泄露、消毒、參數綁定等。

CSRF攻擊

跨站點請求僞造。利用跨站請求,在用戶不知情的狀況下,以用戶的身份僞造請求。核心是利用了瀏覽器Cookie或服務器Session策略,盜取用戶身份。
防護手段:主要是識別請求者身份。主要有下面幾種方法。

  • 表單Token:CSRF是一個僞造用戶請求的操做,因此須要構造用戶請求的全部參數才行。此方法是在請求參數中增長隨機數的辦法來阻止攻擊者得到全部的請求參數。
  • 驗證碼:用戶體驗不太好,僅限必要時使用。
  • Referer check:Http請求的Referer域中記錄着請求來源,可檢測請求來源驗證是否合法。如圖片防盜鏈。

其餘攻擊和漏洞

Error Code、HTML註釋、文件上傳、路徑遍歷等。

 

信息加密

信息加密技術可分爲三類:單項散列加密、對稱加密和非對稱加密。

單項散列加密

過程:不一樣長度的信息 → 散列計算 → 固定長度輸出。
該過程是單向的,從左到右能夠,反之不行,即不能根據固定長度的輸出獲得原始信息。
應用:密碼加密保存。
爲了增長安全性,還會給散列算法加點鹽(salt),salt至關於加密的密鑰,增長破解的難度。
經常使用的單向散列算法:MD五、SHA等。
單向散列算法的特性:輸入的任何微小變化都會致使輸出的徹底不一樣。

對稱加密

對稱加密:加密和解密使用同一個密鑰。
應用:對稱加密一般用在信息須要安全交換或存儲的場合,如Cookie加密、通訊加密等。
優缺點:算法簡單、效率高、開銷小、適合對大量數據加密;如何安全交換密鑰是個難題。
經常使用的對稱加密算法:DES算法、RC算法。

非對稱加密

非對稱加密:加密和解密使用不一樣的密鑰。公鑰加密後的信息必須用私鑰才能解開,私鑰加密後的信息必須用公鑰才能解開。
應用:信息安全傳輸、數字簽名
經常使用的非對稱加密算法:RSA算法。

密鑰的安全管理

無論是單向散列加密用到的salt、對稱加密的密鑰、仍是非對稱加密的私鑰,一旦這些密鑰泄露,則全部基於這些密鑰加密的信息就失去了私密性。

信息的安全性是靠密鑰保證的。實際開發中,有的將密鑰寫在源代碼中,有的放在配置文件中,能夠將密鑰和算法放在獨立的服務器上。

 

 

做者:tsiangleo

出處:http://www.cnblogs.com/tsiangleo/

本文版權歸做者和博客園共有,歡迎轉載,未經贊成須保留此段聲明,且在文章頁面明顯位置給出原文連接。歡迎指正與交流。

相關文章
相關標籤/搜索