第2章 大型網站架構模式

##2.1 網站架構模式## 爲了解決大型網站面臨的高併發訪問，海量數據處理，高可靠運行等一系列問題與挑戰，大型互聯網公司在實踐中提出了許多解決方案，以實現網站高性能，高可用，易伸縮，可擴展，安全等各類技術架構目標。這些解決方案又被更多網站重複使用，從而逐漸造成大型網站架構模式。 ###2.1.1 分層### 分層是企業應用系統中最多見的一種架構模式，將系統在橫向維度上切分紅幾個部分，每一個部分負責一部分相對比較單一的職責，而後經過上層對下層的依賴和調用組成一個完整的系統。

分層結構在計算機世界中無處不在，網絡的7層通訊協議是一種分層結構；計算機硬件，操做系統，應用軟件也能夠看做是一種分層結構。在大型網站中也採用分層結構，將網站軟件系統分爲應用層，服務層，數據層，以下： 應用層：負責具體業務和視圖展現，如網站首頁及搜索輸入和結果展現； 服務層：爲應用層提供服務支持，如用戶管理服務，購物車服務等； 數據層：提供數據存儲訪問服務，如數據庫，緩存，文件，搜索引擎等；

經過分層，能夠更好地將一個龐大的軟件系統切分紅不一樣的部分，便於分工合做開發和維護；各層之間具備必定的獨立性，只要維持調用接口不變，各層能夠根據具體問題獨立演化發展而不須要其餘層必須作出相應調整。

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

分層的架構是邏輯上的，在物理部署上，三層結構能夠部署在同一個物理機器上，可是隨着網站業務的發展，必須須要對已經分層的模塊分離部署，即三層結構分別部署在不一樣的服務器上，使網站擁有更多的計算資源以應對愈來愈多的用戶訪問。 ###2.1.2 分割### 若是說分層是將軟件在橫向方面進行切分，那麼分割就是在縱向方面對軟件進行切分。

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

大型網站分割的粒度可能會很小。好比：在應用層，將不一樣業務進行分割，如：購物，論壇，搜索，廣告分割成不一樣的應用，由獨立的團隊負責，部署在不一樣的服務器上； ###2.1.3 分佈式### 對於大型網站，分層和分割的一個主要目的是爲了切分後的模塊便於分佈式部署，即將不一樣模塊部署在不一樣的服務器上，經過遠程調用協調工做。分佈式意味着可使用更多的計算機完成一樣的功能，計算機越多，CPU，內存，存儲資源也就越多，可以處理的併發訪問和數據量就越大，進而可以爲更多的用戶提供服務。

但分佈式在解決網站高併發問題的同時也帶來了其餘問題。以下： （1）分佈式意味着服務調用必須經過網絡，這可能會對性能形成比較嚴重的影響； （2）服務器越多，服務宕機的機率也就越大，一臺服務器宕機形成的服務不可用可能會致使不少應用不可訪問，使網站可用性下降； （3）數據在分佈式的環境中保持數據一致性也很是困難，分佈式事務也難以保證，這對網站業務正確性和業務流程有可能形成很大影響； （4）分佈式還致使網站依賴錯綜複雜，開發管理維護困難；

在網站應用中，經常使用的分佈式方案有如下幾種： 分佈式應用和服務：將分層和分割後的應用和服務模塊分佈式部署，除了能夠改善網站性能和併發性，加快開發和發佈速度，減小數據庫鏈接資源消耗外；還可使不一樣應用複用共同的服務，便於業務功能擴展。

分佈式靜態資源：網站的靜態資源如JS，CSS，Logo圖片等資源獨立部署，並採用獨立的域名，即人們常說的動靜分離。靜態資源分佈式部署能夠減輕應用服務器的負載壓力；經過使用獨立域名加快瀏覽器併發加載的速度；由負責用戶體驗的團隊進行開發維護有利於網站分工合做，使不一樣技術工種術業有專攻。

分佈式數據和存儲：大型網站須要處理以P爲單位的海量數據，單臺計算機沒法提供如此大的存儲空間，這些數據須要分佈式部署。除了對傳統的關係數據庫進行分佈式部署外，爲網站應用而生的各類NoSQL產品幾乎都是分佈式的。

分佈式計算：嚴格說來，應用，服務，實時數據處理都是計算，網站除了要處理這些在線業務，還有很大一部分用戶沒有直觀感覺的後臺業務要處理，包括搜索 引擎的索引構建，數據倉庫的數據分析統計等。這些業務的計算規模很是龐大，目前網站廣泛使用Hadoop及其MapReduce分佈式計算框架進行此類批處理計算，其特色是移動計算而不是移動數據，將計算程序分發到數據所在的位置以加速計算和分佈式計算。

此外，還有能夠支持網站線上服務器配置實時更新的分佈式配置；分佈式環境下實現併發和協同的分佈式鎖；支持雲存儲的分佈式文件系統等。 ###2.1.4 集羣### 多臺服務器部署相同應用構成一個集羣，經過負載均衡設備共同對外提供服務。

由於服務器集羣有更多服務器提供相同服務，所以能夠提供更好的併發特性，當有更多用戶訪問的時候，只須要向集羣中加入新的機器便可。同是由於一個應用由多臺服務器提供，當某臺服務器發生故障時，負載均衡設備或者系統的失效轉移機制會將請求轉發到集羣中其餘服務器上，使服務器故障不影響用戶使用。因此在網站應用中，即便是訪問量很小的分佈式應用和服務，也至少要部署兩臺服務器構成一個小的集羣，目的就是提升系統的可用性。 ###2.1.5 緩存### 緩存就是將數據存放在距離計算最近的位置以加快處理速度。緩存是改善性能的第一手段。

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

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

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

分佈式緩存：大型網站的數據量很是龐大，即便只緩存一小部分，須要的內存空間也不是單擊能承受的，因此處理本地緩存，還須要分佈式緩存，將數據緩存在一個專門的分佈式緩存集羣中，應用程序經過網絡通訊訪問緩存數據。

使用緩存兩個前提條件：（1）數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這些數據應該放在緩存中；（2）數據在某個時間段內有效，不會很快過時，不然緩存的數據就會因已經失效而產生髒讀，影響結果的正確性。 ###2.1.6 異步### 在單一服務器內部可經過多線程共享內存隊列的方式實現異步，處在業務操做前面的線程將輸出寫入到隊列，後面的線程從隊列中讀取數據進行處理； 在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步，分佈式消息隊列能夠看做內存隊列的分佈式部署。

異步架構是典型的生產者消費者模式，二者不存在直接調用，只要保持數據結構不變，彼此功能實現能夠隨意變化而不互相影響。使用異步消息隊列還有以下特性：提升系統可用性，加快網站響應速度，消除併發訪問高峯（使用消息隊列將忽然增長的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，就不會對整個網站負載形成太大壓力）。 ###2.1.7 冗餘### 服務器冗餘和數據冗餘，訪問和負載很小的服務也必須部署至少兩臺服務器構成一個集羣，其目的就是經過冗餘實現服務高可用。數據庫除了按期備份，存檔保存，實現冷備份外，爲了保證在線業務高可用，還須要對數據庫進行主從分離，實時同步實現熱備份。 ###2.1.8 自動化### 大型網站的自動化架構設計主要集中在發佈運維方面，分爲兩部分： （1）在開發-測試-發佈過程當中，自動化以下： 自動化代碼管理：代碼版本控制，代碼分支建立合併等過程自動化，開發工程師只要提交本身參與開發的產品代號，系統就會自動建立開發分支，後期會自動進行代碼合併； 自動化測試：代碼開發完成，提交測試後，系統自動將代碼部署到測試環境，啓動自動化測試用例進行測試，向相關人員發送測試報告，向系統反饋測試結果； 自動化安全檢測：安全檢測工具經過對代碼進行靜態安全掃描及部署到安全測試環境進行安全攻擊測試，評估其安全性； 自動化部署：將工程代碼自動部署到線上生產環境； （2）在生產環境的自動化管理，自動化以下： 自動化監控：對服務器進行心跳檢測，並監控各項性能指標和應用程序的關鍵數據指標； 自動化報警：若是發生異常，超出預設的閥值，向相關人員發送報警信息，警告故障可能會發生； 自動化失效轉移：在檢測到故障後，系統會自動將失效的服務器從集羣中隔離出去，再也不處理系統中的應用請求； 自動化失效恢復：待故障消除後，系統會自動重啓服務，同步數據保證數據的一致性； 自動化降級：在網站遇到訪問高峯，經過拒絕部分請求及關閉部分不重要的服務，將系統負載降至一個安全的水平； 自動化分配資源：將空閒資源分配給重要的服務，擴大其部署規模； ###2.1.9 安全### （1）經過密碼和手機校驗碼進行身份認證； （2）登陸，交易等操做須要對網絡通訊進行加密，網站服務器上存儲的敏感數據，如用戶信息等也進行加密處理； （3）爲了防止機器人程序濫用網絡資源攻擊網站，網站使用驗證碼進行識別； （4）對於常見的用於攻擊網站的XSS攻擊，SQL注入，進行編碼轉換等相應處理； （5）對於垃圾信息，敏感信息進行過濾； （6）對交易轉帳等重要操做根據交易模式和交易信息進行風險控制； ##2.2 架構模式在新浪微博的應用## 新浪微博系統分爲三個層次： （1）最下層是基礎服務層，提供數據庫，緩存，存儲，搜索等數據服務，以及其餘一些基礎技術服務，這些服務支撐了新浪微博的海量數據和高併發訪問，是整個系統的技術基礎。 （2）中間層是平臺服務和應用服務層，新浪微博的核心服務是微博，關係和用戶，它們是新浪微博業務大廈的支柱。這些服務被分割爲獨立的服務模塊，經過依賴調用和共享基礎數據構成新浪微博的業務基礎。 （3）最上層是API和新浪微博的業務層，各類客戶端（包括WEB網站）和第三方應用，經過調用API集成到新浪微博的系統中，共同組成一個生態系統。

這些被分層和分割後的業務模塊與基礎技術模塊分佈式部署，每一個模塊都部署在一組獨立的服務器集羣上，經過遠程調用的方式進行依賴訪問。新浪微博早期還使用過一種叫MPSS（MultiPort Single Server，單服務器多端口）的分佈式集羣部署方案，在集羣中的多臺服務器上，每臺都部署多個服務，每一個服務使用不一樣的端口對外提供服務，經過這種方式使得有限的服務器能夠部署更多的服務實例，改善服務的負載均衡和可用性。如今網站應用中常見的將物理機虛擬化成多個虛擬機後，在虛擬機之上部署應用的方案跟MPSS方案殊途同歸，只是更加簡單，還能在不一樣虛擬機上使用相同的端口號。