《大型網站架構演化發展歷程》筆記——網站架構模式

模式：關鍵在於模式的可重複性，問題與場景的可重複性帶來解決方案的可重複使用。

 

大型互聯網公司在實踐中提出了許多解決方案，以實現網站高性能、高可用、易伸縮、可擴展、安全等各類技術架構目標。

這些解決方案又被更多網站重複使用，從而逐漸造成大型網站架構模式。

 

1 網站架構模式

1.分層

分層是企業應用系統中最多見的一種架構模式，將系統在橫向維度上切分紅幾個部分，每一個部分負責一部分相對比較單一的職責，而後經過上層對下層的依賴和調用組成一個完整的系統。

在大型網站架構中也採用分層結構，將網站軟件系統分爲應用層、服務層、數據層：

 

分層架構也有一些挑戰，就是必須合理規劃層次邊界和接口，在開發過程當中，嚴格遵循分層架構的約束，禁止跨層次的調用(應用層直接調用數據層)及逆向調用(數據層調用服務層，或者服務層調用應用層)。

大的分層結構內部還能夠繼續分層，如應用層還能夠分爲業務邏輯層和視圖層，服務層還能夠分紅邏輯處理層和數據接口層。

 

分層架構是邏輯上的，在物理部署上，三層架構能夠部署在同一個物理機器上，可是隨着網站業務的發展，必然須要對已經分層的模塊分離部署，即三層結構分別部署在不一樣的服務器上，使網站擁有更多的計算資源以應對愈來愈多的用戶訪問。

 

因此雖然分層架構模式最初的目的是規劃軟件清晰的邏輯結構以便於開發維護，但在網站的發展過程當中，分層結構對網站支持高併發向分佈式方向的發展相當重要。所以在網站規模還很小的時候就應該採用分層的架構，這樣未來網站作大時才能更好應對。

 

2.分割

若是說分層是將軟件在橫向方面進行切分，那麼分割就是在縱向方面對軟件進行切分。

網站越大，功能越複雜，服務和數據處理的種類也越多，將這些不一樣的功能和服務分隔開來，包裝成高內聚低耦合的模塊單元，不只有助於軟件的開發維護也便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展能力。

大型網站分割的粒度可能會很小。好比在應用層，將不一樣業務進行分割，例如將購物、論壇、搜索、廣告分割成不一樣的應用，有獨立的團隊負責，部署在不一樣的服務器上。

若是業務複雜龐大，在同一個應用內部還能夠繼續分割，好比購物業務能夠分割成機票酒店業務，小商品業務等，這些又能夠繼續分割成首頁，搜索列表等。

 

3.分佈式

對於大型網站，分層和分割的一個主要目的是爲了切分後的模塊便於分佈式部署，即將不一樣模塊部署在不一樣的服務器上，經過遠程調用協同工做。

分佈式意味着可使用更多的計算機完一樣的工做，計算機越多，CPU、內存、存儲資源就越多，能過處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。

 

分佈式存在的問題：

1. 分佈式意味着服務調用必須經過網絡，可能會對性能形成比較嚴重影響

2. 服務器越多，宕機機率越大，一臺服務器宕機可能會致使不少應用不可訪問，下降可用性

3. 數據一致性難以保障，分佈式事務

4. 網站依賴綜合複雜，開發管理維護困難

 

經常使用的分佈式方案有如下幾種：

• 分佈式應用和服務：將分層和分割後的應用和服務模塊分佈式部署，能夠改善網站性能和併發性、加快開發和發佈速度、減小數據庫鏈接資源消耗。

• 分佈式靜態資源：網站的靜態資源如JS、CSS、Logo圖片等資源獨立分佈式部署，並採用獨立的域名，即人們常說的動靜分離。靜態資源分佈式部署能夠減輕應用服務器的負載壓力；經過使用獨立域名加快瀏覽器併發加載的速度。

• 分佈式數據和存儲：大型網站須要處理以P爲單位的海量數據，單臺計算機沒法提供如此大的存儲空間，這些數據庫須要分佈式存儲。除了對關係數據庫分佈式部署外，nosql也幾乎都是分佈式的。

• 分佈式計算：目前網站廣泛使用Hadoop和MapReduce分佈式計算框架進行此類批處理計算，其特色是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分佈式計算。

此外，還有支持網站線上服務器配置實時更新的分佈式配置；分佈式環境下實現併發和協同的分佈式鎖；支持雲存儲的分佈式文件系統等

 

4.集羣

對於用戶訪問集中的模塊須要將獨立部署的服務器集羣化，即多臺服務器部署相同的應用構成一個集羣，經過負載均衡設備共同對外提供服務。

服務器集羣可以爲相同的服務提供更多的併發支持，當有更多的用戶訪問時，只須要向集羣中加入新的機器便可；

當其中的某臺服務器發生故障時，負載均衡的失效轉移機制將請求轉移至集羣中其餘服務器上，所以提升系統的可用性。

【即便是訪問量很小的分佈式應用和服務，也至少要部署兩臺服務器構成一個小集羣，就是爲了提升可用性】

 

5.緩存

緩存就是將數據存放在距離計算最近的位置以加快處理速度。

緩存是改善軟件性能的第一手段，軟件設計中緩存無處不在。

網站架構中的緩存有如下幾種：

• CDN：內容分發網絡，部署在距離終端用戶最近的網絡服務商，用戶的請求最早到達這裏，在這裏緩存網站一些靜態資源，能夠就近以最快速度返回給用戶（如視頻網站和門戶網站會將用戶訪問量最大的熱點內容緩存在CDN）。
• 反向代理：當用戶請求到達網站數據中心時，最早訪問到的就是反向代理服務器（架構可參閱網站架構），這裏緩存網站的靜態資源，無需將請求繼續轉發給應用服務器。
• 本地緩存：在應用服務器本地緩存着熱點數據，應用程序能夠在本機內存中直接訪問數據，無需訪問數據庫
• 分佈式緩存：大型網站數據量龐大，須要的內存不是單機能承受的，因此除了本地緩存，還須要分佈式緩存，應用程序經過網絡通訊訪問緩存數據

緩存的兩個前提條件：

1.數據訪問熱點不均衡，被頻繁訪問的數據更該放在緩存中；

2.數據不會很快過時，不然易由於緩存數據失效致使髒讀

6.異步

軟件發展的一個重要目標和驅動力是下降軟件耦合性。解耦合的手段除了分層，分割，分佈等，還有一個重要手段是異步，將一個業務操做分紅多個階段，每一個階段經過共享數據的方式異步執行進行協做

在單一服務器內部可經過多線程共享內存對了的方式處理；在分佈式系統中可經過分佈式消息隊列來實現異步。

異步架構的典型就是生產者消費者方式，二者不存在直接調用。只要保持數據結構不變，彼此功能實現能夠隨意變化而不互相影響，擴展新功能很是便利。

異步還有以下特性：

• 提升系統可用性：消費者服務器發生故障，數據會在消息隊列服務器中存儲堆積，生產者服務器能夠繼續處理業務請求，系統總體表現無端障。消費者服務器正常後，繼續處理消息隊列中的數據
• 加快網站響應速度：生產者服務器處理完業務請求不需等消費者服務器處理就能夠返回，響應延遲較少。
• 消除併發訪問高峯：使用消息隊列將高峯增長的訪問請求數據放入消息隊列中，待消費者服務器依次處理

異步處理業務可能影響用戶體驗，須要產品設計的支持。

 

7.冗餘

服務器規模比較大時，宕機幾乎是必然事件。要保證在服務器宕機的狀況下網站依然能夠繼續服務，不丟失數據，就須要一點程度的服務器冗餘運行，數據冗餘備份。當某臺服務器宕機時，能夠將其上的服務和數據訪問轉移到其餘機器上

訪問和負載很小的服務也必須部署至少兩臺服務器構成集羣，目的就是經過冗餘實現高可用。數據庫除了冷備份外，爲了保證在線業務高可用，還須要對數據庫進行主從分離，實時同步實現熱備份，某些大網站還會部署災備數據中心

 

8.自動化

無人值守的狀況下網站能夠正常運行，一切均可以自動化是網站的理想狀態。目前大型網站的自動化架構設計主要集中在發佈運維方面，包括如下：

• 自動化代碼管理：代碼版本控制、代碼分支建立合併等過程自動化，開發工程師只要提交開發的產品代號，系統會自動爲其建立開發分支，後期會自動進行代碼合併；
• 自動化測試：代碼開發完成，提交測試後，系統自動將代碼部署到測試環境，啓動自動化測試用例進行測試，並向相關人員發送測試報告，反饋測試結果；
• 自動化安全檢測：安全檢測工具經過對代碼進行靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估其安全性；
• 自動化部署：將工程代碼自動部署到線上生產環境
• 自動化監控：對服務器進行心跳檢測，並監控其各項性能指標和應用程序的關鍵數據指標。若是發現異常，超出預設的閾值，就進行自動化報警
• 自動化失效轉移：檢測到故障後，系統會自動將失效的服務器從集羣中分隔，再也不處理系統中應用請求。故障消除後，系統會自動化失效恢復
• 自動化降級：當網站遇到訪問高峯，超出網站最大處理能力時，爲了保證網站安全可用，會經過拒絕部分請求及關閉部分不重要服務將系統負載降至一個安全水平（如雙十一淘寶關閉評價）。必要時還須要自動化分配資源，將空閒資源分配給重要任務，擴大其部署規模

 

9.安全

網站在安全架構方面的一些模式：

• 經過密碼和手機校驗碼進行身份認證；
• 登陸、交易須要對網絡通訊進行加密；
• 服務器存儲的敏感數據進行加密處理；
• 使用驗證碼防止機器程序攻擊，佔用資源；
• 對XSS攻擊、SQL注入進行編碼轉換；
• 對垃圾信息，敏感信息進行過濾；
• 對交易轉帳等根據交易模式和交易信息進行風險控制