如題，就不廢話了，本人只是做的一個文章總結，方便知識點學習，並沒有詳細去講某個知識點，這本書也是這樣，是在「面」上給大家普及了「架構」。也推薦給大家去讀，真的很好。

以下的知識點其實是我最早的時候總結了一個思維導圖，但是知乎並不能上傳那個大圖，所以又做了稍微的修改，總結了以下的內容，有什麼不對的地方可以指點相互學習，排版可能不是很好，敬請原諒。

一.大型網站的架構的演化過程：

1.階段一：應用伺服器中包含：1.應用程序。2.資料庫。3.文件。

2.階段二：應用服務與資料庫，文件存儲分離，三個模塊各在一個伺服器。

3.階段三：使用緩存改善網站的性能：

（1）緩存部署在應用程序的伺服器：

優點：本地緩存訪問速度快。

缺點：受應用伺服器內存限制，與應用程序爭內存。

（2）緩存單獨部署在一個緩存伺服器集羣上：

優點：1.幾乎不受內存的限制（集羣可以添加）。2.有效緩解高並發伺服器壓力。

缺點：訪問速度不如本地緩存快。

4.階段四：在階段三的基礎上，應用伺服器也使用集羣的模式：

作用：為瞭解決高並發，將用戶的請求分發到應用伺服器集羣中的任意一臺伺服器上緩解壓力。

5.階段五：在階段四的基礎上，使資料庫「讀寫分離」:

作用一：資料庫主從2個資料庫，互相連接，可以備份數據，保護數據。

作用二：讀寫分離，讀的在主資料庫，寫在從資料庫，可以改善資料庫壓力。

6.階段六：使用反向代理和CDN加速網站的響應：

原理：和緩存一樣，使數據不從資料庫返回給用戶，而是從反向代理或者CDN伺服器。

（1）反響代理：部署在網站的機房，用戶的請求先訪問反向代理伺服器，如有用戶要的數據，直接返給用戶，加快相應並且緩解資料庫壓力。

（2）CDN：和反響代理的作用是一樣，區別在於部署在網路提供商的機房，用戶請求時可以在離自己近的網路提供商處獲取數據。

7.階段七：在階段六的基礎上，使資料庫和文件系統採用分散式集羣模式：

作用：為了緩解訪問壓力，解決並發，分散式資料庫是資料庫的最後拆分模式：分散式事務管理分散式資料庫

8.階段八：在階段七的基礎上，使用nosql和搜索引擎：

作用：應用程序通過一個統一的訪問模塊訪問數據，減少應用程序管理諸多數據源的麻煩。

9.階段九：在階段八的基礎上，對業務進行拆分（橫向分割）或者對系統縱向分層，採用分散式集羣的模式。

最終目的：提高用戶滿意，解決並發，伺服器壓力，保證7*24運作。

二.網站架構模式：

1.縱向分層：將網站軟體系統劃分，可分散式部署在不同的伺服器上：

（1）應用層

（2）服務層

（3）數據層

2.橫向分割：將網站的業務進行拆分，將不同的功能模塊進行拆分，不同的團隊進行管理部署在不同的分散式伺服器上

優點：部署在不同的伺服器上，那麼CPU，內存，存儲資源就越多，能夠處理並發訪問，提供好的服務

3.分散式：

優點：很多，可以自己度娘。

缺點：列舉幾點

（1）通過網路進行連接，對性能造成影響。

（2）伺服器多，難以維護和部署。

（3）分散式的數據很難保持一致性。

綜合來說優點是遠遠大於缺點的。

4.集羣：通過負載均衡伺服器，使用戶請求平均給伺服器集羣，解決並發問題

注意，集羣和分散式是2個概念。

5.緩存：改善軟體性能的第一手段：

（1）本地緩存

（2）分散式緩存

（3）反向代理

（4）CDN

6.非同步：如activemq：

作用：

（1）消除訪問高峯的並發

（2）加快網站的響應速度

（3）提高系統的可用性

7.資料庫冗餘：

作用：當一個資料庫故障時，需要一定的資料庫冗餘數據，轉移到另一個資料庫上提高可用性

（1）冷備份

（2）熱備份

（3）災備數據中心

8.自動化：

（1）發布過程自動化

（2）自動化代碼管理

（3）自動化測試

（4）自動化安全檢測

（5）自動化部署

（6）自動化監控

（7）自動化報警

（8）自動化失效轉移

（9）自動化失效恢復

（10）自動化降級

（11）自動化分配資源

9.安全：

攻擊類：

（1）SQL注入

（2）XSS攻擊

（3）CSRF攻擊

（4）WEB應用防火牆

（5）其他漏洞攻擊

信息加密：

（1）單向散列加密

（2）對稱加密

（3）非對稱加密

（4）密鑰安全管理

電子商務風險控制：

（1）風險

（2）風控

三.網站架構要素：

1、性能：

（1）網站性能測試：

  • 性能是什麼？

用戶視角下：在瀏覽器上直觀的感受網站響應的快慢。

開發人員視角下：響應延遲，系統吞吐量，並發處理能力，系統穩定等技術指標。

運維人員視角下：基礎設施性能和資源利用率等。

  • 性能測試指標：

響應時間：直觀的反應出系統的快慢，採用平均值的測試方式測試。

並發數：系統能同時處理並發的數目，也反應了系統的負載特性。

吞吐量：單位時間內系統處理請求的數量，體現了系統的整體處理能力。

性能計數器：描述伺服器或操作系統的一些數據指標。

  • 性能測試方法：

性能測試：對系統不斷施壓，驗證系統在資源範圍內是否達到預期性能。

負載測試：對系統不斷施壓，直到系統到安全臨界值。

壓力測試：超過最大安全負載的情況下，繼續施壓，以此獲得系統的最大承受能力。

穩定性測試：在特定的硬體，軟體，網路環境下，給系統載入一定的業務壓力，使系統運行一段時間，以此檢測是否穩定。

  • 性能測試報告：顧名思義，分析總結測試的結果。

（2）性能優化策略：

  • 性能分析：檢查各個請求處日誌，分析哪個環節響應時間超時，檢查監控數據，分析是CPU還是網路，內存，磁碟或者是代碼以及架構不合理。
  • 系統優化：根據具體的原因進行優化。可以分為2大類：

1.web前端性能優化：

（1）瀏覽器訪問優化：1.減少http請求。2.使用瀏覽器緩存。3.啟用壓縮。4.CSS放在頁面最上面，JS放在頁面最下面。5.減少cookie傳輸。

（2）CDN加速。

（3）反向代理。

2.應用伺服器性能優化：

（1）分散式緩存：

1.合理使用緩存：

不保存頻繁修改的數據，不保存沒有訪問熱點的數據（2-8定律），數據不一致與臟讀，緩存可用性，緩存預熱，緩存穿透。

2.分散式緩存架構：

3.更新同步的分散式緩存：企業級應用經常使用：JBOSS Cache。

4.不互相通信的分散式緩存：大型網站通常使用：Memcached：優點：簡單的通信協議，豐富的客戶端程序：支持JAVA等很多語言，高性能的網路通信，高效的內存管理，互不通信的伺服器集羣架構。

（2）非同步操作：「任何可以晚做點的事情都應該晚點再做」，但是要根據業務進行調整，避免產生糾紛，比如並發時期的下單業務。

（3）使用集羣：解決高並發訪問的問題。

（4）優化代碼：

1.多線程：將對象設計為無狀態對象（從JAVA面向對象的思想上看，無狀態對象是一種不良設計）。使用局部對象。並發訪問資源時使用鎖。

2.資源復用：單例，對象池

3.數據結構優化

4.垃圾回收

（5）存儲性能優化：

1. 機械硬碟和固態硬碟

2. B+樹和LSM樹

3. RAID和HDFS

總結：性能優化可能降低了高並發時期的響應延遲，但卻增加了低並非時的響應時間，設計者要心中有數。

2.可用性：

可用性，即為網站服務的可使用。

（1）網站可用性的度量與考覈

1. 網站可用性度量：通常用多少個9來衡量可用性。

  • 2個9，即99%：基本可用
  • 3個9，即99.9%：較高可用
  • 4個9，即99.99%：高可用---------具有自動恢復能力的高可用。
  • 5個9，即99.999%：極高可用性------------網站全年不可用時間小於5分鐘，需要一定的運氣

2. 網站可用性考覈：根據自己公司的政策制度去考覈，行業內也有一般的規則

（2）高可用的網站架構

典型的設計：

1. 應用層（集羣）：功能1，功能2，功能N

2. 服務層（集羣）：Session服務，賬戶服務，服務N

3. 數據層（集羣）：緩存服務，搜索服務，文件服務，資料庫服務等

（3）高可用的應用：

1. 通過負載均衡進行無狀態的服務失效轉移。

2. 應用伺服器的Session管理：

A. Session複製：只適用於集羣規模比較小的情況，大規模集羣的時候需要大量的通信複製Session佔用資源，會出現內存不足的情況

B. Session綁定：利用源地址Hash演算法使用戶總是請求集羣裏的特定的一個伺服器，當這個伺服器掛掉時，session就失效了，很少有網站用這個方法

C. 利用cookie記錄session：

受cookie大小限制，每次請求都要傳輸佔用資源，用戶關閉瀏覽器cookie就不能訪問了。

cookie簡單易用，可用性高，大部分cookie存儲的session比較小，去多網站或多或少都使用cookie記錄session

D. Session伺服器：

獨立的Session集羣伺服器進行session管理，一般採用這種方式和cookie相結合的方式

（4）高可用的服務：

1. 分級管理：運維上將伺服器分級管理，核心服務和應用用更好的硬體，部署上進行單獨部署隔離，避免故障的連鎖反應

2. 超時設置：用戶請求長時間不能影響，根據策略，選擇繼續等待還是將請求轉移到別的伺服器上

3. 非同步調用：消息隊列，如activemq。解決並發訪問，提高用戶響應，但是需要看業務情況使用，避免產生下單失敗，用戶卻收到成功信息這樣的情況

4. 服務降級：

A. 拒絕服務：拒絕低優先順序的服務調用，把資源讓給高優先順序的服務

B. 關閉功能：在高並發的時候，關閉一些非核心的服務，讓出資源

5. 冪等設計：

由於一些延遲情況，一些服務或者應用會被重複調用，這樣的情況是不可避免的，但是我們要保障重複調用和執行一次的結果相同，也有服務具有天然的冪等性，比如設置性別男，一次和多次結果是相同的

（5）高可用的數據：

1. 數據的存儲手段：數據備份和失效機制轉移

2. 緩存服務：

（A）目前主流有2種觀點：

a. 目前主流網站的數據都在緩存中讀取，所以，緩存和資料庫一樣重要，要實現同樣的高可用

b. 緩存不是數據存儲服務，緩存數據丟失，導致伺服器壓力過高應該通過別的手段去解決，而不是提高緩存本身的高可用

（B） CAP原理：

a. 數據持久性：保證數據持久的存儲，任何情況下不會丟失數據，複製存放在多個不同的物理存儲設備上。

b. 數據可訪問性：如果一個數據存儲設備損壞，使訪問快速的轉移到另一個設備上，如果過程不是很快，會造成數據不能訪問

c. 數據一致性：

1. 數據強一致性：各個副本的數據總是一致的，更新的時候要麼同時成功，要麼失敗。

2. 數據用戶一致性：如果各個副本中的數據不一致，通過糾錯和校驗機制，返回給用戶一個正確的數據

3. 數據最終一致性：物理存儲的數據不一致，終端不同用戶訪問的數據不一致，但是通過系統一段時間的自我恢復和修正，數據最終會達到一致性

（C） 數據備份：

a. 冷備：簡單，廉價，古老，數據的最終一致性不能保證，不能保證數據可用性

b. 熱備:

1.非同步熱備：資料庫寫的操作同步到幾個資料庫同時操作

2.同步熱備：數據寫操作只寫到主資料庫，寫完之後返回用戶成功，用線程等方法使主資料庫的數據同步到從資料庫

（D）失效轉移：

a. 失效確認：確認伺服器宕機：1.心跳檢測。2.應用程序訪問失敗報告

b. 訪問轉移：當確認某個伺服器宕機時，使請求路由到其它伺服器上，幾臺存儲資料庫的數據幾乎完全一致

c. 數據恢復：要將宕機的伺服器的數據進行恢復，不然在有伺服器宕機的時候可能出現無法轉移的現象

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

1. 網站發布：相當於給飛行中的飛機更換引擎，但是不能讓飛機墜毀。可以更新集羣伺服器中的一部分伺服器，在用戶不知情的狀況下，慢慢滲透更新全部的伺服器

2. 自動化測試：在發布之前，用自動化測試技術對代碼進行測試，確保無誤之後才發布

3. 預發布驗證：

a. 即使通過了自動化測試，也不要把其發布到正式環境上，在預發布環境下發布，並且進行一定的業務流程來測試是否正常。

b. 預發布的環境可以和正式環境部署在一起，也是就同一個環境。

c. 預發布連接的是真實的生產環境，所以做測試的時候要謹慎，如下單不要隨意更改商品的價格

d. 預發布如果遇到一些錯誤要立即排查，而不要帶著錯誤啟動

4. 代碼控制：

a. 主幹開發，分支發布

b. 分支開發，主幹發布

5. 自動化發布

6. 灰度發布：

a. 可以在伺服器集羣的一部分伺服器上更新版本，可以測試新版本的功能，而且出現錯誤需要回歸版本的時候只需要更新這幾個伺服器即可，避免了大規模伺服器回滾耗時很長的情況

（7）網站運行監控

1. 不允許沒有監控的系統上線：

（A） 監控數據採集：

a. 用戶行為日誌收集：伺服器端日誌收集，客戶瀏覽器日誌收集

b. 伺服器性能監控：收集伺服器性能指標，如系統LOAD，內存佔用，磁碟IO，網路IO等，及時預警，防患於未然

c. 運行數據報告：需要檢測一些具體的業務，比如業務的響應延遲，緩衝命中率，待處理任務總數等

（B）監控管理：

a. 系統報警：當某個值到達一個值的時候可以報警聯繫值班人員。

b. 失效轉移：監控系統發現故障後主動通知應用進行失效轉移。

c. 自動優雅降級：當高並發訪問時，自動關閉部分功能，讓出資源給核心功能。

總結：系統架構的可用性關係到生存死亡，對個人而且，可用性關係到個人的升遷，也許你對系統進行了很多改善，但是別人未必能直觀的感受到，也許你的上司都不知道，但是如果系統出現重大故障，連公司CEO都會知道你的名字。

3.伸縮性：

總的來說，網站都是往外「伸」的，「縮」的網站可能是快運營不下去的網站。

（1）網站架構的伸縮性設計：

1. 根絕功能進行物理分離實現伸縮，不同的伺服器部署不同的功能：

a. 縱向分離：將業務處理流程上的不同部分分離部署，實現伸縮性

b. 橫向分離：將不同的業務模塊分離部署，實現伸縮性

2. 單一功能通過集羣模式實現伸縮，集羣內的多臺伺服器提供相同的服務，功能：

a. 應用伺服器集羣

b. 數據伺服器集羣：緩存數據伺服器集羣，，存儲數據伺服器集羣

（2）應用伺服器集羣的伸縮性：

1. http重定向負載均衡

2. DNS域名解析負載均衡

3. 反向代理負載均衡

4. IP負載均衡

5. 數據鏈路層負載均衡

6. 負載均衡的演算法：

a. 輪詢

b. 加權輪詢

c. 隨機

d. 最少連接

e. 源地址散列

（3）分散式緩存集羣的伸縮性設計：

1. 不同於應用伺服器集羣的伸縮性設計，不能用簡單的負載均衡的手段來實現

2. 緩存數據的訪問不能是伺服器中的任意一臺，而應該是有這個特點數據的緩存伺服器

3. 新加入的緩存資料庫應該對集羣的影響很小，使已經存在的緩存數據還被平均的訪問到

4. memcached分散式緩存的集羣訪問模型

5. memcached分散式緩存集羣的伸縮性挑戰

6. 分散式緩存的一致性HASH演算法

（4）數據存儲伺服器集羣的伸縮性設計

1. 關係資料庫集羣的伸縮性設計

2. 非關係型資料庫集羣的伸縮性設計

總結：一個具有良好的伸縮性的網站，其設計總是走在業務的前面的，在業務需要處理更多訪問和服務之前，就已經做好了準備。反之業務走在技術的前面，採購來的伺服器無法加入集羣，即使勉強加入後，發現瓶頸卻不在這裡，導致技術天天加班，拖公司發展的後腿。

4.擴展性：

遵循開閉原則，即對擴展開放，對修改關閉

（1）構建可擴展的網站架構：

通過分層或者分割的方式進行架構伸縮，分割為若干個低耦合的獨立的組件模塊，獨立的模塊部署在獨立的伺服器上，之後，模塊間聚合的方式主要有分散式消息隊列和分散式服務。

（2）利用分散式消息隊列降低系統耦合性：

1. 事件驅動架構：

a. 經典的EDA架構

b. 具有良好的響應延遲，減少後端負載的數據壓力

2. 分散式消息隊列：如activemq

（3）利用分散式服務打造可復用的業務平臺：

1. 傳統「巨無霸」系統的弊端：

a. 編譯，部署困難

b. 代碼分支管理困難

c. 資料庫連接耗盡

d. 新增業務困難

解決方式：進行拆分：1.橫向拆分，2.縱向拆分。

2. web service 與企業級分散式服務：技術成熟，產品規範，成功案例多

缺點：

a. 臃腫的註冊與發現機制

b. 低效的xml序列化手段

c. 開銷相對較高的HTTP遠程通信

d. 複雜的部署與維護手段

導致了其難以滿足大型網站對系統高性能，高可用，易部署，易維護的要求

3. 大型網站分散式服務的需求與特點

a. 負載均衡

b. 失效轉移

c. 高效的遠程通信

d. 整合異構系統

e. 對應用最少侵入

f. 版本管理

g. 實時監控

4. 分散式服務架構設計：可查看阿里開源的dubbo為例

（4）可擴展的數據結構：

1. 傳統的關係型資料庫數據結構僵硬

2. NOSQL資料庫使用的ColumnFamily設計就是一個解決方案

（5）利用開放平臺建設網站的生態圈

1. API介面

2. 協議轉換

3. 安全

4. 審計

5. 路由

6. 流程

5.安全性：

（1）xss攻擊：跨站點腳本攻擊：

通過篡改網頁，注入惡意HTML腳本，控制用戶瀏覽器進行惡意操作

1. 類型：

a. 反射型：攻擊者誘使用戶點擊一個嵌入惡意腳本的連接，進行攻擊，偷取用戶cookie,密碼，偽造交易，盜取用戶財產，竊取情報

b. 持久型：黑客提交含有惡意腳本的請求，保存在被攻擊的WEB站點的資料庫中，攻擊論壇，微博等web應用

2. 預防手段：

a. 消毒：對某些HTML危險字元轉義，可以防止大部分的攻擊

b. httpOnly：瀏覽器禁止頁面JS訪問帶有httpOnly屬性的cookie

（2）注入攻擊：

1. SQL注入：在http請求中注入惡意的SQL命令（drop table users;），攻擊者要對資料庫結構有所瞭解才能進行攻擊。

a. 攻擊者瞭解資料庫結構的途徑，可進行預防。一般需要注意：

1.開源項目 2.錯誤回顯 3.盲注

b. 預防：

1.消毒：通過正則表達式過濾請求數據中可能注入的SQL。

2.參數綁定

2. OS注入

（3）CSRF攻擊：

1. 跨站點請求偽造，攻擊者通過跨站點請求，以合法的用戶的身份進行非法操作。

2. 核心：是利用了瀏覽器cookie或者伺服器session策略，盜取用戶身份。

3. 預防手段：

a. token

b. 驗證碼

c. Referer check

（4）其他漏洞和攻擊：

1. 錯誤回顯

2. HTML注釋

3. 文件上傳

4. 路徑遍歷

（5）web應用防火牆：

一些收費或者免費的web應用防火牆產品，如ModSecurity：可以統一攔截請求，過濾惡意參數，自動消毒，添加token，並且能夠根據最新的攻擊和漏洞情報，不斷升級策略，處理掉大多數攻擊。

（6）網站安全漏洞掃描：

模擬黑客對網站進行攻擊，查漏補缺。

（7）信息加密技術及密鑰安全管理

1. 單向散列加密

2. 對稱加密

3. 非對稱加密

4. 密鑰安全管理：

a. 把密鑰和演算法放在一個獨立伺服器上

b. 將加密演算法放在應用系統中，密鑰放在獨立的伺服器中

（8）信息過濾與反垃圾：

1. 文本匹配

2. 分類演算法

3. 黑名單

（9）電子商務風險控制：

1. 風險：

a. 賬戶風險：賬戶被盜，惡意註冊等

b. 買家風險：買家惡意下單佔用庫存不正當競爭

c. 賣家風險：不良賣家惡意欺詐的行為

d. 交易風險：盜刷信用卡，支付欺詐，洗錢套現等

2. 風控：

a. 規則引擎：當一些交易滿的某些指標滿足一定條件時，會被認為具有較高風險的欺詐可能性

b. 統計模型

總結：

1.所有的網站都是從小到大，從簡單到複雜，不要妄想一下就設計出一個大的網站架構，淘寶，阿里，騰訊亦是如此從小到大。

2.不要一味追隨大公司的解決方案，只有根據自己本身網站的需求去靈活應對。

3.不要為了技術而技術，一味的追求時髦的新技術可能會將網站引入崎嶇小道。

4.驅動網站技術發展的是網站的業務發展，同時業務的發展也促進了新的技術產生。

5.不要企圖用技術解決所有的問題，技術是用來解決業務的，而業務的問題也可以通過業務的手段去解決。

這本書最後還有對大型有名網站當初問題案例的分析，無非也是遵循了以上的規則。最後也有對一個「合格」架構師的看法，仁者見仁智者見智，我在這裡也就不總結自己的看法了，還是希望大家自己去讀一下這本書。


推薦閱讀：
相關文章