「 系統(tǒng)設(shè)計(jì) 」 為什么要做架構(gòu)分層？

參考&鳴謝

3.設(shè)計(jì)模式之分層思維：為什么要做代碼分層架構(gòu)？

從零開(kāi)始學(xué)架構(gòu)（八）分層架構(gòu)和設(shè)計(jì)模式

架構(gòu)模式之分層架構(gòu)總結(jié)

---

引言

在軟件系統(tǒng)設(shè)計(jì)中，分層架構(gòu)是一種常見(jiàn)而強(qiáng)大的設(shè)計(jì)模式。通過(guò)將系統(tǒng)劃分為不同的層次，每個(gè)層次專注于特定功能，分層架構(gòu)有助于提高系統(tǒng)的可維護(hù)性、可擴(kuò)展性和模塊化。本文將深入探討分層架構(gòu)的底層原理，闡述其優(yōu)勢(shì)以及一些可能的缺陷。

一、什么是分層架構(gòu)

分層架構(gòu)是一種將系統(tǒng)劃分為多個(gè)層次的設(shè)計(jì)模式，每個(gè)層次專注于特定的功能。這樣的設(shè)計(jì)使得系統(tǒng)的不同部分能夠更好地組織和管理，從而提高了系統(tǒng)的可維護(hù)性、可擴(kuò)展性和可理解性。

MVC

我們?cè)趧倓偝蔀槌绦騿T的時(shí)候，會(huì)被“教育”說(shuō)系統(tǒng)的設(shè)計(jì)要是“MVC”（Model-View-Controller）架構(gòu)。它將整體的系統(tǒng)分成了 Model（模型），View（視圖）和 Controller（控制器）三個(gè)層次，也就是將用戶視圖和業(yè)務(wù)處理隔離開(kāi)，并且通過(guò)控制器連接起來(lái)，很好地實(shí)現(xiàn)了表現(xiàn)和邏輯的解耦，是一種標(biāo)準(zhǔn)的軟件分層架構(gòu)。

另外一種常見(jiàn)的分層方式是將整體架構(gòu)分為表現(xiàn)層、邏輯層和數(shù)據(jù)訪問(wèn)層：

• 表現(xiàn)層，顧名思義嘛，就是展示數(shù)據(jù)結(jié)果和接受用戶指令的，是最靠近用戶的一層；
• 邏輯層里面有復(fù)雜業(yè)務(wù)的具體實(shí)現(xiàn)；
• 數(shù)據(jù)訪問(wèn)層則是主要處理和存儲(chǔ)之間的交互。

這是在架構(gòu)上最簡(jiǎn)單的一種分層方式。其實(shí)，我們?cè)诓唤?jīng)意間已經(jīng)按照三層架構(gòu)來(lái)做系統(tǒng)分層設(shè)計(jì)了，比如在構(gòu)建項(xiàng)目的時(shí)候，我們通常會(huì)建立三個(gè)目錄：Web、Service 和 Dao，它們分別對(duì)應(yīng)了表現(xiàn)層、邏輯層還有數(shù)據(jù)訪問(wèn)層。

OSI

除此之外，如果我們稍加留意，就可以發(fā)現(xiàn)很多的分層的例子。比如我們?cè)诖髮W(xué)中學(xué)到的 OSI 網(wǎng)絡(luò)模型，它把整個(gè)網(wǎng)絡(luò)分了七層，自下而上分別是物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會(huì)話層、表示層和應(yīng)用層。

TCP/IP

工作中經(jīng)常能用到 TCP/IP 協(xié)議，它把網(wǎng)絡(luò)簡(jiǎn)化成了四層，即鏈路層、網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。每一層各司其職又互相幫助，網(wǎng)絡(luò)層負(fù)責(zé)端到端的尋址和建立連接，傳輸層負(fù)責(zé)端到端的數(shù)據(jù)傳輸?shù)?#xff0c;同時(shí)呢相鄰兩層還會(huì)有數(shù)據(jù)的交互。這樣可以隔離關(guān)注點(diǎn)，讓不同的層專注做不同的事情。

文件系統(tǒng)

Linux 文件系統(tǒng)也是分層設(shè)計(jì)的，從下圖你可以清晰地看出文件系統(tǒng)的層次。在文件系統(tǒng)的最上層是虛擬文件系統(tǒng)（VFS），用來(lái)屏蔽不同的文件系統(tǒng)之間的差異，提供統(tǒng)一的系統(tǒng)調(diào)用接口。虛擬文件系統(tǒng)的下層是 Ext3、Ext4 等各種文件系統(tǒng)，再向下是為了屏蔽不同硬件設(shè)備的實(shí)現(xiàn)細(xì)節(jié)，我們抽象出來(lái)的單獨(dú)的一層——通用塊設(shè)備層，然后就是不同類型的磁盤(pán)了。

我們可以看到，某些層次負(fù)責(zé)的是對(duì)下層不同實(shí)現(xiàn)的抽象，從而對(duì)上層屏蔽實(shí)現(xiàn)細(xì)節(jié)。比方說(shuō) VFS 對(duì)上層（系統(tǒng)調(diào)用層）來(lái)說(shuō)提供了統(tǒng)一的調(diào)用接口，同時(shí)對(duì)下層中不同的文件系統(tǒng)規(guī)約了實(shí)現(xiàn)模型，當(dāng)新增一種文件系統(tǒng)實(shí)現(xiàn)的時(shí)候，只需要按照這種模型來(lái)設(shè)計(jì)，就可以無(wú)縫插入到 Linux 文件系統(tǒng)中。

那么，為什么這么多系統(tǒng)一定要做分層的設(shè)計(jì)呢？答案是分層設(shè)計(jì)存在一定的優(yōu)勢(shì)。

---

二、分層有什么好處

模塊化

**分層的設(shè)計(jì)可以簡(jiǎn)化系統(tǒng)設(shè)計(jì)，讓不同的人專注做某一層次的事情。**想象一下，如果你要設(shè)計(jì)一款網(wǎng)絡(luò)程序卻沒(méi)有分層，該是一件多么痛苦的事情。

因?yàn)槟惚仨毷且粋€(gè)通曉網(wǎng)絡(luò)的全才，要知道各種網(wǎng)絡(luò)設(shè)備的接口是什么樣的，以便可以將數(shù)據(jù)包發(fā)送給它。你還要關(guān)注數(shù)據(jù)傳輸?shù)募?xì)節(jié)，并且需要處理類似網(wǎng)絡(luò)擁塞，數(shù)據(jù)超時(shí)重傳這樣的復(fù)雜問(wèn)題。當(dāng)然了，你更需要關(guān)注數(shù)據(jù)如何在網(wǎng)絡(luò)上安全傳輸，不會(huì)被別人窺探和篡改。

而有了分層的設(shè)計(jì)，你只需要專注設(shè)計(jì)應(yīng)用層的程序就可以了，其他的，都可以交給下面幾層來(lái)完成。

復(fù)用性

**再有，分層之后可以做到很高的復(fù)用。**比如，我們?cè)谠O(shè)計(jì)系統(tǒng) A 的時(shí)候，發(fā)現(xiàn)某一層具有一定的通用性，那么我們可以把它抽取獨(dú)立出來(lái)，在設(shè)計(jì)系統(tǒng) B 的時(shí)候使用起來(lái)，這樣可以減少研發(fā)周期，提升研發(fā)的效率。

拓展性

**最后一點(diǎn)，分層架構(gòu)可以讓我們更容易做橫向擴(kuò)展。**如果系統(tǒng)沒(méi)有分層，當(dāng)流量增加時(shí)我們需要針對(duì)整體系統(tǒng)來(lái)做擴(kuò)展。但是，如果我們按照上面提到的三層架構(gòu)將系統(tǒng)分層后，那么我們就可以針對(duì)具體的問(wèn)題來(lái)做細(xì)致的擴(kuò)展。

比如說(shuō)，業(yè)務(wù)邏輯里面包含有比較復(fù)雜的計(jì)算，導(dǎo)致 CPU 成為性能的瓶頸，那這樣就可以把邏輯層單獨(dú)抽取出來(lái)獨(dú)立部署，然后只對(duì)邏輯層來(lái)做擴(kuò)展，這相比于針對(duì)整體系統(tǒng)擴(kuò)展所付出的代價(jià)就要小的多了。

橫向擴(kuò)展是高并發(fā)系統(tǒng)設(shè)計(jì)的常用方法之一，既然分層的架構(gòu)可以為橫向擴(kuò)展提供便捷， 那么支撐高并發(fā)的系統(tǒng)一定是分層的系統(tǒng)。

---

三、如何來(lái)做系統(tǒng)分層

說(shuō)了這么多分層的優(yōu)點(diǎn)，那么當(dāng)我們要做分層設(shè)計(jì)的時(shí)候，需要考慮哪些關(guān)鍵因素呢？

確定層次

在我看來(lái)，最主要的一點(diǎn)就是你需要理清楚每個(gè)層次的邊界是什么。你也許會(huì)問(wèn)：“如果按照三層架構(gòu)來(lái)分層的話，每一層的邊界不是很容易就界定嗎？”

沒(méi)錯(cuò)，當(dāng)業(yè)務(wù)邏輯簡(jiǎn)單時(shí)，層次之間的邊界的確清晰，開(kāi)發(fā)新的功能時(shí)也知道哪些代碼要往哪兒寫(xiě)。但是當(dāng)業(yè)務(wù)邏輯變得越來(lái)越復(fù)雜時(shí)，邊界就會(huì)變得越來(lái)越模糊。

定義接口

任何一個(gè)系統(tǒng)中都有用戶系統(tǒng)，最基本的接口是返回用戶信息的接口，它調(diào)用邏輯層的 GetUser 方法，GetUser 方法又和 User DB 交互獲取數(shù)據(jù)，就像下圖左邊展示的樣子。

這時(shí)，產(chǎn)品提出一個(gè)需求，在 APP 中展示用戶信息的時(shí)候，如果用戶不存在，那么要自動(dòng)給用戶創(chuàng)建一個(gè)用戶。同時(shí)，要做一個(gè) HTML5 的頁(yè)面，HTML5 頁(yè)面要保留之前的邏輯，也就是不需要?jiǎng)?chuàng)建用戶。這時(shí)邏輯層的邊界就變得不清晰，表現(xiàn)層也承擔(dān)了一部分的業(yè)務(wù)邏輯（將獲取用戶和創(chuàng)建用戶接口編排起來(lái)）。

遵循設(shè)計(jì)原則

使用設(shè)計(jì)原則如單一職責(zé)原則、依賴倒置原則等，確保每個(gè)層次都專注于一個(gè)特定的功能。這有助于確保系統(tǒng)的一致性和可維護(hù)性。

那我們要如何做呢？參照阿里發(fā)布的《阿里巴巴 Java 開(kāi)發(fā)手冊(cè) v1.4.0（詳盡版）》，我們可以將原先的三層架構(gòu)細(xì)化成下面的樣子：

我來(lái)解釋一下這個(gè)分層架構(gòu)中的每一層的作用。

• 終端顯示層：各端模板渲染并執(zhí)行顯示的層。當(dāng)前主要是 Velocity 渲染，JS 渲染， JSP 渲染，移動(dòng)端展示等。
• 開(kāi)放接口層：將 Service 層方法封裝成開(kāi)放接口，同時(shí)進(jìn)行網(wǎng)關(guān)安全控制和流量控制等。
• Web 層：主要是對(duì)訪問(wèn)控制進(jìn)行轉(zhuǎn)發(fā)，各類基本參數(shù)校驗(yàn)，或者不復(fù)用的業(yè)務(wù)簡(jiǎn)單處理等。
• Service 層：業(yè)務(wù)邏輯層。
• Manager 層：通用業(yè)務(wù)處理層。這一層主要有兩個(gè)作用，其一，你可以將原先 Service 層的一些通用能力下沉到這一層，比如與緩存和存儲(chǔ)交互策略，中間件的接入；其二，你也可以在這一層封裝對(duì)第三方接口的調(diào)用，比如調(diào)用支付服務(wù)，調(diào)用審核服務(wù)等。
• DAO 層：數(shù)據(jù)訪問(wèn)層，與底層 MySQL、Oracle、Hbase 等進(jìn)行數(shù)據(jù)交互。
• 外部接口或第三方平臺(tái)：包括其它部門(mén) RPC 開(kāi)放接口，基礎(chǔ)平臺(tái)，其它公司的 HTTP 接口。

在這個(gè)分層架構(gòu)中主要增加了 Manager 層，它與 Service 層的關(guān)系是：Manager 層提供原子的服務(wù)接口，Service 層負(fù)責(zé)依據(jù)業(yè)務(wù)邏輯來(lái)編排原子接口。

以上面的例子來(lái)說(shuō)，Manager 層提供創(chuàng)建用戶和獲取用戶信息的接口，而 Service 層負(fù)責(zé)將這兩個(gè)接口組裝起來(lái)。這樣就把原先散布在表現(xiàn)層的業(yè)務(wù)邏輯都統(tǒng)一到了 Service 層，每一層的邊界就非常清晰了。

除此之外，分層架構(gòu)需要考慮的另一個(gè)因素，是層次之間一定是相鄰層互相依賴，數(shù)據(jù)的流轉(zhuǎn)也只能在相鄰的兩層之間流轉(zhuǎn)。

我們還是以三層架構(gòu)為例，數(shù)據(jù)從表示層進(jìn)入之后一定要流轉(zhuǎn)到邏輯層，做業(yè)務(wù)邏輯處理，然后流轉(zhuǎn)到數(shù)據(jù)訪問(wèn)層來(lái)和數(shù)據(jù)庫(kù)交互。那么你可能會(huì)問(wèn)：“如果業(yè)務(wù)邏輯很簡(jiǎn)單的話可不可以從表示層直接到數(shù)據(jù)訪問(wèn)層，甚至直接讀數(shù)據(jù)庫(kù)呢？”

其實(shí)從功能上是可以的，但是從長(zhǎng)遠(yuǎn)的架構(gòu)設(shè)計(jì)考慮，這樣會(huì)造成層級(jí)調(diào)用的混亂，比方說(shuō)如果表示層或者業(yè)務(wù)層可以直接操作數(shù)據(jù)庫(kù)，那么一旦數(shù)據(jù)庫(kù)地址發(fā)生變更，你就需要在多個(gè)層次做更改，這樣就失去了分層的意義，并且對(duì)于后面的維護(hù)或者重構(gòu)都會(huì)是災(zāi)難性的。

---

四、分層架構(gòu)的不足

任何事物都不可能是盡善盡美的，分層架構(gòu)雖有優(yōu)勢(shì)也會(huì)有缺陷。

復(fù)雜性問(wèn)題

它最主要的一個(gè)缺陷就是增加了代碼的復(fù)雜度。這是顯而易見(jiàn)的嘛，明明可以在接收到請(qǐng)求后就可以直接查詢數(shù)據(jù)庫(kù)獲得結(jié)果，卻偏偏要在中間插入多個(gè)層次，并且有可能每個(gè)層次只是簡(jiǎn)單地做數(shù)據(jù)的傳遞。有時(shí)增加一個(gè)小小的需求也需要更改所有層次上的代碼，看起來(lái)增加了開(kāi)發(fā)的成本，并且從調(diào)試上來(lái)看也增加了復(fù)雜度，原本如果直接訪問(wèn)數(shù)據(jù)庫(kù)我只需要調(diào)試一個(gè)方法，現(xiàn)在我卻要調(diào)試多個(gè)層次的多個(gè)方法。

性能問(wèn)題

另外一個(gè)可能的缺陷是，如果我們把每個(gè)層次獨(dú)立部署，層次間通過(guò)網(wǎng)絡(luò)來(lái)交互，那么多層的架構(gòu)在性能上會(huì)有損耗。這也是為什么服務(wù)化架構(gòu)性能要比單體架構(gòu)略差的原因，也就是所謂的**“多一跳”**問(wèn)題。

靈活性問(wèn)題

過(guò)于剛性的分層結(jié)構(gòu)可能使系統(tǒng)難以適應(yīng)變化。在一些需求頻繁變更的項(xiàng)目中，可能需要更靈活的架構(gòu)設(shè)計(jì)。

---

那我們是否要選擇分層的架構(gòu)呢？答案當(dāng)然是肯定的。

你要知道，任何的方案架構(gòu)都是有優(yōu)勢(shì)有缺陷的，天地尚且不全何況我們的架構(gòu)呢？分層架構(gòu)固然會(huì)增加系統(tǒng)復(fù)雜度，也可能會(huì)有性能的損耗，但是相比于它能帶給我們的好處來(lái)說(shuō)，這些都是可以接受的，或者可以通過(guò)其它的方案解決的。我們?cè)谧鰶Q策的時(shí)候切不可以偏概全，因噎廢食。

---

五、回顧&小結(jié)

在系統(tǒng)設(shè)計(jì)中，分層架構(gòu)是一種強(qiáng)大而常見(jiàn)的設(shè)計(jì)模式。它通過(guò)將系統(tǒng)劃分為不同的層次，每個(gè)層次專注于特定功能，提高了系統(tǒng)的可維護(hù)性、可擴(kuò)展性和模塊化。

分層架構(gòu)有著多種形式，如MVC、OSI網(wǎng)絡(luò)模型、TCP/IP協(xié)議等，適用于不同領(lǐng)域和問(wèn)題。這種設(shè)計(jì)模式的優(yōu)勢(shì)包括模塊化、復(fù)用性和橫向擴(kuò)展的便利性。

然而，分層架構(gòu)也存在一些缺陷，包括增加代碼復(fù)雜性、性能損耗以及過(guò)于剛性可能導(dǎo)致難以適應(yīng)變化。在選擇架構(gòu)時(shí)，需要權(quán)衡各方面的利弊，根據(jù)項(xiàng)目需求和特點(diǎn)做出明智的決策。

分層架構(gòu)是項(xiàng)目中用到的最多的架構(gòu)模式之一，核心思想是歸類和解耦，實(shí)現(xiàn)有多種方式，不應(yīng)局限于三層，四層，也可能是兩層，五層，六層，具體以實(shí)際的項(xiàng)目為準(zhǔn)。

實(shí)際每一層還會(huì)有一些變化，不同的設(shè)計(jì)模式和架構(gòu)模式實(shí)現(xiàn)的分層和代碼的組織方式也是不同的，沒(méi)有完全一樣的架構(gòu)，合適的就是最好的。

總體而言，分層架構(gòu)為軟件系統(tǒng)提供了一種有力的組織和設(shè)計(jì)方式，為系統(tǒng)的健壯性和可維護(hù)性奠定了基礎(chǔ)。