前言

軟件剛出現(xiàn)的時(shí)候，還是大型計(jì)算機(jī)的年代，一個(gè)軟件系統(tǒng)一般都只會(huì)運(yùn)行在一臺(tái)機(jī)器上。隨著軟硬件技術(shù)的革新，計(jì)算機(jī)體積和成本逐漸變小，此時(shí)工程師們發(fā)現(xiàn)一個(gè)軟件系統(tǒng)只運(yùn)行在單臺(tái)機(jī)器上會(huì)存在各種瓶頸。如果將系統(tǒng)按照功能劃分成前端和后端，分別部署在兩臺(tái)服務(wù)器上，問題得到了緩解，于是便有了Client/Server架構(gòu)的出現(xiàn)。

隨后，個(gè)人電腦的興起帶動(dòng)了眾多富桌面應(yīng)用（rich desktop application）的出現(xiàn)，它們基于操作系統(tǒng)上的user interface開發(fā)，數(shù)據(jù)則是存儲(chǔ)在單獨(dú)部署的database server上，通過標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議進(jìn)行數(shù)據(jù)通信。這種Desktop + Database Server的架構(gòu)和C/S架構(gòu)一樣，同屬 兩層架構(gòu) （two-tier architecture）。

隨著90年代互聯(lián)網(wǎng)的迅速崛起，Browser + Web Server + Database Server的組合也漸漸風(fēng)靡。Browser為表現(xiàn)層，提供用戶交互界面；Web Server為業(yè)務(wù)層，處理具體的業(yè)務(wù)邏輯；Database Server為數(shù)據(jù)層，存儲(chǔ)系統(tǒng)數(shù)據(jù)。三個(gè)層次各司其職，這也是大家最熟悉的 三層架構(gòu) （three-tier architecture）。

上述的幾種架構(gòu)模式都屬于 分層架構(gòu) （layered architecture）的范疇，分層架構(gòu)并沒有限定一定得有多少個(gè)層次，層次的數(shù)量可以根據(jù)應(yīng)用場(chǎng)景靈活控制，因此也被稱為 n-tier architecture 。它結(jié)構(gòu)簡(jiǎn)單，基于此架構(gòu)進(jìn)行系統(tǒng)開發(fā)成本也很低（很多公司在組織結(jié)構(gòu)上劃分為前端工程師、后端工程師、DBA，根據(jù) 康威定律 ，這天然就具備了分層架構(gòu)開發(fā)的良好條件），因此它在業(yè)界備受歡迎。 如果你的團(tuán)隊(duì)還不確定選擇什么樣的架構(gòu)，又或者為了踐行敏捷宣言中的“just starts coding“，那么分層架構(gòu)會(huì)是一個(gè)不錯(cuò)的選擇 。

架構(gòu)視圖

在分層架構(gòu)中，組件根據(jù)功能被劃分在不同的層次上，雖然層次的數(shù)量和類型并沒有被限制，但大多數(shù)的分層架構(gòu)都由以下4層組成： 表現(xiàn)層 （presentation）、 業(yè)務(wù)層 （business）、 持久層 （persistence）和 數(shù)據(jù)層 （database），如下圖所示。在一些簡(jiǎn)單的系統(tǒng)中，持久層的邏輯（如SQL）被嵌入到業(yè)務(wù)層中，形成了經(jīng)典的三層架構(gòu)；而在一些復(fù)雜的系統(tǒng)中，也會(huì)根據(jù)具體的業(yè)務(wù)劃分為五層甚至更多的層次。

分層架構(gòu)的標(biāo)準(zhǔn)邏輯分層

前文所述的表現(xiàn)層等4個(gè)層次都是邏輯的劃分方法，在實(shí)際部署時(shí)，一般會(huì)有下圖所示的幾種部署形態(tài)。形態(tài)1中，表現(xiàn)層、業(yè)務(wù)層和持久層為一個(gè)部署單元，而數(shù)據(jù)層則單獨(dú)部署，具體表現(xiàn)為一個(gè)獨(dú)立部署的數(shù)據(jù)庫或文件系統(tǒng)；形態(tài)2中，表現(xiàn)層被分離出單獨(dú)部署，業(yè)務(wù)層和持久層組成一個(gè)部署單元，數(shù)據(jù)層依舊是單獨(dú)部署的數(shù)據(jù)庫或文件系統(tǒng)；形態(tài)3中，包括數(shù)據(jù)層在內(nèi)的4層全都在同一個(gè)部署單元內(nèi)，常見于業(yè)務(wù)簡(jiǎn)單的系統(tǒng)，它們往往使用的是嵌入式數(shù)據(jù)庫或內(nèi)存數(shù)據(jù)庫。

分層架構(gòu)的部署形態(tài)

分層架構(gòu)中的每一層都扮演著各自的角色，比如表現(xiàn)層負(fù)責(zé)處理所有的用戶請(qǐng)求和瀏覽器交互，而業(yè)務(wù)層則負(fù)責(zé)執(zhí)行每次請(qǐng)求下的特定業(yè)務(wù)邏輯；表現(xiàn)層無需擔(dān)心從哪里獲取用戶數(shù)據(jù)，它只需要將數(shù)據(jù)以特定的格式在瀏覽器上顯示即可。同樣地，業(yè)務(wù)層也無需關(guān)心用戶數(shù)據(jù)從何而來以及如何呈現(xiàn)，它只需從持久層中取出數(shù)據(jù)，執(zhí)行特定的業(yè)務(wù)邏輯（比如聚合數(shù)據(jù)），然后將結(jié)果返回給表現(xiàn)層。

每一層都是特定行為的抽象，這樣的職責(zé)劃分，使得組織能夠快速高效地創(chuàng)建出責(zé)任模型，圍繞各層打造開發(fā)團(tuán)隊(duì) 。

層間隔離

分層架構(gòu)中的每一層可以是封閉的或者開放的，封閉意味著當(dāng)一個(gè)請(qǐng)求自頂向下在層間傳遞時(shí)，它不能跳過任意的一層。比如，當(dāng)表現(xiàn)層接收到請(qǐng)求之后，它必須先后經(jīng)過業(yè)務(wù)層和持久層才能到達(dá)數(shù)據(jù)層，如下圖所示。

封閉的分層架構(gòu)

對(duì)于簡(jiǎn)單的數(shù)據(jù)獲取類請(qǐng)求，如果讓表現(xiàn)層能夠直接訪問數(shù)據(jù)層獲取數(shù)據(jù)，無疑是最簡(jiǎn)單高效的。也即是讓業(yè)務(wù)層和持久層變成開放狀態(tài)，允許請(qǐng)求在層間傳遞時(shí)跳過此層。那么， 究竟是封閉好，還是開放好呢 ？要解答這個(gè)問題，就要回到層間隔離的出發(fā)點(diǎn)上。

所謂的層間隔離，旨在降低一個(gè)層次上的變化對(duì)其他層次的組件的影響，簡(jiǎn)單來說，就是每個(gè)層次對(duì)其他層次的功能知道的越少越好 。為了達(dá)到層間隔離的目的，就需要將每個(gè)層次置為封閉的狀態(tài)。假設(shè)表現(xiàn)層能夠直接訪問持久層，那么持久層的變化將會(huì)直接影響到業(yè)務(wù)層和表現(xiàn)層，這加劇了層間的耦合，導(dǎo)致系統(tǒng)變化的代價(jià)高昂。

層間隔離可以降低層次變化對(duì)系統(tǒng)的影響，凡事沒有絕對(duì)， 在某些的場(chǎng)景，將特定的層次置為開放的狀態(tài)也不失為一件好事 。考慮以下例子，業(yè)務(wù)層中存在著一些共享組件承載著業(yè)務(wù)層公共的功能（比如日志類、審計(jì)類、日期和字符串工具類等）。現(xiàn)在有一項(xiàng)架構(gòu)決策要求表現(xiàn)層不能直接訪問這些共享組件，但矛盾的是，原則上表現(xiàn)層是可以直接訪問業(yè)務(wù)層的，這種需要違反原則的決策將會(huì)很難落地。

業(yè)務(wù)層中的共享組件

一種解決方法是，新增一個(gè)服務(wù)層，該層包含了業(yè)務(wù)層的這些共享組件。因?yàn)闃I(yè)務(wù)層是關(guān)閉的狀態(tài)，故表現(xiàn)層也就不能訪問到這些共享組件了。然而，新增的服務(wù)層必須置為開放狀態(tài)，否則業(yè)務(wù)層將無法直接訪問持久層。新增一個(gè)服務(wù)層并置為開放狀態(tài)，這樣既落地了架構(gòu)決策，也不會(huì)影響到原有的功能，一舉兩得。

在分層架構(gòu)中新增一個(gè)層次

一些注意事項(xiàng)

在使用分層架構(gòu)時(shí)，需要注意以下兩點(diǎn)：

1、做好模塊的劃分

為分層架構(gòu)做好模塊劃分主要是為后續(xù)的架構(gòu)演進(jìn)做好準(zhǔn)備，比如在業(yè)務(wù)復(fù)雜到一定程度后演進(jìn)為微服務(wù)架構(gòu)時(shí)，各個(gè)模塊可以很自然地演進(jìn)為微服務(wù)。為此，應(yīng)該避免出現(xiàn)類的繼承層次過深的現(xiàn)象，這會(huì)導(dǎo)致代碼嚴(yán)重的耦合，不利于后續(xù)的架構(gòu)演進(jìn)。

2、避免掉進(jìn)sinkhole反模式的陷阱

所謂sinkhole反模式指的是請(qǐng)求只是簡(jiǎn)單地路過各個(gè)層次，并沒有做一些業(yè)務(wù)處理。

比如，表現(xiàn)層接收到一個(gè)獲取基本用戶數(shù)據(jù)（姓名、地址等）的請(qǐng)求后將它傳遞到業(yè)務(wù)層；然而，業(yè)務(wù)層并沒有做任何的業(yè)務(wù)處理，直接將請(qǐng)求傳遞到持久層；持久層也僅僅是構(gòu)造了一個(gè)簡(jiǎn)單的SQL語句，向數(shù)據(jù)層查詢用戶數(shù)據(jù)；最后，數(shù)據(jù)按照原路返回到表現(xiàn)層，中途沒有經(jīng)過任何的數(shù)據(jù)匯聚、轉(zhuǎn)換等操作。

sinkhole反模式會(huì)導(dǎo)致很多不必要的對(duì)象實(shí)例化開銷，從而增大了系統(tǒng)的內(nèi)存消耗，并且影響了性能 。

然而，一個(gè)系統(tǒng)多多少少都會(huì)存在一些sinkhole反模式場(chǎng)景，要判斷一個(gè)系統(tǒng)是否已經(jīng)徹底掉進(jìn)sinkhole反模式的陷阱，主要還是看這類業(yè)務(wù)請(qǐng)求所占的百分比。根據(jù)20-80法則，當(dāng)系統(tǒng)中有超過80%的業(yè)務(wù)請(qǐng)求是sinkhole類請(qǐng)求時(shí)，表示系統(tǒng)已經(jīng)掉進(jìn)sinkhole反模式的陷阱，這從側(cè)面也說明該系統(tǒng)已經(jīng)不再適合分層架構(gòu)，是時(shí)候考慮架構(gòu)演進(jìn)了。

綜合得分

分層架構(gòu)的綜合得分

從綜合得分上看，分層架構(gòu)的Overall cost和Simplicity得分很高，這很大程度上得益于分層架構(gòu)本身是單體架構(gòu)，少了很多分布式系統(tǒng)才有的復(fù)雜性。但這樣導(dǎo)致Deployability得分很低，因?yàn)?行代碼的改動(dòng)就足以造成整個(gè)系統(tǒng)的重新部署。Testability得分不高也是這個(gè)原因，整系統(tǒng)的重新上線通常都需要將測(cè)試用例全部執(zhí)行一遍，多了不少額外的工作量。

Elasticity、Fault tolerance、Scalability這些都是單體架構(gòu)天然的劣勢(shì)，自然地，分層架構(gòu)在這些方面得分都很低。另外，sinkhole反模式的存在也拉低了分層架構(gòu)在Performance上的得分。

總結(jié)

分層架構(gòu)簡(jiǎn)單而高效，業(yè)界已經(jīng)有很多成熟的應(yīng)用，對(duì)那些項(xiàng)目剛剛起步，架構(gòu)師們還沒想好要采用哪種架構(gòu)模式的系統(tǒng)而言，這是非常適合的。在實(shí)現(xiàn)分層架構(gòu)時(shí)，我們需要合理地設(shè)置各個(gè)層次的封閉或開放狀態(tài)，做好層間隔離，同時(shí)也要避免掉進(jìn)sinkhole反模式陷阱。隨著業(yè)務(wù)的不斷擴(kuò)張，分層架構(gòu)在可維護(hù)性、可測(cè)試性、可擴(kuò)展性等上的短板也會(huì)逐步被放大，此時(shí)就需要考慮往其他架構(gòu)模式演進(jìn)了。

每種架構(gòu)模式都有其合適的應(yīng)用場(chǎng)景，只有熟悉常用的幾種架構(gòu)模式，才能設(shè)計(jì)出更好的軟件系統(tǒng)。下一篇文章，我們將繼續(xù)介紹 管道架構(gòu) 。