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

本篇內(nèi)容主要講解“標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層實(shí)例分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層實(shí)例分析”吧!

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

負(fù)載層還有一個作用，是根據(jù)用戶的請求規(guī)則，將不同的請求類型分派到不同的服務(wù)器上。例如：如果某一個HTTP請求是請求一張圖片，那么負(fù)載層會直接到圖片存儲介質(zhì)上尋找相應(yīng)的圖片；如果某一個HTTP請求是提交的一張訂單，那么負(fù)載層會根據(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ù)層，訂單業(yè)務(wù)、施工管理業(yè)務(wù)、診療業(yè)務(wù)、付款業(yè)務(wù)、日志業(yè)務(wù)等等。如下圖所示：

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

不得不提的HTTP請求方式

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

從上圖中我們可以看出以下幾個問題：

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

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

文件存儲原理

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

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

塊存儲和文件存儲

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

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

塊存儲系統(tǒng)

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

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

文件存儲系統(tǒng)

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

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

對象存儲系統(tǒng)

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

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

墻裂分享，標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層，看看沒錯

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

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

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

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

數(shù)據(jù)庫存儲

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

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

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

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

建設(shè)成本

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

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

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

抗攻擊水平

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

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

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

業(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ù)。另外說明兩點(diǎn)，目前行業(yè)內(nèi)有很多為解決相同業(yè)務(wù)場景存在的不同方案，架構(gòu)師在進(jìn)行方案選型的過程中，一定要對各種解決方案的特點(diǎn)足夠掌握，這樣才能做出正確的選擇；另外行業(yè)內(nèi)的解決方案已經(jīng)足夠多，架構(gòu)師在業(yè)務(wù)沒有特殊要求的情況下一定不要做“ 重復(fù)發(fā)明輪子”的事情。

維護(hù)難易程度

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

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

到此，相信大家對“標(biāo)準(zhǔn)Web系統(tǒng)的架構(gòu)分層實(shí)例分析”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！