標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層

在上圖中我們描述了Web系統(tǒng)架構(gòu)中的組成部分。并且給出了每一層常用的技術(shù)組件/服務(wù)實現(xiàn)。需要注意以下幾點：

• 系統(tǒng)架構(gòu)是靈活的，根據(jù)需求的不同，不一定每一層的技術(shù)都需要使用。例如：一些簡單的CRM系統(tǒng)可能在產(chǎn)品初期并不需要K-V作為緩存；一些系統(tǒng)訪問量不大，并且可能只有一臺業(yè)務(wù)服務(wù)器存在，所以不需要運用負載均衡層。

• 業(yè)務(wù)系統(tǒng)間通信層并沒有加入傳統(tǒng)的HTTP請求方式。這是因為HTTP請求-響應(yīng)的延遲比較高，并且有很多次和正式請求無關(guān)的通信（這在下面的內(nèi)容中會詳細講到）。所以，傳統(tǒng)的HTTP請求方式并不適合在兩個高負載系統(tǒng)之間使用，其更多的應(yīng)用場景是各種客戶端（WEB、IOS、Android等）->服務(wù)器端的請求調(diào)用。

• 我們把業(yè)務(wù)編碼中常使用的緩存系統(tǒng)歸入到數(shù)據(jù)存儲層，是因為類似于Redis這樣的K-V存儲系統(tǒng)，從本質(zhì)上講是一種鍵值數(shù)據(jù)庫。為什么Redis會很快以至于可以作為緩存使用，我將在隨后的文章中進行詳細的描述。

• 還有一點需要注意的是，上面架構(gòu)圖中的每層之間實際上不存在絕對的聯(lián)系（例如負載層一定會把請求轉(zhuǎn)送的業(yè)務(wù)層，這樣的必然性是不存在的），在通常情況下各層是可以跨越訪問的。舉例說明：如果HTTP訪問的是一張圖片資源，負載層不會把請求送到業(yè)務(wù)層，而是直接到部署的分布式文件系統(tǒng)上尋找圖片資源并返回。再比如運用LVS做Mysql負載時，負載層是直接和數(shù)據(jù)存儲層進行合作。

我們?nèi)绾蝸碓u價一個服務(wù)系統(tǒng)的頂層設(shè)計是否優(yōu)秀呢？拋開八股文式的擴展性、穩(wěn)定性、健壯性、安全性這樣的套話不說。我從實際工作中為大家總結(jié)了一下幾個評價要點。

1、建設(shè)成本

任何系統(tǒng)架構(gòu)在進行生產(chǎn)環(huán)境實施的時候，都是需要付出建設(shè)成本的。顯然各個公司/組織對成本的承受度是不一樣的（這些成本包括：設(shè)計成本、資產(chǎn)采購成本、運維成本、第三方服務(wù)成本），所以如何利用有限的成本建設(shè)出符合業(yè)務(wù)需求、適應(yīng)訪問規(guī)模的系統(tǒng)，就是一個復(fù)雜的問題。另外，這種要求下架構(gòu)師是不能進行過度設(shè)計的。

2、擴展/規(guī)劃水平

根據(jù)業(yè)務(wù)的發(fā)展，整個系統(tǒng)是需要進行升級的（這包括已有模塊的功能升級、合并已有的模塊、加入新的業(yè)務(wù)模塊或者在模塊功能不變的情況下提高數(shù)據(jù)吞吐量）。那么如何盡量不影響原業(yè)務(wù)的工作，以最快的速度、最小的工作量來進行系統(tǒng)的橫向、縱向擴展，也就是一個復(fù)雜的問題了。好的系統(tǒng)架構(gòu)是可以在用戶無任何感覺的情況下進行升級的，或者只需要在某些關(guān)鍵子系統(tǒng)升級時才需要短暫的停止服務(wù)。

3、抗攻擊水平

對系統(tǒng)的攻擊肯定是瞄準(zhǔn)整個系統(tǒng)最薄弱的環(huán)節(jié)進行的，攻擊可能來自于外部（例如Dos/DDos攻擊）也可能來自于內(nèi)部（口令入侵）。好架構(gòu)的系統(tǒng)不是“絕對不能攻破”的系統(tǒng)，而是“預(yù)防很好”的系統(tǒng)。所謂預(yù)防，就是預(yù)防可能的攻擊，分階段對可能遇到的各種攻擊進行模擬；所謂隱藏，就是利用各種手段對整個系統(tǒng)的關(guān)鍵信息進行涉密管理，ROOT權(quán)限、物理位置、防火墻參數(shù)、用戶身份。

4、容災(zāi)恢復(fù)等級

好的架構(gòu)應(yīng)該考慮不同等級的容災(zāi)。集群容災(zāi)，在集群中某一個服務(wù)節(jié)點崩潰的情況下，集群中另外一臺主機能夠接替馬上接替他的工作，并且故障節(jié)點能夠脫離；分布式容災(zāi)：分布式系統(tǒng)一般會假設(shè)整個系統(tǒng)中隨時都在發(fā)生單點故障/多點故障，當(dāng)產(chǎn)生單點故障/多點故障時，整個分布式系統(tǒng)都還可以正常對外提供服務(wù)，并且分布式系統(tǒng)中的單點故障/多點故障區(qū)可以通過自動/人工的方式進行恢復(fù)，分布式系統(tǒng)會重新接納它們；異地容災(zāi)（機房等級容災(zāi)）：在機房產(chǎn)生物理災(zāi)難的情況下（物理網(wǎng)絡(luò)斷裂、戰(zhàn)爭摧毀、地震等），在某個相隔較遠的異地，備份系統(tǒng)能夠發(fā)現(xiàn)這樣的災(zāi)難發(fā)生，并主動接過系統(tǒng)運行權(quán)，通知系統(tǒng)運維人員（根據(jù)系統(tǒng)不同的運行要求，可能還有多個備份系統(tǒng)）。異地容災(zāi)最大的挑戰(zhàn)性是如何保證異地數(shù)據(jù)的完整性。

5、業(yè)務(wù)適應(yīng)性水平

系統(tǒng)架構(gòu)歸根結(jié)底還是為業(yè)務(wù)服務(wù)的，系統(tǒng)架構(gòu)的設(shè)計選型一定是以服務(wù)當(dāng)前的業(yè)務(wù)為前提。在上文中提到的業(yè)務(wù)通信層中，選擇SOA組件還是消息隊列組件，又或者選擇什么樣的消息隊列，就是一個很好的業(yè)務(wù)驅(qū)動事件。例如，A業(yè)務(wù)是一種WEB前端服務(wù)，需要及時反饋給客戶操作結(jié)果，B業(yè)務(wù)的服務(wù)壓力又非常大。A業(yè)務(wù)在調(diào)用B業(yè)務(wù)時，B業(yè)務(wù)無法在毫秒級的時間內(nèi)返回給A業(yè)務(wù)調(diào)用結(jié)果。這種業(yè)務(wù)場景下可以使用AMQP類型的消息隊列服務(wù)。另外說明兩點，目前行業(yè)內(nèi)有很多為解決相同業(yè)務(wù)場景存在的不同方案，架構(gòu)師在進行方案選型的過程中，一定要對各種解決方案的特點足夠掌握，這樣才能做出正確的選擇；另外行業(yè)內(nèi)的解決方案已經(jīng)足夠多，架構(gòu)師在業(yè)務(wù)沒有特殊要求的情況下一定不要做“ 重復(fù)發(fā)明輪子”的事情。

6、維護難易程度

一套服務(wù)系統(tǒng)從架設(shè)之初就需要運維團隊不斷的進行投入。顯然根據(jù)系統(tǒng)的復(fù)雜程度和物理機器的數(shù)量，運維團隊的知識復(fù)雜性也是不一樣的。在架構(gòu)師進行頂層架構(gòu)設(shè)計時，必須還要考慮系統(tǒng)的運維難度和運維成本。