大型網站架構之架構模式

上節講了《大型網站架構之架構演變》，今天講下架構的模式，什麼是模式呢？每個模式描述了一個再咱們周圍不斷重複發生的問題及問題解決方案的核心，這樣你就能一次次重用該方案而沒必要去作重複的工做，可見模式的關鍵在於可重複性。

網站架構模式的目標：面臨高併發訪問，海量數據處理，高可靠運行等問題和挑戰，咱們在實踐中提出不少解決方案，主要爲了實現網站的高性能、高可用、易伸縮、可擴展、安全等架構目標。

網站架構模式具體方案以下：

一、分層

分層是一種常見的架構模式，將系統在橫向維度上切分爲幾個部分，每一個部分負責單一的職責，而後經過上層對下層的依賴和調用完成整個系統工做。通常大型網站系統都分爲下面3層：

• 應用層：負責具體業務和視圖展現；

• 服務層：爲應用層提供服務支持；

• 數據層：提供數據存儲訪問服務；

分層架構的挑戰：必須合理規劃層次邊界和接口；

分層架構的約束：禁止跨層次調用及逆向調用（數據層不容許調用服務層，服務層不容許調用應用層）

二、分割

分層是橫向切分，分割則是縱向切分，將不一樣的功能和服務分割開，包裝成高內聚低耦合的模塊單元，這樣作的好處在於：

• 有助於軟件開發和維護；

• 便於不一樣模塊的分佈式部署，提升網站的併發處理能力和功能擴展能力；

三、分佈式

對於大型網站，分層和分割的目的都是爲了便於分佈式部署，將不一樣的模塊部署在不一樣的服務器上，經過遠程調用協同工做，分佈式意味着咱們可使用更多的計算機完成同一個任務，計算機物理機越多，CPU，內存，存儲資源就越多，能處理的併發訪問和數據量也就更大，可是分佈式也會帶來一些問題：

• 分佈式服務意味着經過網絡調用，會對性能形成影響；

• 服務器越多，服務器宕機的機率就越大，使網站的可用性下降；

• 數據在分佈式環境下保持數據一致性也就比較困難；

• 分佈式下的事務也難以保證；

• 分佈式管理增了開發和維護的難度，切記不要爲了分佈式而分佈式；

分佈式的常見幾種方案：

• 分佈式應用和服務：將分層和分割後的應用和服務模塊分佈式部署，能夠改善網站性能和併發性，加快開發和發佈的速度，減小數據庫鏈接資源消耗，使不一樣的應用複用共同的服務，便於業務擴展；

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

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

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

• 分佈式配置：網站線上服務器配置實時更新；

• 分佈式鎖：分佈式環境下實現併發和協同工做；

• 分佈式文件：支持雲存儲的分佈式文件系統；

四、集羣

對於用戶訪問集中的模塊，咱們還須要考慮將其集羣化，多臺服務器部署相同應用構成一個集羣，經過負載均衡器將請求分發給集羣中不一樣的服務器處理。集羣模式能夠很好的擴展，當有更多用戶訪問時，只須要向集羣中添加一臺新的服務器加入集羣便可，同時由於一個應用由多臺服務器提供服務，當某臺服務器發生故障時，負載均衡器或者系統的失效轉移機制會將請求轉發到集羣中其餘的服務器上，因此咱們在配置集羣時，至少須要2臺以上服務器構成一個集羣，目的就是爲了提供系統的可用性。

五、緩存

將數據存放在距離計算最近的位置，加快處理速度。大型網站架構設計通常在下面幾個方面使用緩存設計：

• CDN：即內容分發網絡，部署在距離終端用戶最近的網絡服務商，用戶網絡請求老是先到達他的網絡服務商那裏，在這裏緩存一些靜態資源，就能夠以最快的速度返回資源給用戶；

• 反向代理：屬於網站前端部分，部署在網站的前端，當用戶請求到達網站的時候，最早訪問到的就是反向代理服務器，這裏緩存網站的靜態資源，無需將請求繼續轉發給應用服務器就能直接返回給用戶；

• 本地緩存：在應用服務器本地緩存一些熱點數據（段時間內常常被訪問的數據），應用程序能夠在本機內存中直接訪問數據，而無需訪問數據庫；

• 分佈式緩存：將數據緩存在一個專門的分佈式緩存集羣中，應用程序經過網絡通訊獲取緩存的數據；

使用緩存有2個前提條件：

• 數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這部分數據就該放入緩存；

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

使用緩存的優點：加快數據訪問速度以及減輕後端應用和數據存儲的負載壓力；

六、異步

大型網站的一個重要目標是下降軟件的耦合性，系統解耦合的手段除了前面提到的分層、分割和分佈式等，還有一個異步，業務之間的消息傳遞不是同步調用，而是將業務操做分紅多個階段，每一個階段之間經過共享數據的方式異步的進行協做；

• 在單一服務器內部能夠經過多線程共享內存隊列的方式實現異步，業務前執行的線程將數據寫入隊列，後續線程從隊列中讀取數據進行處理；

• 在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步，分佈式消息隊列能夠看作是內存隊列的分佈式部署；

異步架構是典型的生產者和消費者模式，此外異步消息隊列還有以下特性：

• 提升系統可用性：消費者服務器宕機時，數據會堆積在消息隊列中，生產者服務器能夠繼續處理業務請求，不影響系統總體運行，當消費者服務器恢復正常後能夠繼續處理消息隊列中的數據；

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

• 消除併發訪問高峯：使用消息隊列將突發的高峯訪問請求數據放入消息隊列中，等待消費者依次處理，不會對整個網站負載形成太大的壓力；

七、冗餘

網站須要24小時爲用戶提供服務，想要保證在服務器宕機的狀況下，不影響網站的運行，不丟失數據，就須要將必定程度的服務器冗餘運行，數據冗餘備份，這樣，當某臺服務器宕機時，能夠將其上面的服務和數據訪問轉移到其餘冗餘的服務器上。

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

爲了抵制一些非人爲的天災，通常還須要對整個網站數據中心進行備份，全球範圍內部署災備數據中心，網站程序和數據實時同步到多個災備中心。

八、自動化

主要包括自動化代碼管理、自動化測試、自動化安全檢測、自動化部署等實現發佈過程自動化；此外還須要對服務器進行自動化監控、自動化報警、自動化失效轉移（將失效的服務器從集羣中隔離出去）、自動化失效恢復（重啓服務以後同步數據保證數據的一致性）、自動化降級（經過拒絕部分請求及關閉一些不重要的服務將系統負載降至一個安全的水平）以及自動化分配資源（將空閒資源分配給重要的服務，擴大部署規模）。

九、安全

主要從下面幾點考慮

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

• 登陸，交易等操做對網絡通訊進行加密；

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

• 對常見的XSS攻擊、SQL注入進行編碼轉換等處理；

• 對垃圾信息。敏感信息進行過濾；

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

十、總結