分層單體架構(gòu)系統(tǒng)的風格及其本質(zhì)

分層單體架構(gòu)風格是分層思想在單體架構(gòu)中的應(yīng)用，其關(guān)注于技術(shù)視角的職責分層。

同時，基于不同層變化速率的不同，在一定程度上控制變化在系統(tǒng)內(nèi)的傳播，有助于提升系統(tǒng)的穩(wěn)定性。

但這種技術(shù)視角而非業(yè)務(wù)視角的關(guān)注點隔離，導(dǎo)致了問題域與工程實現(xiàn)之間的Gap，這種割裂會導(dǎo)致系統(tǒng)認知復(fù)雜度的提升。

1 經(jīng)典單體分層架構(gòu)

1.1 四層單體架構(gòu)風格

經(jīng)典的四層單體分層架構(gòu)如下圖所示，應(yīng)用在邏輯上劃分為展現(xiàn)層、業(yè)務(wù)層、持久層及數(shù)據(jù)存儲層，每層的職責如下：

展現(xiàn)層：負責給最終用戶展現(xiàn)信息，并接受用戶的輸入觸發(fā)系統(tǒng)的業(yè)務(wù)邏輯。用戶可以是使用系統(tǒng)的人，也可以是其他軟件系統(tǒng)。

業(yè)務(wù)層：關(guān)注系統(tǒng)業(yè)務(wù)邏輯的實現(xiàn)

持久層：負責數(shù)據(jù)的存取

數(shù)據(jù)存儲層：底層的數(shù)據(jù)存儲設(shè)施

這種分層單體架構(gòu)可能是大多數(shù)開發(fā)人員最早接觸、最為熟悉的應(yīng)用架構(gòu)風格，其特點是：

層間的依賴關(guān)系由上到下逐層向下直接依賴，每層都是關(guān)閉狀態(tài)，請求的數(shù)據(jù)流向從上到下，必須嚴格通過每個分層進行流轉(zhuǎn)，而不能進行穿透調(diào)用。

關(guān)注點隔離：通過分層將系統(tǒng)的關(guān)注點進行垂直分配，每層只關(guān)注自身層邊界內(nèi)的職責，層間職責相互獨立不存在交叉。比如業(yè)務(wù)層負責處理系統(tǒng)的核心業(yè)務(wù)邏輯，而持久層則關(guān)注于對數(shù)據(jù)的存取。

除了關(guān)注點隔離這一維度，分層也在 “變化” 的維度進行隔離。每層的變化速率不同，由下級上逐層增加，展現(xiàn)層的變化速率最快，數(shù)據(jù)存儲層變化速率最低。

通過嚴格層依賴關(guān)系約束，盡量降低低層變化對上層的影響。這個特點的上下文是分層之間依賴于抽象，而非依賴于具體。

當實現(xiàn)發(fā)生變化而接口契約不變時，變更范圍框定在當前層。但，如果是接口契約的變更，則可能會直接影響到上游的依賴層。

這種分層架構(gòu)風格具有明顯的優(yōu)勢：

分層模型比較簡單，理解和實現(xiàn)成本低

開放人員接受度和熟悉程度高，認知和學習成本低

1.2 五層單體架構(gòu)風格

四層架構(gòu)面臨的問題是:

層間數(shù)據(jù)效率問題: 由于層間調(diào)用關(guān)系的依賴約束，層間的數(shù)據(jù)流轉(zhuǎn)需要付出額外成本

業(yè)務(wù)層服務(wù)能力的復(fù)用性：業(yè)務(wù)層中處于對等地位的組件或模塊之間存在共享服務(wù)的訴求

從復(fù)用性的角度考慮，如下所示的五層架構(gòu)中，通過引入中間層解決復(fù)用問題。將共享服務(wù)從業(yè)務(wù)層沉淀到通用服務(wù)層，以提高復(fù)用性。其特點是：

引入通用服務(wù)層提供通用服務(wù)，提高復(fù)用性

通用服務(wù)層是開放層，允許調(diào)用鏈路穿透，業(yè)務(wù)層可以按需直接訪問更下層的持久層

相比于四層架構(gòu)，五層分層架構(gòu)的主要優(yōu)勢是：通過中間層的引入一定程度解決系統(tǒng)的復(fù)用性問題。但從反向角度看，正是由于中間層的引入導(dǎo)致了如下問題：

引入中間層降低了數(shù)據(jù)傳輸效率，提高了開發(fā)實現(xiàn)成本

有造成系統(tǒng)混亂度提升的風險：由于通用服務(wù)層的開放性導(dǎo)致業(yè)務(wù)層可以穿透調(diào)用。

但這種是否需要進行穿透的場景無法形成統(tǒng)一的判定原則，往往依賴于實現(xiàn)人員的個人經(jīng)驗進行權(quán)衡，同一個業(yè)務(wù)場景由不同的開發(fā)人員實現(xiàn)可能會有不同的判定結(jié)果（在四層架構(gòu)中如果放開層間調(diào)用約束也會存在該問題）。隨著業(yè)務(wù)需求迭代，系統(tǒng)的依賴關(guān)系一定會日趨增加，最終形成復(fù)雜的調(diào)用關(guān)系，也導(dǎo)致系統(tǒng)復(fù)雜性上升，增加團隊成員的認知成本。

2 單體分層架構(gòu)的共性問題探討

當然，正是由于其極高的接受度，也造成了大家對分層的認知誤區(qū)，認為分層是必然的“默認選項” ，從而忽略了分層的本質(zhì)。分層到底是為了解決什么問題？

分層本質(zhì)上是處理復(fù)雜性的一種方式：將復(fù)雜性在不同級別進行抽象，通過分層進行職責隔離，以此降低認知成本。同時，通過分層形成的“屏障”，控制變化在系統(tǒng)間的傳播，提升系統(tǒng)穩(wěn)定性。

不論是四層架構(gòu)還是五層架構(gòu)都是分層思想在單體應(yīng)用架構(gòu)風格下的實踐，這種分層模式存在的固有問題主要體現(xiàn)在以下幾個方面：

分層對系統(tǒng)復(fù)雜度和效率的影響

變化真的能完全隔離嗎？

問題域與解決方案的隔離

2.1 分層對系統(tǒng)復(fù)雜度和效率的影響

如上文所述，分層架構(gòu)中各層的變化速度不同。越往上變化越快，穩(wěn)定性越低，越往下變化越慢，穩(wěn)定性越高。比如，展現(xiàn)層的用戶展示邏輯可能頻繁變化，對應(yīng)于不同的場景訴求展示數(shù)據(jù)及形式都可能不同。

如果劃分層次越多，層間依賴關(guān)系越嚴格，則系統(tǒng)的調(diào)用鏈路和依賴關(guān)系會更加清晰。但，請求及響應(yīng)的鏈路越長，層間數(shù)據(jù)轉(zhuǎn)換有額外成本。即使引入各種數(shù)據(jù)轉(zhuǎn)換工具，比如MapStruct，實現(xiàn)起來依然會感覺非常繁瑣和重復(fù)。

如果劃分層次越多，層間依賴關(guān)系寬松，允許跨層調(diào)用（如下所示的從展現(xiàn)層調(diào)用持久層只是一個示意），則能在一定程度降低數(shù)據(jù)頻繁轉(zhuǎn)換的成本。但:

其一：如何判定是否要跨層調(diào)用很難形成統(tǒng)一的嚴格判定標準，只能進行粗粒度劃分。因此，在實現(xiàn)過程中會有不同的判定結(jié)果，系統(tǒng)的調(diào)用關(guān)系會隨著代碼規(guī)模增長而日趨復(fù)雜。當然，團隊可以加強代碼評審的粒度，每次評審基于是否穿透調(diào)用進行討論、判斷并達成一致。但實際經(jīng)驗是，由于人為因素，靠嚴格的代碼評審并不能保證決策的一致性。

其二：如果允許跨層調(diào)用，則意味著 “模型” 的穿透，低層的模型會直接暴露在更上層，這與我們追求的組件內(nèi)聚性和模型的封裝性存在沖突

注：層間的依賴約束是一種架構(gòu)決策，可以考慮通過自動化單元測試機制進行保證

2.2 變化的隔離

我們對分層有一個普遍的、“先入為主” 的認知，分層能夠隔離變化。首先會想到的例子，比如，如果底層的數(shù)據(jù)庫發(fā)生了變更，又或者ORM框架發(fā)生了變更，那么，我們只需要修改DAO層的實現(xiàn)，而不需要更改上層的業(yè)務(wù)層代碼。

你真的會替換數(shù)據(jù)庫嗎？你真的會替換ORM框架嗎？有可能，但概率非常低，大部分系統(tǒng)并不會發(fā)生這種場景。

發(fā)生替換就真的能隔離嗎？如果你的層間不是依賴于抽象，而是依賴于具體，那么隔離也無從談起。

即使層間依賴于抽象，變化就真的隔離了嗎？實現(xiàn)發(fā)生變化的直接結(jié)果就是依賴方需要引用新的實現(xiàn)，這種變化也同樣會影響到上層。只不過是基于現(xiàn)在的普遍技術(shù)棧，這種變化交由IOC容器了

但，這個變化隔離的全部嗎？

如果是展現(xiàn)層需要增加一個新的字段，而當前數(shù)據(jù)庫模型中沒有？

如果是數(shù)據(jù)庫中需要增加一個新的字段，而展現(xiàn)層和業(yè)務(wù)邏輯層不關(guān)心？

如果是......

所以，引起系統(tǒng)變化的原因很多，場景各異，業(yè)務(wù)訴求亦不相同，分層對變化隔離程度也不相同：

分層可以控制變化在系統(tǒng)內(nèi)的傳播，由于變化場景的多樣化，分層不能完全的隔離變化。

2.3 問題域與解決方案的割裂

重新思考下上文提到的分層單體架構(gòu)的特點之一：關(guān)注點隔離，展現(xiàn)層、業(yè)務(wù)層、數(shù)據(jù)訪問層、存儲層等各層聚焦于自身的職責。這種關(guān)注點的本質(zhì)是什么？

技術(shù)視角的隔離！?。?/p>

每層都是從技術(shù)視角將技術(shù)關(guān)注點進行隔離，而非業(yè)務(wù)領(lǐng)域視角。技術(shù)視角是研發(fā)友好的，作為開發(fā)人員，天然的可以理解和接受這種技術(shù)維度的統(tǒng)一語言：DAO層只負責處理數(shù)據(jù)相關(guān)邏輯，Controller層之服務(wù)處理Restful API相關(guān)，RPC層只處理與外部系統(tǒng)的跨進程調(diào)用等等。

而對于非常核心的業(yè)務(wù)概念，比如以訂單為例，在單體分層架構(gòu)下需要回答這樣一個問題：“訂單組件” 在哪里？

在經(jīng)典的分層單體架構(gòu)風格中，典型的實現(xiàn)如下圖所示：

OrderConroller：Spring技術(shù)棧下的系統(tǒng)訪問的Rest接口

OrderService/OrderServiceImpl：訂單的核心業(yè)務(wù)邏輯實現(xiàn)服務(wù)，實現(xiàn)諸如下單、取消訂單等邏輯

OrderDAO/OrdeDAOImpl：訂單數(shù)據(jù)的存取

訂單組件并不是以一個單一的、內(nèi)聚的事物存在，其組成元素OrderService以及其依賴的OrderDAO分散于不同的層，因此，這種模式下訂單組件只是邏輯性、概念性的存在。作為業(yè)務(wù)域的核心抽象，訂單組件沒有真實的、直觀的、內(nèi)聚的反映在代碼實現(xiàn)中。我們在工程代碼庫中尋找“訂單組件”：

首先，在工程頂層最先看到的是技術(shù)視角的Module(Maven Module)：web、service 、dao

然后，需要在各層導(dǎo)航才能一窺其全貌

在IDE的支持下，這種導(dǎo)航并不會很復(fù)雜。但問題的根本在于：認知成本的增加。

我們?nèi)チ私庀到y(tǒng)，天然的是從業(yè)務(wù)域而非技術(shù)域出發(fā)，單體分層恰恰是從技術(shù)域而非業(yè)務(wù)域出發(fā)，這種不同導(dǎo)致業(yè)務(wù)域與實現(xiàn)間的割裂，增加了對系統(tǒng)的認知成本。

實現(xiàn)要反應(yīng)抽象，組件化思維本質(zhì)上一種模塊化思維，通過內(nèi)聚性和封裝性，將問題空間進行拆分成子空間，分而治之。對外通過接口提供組件能力，屏蔽內(nèi)部的復(fù)雜性。接口契約的大小粒度需要權(quán)衡，粒度越小，能力提供越約聚焦，理解和接入成本越低，但通用性越差。接口契約粒度越大，則通用性越強，但理解和接入復(fù)雜性越高。

將組件化思維應(yīng)用于單體分層架構(gòu)，引申出模塊化單體架構(gòu)風格。應(yīng)用架構(gòu)按照問題域進行模塊化組織，而非基于技術(shù)關(guān)注點進行拆分。組件內(nèi)部遵循內(nèi)聚性原則，其內(nèi)包含了實現(xiàn)組件能力所需要的各個元素及交互關(guān)系。組件之間通過統(tǒng)一的、合適粒度的接口契約進行交互，不直接依賴于組件的內(nèi)部能力或模型。

同時，組織良好的模塊化單體應(yīng)用架構(gòu)也是進行微服務(wù)拆分的重要保證。如果你無法在單體架構(gòu)中進行優(yōu)雅的模塊化組織，又何談合理的微服務(wù)拆分呢？

3 結(jié)語

單體分層架構(gòu)風格是分層思想在單體架構(gòu)中的應(yīng)用，其關(guān)注于技術(shù)視角的職責分層。同時，基于不同層變化速率的不同，在一定程度上控制變化在系統(tǒng)內(nèi)的傳播，有助于提升系統(tǒng)的穩(wěn)定性。但這種技術(shù)視角而非業(yè)務(wù)視角的關(guān)注點隔離，導(dǎo)致了問題域與工程實現(xiàn)之間的Gap，這種割裂會導(dǎo)致系統(tǒng)認知復(fù)雜度的提升。

將組件化思維應(yīng)用于單體分層架構(gòu)，模塊化單體技術(shù)視角的分層拉回至業(yè)務(wù)域視角的模塊化，一定程度上降低了業(yè)務(wù)于工程實現(xiàn)間的隔離。良好的模塊化是單體走向微服務(wù)的重要基石，如果模塊化設(shè)計較差的系統(tǒng)，不僅會增加微服務(wù)拆分的成本，更為重要的是，會增加拆分后形成分布式單體的概率和風險。

審核編輯：劉清