自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

單體分層應(yīng)用架構(gòu)剖析

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

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

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

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

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

  • 展現(xiàn)層:負(fù)責(zé)給最終用戶展現(xiàn)信息,并接受用戶的輸入觸發(fā)系統(tǒng)的業(yè)務(wù)邏輯。用戶可以是使用系統(tǒng)的人,也可以是其他軟件系統(tǒng)。
  • 業(yè)務(wù)層:關(guān)注系統(tǒng)業(yè)務(wù)邏輯的實(shí)現(xiàn)
  • 持久層:負(fù)責(zé)數(shù)據(jù)的存取
  • 數(shù)據(jù)存儲層:底層的數(shù)據(jù)存儲設(shè)施

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

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

  • 關(guān)注點(diǎn)隔離:通過分層將系統(tǒng)的關(guān)注點(diǎn)進(jìn)行垂直分配,每層只關(guān)注自身層邊界內(nèi)的職責(zé),層間職責(zé)相互獨(dú)立不存在交叉。比如業(yè)務(wù)層負(fù)責(zé)處理系統(tǒng)的核心業(yè)務(wù)邏輯,而持久層則關(guān)注于對數(shù)據(jù)的存取。
  • 除了關(guān)注點(diǎn)隔離這一維度,分層也在 “變化” 的維度進(jìn)行隔離。每層的變化速率不同,由下級上逐層增加,展現(xiàn)層的變化速率最快,數(shù)據(jù)存儲層變化速率最低。通過嚴(yán)格層依賴關(guān)系約束,盡量降低低層變化對上層的影響。這個特點(diǎn)的上下文是分層之間依賴于抽象,而非依賴于具體。當(dāng)實(shí)現(xiàn)發(fā)生變化而接口契約不變時(shí),變更范圍框定在當(dāng)前層。但,如果是接口契約的變更,則可能會直接影響到上游的依賴層。

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

  • 分層模型比較簡單,理解和實(shí)現(xiàn)成本低
  • 開放人員接受度和熟悉程度高,認(rèn)知和學(xué)習(xí)成本低

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

四層架構(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ù)用性。其特點(diǎn)是:

  • 引入通用服務(wù)層提供通用服務(wù),提高復(fù)用性
  • 通用服務(wù)層是開放層,允許調(diào)用鏈路穿透,業(yè)務(wù)層可以按需直接訪問更下層的持久層

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

  • 引入中間層降低了數(shù)據(jù)傳輸效率,提高了開發(fā)實(shí)現(xiàn)成本
  • 有造成系統(tǒng)混亂度提升的風(fēng)險(xiǎn):由于通用服務(wù)層的開放性導(dǎo)致業(yè)務(wù)層可以穿透調(diào)用。但這種是否需要進(jìn)行穿透的場景無法形成統(tǒng)一的判定原則,往往依賴于實(shí)現(xiàn)人員的個人經(jīng)驗(yàn)進(jìn)行權(quán)衡,同一個業(yè)務(wù)場景由不同的開發(fā)人員實(shí)現(xiàn)可能會有不同的判定結(jié)果(在四層架構(gòu)中如果放開層間調(diào)用約束也會存在該問題)。隨著業(yè)務(wù)需求迭代,系統(tǒng)的依賴關(guān)系一定會日趨增加,最終形成復(fù)雜的調(diào)用關(guān)系,也導(dǎo)致系統(tǒng)復(fù)雜性上升,增加團(tuán)隊(duì)成員的認(rèn)知成本。

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

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

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

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

  • 分層對系統(tǒng)復(fù)雜度和效率的影響
  • 變化真的能完全隔離嗎?
  • 問題域與解決方案的隔離

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

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

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

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

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

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

注:層間的依賴約束是一種架構(gòu)決策,可以考慮通過自動化單元測試機(jī)制進(jìn)行保證,具體參考:

《 基于ArchUnit守護(hù)系統(tǒng)架構(gòu) 》

《 輕量級的架構(gòu)決策記錄機(jī)制 - ADR》

2.2 變化的隔離

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

  • 你真的會替換數(shù)據(jù)庫嗎?你真的會替換ORM框架嗎?有可能,但概率非常低,大部分系統(tǒng)并不會發(fā)生這種場景。
  • 發(fā)生替換就真的能隔離嗎?如果你的層間不是依賴于抽象,而是依賴于具體,那么隔離也無從談起。
  • 即使層間依賴于抽象,變化就真的隔離了嗎?實(shí)現(xiàn)發(fā)生變化的直接結(jié)果就是依賴方需要引用新的實(shí)現(xiàn),這種變化也同樣會影響到上層。只不過是這種變化可能交由IOC容器了

但,這個是變化隔離的全部嗎?

  • 如果是展現(xiàn)層需要增加一個新的字段,而當(dāng)前數(shù)據(jù)庫模型中沒有?
  • 如果是數(shù)據(jù)庫中需要增加一個新的字段,而展現(xiàn)層和業(yè)務(wù)邏輯層不關(guān)心?
  • 如果是......

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

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

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

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

技術(shù)視角的隔離?。?!

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

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

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

  • OrderConroller:Spring技術(shù)棧下的系統(tǒng)訪問的Rest接口
  • OrderService/OrderServiceImpl:訂單的核心業(yè)務(wù)邏輯實(shí)現(xiàn)服務(wù),實(shí)現(xiàn)諸如下單、取消訂單等邏輯
  • OrderDAO/OrdeDAOImpl:訂單數(shù)據(jù)的存取

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

  • 首先,在工程頂層最先看到的是技術(shù)視角的Module(Maven Module):web、service 、dao
  • 然后,需要在各層導(dǎo)航才能一窺其全貌

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

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

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

將組件化思維應(yīng)用于單體分層架構(gòu),引申出模塊化單體架構(gòu)風(fēng)格。應(yīng)用架構(gòu)按照問題域進(jìn)行模塊化組織,而非基于技術(shù)關(guān)注點(diǎn)進(jìn)行拆分。組件內(nèi)部遵循內(nèi)聚性原則,其內(nèi)包含了實(shí)現(xiàn)組件能力所需要的各個元素及交互關(guān)系。組件之間通過統(tǒng)一的、合適粒度的接口契約進(jìn)行交互,不直接依賴于組件的內(nèi)部能力或模型。同時(shí),組織良好的模塊化單體應(yīng)用架構(gòu)也是進(jìn)行微服務(wù)拆分的重要保證。如果你無法在單體架構(gòu)中進(jìn)行優(yōu)雅的模塊化組織,又何談合理的微服務(wù)拆分呢?

3、結(jié)語

單體分層架構(gòu)風(fēng)格是分層思想在單體架構(gòu)中的應(yīng)用,其關(guān)注于技術(shù)視角的職責(zé)分層。同時(shí),基于不同層變化速率的不同,在一定程度上控制變化在系統(tǒng)內(nèi)的傳播,有助于提升系統(tǒng)的穩(wěn)定性。但這種技術(shù)視角而非業(yè)務(wù)視角的關(guān)注點(diǎn)隔離,導(dǎo)致了問題域與工程實(shí)現(xiàn)之間的Gap,這種割裂會導(dǎo)致系統(tǒng)認(rèn)知復(fù)雜度的提升。將組件化思維應(yīng)用于單體分層架構(gòu),模塊化單體技術(shù)視角的分層拉回至業(yè)務(wù)域視角的模塊化,一定程度上降低業(yè)務(wù)與工程實(shí)現(xiàn)間的隔離。良好的模塊化是單體走向微服務(wù)的重要基石,如果模塊化設(shè)計(jì)較差的系統(tǒng),不僅會增加微服務(wù)拆分的成本,更為重要的是,會增加形成分布式單體的概率和風(fēng)險(xiǎn)。

責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2021-03-16 06:38:44

架構(gòu)分層插件化

2023-08-02 08:51:46

服務(wù)架構(gòu)分層架構(gòu)

2023-02-27 16:24:17

架構(gòu)開發(fā)數(shù)字化

2021-03-26 07:47:18

單體架構(gòu)程序

2023-12-09 14:33:05

2023-06-16 13:34:00

軟件架構(gòu)模式

2022-12-21 16:13:31

微服務(wù)架構(gòu)

2023-01-05 08:12:11

分層應(yīng)用代碼

2021-12-24 07:10:36

架構(gòu)分層模塊化

2024-02-05 08:11:30

架構(gòu)模式單體

2022-04-28 11:04:27

架構(gòu)微服務(wù)技術(shù)

2023-11-01 11:17:26

單體架構(gòu)微服務(wù)架構(gòu)

2024-11-19 08:10:00

2024-01-19 11:57:42

2016-06-07 16:43:57

云計(jì)算混合云

2017-11-17 07:06:27

互聯(lián)網(wǎng)分層架構(gòu)APP

2019-12-10 10:59:11

分層架構(gòu)項(xiàng)目

2015-09-22 09:17:19

2023-05-31 08:41:23

分層架構(gòu)對象模型

2023-06-09 14:01:00

架構(gòu)程序APP
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號