標準web架構分層

標準Web系統的架構分層

轉載：http://blog.csdn.net/yinwenjie    http://blog.csdn.net/yinwenjie/article/details/46480485 

一、架構體系分層圖

在上圖中咱們描述了Web系統架構中的組成部分。而且給出了每一層經常使用的技術組件/服務實現。須要注意如下幾點：

• 系統架構是靈活的，根據需求的不一樣，不必定每一層的技術都須要使用。例如：一些簡單的CRM系統可能在產品初期並不須要K-V做爲緩存；一些系統訪問量不大，而且可能只有一臺業務服務器存在，因此不須要運用負載均衡層。

• 業務系統間通訊層並無加入傳統的HTTP請求方式。這是由於HTTP請求-響應的延遲比較高，而且有不少次和正式請求無關的通訊（這在下面的內容中會詳細講到）。因此，傳統的HTTP請求方式並不適合在兩個高負載系統之間使用，其更多的應用場景是各類客戶端（WEB、IOS、Android等）->服務器端的請求調用。

• 咱們把業務編碼中常使用的緩存系統納入到數據存儲層，是由於相似於Redis這樣的K-V存儲系統，從本質上講是一種鍵值數據庫。爲何Redis會很快以致於能夠做爲緩存使用，我將在隨後的文章中進行詳細的描述。

• 還有一點須要注意的是，上面架構圖中的每層之間實際上不存在絕對的聯繫（例如負載層必定會把請求轉送的業務層，這樣的必然性是不存在的），在一般狀況下各層是能夠跨越訪問的。舉例說明：若是HTTP訪問的是一張圖片資源，負載層不會把請求送到業務層，而是直接到部署的分佈式文件系統上尋找圖片資源並返回。再好比運用LVS作Mysql負載時，負載層是直接和數據存儲層進行合做。

二、負載分配層

實際上負載均衡的概念很普遍，所述的過程是未來源於外部的處理壓力經過某種規律/手段分攤到內部各個處理節點上。在平常生活中咱們隨時隨地在和負載技術打交道，例如：上下班高峯期的車流量引導、民航空管局的航空流量管制、銀行櫃檯的叫號系統。

這裏咱們所說的負載分配層，是單指利用軟件實現的計算機系統上的狹義負載均衡。一個大型（日PV一億+）、中型（日PV一千萬+）Web業務系統，是不可能只有一個業務處理服務，而是多臺服務器同時進行某一個相同業務的服務。因此咱們須要根據業務形態設計一種架構方式，未來自外部客戶端的業務請求分擔到每個可用的業務節點上。以下圖所示：

負載層還有一個做用，是根據用戶的請求規則，將不一樣的請求類型分派到不一樣的服務器上。例如：若是某一個HTTP請求是請求一張圖片，那麼負載層會直接到圖片存儲介質上尋找相應的圖片；若是某一個HTTP請求是提交的一張訂單，那麼負載層會根據規則將這張訂單提交發送到指定的「訂單服務」節點上。

不一樣的業務需求，使用的負載層方案也是不一樣的，這就考驗架構師的方案選擇能力。例如Nginx只能處理TCP/IP協議的之上應用層HTTP協議，若是要處理TCP/IP協議，則要按照第三方的TCP-Proxy-Module模。更好的直接在TCP/IP層負載的方案，是使用HAProxy。

經常使用的負載層架構方式包括： 
- 獨立的Nginx負載或HAProxy方案 
- LVS（DR）+ Nginx方案 
- DNS輪詢 + LVS + Nginx方案 
- 智能DNS（DNS路由） + LVS + Nginx方案

隨後的文章中將詳細介紹這些負載架構方案以及這些方案的變形。

三、業務服務層和通訊層

3.一、概述

通俗來說就是咱們的核心業務層，訂單業務、施工管理業務、診療業務、付款業務、日誌業務等等。以下圖所示：

很明顯在中大型系統中，這些業務不多是獨立存在的，通常的設計要求都會涉及到子系統間脫耦：即X1系統除了知曉底層支撐系統的存在外（例如用戶權限系統），X1系統不須要知道和它邏輯對等的X2系統的存在就能夠工做。這種狀況下要完成一個較複雜業務，子系統間調用又是必不可少的：例如A業務在處理成功後，會調用B業務進行執行；A業務在處理失敗後，會調用C業務進行執行；又或者A業務和D業務在某種狀況下是不可分割的總體，只有同時成功才成功，其中有一個失敗整個大的業務過程都失敗。以下圖所示：

這樣一來業務間的通訊層又是一個逃不開的話題。 在隨後的文章中，咱們將以Alibaba的Dubbo框架、基於AMQP協議的消息隊列和Kafka消息隊列技術的原理和使用方式，來說解業務通訊層技術，特別是業務通訊層的技術選型注意事項。

3.二、不得不提的HTTP請求方式

有的讀者可能會問，爲何業務系統間通訊層沒有提到HTTP這樣的調用方式。畢竟不少公司目前都採用這種方式做爲業務系統間的調用方式。咱們首先經過一個圖來看看HTTP方式的調用過程。（注意，此過程不考慮http客戶端緩存的過程也不考慮DNS域名解析的過程，從HTTP創建可靠的TCP鏈接開始）：

從上圖中咱們能夠看出如下幾個問題：

• 從技術原理層面看，HTTP請求是在須要進行調用時創建TCP鏈接，而且發送並等待數據回送，在獲得請求結果後，可能須要再關閉這個TCP鏈接。這樣的原理使得不少時間浪費在和業務無關的技術特性上。
• 另外，發送Head信息和接收Head這樣的數據，對業務數據來講是毫無心義的。在訪問量較小的狀況下，這樣的過程都仍是能夠接收的，可是當帶寬資源吃緊的狀況下，這樣的數據空間就是彌足珍貴的。
• 獨立的HTTP請求因爲沒有SOA結構中的「治理中心」的概念，因此單純的HTTP請求很難保證負責業務聯動中的上下文一致性。固然你能夠自行編碼來保證，但那樣真的合理嗎？
• 最後，須要說明的是，如今相似Apache HTTP Components這樣的組件提供了HTTP Pool來減小TCP鏈接時長，但這僅僅是優化了HTTP做爲業務間通訊時的一個問題，其餘的問題依然存在。

基於以上的描述，本文並不推薦使用HTTP做爲業務間通訊/調用的方式，而建議HTTP方式僅限於WEB、iOS、Android等這樣的客戶端請求服務的方式。

四、數據存儲層

數據存儲將是這個系列文章中將要介紹的另外一個重點。進行業務計算前的初始數據、計算過程當中的臨時數據、計算完成後獲得的計算結果都須要進行存儲。咱們經過一張思惟導圖首先從幾個維度闡述一下數據存儲的基本分類。

4.一、文件存儲原理

咱們經過一個最基本的在Centos6.5系統上建立Ext4文件系統的過程，講解文件系統的最基本原理。

• 首先咱們會經過fdisk命令對本地硬盤進行分區（即肯定可控制的扇區的範圍），以下圖所示：

• 而後咱們會在這個區上面經過mkfs命令建立咱們想要的文件系統（Ext三、Ext四、LVM、XF、BTRFS等），以下圖所示：

• 最後咱們掛載這個文件系統到指定的路徑，以下圖所示：

• 經過df命令查看掛載信息，以下圖所示： 
  

• 萬變不離其宗的建立過程告訴咱們一個什麼事實呢？

• 物理塊，一個物理塊是咱們上層文件系統可以操做的最小單位（一般爲512字節），一個物理塊在底層對應了多個物理扇區。一般一塊SATA硬盤會有若干機械手臂（決定於物理盤片數量），和若干個物理扇區（物理扇區的大小是磁盤出廠時就肯定的，咱們沒法改變）。

• 單個扇區的工做是單向的，那麼映射出來的一個物理塊的工做方式也是單向的。原理就是機械手臂在讀取這個扇區的數據時，硬件芯片是不容許機械手臂同時向這個扇區寫入數據的。

• 經過上層文件系統（EXT、NTFS、BTRFS、XF）對下層物理塊的封裝，OS是不須要直接操做磁盤物理塊的，操做者經過ls這樣的命令看到的一個一個文件也不須要關心這些文件在物理塊的存儲格式。這就是爲何不一樣的文件系統有不一樣的特性（有的文件系統支持快照，有的文件系統支持數據恢復），基本原理就是這些文件系統對下層物理塊的操做規範不同。

4.二、塊存儲和文件存儲

上一小節咱們敘述了最簡單、最原始的物理塊和文件格式規範的工做方式，可是隨着服務器端不斷擴大的數據存儲容量的需求和數據安全性的需求，很顯然單機的存儲是沒辦法知足要求的，目前存儲環境兩種大的需求類型是：

• 穩定的擴展存儲容量，而且不破壞目前已存儲的數據信息，不影響整個存儲系統的穩定性。

• 文件共享，讓多臺服務器可以共享存儲數據，而且均可以對文件系統進行讀寫操做。

要解決這兩個問題，咱們首先要將問題擴展到上一小節的圖例中，以下圖所示：

很明顯圖中兩個問題的答案是確定的，也就是咱們將要介紹的塊存儲系統要解決的問題。

4.2.一、塊存儲系統

咱們先來聊一下塊存儲。以前咱們提到的最簡單的狀況就是磁盤在本地物理機上，傳輸的物理塊I/O命令，也是經過本地物理機主板上的南橋進行的。可是爲了擴展更大的磁盤空間，而且保證數據吞吐量，咱們須要將磁盤介質和本地物理機分離，而且讓物理塊的I/O命令在網絡上進行傳輸：

• 雖然磁盤介質和本地物理機發生了分離，可是直接傳輸塊I/O命令的本質是沒有改變的。本地南橋傳輸I/O命令變成了光纖傳輸，只在本物理機內部傳輸I/O命令變成了網絡傳輸，而且I/O命令經過某種通訊協議進行了規範（例如FC、SCSI等）。

• 文件系統的映射倒是在本地進行，而非遠程的文件系統映射。上文中咱們已經提到，因爲塊操做的順序性（在一個扇區進行寫入的時候，是不會進行這個扇區的讀取操做的），且塊操做屬於底層物理操做沒法向上層的文件邏輯層主動反饋變化。因此多個物理主機是沒法經過這個技術進行文件共享的。

• 塊存儲系統要解決的是大物理存儲空間、高數據吞吐量、強穩定性的共存問題。做爲上層使用這個文件系統的服務器來講，它很是清楚，除了它之外沒有其餘的服務器可以對專屬於它的這些物理塊進行讀寫操做了。也就是說它認爲這個龐大容量的文件存儲空間只是它本地物理機上的存儲空間。

• 固然隨着技術的發展，如今已經有一些技術能夠只用TCP/IP協議對標準的SCSI命令進行傳輸，以便減少這個塊存儲系統的建設成本（例如iSCSI技術）。可是這種折中方式也是以減弱整個系統的數據吞吐量爲代價的。不一樣的業務需求能夠根據實際狀況進行技術選型。

4.2.二、文件存儲系統

那麼若是是將文件系統從本地物理機經過網絡移植到遠程呢？固然能夠，典型的文件存儲系統包括了FTP、NFS、DAS： 

• 文件存儲系統的關鍵在於，文件系統並不在本機。而是經過網絡訪問存在於遠程的文件系統，再由遠程的文件系統操做塊I/O命令完成數據操做。

• 通常來講諸如本地文件系統NTFS/EXT/LVM/XF等是不容許直接網絡訪問的，因此通常文件存儲系統會進行一層網絡協議封裝，這就是NFS協議/FTP協議/NAS協議（注意咱們說的是協議），再由協議操做文件存儲系統的服務器文件系統。

• 文件存儲系統要解決的問題首要的文件共享，網絡文件協議能夠保證多臺客戶端共享服務器上的文件結構。從整個架構圖上能夠看到文件存儲系統的數據讀寫速度、數據吞吐量是沒辦法和塊存儲系統相比的（由於這不是文件存儲系統要解決的首要問題）。

從上面的簡介中咱們能夠清楚的知曉，當面對大量的數據讀寫壓力的時候，文件存儲系統確定不是咱們的首要選擇，而當咱們須要選擇塊存儲系統時又面臨成本和運維的雙重壓力（SAN系統的搭建是比較複雜的，而且設備費用昂貴）。而且在實際生產環境中咱們常常遇到數據讀取壓力大，且須要共享文件信息的場景。那麼這個問題怎麼解決呢？

4.三、對象存儲系統

兼具塊存儲系統的高吞吐量、高穩定性和文件存儲的網絡共享性、廉價性的對象存儲就是爲了知足這樣的需求出現的。典型的對象存儲系統包括：MFS、Swift、Ceph、Ozone等。下面咱們簡單介紹一下對象存儲系統的特色，在後面的文章中，咱們將選擇一款對象存儲系統進行詳細說明。

對象存儲系統必定是分佈式文件系統。但分佈式文件系統不必定是對象存儲系統

• 咱們知道文件信息是由若干屬性進行描述的，包括文件名、存儲位置、文件大小、當前狀態、副本數量等信息。咱們將這些屬性抽離出來，專門使用服務器進行存儲（元數據服務器）。這樣一來文件操做的客戶端要訪問某一個文件，首先會詢問元數據節點這個文件的基本信息。

• 因爲是分佈式系統，那麼數據一致性、資源爭奪、節點異常問題都須要進行統一的協調。因此對象存儲系統中通常會有監控/協調節點。不一樣的對象存儲系統，支持的元數據節點和監控/協調節點的數量是不一致的。但總的趨勢都是「去中心化」。

• OSD節點（基於對象的存儲設備）用於存儲文件內容信息。這裏要注意，雖然OSD節點的底層和塊存儲底層同樣都是依靠塊I/O進行操做的，可是上層構造二者徹底不一樣：OSD節點並不是向塊存儲設備那樣，經過塊操做命令跳過本地文件系統直接進行物理塊操做。

• 隨後的文章中咱們將選擇一款流行的對象存儲系統，詳細剖析對象存儲系統，而且對分佈式存儲系統中三個核心概念和取捨進行說明（CAP）：一致性、擴展性和容錯性。

4.三、數據庫存儲

這篇文章已經寫了不少存儲層的概要描述了，因此咱們熟悉或者不熟悉的數據庫存儲技術的概述就不在這裏介紹了。

後續的文章我將使用Mysql講解幾個經常使用的架構方案和性能優化點，固然也會講到Mysql中，諸如Innodb這樣的核心數據引擎的工做方式。這些架構方案主要解決的是Mysql的單機I/O瓶頸、機房內數據容災、數據庫穩定性、跨機房數據容災等核心問題。

後續的文章我還會選取目前流行的數據緩存系統，講解其工做原理、核心算法和架構方案。以便讀者們根據本身的業務狀況設計符合業務的存儲集羣。固然還有非關係型數據庫Cassandra、HBase、MongoDB的深刻介紹。

五、評價架構的特性

咱們如何來評價一個服務系統的頂層設計是否優秀呢？拋開八股文式的擴展性、穩定性、健壯性、安全性這樣的套話不說。我從實際工做中爲你們總結了一下幾個評價要點。

5.一、建設成本

任何系統架構在進行生產環境實施的時候，都是須要付出建設成本的。顯然各個公司/組織對成本的承受度是不同的（這些成本包括：設計成本、資產採購成本、運維成本、第三方服務成本），因此如何利用有限的成本建設出符合業務需求、適應訪問規模的系統，就是一個複雜的問題。另外，這種要求下架構師是不能進行過分設計的。

5.二、擴展/規劃水平

根據業務的發展，整個系統是須要進行升級的（這包括已有模塊的功能升級、合併已有的模塊、加入新的業務模塊或者在模塊功能不變的狀況下提升數據吞吐量）。那麼如何儘可能不影響原業務的工做，以最快的速度、最小的工做量來進行系統的橫向、縱向擴展，也就是一個複雜的問題了。好的系統架構是能夠在用戶無任何感受的狀況下進行升級的，或者只須要在某些關鍵子系統升級時才須要短暫的中止服務。

5.三、抗攻擊水平

對系統的攻擊確定是瞄準整個系統最薄弱的環節進行的，攻擊可能來自於外部（例如Dos/DDos攻擊）也可能來自於內部（口令入侵）。好架構的系統不是「絕對不能攻破」的系統，而是「預防很好」的系統。所謂預防，就是預防可能的攻擊，分階段對可能遇到的各類攻擊進行模擬；所謂隱藏，就是利用各類手段對整個系統的關鍵信息進行涉密管理，ROOT權限、物理位置、防火牆參數、用戶身份。

5.三、容災恢復等級

好的架構應該考慮不一樣等級的容災。集羣容災，在集羣中某一個服務節點崩潰的狀況下，集羣中另一臺主機可以接替立刻接替他的工做，而且故障節點可以脫離；分佈式容災：分佈式系統通常會假設整個系統中隨時都在發生單點故障/多點故障，當產生單點故障/多點故障時，整個分佈式系統都還能夠正常對外提供服務，而且分佈式系統中的單點故障/多點故障區能夠經過自動/人工的方式進行恢復，分佈式系統會從新接納它們；異地容災（機房等級容災）：在機房產生物理災難的狀況下（物理網絡斷裂、戰爭摧毀、地震等），在某個相隔較遠的異地，備份系統可以發現這樣的災難發生，並主動接過系統運行權，通知系統運維人員（根據系統不一樣的運行要求，可能還有多個備份系統）。異地容災最大的挑戰性是如何保證異地數據的完整性。

5.四、業務適應性水平

系統架構歸根結底仍是爲業務服務的，系統架構的設計選型必定是以服務當前的業務爲前提。在上文中提到的業務通訊層中，選擇SOA組件仍是消息隊列組件，又或者選擇什麼樣的消息隊列，就是一個很好的業務驅動事件。例如，A業務是一種WEB前端服務，須要及時反饋給客戶操做結果，B業務的服務壓力又很是大。A業務在調用B業務時，B業務沒法在毫秒級的時間內返回給A業務調用結果。這種業務場景下可使用AMQP類型的消息隊列服務。另外說明兩點，目前行業內有不少爲解決相同業務場景存在的不一樣方案，架構師在進行方案選型的過程當中，必定要對各類解決方案的特色足夠掌握，這樣才能作出正確的選擇；另外行業內的解決方案已經足夠多，架構師在業務沒有特殊要求的狀況下必定不要作「 重複發明輪子」的事情。

5.五、維護難易程度

一套服務系統從架設之初就須要運維團隊不斷的進行投入。顯然根據系統的複雜程度和物理機器的數量，運維團隊的知識複雜性也是不同的。在架構師進行頂層架構設計時，必須還要考慮系統的運維難度和運維成本。

六、其餘說明

• 負載層、業務層、業務通訊層、數據存儲層的詳細架構方案在後續文章中咱們會用若干文章進行深刻講解，包括核心算法、架設原理、架設案例。隨後的文章中咱們將首先介紹系統負載層。

• 在不少系統中咱們還涉及存儲的數據進行分析，造成數據分析結果。這涉及到數據分析層的架構知識。Hadoop生態系統是目前行業公認的高效率、高穩定性、高擴展性的數據分析生態系統。這個系列的博文暫時不會介紹數據分析層的架構設計和開發知識，後續將會獨立成文。

• 各位看官咱們立刻進入負載層技術的詳細講解！