前言

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

隨后，個人電腦的興起帶動了眾多富桌面應(yīng)用（rich desktop application）的出現(xiàn)，它們基于操作系統(tǒng)上的user interface開發(fā)，數(shù)據(jù)則是存儲在單獨(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ù)層，存儲系統(tǒng)數(shù)據(jù)。三個層次各司其職，這也是大家最熟悉的 三層架構(gòu) （three-tier architecture）。

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

架構(gòu)視圖

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

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

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

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

分層架構(gòu)中的每一層都扮演著各自的角色，比如表現(xiàn)層負(fù)責(zé)處理所有的用戶請求和瀏覽器交互，而業(yè)務(wù)層則負(fù)責(zé)執(zhí)行每次請求下的特定業(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)隊 。

層間隔離

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

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

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

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

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

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

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

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

一些注意事項(xiàng)

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

1、做好模塊的劃分

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

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

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

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

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

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

綜合得分

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

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

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

總結(jié)

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

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