架構(gòu)體系分層圖

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

• 系統(tǒng)架構(gòu)是靈活的，根據(jù)需求的不同，不一定每一層的技術(shù)都需要使用。例如：一些簡(jiǎn)單的CRM系統(tǒng)可能在產(chǎn)品初期并不需要K-V作為緩存；一些系統(tǒng)訪問(wèn)量不大，并且可能只有一臺(tái)業(yè)務(wù)服務(wù)器存在，所以不需要運(yùn)用負(fù)載均衡層。
• 業(yè)務(wù)系統(tǒng)間通信層并沒(méi)有加入傳統(tǒng)的HTTP請(qǐng)求方式。這是因?yàn)镠TTP請(qǐng)求-響應(yīng)的延遲比較高，并且有很多次和正式請(qǐng)求無(wú)關(guān)的通信（這在下面的內(nèi)容中會(huì)詳細(xì)講到）。所以，傳統(tǒng)的HTTP請(qǐng)求方式并不適合在兩個(gè)高負(fù)載系統(tǒng)之間使用，其更多的應(yīng)用場(chǎng)景是各種客戶端（WEB、IOS、Android等）->服務(wù)器端的請(qǐng)求調(diào)用。
• 我們把業(yè)務(wù)編碼中常使用的緩存系統(tǒng)歸入到數(shù)據(jù)存儲(chǔ)層，是因?yàn)轭愃朴趓edis這樣的K-V存儲(chǔ)系統(tǒng)，從本質(zhì)上講是一種鍵值數(shù)據(jù)庫(kù)。為什么Redis會(huì)很快以至于可以作為緩存使用，我將在隨后的文章中進(jìn)行詳細(xì)的描述。
• 還有一點(diǎn)需要注意的是，上面架構(gòu)圖中的每層之間實(shí)際上不存在絕對(duì)的聯(lián)系（例如負(fù)載層一定會(huì)把請(qǐng)求轉(zhuǎn)送的業(yè)務(wù)層，這樣的必然性是不存在的），在通常情況下各層是可以跨越訪問(wèn)的。舉例說(shuō)明：如果HTTP訪問(wèn)的是一張圖片資源，負(fù)載層不會(huì)把請(qǐng)求送到業(yè)務(wù)層，而是直接到部署的分布式文件系統(tǒng)上尋找圖片資源并返回。再比如運(yùn)用LVS做MySQL負(fù)載時(shí)，負(fù)載層是直接和數(shù)據(jù)存儲(chǔ)層進(jìn)行合作。

負(fù)載分配層

實(shí)際上負(fù)載均衡的概念很廣泛，所述的過(guò)程是將來(lái)源于外部的處理壓力通過(guò)某種規(guī)律/手段分?jǐn)偟絻?nèi)部各個(gè)處理節(jié)點(diǎn)上。在日常生活中我們隨時(shí)隨地在和負(fù)載技術(shù)打交道，例如：上下班高峰期的車(chē)流量引導(dǎo)、民航空管局的航空流量管制、銀行柜臺(tái)的叫號(hào)系統(tǒng)。

這里我們所說(shuō)的負(fù)載分配層，是單指利用軟件實(shí)現(xiàn)的計(jì)算機(jī)系統(tǒng)上的狹義負(fù)載均衡。一個(gè)大型（日PV一億+）、中型（日PV一千萬(wàn)+）Web業(yè)務(wù)系統(tǒng)，是不可能只有一個(gè)業(yè)務(wù)處理服務(wù)，而是多臺(tái)服務(wù)器同時(shí)進(jìn)行某一個(gè)相同業(yè)務(wù)的服務(wù)。所以我們需要根據(jù)業(yè)務(wù)形態(tài)設(shè)計(jì)一種架構(gòu)方式，將來(lái)自外部客戶端的業(yè)務(wù)請(qǐng)求分擔(dān)到每一個(gè)可用的業(yè)務(wù)節(jié)點(diǎn)上。如下圖所示：

負(fù)載層還有一個(gè)作用，是根據(jù)用戶的請(qǐng)求規(guī)則，將不同的請(qǐng)求類型分派到不同的服務(wù)器上。例如：如果某一個(gè)HTTP請(qǐng)求是請(qǐng)求一張圖片，那么負(fù)載層會(huì)直接到圖片存儲(chǔ)介質(zhì)上尋找相應(yīng)的圖片；如果某一個(gè)HTTP請(qǐng)求是提交的一張訂單，那么負(fù)載層會(huì)根據(jù)規(guī)則將這張訂單提交發(fā)送到指定的“訂單服務(wù)”節(jié)點(diǎn)上。

不同的業(yè)務(wù)需求，使用的負(fù)載層方案也是不同的，這就考驗(yàn)架構(gòu)師的方案選擇能力。例如Nginx只能處理TCP/IP協(xié)議的之上應(yīng)用層HTTP協(xié)議，如果要處理TCP/IP協(xié)議，則要按照第三方的TCP-Proxy-Module模。更好的直接在TCP/IP層負(fù)載的方案，是使用HAProxy。

常用的負(fù)載層架構(gòu)方式包括：

- 獨(dú)立的Nginx負(fù)載或HAProxy方案

- LVS（DR）+ Nginx方案

- DNS輪詢 + LVS + Nginx方案

- 智能DNS（DNS路由） + LVS + Nginx方案

隨后的文章中將詳細(xì)介紹這些負(fù)載架構(gòu)方案以及這些方案的變形。

業(yè)務(wù)服務(wù)層和通信層

概述

通俗來(lái)講就是我們的核心業(yè)務(wù)層，訂單業(yè)務(wù)、施工管理業(yè)務(wù)、診療業(yè)務(wù)、付款業(yè)務(wù)、日志業(yè)務(wù)等等。如下圖所示：

很明顯在中大型系統(tǒng)中，這些業(yè)務(wù)不可能是獨(dú)立存在的，一般的設(shè)計(jì)要求都會(huì)涉及到子系統(tǒng)間脫耦：即X1系統(tǒng)除了知曉底層支撐系統(tǒng)的存在外（例如用戶權(quán)限系統(tǒng)），X1系統(tǒng)不需要知道和它邏輯對(duì)等的X2系統(tǒng)的存在就可以工作。這種情況下要完成一個(gè)較復(fù)雜業(yè)務(wù)，子系統(tǒng)間調(diào)用又是必不可少的：例如A業(yè)務(wù)在處理成功后，會(huì)調(diào)用B業(yè)務(wù)進(jìn)行執(zhí)行；A業(yè)務(wù)在處理失敗后，會(huì)調(diào)用C業(yè)務(wù)進(jìn)行執(zhí)行；又或者A業(yè)務(wù)和D業(yè)務(wù)在某種情況下是不可分割的整體，只有同時(shí)成功才成功，其中有一個(gè)失敗整個(gè)大的業(yè)務(wù)過(guò)程都失敗。如下圖所示：

這樣一來(lái)業(yè)務(wù)間的通信層又是一個(gè)逃不開(kāi)的話題。 在隨后的文章中，我們將以Alibaba的Dubbo框架、基于AMQP協(xié)議的消息隊(duì)列和Kafka消息隊(duì)列技術(shù)的原理和使用方式，來(lái)講解業(yè)務(wù)通信層技術(shù)，特別是業(yè)務(wù)通信層的技術(shù)選型注意事項(xiàng)。

不得不提的HTTP請(qǐng)求方式

有的讀者可能會(huì)問(wèn)，為什么業(yè)務(wù)系統(tǒng)間通信層沒(méi)有提到HTTP這樣的調(diào)用方式。畢竟很多公司目前都采用這種方式作為業(yè)務(wù)系統(tǒng)間的調(diào)用方式。我們首先通過(guò)一個(gè)圖來(lái)看看HTTP方式的調(diào)用過(guò)程。（注意，此過(guò)程不考慮http客戶端緩存的過(guò)程也不考慮DNS域名解析的過(guò)程，從HTTP建立可靠的TCP連接開(kāi)始）：

從上圖中我們可以看出以下幾個(gè)問(wèn)題：

• 從技術(shù)原理層面看，HTTP請(qǐng)求是在需要進(jìn)行調(diào)用時(shí)建立TCP連接，并且發(fā)送并等待數(shù)據(jù)回送，在得到請(qǐng)求結(jié)果后，可能需要再關(guān)閉這個(gè)TCP連接。這樣的原理使得很多時(shí)間浪費(fèi)在和業(yè)務(wù)無(wú)關(guān)的技術(shù)特性上。
• 另外，發(fā)送Head信息和接收Head這樣的數(shù)據(jù)，對(duì)業(yè)務(wù)數(shù)據(jù)來(lái)說(shuō)是毫無(wú)意義的。在訪問(wèn)量較小的情況下，這樣的過(guò)程都還是可以接收的，但是當(dāng)帶寬資源吃緊的情況下，這樣的數(shù)據(jù)空間就是彌足珍貴的。
• 獨(dú)立的HTTP請(qǐng)求由于沒(méi)有SOA結(jié)構(gòu)中的“治理中心”的概念，所以單純的HTTP請(qǐng)求很難保證負(fù)責(zé)業(yè)務(wù)聯(lián)動(dòng)中的上下文一致性。當(dāng)然你可以自行編碼來(lái)保證，但那樣真的合理嗎？
• 最后，需要說(shuō)明的是，現(xiàn)在類似Apache HTTP Components這樣的組件提供了HTTP Pool來(lái)減少TCP連接時(shí)長(zhǎng)，但這僅僅是優(yōu)化了HTTP作為業(yè)務(wù)間通信時(shí)的一個(gè)問(wèn)題，其他的問(wèn)題依然存在。

基于以上的描述，本文并不推薦使用HTTP作為業(yè)務(wù)間通信/調(diào)用的方式，而建議HTTP方式僅限于WEB、iOS、Android等這樣的客戶端請(qǐng)求服務(wù)的方式。

數(shù)據(jù)存儲(chǔ)層

數(shù)據(jù)存儲(chǔ)將是這個(gè)系列文章中將要介紹的另一個(gè)重點(diǎn)。進(jìn)行業(yè)務(wù)計(jì)算前的初始數(shù)據(jù)、計(jì)算過(guò)程中的臨時(shí)數(shù)據(jù)、計(jì)算完成后得到的計(jì)算結(jié)果都需要進(jìn)行存儲(chǔ)。我們通過(guò)一張思維導(dǎo)圖首先從幾個(gè)維度闡述一下數(shù)據(jù)存儲(chǔ)的基本分類。

文件存儲(chǔ)原理

我們通過(guò)一個(gè)最基本的在centos6.5系統(tǒng)上創(chuàng)建Ext4文件系統(tǒng)的過(guò)程，講解文件系統(tǒng)的最基本原理。

首先我們會(huì)通過(guò)fdisk命令對(duì)本地硬盤(pán)進(jìn)行分區(qū)（即確定可控制的扇區(qū)的范圍），如下圖所示：

然后我們會(huì)在這個(gè)區(qū)上面通過(guò)mkfs命令創(chuàng)建我們想要的文件系統(tǒng)（Ext3、Ext4、LVM、XF、BTRFS等），如下圖所示：

最后我們掛載這個(gè)文件系統(tǒng)到指定的路徑，如下圖所示：

通過(guò)df命令查看掛載信息，如下圖所示：

萬(wàn)變不離其宗的創(chuàng)建過(guò)程告訴我們一個(gè)什么事實(shí)呢？

物理塊，一個(gè)物理塊是我們上層文件系統(tǒng)能夠操作的最小單位（通常為512字節(jié)），一個(gè)物理塊在底層對(duì)應(yīng)了多個(gè)物理扇區(qū)。通常一塊SATA硬盤(pán)會(huì)有若干機(jī)械手臂（決定于物理盤(pán)片數(shù)量），和若干個(gè)物理扇區(qū)（物理扇區(qū)的大小是磁盤(pán)出廠時(shí)就確定的，我們無(wú)法改變）。

單個(gè)扇區(qū)的工作是單向的，那么映射出來(lái)的一個(gè)物理塊的工作方式也是單向的。原理就是機(jī)械手臂在讀取這個(gè)扇區(qū)的數(shù)據(jù)時(shí)，硬件芯片是不允許機(jī)械手臂同時(shí)向這個(gè)扇區(qū)寫(xiě)入數(shù)據(jù)的。

通過(guò)上層文件系統(tǒng)（EXT、NTFS、BTRFS、XF）對(duì)下層物理塊的封裝，OS是不需要直接操作磁盤(pán)物理塊的，操作者通過(guò)ls這樣的命令看到的一個(gè)一個(gè)文件也不需要關(guān)心這些文件在物理塊的存儲(chǔ)格式。這就是為什么不同的文件系統(tǒng)有不同的特性（有的文件系統(tǒng)支持快照，有的文件系統(tǒng)支持?jǐn)?shù)據(jù)恢復(fù)），基本原理就是這些文件系統(tǒng)對(duì)下層物理塊的操作規(guī)范不一樣。

塊存儲(chǔ)和文件存儲(chǔ)

上一小節(jié)我們敘述了最簡(jiǎn)單、最原始的物理塊和文件格式規(guī)范的工作方式，但是隨著服務(wù)器端不斷擴(kuò)大的數(shù)據(jù)存儲(chǔ)容量的需求和數(shù)據(jù)安全性的需求，很顯然單機(jī)的存儲(chǔ)是沒(méi)辦法滿足要求的，目前存儲(chǔ)環(huán)境兩種大的需求類型是：

穩(wěn)定的擴(kuò)展存儲(chǔ)容量，并且不破壞目前已存儲(chǔ)的數(shù)據(jù)信息，不影響整個(gè)存儲(chǔ)系統(tǒng)的穩(wěn)定性。

文件共享，讓多臺(tái)服務(wù)器能夠共享存儲(chǔ)數(shù)據(jù)，并且都可以對(duì)文件系統(tǒng)進(jìn)行讀寫(xiě)操作。

要解決這兩個(gè)問(wèn)題，我們首先要將問(wèn)題擴(kuò)展到上一小節(jié)的圖例中，如下圖所示：

很明顯圖中兩個(gè)問(wèn)題的答案是肯定的，也就是我們將要介紹的塊存儲(chǔ)系統(tǒng)要解決的問(wèn)題。

塊存儲(chǔ)系統(tǒng)

我們先來(lái)聊一下塊存儲(chǔ)。之前我們提到的最簡(jiǎn)單的情況就是磁盤(pán)在本地物理機(jī)上，傳輸?shù)奈锢韷KI/O命令，也是通過(guò)本地物理機(jī)主板上的南橋進(jìn)行的。但是為了擴(kuò)展更大的磁盤(pán)空間，并且保證數(shù)據(jù)吞吐量，我們需要將磁盤(pán)介質(zhì)和本地物理機(jī)分離，并且讓物理塊的I/O命令在網(wǎng)絡(luò)上進(jìn)行傳輸：

雖然磁盤(pán)介質(zhì)和本地物理機(jī)發(fā)生了分離，但是直接傳輸塊I/O命令的本質(zhì)是沒(méi)有改變的。本地南橋傳輸I/O命令變成了光纖傳輸，只在本物理機(jī)內(nèi)部傳輸I/O命令變成了網(wǎng)絡(luò)傳輸，并且I/O命令通過(guò)某種通信協(xié)議進(jìn)行了規(guī)范（例如FC、SCSI等）。

文件系統(tǒng)的映射卻是在本地進(jìn)行，而非遠(yuǎn)程的文件系統(tǒng)映射。上文中我們已經(jīng)提到，由于塊操作的順序性（在一個(gè)扇區(qū)進(jìn)行寫(xiě)入的時(shí)候，是不會(huì)進(jìn)行這個(gè)扇區(qū)的讀取操作的），且塊操作屬于底層物理操作無(wú)法向上層的文件邏輯層主動(dòng)反饋?zhàn)兓?。所以多個(gè)物理主機(jī)是無(wú)法通過(guò)這個(gè)技術(shù)進(jìn)行文件共享的。

塊存儲(chǔ)系統(tǒng)要解決的是大物理存儲(chǔ)空間、高數(shù)據(jù)吞吐量、強(qiáng)穩(wěn)定性的共存問(wèn)題。作為上層使用這個(gè)文件系統(tǒng)的服務(wù)器來(lái)說(shuō)，它非常清楚，除了它以外沒(méi)有其他的服務(wù)器能夠?qū)儆谒倪@些物理塊進(jìn)行讀寫(xiě)操作了。也就是說(shuō)它認(rèn)為這個(gè)龐大容量的文件存儲(chǔ)空間只是它本地物理機(jī)上的存儲(chǔ)空間。

當(dāng)然隨著技術(shù)的發(fā)展，現(xiàn)在已經(jīng)有一些技術(shù)可以只用TCP/IP協(xié)議對(duì)標(biāo)準(zhǔn)的SCSI命令進(jìn)行傳輸，以便減小這個(gè)塊存儲(chǔ)系統(tǒng)的建設(shè)成本（例如iSCSI技術(shù)）。但是這種折中方式也是以減弱整個(gè)系統(tǒng)的數(shù)據(jù)吞吐量為代價(jià)的。不同的業(yè)務(wù)需求可以根據(jù)實(shí)際情況進(jìn)行技術(shù)選型。

文件存儲(chǔ)系統(tǒng)

那么如果是將文件系統(tǒng)從本地物理機(jī)通過(guò)網(wǎng)絡(luò)移植到遠(yuǎn)程呢？當(dāng)然可以，典型的文件存儲(chǔ)系統(tǒng)包括了FTP、NFS、DAS：

文件存儲(chǔ)系統(tǒng)的關(guān)鍵在于，文件系統(tǒng)并不在本機(jī)。而是通過(guò)網(wǎng)絡(luò)訪問(wèn)存在于遠(yuǎn)程的文件系統(tǒng)，再由遠(yuǎn)程的文件系統(tǒng)操作塊I/O命令完成數(shù)據(jù)操作。

一般來(lái)說(shuō)諸如本地文件系統(tǒng)NTFS/EXT/LVM/XF等是不允許直接網(wǎng)絡(luò)訪問(wèn)的，所以一般文件存儲(chǔ)系統(tǒng)會(huì)進(jìn)行一層網(wǎng)絡(luò)協(xié)議封裝，這就是NFS協(xié)議/FTP協(xié)議/NAS協(xié)議（注意我們說(shuō)的是協(xié)議），再由協(xié)議操作文件存儲(chǔ)系統(tǒng)的服務(wù)器文件系統(tǒng)。

文件存儲(chǔ)系統(tǒng)要解決的問(wèn)題首要的文件共享，網(wǎng)絡(luò)文件協(xié)議可以保證多臺(tái)客戶端共享服務(wù)器上的文件結(jié)構(gòu)。從整個(gè)架構(gòu)圖上可以看到文件存儲(chǔ)系統(tǒng)的數(shù)據(jù)讀寫(xiě)速度、數(shù)據(jù)吞吐量是沒(méi)辦法和塊存儲(chǔ)系統(tǒng)相比的（因?yàn)檫@不是文件存儲(chǔ)系統(tǒng)要解決的首要問(wèn)題）。

從上面的簡(jiǎn)介中我們可以清楚的知曉，當(dāng)面對(duì)大量的數(shù)據(jù)讀寫(xiě)壓力的時(shí)候，文件存儲(chǔ)系統(tǒng)肯定不是我們的首要選擇，而當(dāng)我們需要選擇塊存儲(chǔ)系統(tǒng)時(shí)又面臨成本和運(yùn)維的雙重壓力（SAN系統(tǒng)的搭建是比較復(fù)雜的，并且設(shè)備費(fèi)用昂貴）。并且在實(shí)際生產(chǎn)環(huán)境中我們經(jīng)常遇到數(shù)據(jù)讀取壓力大，且需要共享文件信息的場(chǎng)景。那么這個(gè)問(wèn)題怎么解決呢？

對(duì)象存儲(chǔ)系統(tǒng)

兼具塊存儲(chǔ)系統(tǒng)的高吞吐量、高穩(wěn)定性和文件存儲(chǔ)的網(wǎng)絡(luò)共享性、廉價(jià)性的對(duì)象存儲(chǔ)就是為了滿足這樣的需求出現(xiàn)的。典型的對(duì)象存儲(chǔ)系統(tǒng)包括：MFS、Swift、Ceph、Ozone等。下面我們簡(jiǎn)單介紹一下對(duì)象存儲(chǔ)系統(tǒng)的特點(diǎn)，在后面的文章中，我們將選擇一款對(duì)象存儲(chǔ)系統(tǒng)進(jìn)行詳細(xì)說(shuō)明。

對(duì)象存儲(chǔ)系統(tǒng)一定是分布式文件系統(tǒng)。但分布式文件系統(tǒng)不一定是對(duì)象存儲(chǔ)系統(tǒng)

我們知道文件信息是由若干屬性進(jìn)行描述的，包括文件名、存儲(chǔ)位置、文件大小、當(dāng)前狀態(tài)、副本數(shù)量等信息。我們將這些屬性抽離出來(lái)，專門(mén)使用服務(wù)器進(jìn)行存儲(chǔ)（元數(shù)據(jù)服務(wù)器）。這樣一來(lái)文件操作的客戶端要訪問(wèn)某一個(gè)文件，首先會(huì)詢問(wèn)元數(shù)據(jù)節(jié)點(diǎn)這個(gè)文件的基本信息。

由于是分布式系統(tǒng)，那么數(shù)據(jù)一致性、資源爭(zhēng)奪、節(jié)點(diǎn)異常問(wèn)題都需要進(jìn)行統(tǒng)一的協(xié)調(diào)。所以對(duì)象存儲(chǔ)系統(tǒng)中一般會(huì)有監(jiān)控/協(xié)調(diào)節(jié)點(diǎn)。不同的對(duì)象存儲(chǔ)系統(tǒng)，支持的元數(shù)據(jù)節(jié)點(diǎn)和監(jiān)控/協(xié)調(diào)節(jié)點(diǎn)的數(shù)量是不一致的。但總的趨勢(shì)都是“去中心化”。

OSD節(jié)點(diǎn)（基于對(duì)象的存儲(chǔ)設(shè)備）用于存儲(chǔ)文件內(nèi)容信息。這里要注意，雖然OSD節(jié)點(diǎn)的底層和塊存儲(chǔ)底層一樣都是依靠塊I/O進(jìn)行操作的，但是上層構(gòu)造兩者完全不同：OSD節(jié)點(diǎn)并非向塊存儲(chǔ)設(shè)備那樣，通過(guò)塊操作命令跳過(guò)本地文件系統(tǒng)直接進(jìn)行物理塊操作。

隨后的文章中我們將選擇一款流行的對(duì)象存儲(chǔ)系統(tǒng)，詳細(xì)剖析對(duì)象存儲(chǔ)系統(tǒng)，并且對(duì)分布式存儲(chǔ)系統(tǒng)中三個(gè)核心概念和取舍進(jìn)行說(shuō)明（CAP）：一致性、擴(kuò)展性和容錯(cuò)性。

數(shù)據(jù)庫(kù)存儲(chǔ)

這篇文章已經(jīng)寫(xiě)了很多存儲(chǔ)層的概要描述了，所以我們熟悉或者不熟悉的數(shù)據(jù)庫(kù)存儲(chǔ)技術(shù)的概述就不在這里介紹了。

后續(xù)的文章我將使用Mysql講解幾個(gè)常用的架構(gòu)方案和性能優(yōu)化點(diǎn)，當(dāng)然也會(huì)講到Mysql中，諸如Innodb這樣的核心數(shù)據(jù)引擎的工作方式。這些架構(gòu)方案主要解決的是Mysql的單機(jī)I/O瓶頸、機(jī)房?jī)?nèi)數(shù)據(jù)容災(zāi)、數(shù)據(jù)庫(kù)穩(wěn)定性、跨機(jī)房數(shù)據(jù)容災(zāi)等核心問(wèn)題。

后續(xù)的文章我還會(huì)選取目前流行的數(shù)據(jù)緩存系統(tǒng)，講解其工作原理、核心算法和架構(gòu)方案。以便讀者們根據(jù)自己的業(yè)務(wù)情況設(shè)計(jì)符合業(yè)務(wù)的存儲(chǔ)集群。當(dāng)然還有非關(guān)系型數(shù)據(jù)庫(kù)Cassandra、HBase、MongoDB的深入介紹。

評(píng)價(jià)架構(gòu)的特性

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

建設(shè)成本

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

擴(kuò)展/規(guī)劃水平

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

抗攻擊水平

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

容災(zāi)恢復(fù)等級(jí)

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

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

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

維護(hù)難易程度

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

其他說(shuō)明

負(fù)載層、業(yè)務(wù)層、業(yè)務(wù)通信層、數(shù)據(jù)存儲(chǔ)層的詳細(xì)架構(gòu)方案在后續(xù)文章中我們會(huì)用若干文章進(jìn)行深入講解，包括核心算法、架設(shè)原理、架設(shè)案例。隨后的文章中我們將首先介紹系統(tǒng)負(fù)載層。

在很多系統(tǒng)中我們還涉及存儲(chǔ)的數(shù)據(jù)進(jìn)行分析，形成數(shù)據(jù)分析結(jié)果。這涉及到數(shù)據(jù)分析層的架構(gòu)知識(shí)。Hadoop生態(tài)系統(tǒng)是目前行業(yè)公認(rèn)的高效率、高穩(wěn)定性、高擴(kuò)展性的數(shù)據(jù)分析生態(tài)系統(tǒng)。這個(gè)系列的博文暫時(shí)不會(huì)介紹數(shù)據(jù)分析層的架構(gòu)設(shè)計(jì)和開(kāi)發(fā)知識(shí)，后續(xù)將會(huì)獨(dú)立成文。

各位看官我們馬上進(jìn)入負(fù)載層技術(shù)的詳細(xì)講解！

原文鏈接：https://blog.csdn.net/yinwenjie/article/details/46480485