大型網站架構模式

學習本文章須要弄懂的問題：

1.模式的定義

2.分層：什麼是分層？請舉個例子，分層有什麼好處？分層必須注意的事項？

3.分割：分割的定義和好處？

4.分佈式的定義？分佈式所面臨的問題？分佈式方案有哪些？各有什麼優勢？

5.集羣的定義？集羣的優勢有那些？

6.緩存的定義？緩存的優勢？使用緩存的條件？緩存的種類？

7.什麼是異步？異步的優勢和缺點？

8.冗餘的必要性？

9.發佈過程自動化的流程？運維自動化的機制？

10.保證安全經常使用的手段，列舉一些？

 

關於什麼是模式，這個來自建築學的詞彙是這樣定義的：「每個模式描述了一個在咱們周圍不斷重複發生的問題及該問題解決方案的核心。

這樣，你就能一次又一次地使用該方案而沒必要作重複工做」。模式的關鍵在於模式地可重複性，問題場景的可重複性帶來解決方案的可重複性。

 

也許互聯網產品不是隨便複製就能成功的，創新的產品更能爲用戶創造價值。

可是網站架構卻有一些共同的模式，這些模式已經被許多大型網站一再驗證，經過對這些模式的學習，

咱們能夠掌握大型網站架構的通常思路和解決方案，以指導咱們的架構設計。

 

爲了解決大型網站面臨的高併發訪問、海量數據處理、高可靠運行等一系列問題與挑戰，

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

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

下面會介紹一些大型網站經常使用的模式。

 

1.分層

分層是企業應用系統中最多見的一種架構模式，

（定義：）將系統在橫向維度上切分紅幾個部分，每一個部分負責一部分相對比較單一的職責，而後經過上層對下層的依賴組成一個完整的系統。

分層結構在計算機世界中無處不在，網絡的七層通訊協議是一種分層結構；計算機硬件、操做系統、應用軟件也能夠看作是一種分層結構。

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

網站分層架構

應用層	負責具體業務和視圖展現，如網站首頁及搜索輸入和結果展現
服務層	爲應用層提供服務支持，如用戶管理服務，購物車服務等
數據層	提供數據存儲訪問，如數據庫、緩存、文件、搜索引擎等

 

 

 

 

 

（分層的好處：）經過分層，能夠更好的將一個龐大的軟件系統切分紅不一樣的部分，便於分工合做開發和維護；

各層之間具備必定的獨立性，只維持調用接口不變，各層能夠根據具體問題獨立演化發展而不須要其餘層必須作出相應調整。

 

（分層的挑戰：）可是分層架構也有一些挑戰，就是必須合理規劃層次邊界和接口，在開發過程當中，嚴格遵循分層架構的約束，

禁止跨層次的調用（應用層直接調用數據層）及逆向調用（數據層調用服務層，或者服務層調用應用層）。

 

在實踐中，大的分層結構內部還能夠繼續分層，如應用層能夠再細分爲視圖層（美工負責）和業務邏輯層（工程師負責）；

服務層也能夠細分爲數據接口層（適配各類輸入和輸出的數據格式）和邏輯處理層。

 

分層架構是邏輯上的，在物理部署上，三層結構能夠部署在同一臺物理機器上，可是隨着網站業務的發展，必然須要對已經分層的模塊分離部署，

即三層結構分別部署在不一樣的服務器上，使網站有愈來愈多的計算資源以應對愈來愈多的客戶訪問。

 

雖然分層架構模式最初的目的是規劃軟件清晰的邏輯結構便於開發維護，但在網站的發展過程當中，分層式結構對網站支持高併發向分佈式方向發展相當重要。

所以在網站規模還很小的時候就應該採用分層的架構，這樣未來網站作大時才能更好地應對。

 

 

2.分割

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

（分割的定義：）分割就在縱向上根據業務的需求將一個服務分紅多個更小更細的服務。

網站越大功能越複雜，服務和數據處理的種類也越多，將這些不一樣的服務和功能分割開來，包裝成高內聚低耦合的模塊單元，

（分割的優勢：）一方面有助於網站的開發和維護；另外一方面，便於不一樣模塊的分佈式部署，提升網站的併發能力和功能擴展能力。

 

大型網站分割的顆粒度可能會很小。好比在應用層，將不一樣業務進行分割，

例如將購物、論壇、搜索、廣告分割成不一樣的應用，由獨立的團隊負責，部署在不一樣的服務器上；

在同一個應用內部，若是規模龐大業務複雜，會繼續進行分割，

好比購物業務，能夠進一步分割成機票酒店業務、3C業務、小商品業務等更小的顆粒度。

而即便在這個顆粒度上，仍是能夠繼續分割成首頁、搜索列表、商品詳情等模塊，這些模塊無論在邏輯上仍是物理部署上，均可以是獨立的。

一樣在服務層也能夠根據須要將服務分割成合適的模塊。

 

 

3.分佈式

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

分佈式意味着可使用更多的計算機完成一樣的功能，計算機越多，CPU、內層、存儲資源也就越多，

可以處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。

 

（分佈式部署面臨的四個問題：）但分佈式在解決網站高併發問題的同時也帶來了其餘問題。

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

其次服務器越多，服務器宕機的機率也就越大，一臺服務器宕機形成的服務不可用可能會致使不少應用不可訪問，使網站可用性下降；

另外數據在分佈式的環境中保持數據一致性也很是困難，分佈式事務也難以保證，這對網站業務正確性和業務流程有可能形成很大影響；

分佈式還致使網站依賴錯綜複雜，開發管理維護困難。

所以，分佈式設計要根據具體狀況量力而行，切莫爲了分佈式而分佈式。

 

在網站應用中，經常使用的分佈式方案有如下幾種。

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

還可使不一樣應用複用共同的服務，便於業務功能擴展。

 

分佈式靜態資源：網站的靜態資源如JS，CSS，Logo圖片等資源獨立分佈式部署，並採用獨立的域名，即人們常說的動靜分離。

靜態資源分佈式部署能夠減輕應用服務器的負載壓力；經過使用獨立域名加快瀏覽器併發加載的速度；

由負責用戶體驗的團隊進行開發維護有利於網站分工合做，使不一樣技術工種術業有專攻。

 

分佈式數據和存儲：大型網站須要處理以P爲單位的海量數據，單臺計算機沒法提供如此大的空間，這些數據須要分佈式存儲。

除了對傳統的關係數據庫進行分佈式部署外，爲網站應用而生的各類NoSQL幾乎都是分佈式。

 

分佈式計算：嚴格說來，應用、服務、實時數據處理都是計算，網站除了要處理這些在線業務，

還有很大一部分用戶沒有直觀感覺的後臺業務要處理，包括搜索引擎的索引構建、數據倉庫的數據分析統計等。

這些業務的計算規模很是龐大，目前網站廣泛使用Hadoop及其MapReduce分佈式計算框架進行此類批處理計算，

其特色是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分佈式計算。

 

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

 

 

4.集羣

使用分佈式雖然已經將分層和分割後的模塊獨立部署，可是對用戶訪問集中的模塊·（好比網站的首頁），

還須要將獨立部署的服務器集羣化，即（定義：）多臺服務器部署相同的應用構成一個集羣，經過負載均衡設備共同對外提供服務。

 

由於服務器集羣有更多服務器提供相同服務，所以能夠提供更好的併發特性，當有更多用戶訪問的時候，只須要向集羣中加入新的機器便可。

同時由於一個應用由多臺服務器提供，當某臺機器發生故障時，負載均衡設備或者系統的失效轉移機制會將請求轉發到集羣中其餘服務器上，是服務器故障不影響用戶使用。

因此在網站應用中，即便是訪問量很小的分佈式應用和服務，也至少要部署兩臺服務器構成一個小的集羣，目的就是提升系統的可用性。

 

 

5.緩存

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

緩存是改善軟件性能的第一手段，現代CPU愈來愈快的一個重要因素就是使用了緩存。在複雜的軟件設計中，緩存幾乎無處不在。

大型網站架構在不少方面都是用了緩存設計。

 

常見的緩存種類有如下幾種。

CDN：即內容網絡分發，部署在距離終端用戶最近的網絡服務商，用戶的網絡請求老是先到達它的網絡服務商那裏。

在這裏緩存一些網站的靜態資源（較少變化的數據），能夠就近以最快速度返回給用戶，如視頻網站和門戶網站會將用戶訪問量最大的熱點內容還存在CDN。

 

反向代理：反向代理屬於網站前端架構的一部分即在部署網站的前端，當用戶請求到達網站的數據中心時，

最早訪問到的就是反向代理服務器，這裏緩存網站的靜態資源，無需將請求繼續轉發給應用服務器就能返回給用戶。

 

本地緩存：在應用服務器本地緩存着熱點數據，應用服務器能夠在本機內存中直接訪問數據，而無須訪問數據庫。

 

分佈式緩存：大型網站的數量很是龐大，即只緩存一小部分，須要的內存空間也不是單機能承受的，

因此除了本地緩存還須要分佈式緩存，將數據緩存在一個專門的分佈式緩存集羣中，應用程序經過網絡通訊訪問緩存數據。

 

使用緩存有兩個前提條件，一是數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這數據應該放在緩存中；

二是數據在某個時間段內有效，不會很快過時，不然緩存的數據就會由於已經失效而產生髒讀影響結果的正確性。

 

網站應用中，（優勢：）緩存除了能夠加快應用訪問速度，還能夠減輕後端應用和數據存儲的負載壓力，

這一點對網站數據庫架構相當重要，網站的數據庫幾乎是按照有緩存的前提進行負載能力設計的。

 

 

 

6.異步

計算機軟件發展的一個重要目標和驅動力是下降軟件耦合性。事物之間直接關係越少，就越少被彼此影響，越能夠獨立發展。

大型網站架構中，系統解耦合的手段除了前面提到的分層、分割、分佈等，還有一個重要手段是異步，

（概念：）業務之間的消息傳遞不是同步調用，而是將一個業務操做分紅多個階段，每一個階段之間經過共享數據的方式異步執行進行協做。

 

在單一服務器內部可經過多線程共享內存隊列的方式實現異步，處在業務操做前面的線程將輸出寫入到隊列，後面的線程從隊列中讀取數據進行處理；

在分佈式系統中，多個分佈式集羣經過分佈式消息隊列實現異步，分佈式消息隊列能夠看做內存隊列的分佈式部署。

 

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

除此以外，使用異步消息隊列還有以下特性。

 

提升系統可用性。消費者服務器發生故障，數據會在消息隊列服務器中存儲堆積，生產者服務器能夠繼續處理業務請求，系統總體表現無端障。

消費者服務器恢復正常後，繼續處理消息隊列中的數據。

 

加快網站響應速度。處在業務處理前端的生產者服務器在處理完業務請求後，將數據寫入消息隊列，，不須要等待消費者服務器處理就能夠返回，響應延遲減小。

 

消除併發訪問高峯。用戶訪問網站是隨機的，存在訪問高峯和低谷，即便網站按照通常訪問高峯進行規劃和部署，也依然會出現突發事件，

好比購物網站的促銷活動，微博上的熱點事件，都會形成網站併發訪問忽然增大，這可能會形成整個網站負載太重，響應延遲，嚴重時甚至出現服務宕機的狀況。

使用消息隊列將忽然增大的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，就不會對網站負載形成太大壓力。

 

但須要注意的是，使用異步方式處理業務可能會對用戶體驗、業務流程形成影響，須要網站產品設計方面的支持。

 

 

 

7.冗餘

網站須要7X24小時連續運行，但服務器隨時可能出現故障，特別是服務器規模比較大·時，出現某臺服務器宕機是必然事件。

要想保證在服務器宕機的狀況下網站依然能夠繼續服務，不丟失數據，就須要必定的服務器冗餘運行，數據冗餘備份，

這樣當某臺服務器宕機時，能夠將其上的服務和數據訪問轉移到其餘機器上。（爲何要進行冗餘？）

 

訪問和負載很小的服務也必須部署至少兩臺服務器構成一個集羣，其目的就是經過冗餘實現服務高可用。

數據庫除了按期備份，存檔保存，實現冷備份外，爲了保證在線業務高可用，還須要對數據庫進行主從分離，實時同步熱備份。

 

爲了抵禦地震、海嘯等不可抗力致使的網站徹底癱瘓，某些大型網站會對整個數據中心進行備份，

全球範圍內部署災備數據中心。網站程序和數據實時同步到多個災備數據中心。

 

 

8.自動化

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

 

發佈對網站都是頭等大事，許多網站故障出在發佈環節，網站工程師常常加班也是由於發佈不順。

經過減小人爲干預，使發佈過程自動化可有效減小故障。發佈過程包括諸多環節。（發佈過程自動化的流程？）

自動化代碼管理，代碼分支建立合併等過程自動化，開發工程師只要提交本身參與開發的產品代號，系統就會自動爲其建立開發分支，後期會自動進行代碼合併；

自動化測試，代碼開發完成，提交測試後，系統自動將代碼部署到測試環境，啓動自動化測試進行測試，向相關人員發送測試報告，向系統反饋測試結果；

自動化安全檢測，安全工具經過對代碼進行靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估其安全性。

最後進行自動化部署，將工程代碼自動部署到線上生產環境。

此外，網站在運行過程當中可能會遇到各類問題：服務器宕機、程序Bug、存儲空間不足、忽然爆發的訪問高峯。（自動化運維的機制？）

網站須要對線上生產環境進行自動化監控，對服務器進行心跳檢測，並監控其各項性能指標和應用程序的關鍵數據指標。

若是發現異常、超出預設的閾值，就進行自動化報警，向相關人員發送報警信息，警告故障可能發生。

在檢測到故障發生後，系統會進行自動化失效轉移，將失效的服務器從集羣中隔離出去，不在處理系統中的應用請求。

待故障消除後，系統進行自動化失效恢復，從新啓動服務，同步數據保證數據的一致性。

在網站遇到訪問高峯，超出網站最大處理能力時，爲了保證整個網站的安全可用，還會進行自動化降級，

經過拒絕部分請求及關閉部分不重要的服務將系統的負載降至一個安全的水平，必要時，還須要自動化分配資源，將空閒資源分配給重要的服務，擴大其部署規模。

 

 

9.安全

互聯網的開放特性使得其從誕生起就面對巨大的安全挑戰，網站在安全架構方面也積累了許多模式：

經過密碼和手機校驗碼進行身份驗證；

登錄、交易等操做須要對網絡通訊進行加密，網站服務器上存儲敏感數據如用戶信息等也進行加密處理；

爲了防止機器人程序濫用網絡資源攻擊網站，網站使用驗證碼進行識別；

對於常見的用於攻擊網站的XSS攻擊、SQL注入，進行編碼轉換等相應處理；

對於垃圾信息、敏感信息進行過濾；

對交易轉帳等重要操做根據交易模式和交易信息進行風險控制。