偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

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

開(kāi)發(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)致了問(wèn)題域與工程實(shí)現(xiàn)之間的Gap,這種割裂會(huì)導(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)致了問(wèn)題域與工程實(shí)現(xiàn)之間的Gap,這種割裂會(huì)導(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ù)存儲(chǔ)層,每層的職責(zé)如下:

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

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

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

  • 關(guān)注點(diǎn)隔離:通過(guò)分層將系統(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)注于對(duì)數(shù)據(jù)的存取。
  • 除了關(guān)注點(diǎn)隔離這一維度,分層也在 “變化” 的維度進(jìn)行隔離。每層的變化速率不同,由下級(jí)上逐層增加,展現(xiàn)層的變化速率最快,數(shù)據(jù)存儲(chǔ)層變化速率最低。通過(guò)嚴(yán)格層依賴(lài)關(guān)系約束,盡量降低低層變化對(duì)上層的影響。這個(gè)特點(diǎn)的上下文是分層之間依賴(lài)于抽象,而非依賴(lài)于具體。當(dāng)實(shí)現(xiàn)發(fā)生變化而接口契約不變時(shí),變更范圍框定在當(dāng)前層。但,如果是接口契約的變更,則可能會(huì)直接影響到上游的依賴(lài)層。

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

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

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

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

  • 層間數(shù)據(jù)效率問(wèn)題: 由于層間調(diào)用關(guān)系的依賴(lài)約束,層間的數(shù)據(jù)流轉(zhuǎn)需要付出額外成本
  • 業(yè)務(wù)層服務(wù)能力的復(fù)用性:業(yè)務(wù)層中處于對(duì)等地位的組件或模塊之間存在共享服務(wù)的訴求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2 變化的隔離

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

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

但,這個(gè)是變化隔離的全部嗎?

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

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

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

2.3 問(wèn)題域與解決方案的割裂

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

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

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

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

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

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

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

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

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

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

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

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

3、結(jié)語(yǔ)

單體分層架構(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)致了問(wèn)題域與工程實(shí)現(xiàn)之間的Gap,這種割裂會(huì)導(dǎo)致系統(tǒng)認(rèn)知復(fù)雜度的提升。將組件化思維應(yīng)用于單體分層架構(gòu),模塊化單體技術(shù)視角的分層拉回至業(yè)務(wù)域視角的模塊化,一定程度上降低業(yè)務(wù)與工程實(shí)現(xiàn)間的隔離。良好的模塊化是單體走向微服務(wù)的重要基石,如果模塊化設(shè)計(jì)較差的系統(tǒng),不僅會(huì)增加微服務(wù)拆分的成本,更為重要的是,會(huì)增加形成分布式單體的概率和風(fēng)險(xiǎn)。

責(zé)任編輯:武曉燕 來(lái)源: 今日頭條
相關(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)開(kāi)發(fā)數(shù)字化

2023-12-09 14:33:05

2021-03-26 07:47:18

單體架構(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)模式單體

2023-06-16 13:34:00

軟件架構(gòu)模式

2022-12-21 16:13:31

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

2022-04-28 11:04:27

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

2024-11-19 08:10:00

2023-11-01 11:17:26

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

2010-02-23 09:34:15

WCF重載

2015-09-22 09:17:19

2022-04-29 14:56:40

通話(huà)應(yīng)用源碼剖析

2010-01-25 17:43:13

Android資源

2023-12-18 14:56:00

模塊化單體系統(tǒng)數(shù)據(jù)庫(kù)

2024-01-19 11:57:42

2023-05-31 08:41:23

分層架構(gòu)對(duì)象模型
點(diǎn)贊
收藏

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