...

軟件架構設計分層模型和構圖思考

2022-03-21

架構思維概述


對(duì)于架構思維本身仍然是類似系統思維,結構化思維,編程思維等諸多思維模式的一個合集。由于架構的核心作用是在業務現實世界和抽象的IT實現之間建立起(qǐ)一道(dào)橋梁,因此架構思維最核心的就(jiù)是要理解到業務驅動技術,技術爲最終的業務服務。要真正通過(guò)架構設計來完成(chéng)業務和技術,需求和實現,軟件和硬件,靜态和動态,成(chéng)本和收益等多方面(miàn)的平衡。

圖片

架構設計中有兩(liǎng)個重點,一個是分解,一個是集成(chéng)。

分解是最基礎的,架構的重點就(jiù)是要對(duì)複雜問題進(jìn)行分而治之,同時(shí)保證分解後(hòu)的各個部分還(hái)能(néng)夠高内聚,松耦合,最終又集成(chéng)爲一個完整的整體。分解核心是定義問題,因此架構首先仍然需要理解清楚需求。

集成(chéng)是配合分解完成(chéng)的動作,最終分解完成(chéng)的各個組件或子系統,通過(guò)合适的接口設計,最終還(hái)能(néng)夠集成(chéng)爲一個完整的整體,分解僅僅是加速開(kāi)發(fā)和降低問題複雜度,如果分解後(hòu)的内容無法集成(chéng)在一起(qǐ),那麼(me)分解就(jiù)沒(méi)有任何意義。

分解+集成(chéng)可以理解爲架構最核心的思考方式和方法。

在分解完成(chéng)後(hòu),一個大的系統已經(jīng)拆分爲了諸多的小模塊,或者一個小模塊實現本身又分爲了多個步驟階段。那麼(me)零散的節點必須向(xiàng)上彙集和歸納,形成(chéng)一個完整的架構。

而這(zhè)個架構的形成(chéng)要給關鍵就(jiù)是要又分層思維。架構分層是談架構絕對(duì)繞不開(kāi)的一個點,通過(guò)架構分層可以更好(hǎo)地全面(miàn)理解業務系統或功能(néng)實現。




雲平台三層架構:資源-平台-應用


在規劃大架構的時(shí)候,常會(huì)參考雲計算的标準三層架構,即IaaS層,PaaS層,SaaS層。對(duì)于IaaS層重點是IT基礎設施和虛拟化;PaaS層重點是構建平台層服務能(néng)力;而對(duì)于SaaS層則是具體的應用。

對(duì)于資源層從物理資源,再到虛拟化邏輯資源,從虛拟機到現在更加輕量的容器資源。而對(duì)于平台層原來隻談技術平台,但是當前又進(jìn)一步拆分出業務平台,也可以理解成(chéng)當前說(shuō)得比較多的中台層。

同時(shí)在平台層和應用層之間增加了服務層,實現資源和服務的解耦。

圖片

如果涉及到物聯網類應用,一般還(hái)會(huì)在底層增加網絡層和感知層,比如一個智慧城市标準平台和應用的架構圖類似如下:

圖片

在平台+應用構建模式下,一般在平台和應用之間還(hái)會(huì)有一個單獨的服務層來實現接口服務對(duì)外的能(néng)力開(kāi)放。資源+服務+應用也是我們常說(shuō)的SOA分層架構模式,因此對(duì)于服務層也可以單獨拆分出來作爲一個小分層。

圖片

問題1:數據庫和數據層

在構建一個完整的總體架構的時(shí)候,實際上沒(méi)有數據層這(zhè)個概念,數據層是在表達單個應用系統的分層架構實現的時(shí)候才會(huì)出現的内容。

在總架構圖裡(lǐ)面(miàn)把類似結構化數據庫,非結構化數據等全部列出單獨一層這(zhè)個也不對(duì),這(zhè)個應該是在技術架構裡(lǐ)面(miàn)體現。

還(hái)有一種(zhǒng)是單獨分出一個數據層,將(jiāng)大的公共基礎數據列出,比如上面(miàn)談的智慧城市架構圖。如果這(zhè)些基礎數據存在共性能(néng)力朝上提供,那麼(me)可以歸納到PaaS平台層,在PaaS平台層單獨分出一個數據平台域來進(jìn)行體現。

問題2:服務層和服務

在構建整體架構的時(shí)候可以單獨出一個能(néng)力開(kāi)放平台或服務層,但是不用體現具體有哪些業務服務能(néng)力。因爲單獨出業務服務能(néng)力本質已經(jīng)屬于應用層内容,即應用又細化拆分爲了業務中台和前台應用,中間銜接的服務。我們可以參考網上的另外一個構圖,如下:

圖片

這(zhè)個構圖既不像雲平台中的分層架構,也不像應用功能(néng)實現中的分層架構。實際可以看到如果體現單獨的支撐層,支撐層已經(jīng)類似現在經(jīng)常說(shuō)到的業務中台和能(néng)力提供。

那麼(me)整個架構應該爲 技術平台+中台+應用 方式來進(jìn)行構圖。




SOA分層:組件-服務-流程


對(duì)于SOA架構分層,重點要體現的就(jiù)是服務,對(duì)于組件本身是屬于邏輯資源層的概念,而對(duì)于服務則是資源對(duì)外暴露的能(néng)力抽象。

圖片

SOA架構分層重點就(jiù)是要體現出獨立的服務層,注意不是畫服務總線,這(zhè)裡(lǐ)可以單獨畫出具體提供哪些業務服務能(néng)力,技術服務能(néng)力。在采用SOA架構進(jìn)行開(kāi)發(fā)的時(shí)候,整體業務系統拆分爲4個組件,10類服務域,5類流程,那麼(me)在構建的時(shí)候重點就(jiù)是將(jiāng)上述組件,服務域和流程類體現出來。對(duì)于參考SOA架構來進(jìn)行的構圖,參考如下:

圖片

這(zhè)裡(lǐ)的數據層最好(hǎo)改爲标準的組件層,更加貼近SOA架構模型。在圖中的服務層已經(jīng)可以看到一個個獨立的API服務接口。如果服務接口數據大,一般隻會(huì)劃分到服務域,比如用戶中心服務,采購類服務等。在這(zhè)種(zhǒng)方式下構圖參考如下:

圖片

在上圖中結合了雲和SOA兩(liǎng)種(zhǒng)架構融合在一起(qǐ),對(duì)于上圖中的服務層實際可以理解爲組件資源層和服務接口層的融合。更好(hǎo)的構圖方式應該是拆分爲标準的中台資源層-服務層-應用層。




雲和SOA架構融合


圖片

注意對(duì)于雲分層架構重點強調的是基礎設施,平台和應用三層架構。而對(duì)于SOA架構強調的是資源,服務和應用三層。而對(duì)于對(duì)于傳統的應用系統的構建一般又包括了IT基礎設施,技術平台,數據庫,中間件和應用。再到應用系統本身的分層架構可能(néng)又是标準的三層架構模式等。

這(zhè)些架構分層方法都(dōu)幫助我們進(jìn)一步融合分層架構模式。

架構分層有很多方法,包括基礎設施層,平台層,組件層,支撐層,服務層,應用層,數據層,展現層等。多種(zhǒng)分發(fā)導緻分層模型反而出現歧義和模糊。

在這(zhè)裡(lǐ)我們從技術架構和應用架構兩(liǎng)個層面(miàn)來談,技術架構沿用雲計算的三層模型;而對(duì)于應用架構則采用eTOM模型标準的資源,服務,應用三層模型。那麼(me)兩(liǎng)種(zhǒng)分層架構模型的融合則是一個完整的雲和SOA融合的分層架構模型。

即雲計算的三層中,每一個層次本身又可以進(jìn)一步拆分爲資源,服務和應用三層。

拿IaaS層來說(shuō),最底層的物理資源虛拟機等是屬于資源層内容,通過(guò)IaaS層資源能(néng)力提供API接口作爲技術服務進(jìn)行能(néng)力開(kāi)放,即是服務層;最終基于資源能(néng)力,構建了一個公有雲的面(miàn)向(xiàng)公衆的運營服務平台,本身又屬于應用層的内容。而對(duì)于SaaS層,則底層的業務組件是資源,抽象的API接口是服務層,最終的前端業務或流程是應用功能(néng)實現。




應用架構分層


回到單個應用的架構分層,談得最多的就(jiù)是常說(shuō)的三層架構模式。在軟件架構中,經(jīng)典三層架構自頂向(xiàng)下由用戶界面(miàn)層(User Interface Layer)、業務邏輯層(Business Logic Layer)與數據訪問層(Data Access Layer)組成(chéng)。
在整個實現過(guò)程中,可能(néng)還(hái)會(huì)增加獨立的Facade層,或獨立的API接口服務提供層,統一的DTO數據傳輸對(duì)象層等,但是這(zhè)些都(dōu)不影響整體的三層邏輯結構。

圖片

三層架構本身也和一個業務功能(néng)實現的完整對(duì)應,在數據訪問層處理數據獲取和持久化操作,在業務邏輯層對(duì)業務規則進(jìn)行處理,在界面(miàn)展現層進(jìn)行相應的前端展現和用戶交互。而談到領域建模的時(shí)候,又引入了領域模型 中的分層架構,如下:

圖片

領域驅動設計在經(jīng)典三層架構的基礎上做了進(jìn)一步改良,在用戶界面(miàn)層與業務邏輯層之間引入了新的一層,即應用層(Application Layer)。同時(shí),一些層次的命名也發(fā)生了變化。將(jiāng)業務邏輯層更名爲領域層自然是題中應有之義,而將(jiāng)數據訪問層更名爲基礎設施層(Infrastructure Layer),則突破了之前數據庫管理系統的限制,擴大了這(zhè)個負責封裝技術複雜度的基礎層次的内涵。

當然,也有融合了領域模型和傳統三架構思路後(hòu)的技術架構如下:

圖片

領域層和業務邏輯層

在領域建模的一個核心是領域模型,領域模型不再是一個個獨立的數據庫表或數據對(duì)象,而是一個業務對(duì)象或領域對(duì)象。因此領域層是面(miàn)向(xiàng)領域對(duì)象而設計實現,而業務規則能(néng)力本身也是屬于領域對(duì)象對(duì)外提供的能(néng)力接口。即業務規則本身也是領域對(duì)象暴露的能(néng)力。

傳統業務邏輯層實現往往是一個數據對(duì)象對(duì)應一個DAO,一個Service和一個Interface。而領域模型下DAO可以是分開(kāi)的,但是Service邏輯層往往則更多應該按領域模型思路對(duì)DAO層的能(néng)力進(jìn)行組裝和聚合。

獨立應用層拆分

圖片

在我原來理解裡(lǐ)面(miàn),領域層提供領域模型和領域服務能(néng)力接口,而應用層更多的是對(duì)領域層多個領域對(duì)象模型提供的服務能(néng)力進(jìn)一步進(jìn)行組裝和編排,然後(hòu)再暴露給前端應用。

談到應用層的概念,實際上可以理解爲前端應用中存在的共性能(néng)力的進(jìn)一步下沉。即應用本身隻是用戶業務功能(néng)實現的承載,但是這(zhè)個功能(néng)的實現可以通過(guò)多種(zhǒng)前端展現形式,比如傳統的CS桌面(miàn)應用,BS應用,或手機端APP。

在電商裡(lǐ)面(miàn),一個商品訂購就(jiù)是一個獨立的應用,用戶可以在APP完成(chéng),也可以在BS端完成(chéng),但是不論在哪裡(lǐ)完成(chéng)最終應用層提供的能(néng)力都(dōu)應該一樣。比如完成(chéng)一個商品訂購需要同時(shí)和底層的訂單,庫存,支付多個服務進(jìn)行交付和協同。那麼(me)這(zhè)個邏輯顯然不适合同時(shí)在BS端應用和APP端應用中進(jìn)行重複編寫和開(kāi)發(fā)。那麼(me)這(zhè)個内容就(jiù)應該在應用層實現。

如果回到微服務和中台架構下,這(zhè)個應用層拆分更加必要,即通過(guò)應用層來下沉共性的服務組合和組裝邏輯,這(zhè)個邏輯和協同不應該屬于任何一個前端應用。

界面(miàn)層還(hái)是接口層

在開(kāi)發(fā)一個聚合能(néng)力的中台微服務模塊的時(shí)候,可以看到這(zhè)個微服務模塊本身并沒(méi)有界面(miàn)展現層,那麼(me)該微服務的最上層僅僅是提供API接口的接口服務層。

該API接口服務能(néng)力既可以提供給APP前端,也可以提供給BS端使用。




軟件技術架構分層


軟件技術架構構圖,分層仍然可以沿用軟件三層分層模型,重點是說(shuō)明清楚各層用到的關鍵技術組件或技術服務能(néng)力。比如軟件開(kāi)發(fā)三層模型的技術架構分層如下:

圖片

如果本身就(jiù)是一個技術平台,類似大數據平台,那麼(me)我們在整體構圖的時(shí)候仍然需要考慮先進(jìn)行分層,再詳細說(shuō)明每層裡(lǐ)面(miàn)的技術内容。

比如對(duì)應一個大數據平台,包括了大數據采集,大數據存儲,大數據處理,大數據分析和應用,那麼(me)這(zhè)個就(jiù)是關鍵的分層,可以基于這(zhè)個分層再來考慮各層采用的關鍵技術。

圖片

對(duì)于技術棧構圖基本也可以參考技術架構構圖模式進(jìn)行。

圖片

技術架構重點需要回答的就(jiù)是你在進(jìn)行軟件架構設計過(guò)程中,究竟會(huì)用到哪些關鍵技術,哪些開(kāi)源産品或工具等。可以細化到具體的技術産品,也可以僅細化到産品類型。

比如消息中間件,你可以細化到采用RabbitMQ,也可以在技術架構中隻體現采用消息中間件。

技術架構和軟件功能(néng)分層架構唯一相同的就(jiù)是分層,技術架構在各個分層裡(lǐ)面(miàn)都(dōu)沒(méi)有具體的業務功能(néng)點和實現内容,僅僅是關鍵技術點說(shuō)明。




單個應用功能(néng)架構


注意應用功能(néng)架構完全是重點描述應用系統具備哪些功能(néng),一個功能(néng)究竟是采用什麼(me)三層技術架構實現并不用關心。因此功能(néng)架構不應該體現數據層,邏輯層,技術點這(zhè)些内容。

那麼(me)對(duì)于一個應用系統的功能(néng)如何分層?

我們可以參考業務分層分類,將(jiāng)業務分爲基礎支撐層,執行層,決策管理層。這(zhè)樣基本的分層模式就(jiù)出來了,基于該方式可以完成(chéng)一個功能(néng)架構構圖。

圖片

對(duì)于單個應用來說(shuō)一般不會(huì)自身有雲平台,PaaS平台這(zhè)類概念。但是單個應用構建一定存在共性技術支撐平台能(néng)力,比如有自己的流程管理,各自共性技術功能(néng)組件等。因此單應用構建還(hái)可以采用基礎技術支撐層+應用層+門戶層的方式進(jìn)行構圖。

在應用層再按具體的業務域或業務階段進(jìn)行進(jìn)一步細分。

圖片




架構圖的分層構圖邏輯


圖片

在前面(miàn)基本給出了不同類型的架構圖的核心分層邏輯,可以看到在畫架構圖的時(shí)候盡量不要混合使用不同場景下的構圖方式,否則就(jiù)導緻整體架構圖混亂。

在畫整體架構的時(shí)候一般需要重點參考雲三層架構,SOA三層架構的構圖模式進(jìn)行構圖。而在細化到某一個應用系統的時(shí)候,仍然還(hái)需要分清是構建技術架構圖還(hái)是功能(néng)架構圖,兩(liǎng)者本身的分層邏輯也存在很大的差别而不能(néng)混用。

架構圖的構圖邏輯

要完成(chéng)一個完整的架構圖構圖,可以先拆分爲兩(liǎng)邊+中間。兩(liǎng)邊一般是放具體的标準,規範等,比如安全管理,質量管理,技術标準規範,開(kāi)發(fā)運維規範等。

中間即是重點需要考慮進(jìn)行分層構建的地方。

在前面(miàn)也談到了中間部分重點參考雲計算和SOA的架構分層邏輯。一般來說(shuō)核心的還(hái)是資源層,平台層,應用層,門戶層。而對(duì)于應用層本身又可以考慮業務域進(jìn)一步拆分,或者根據價值鏈或業務生命周期拆分爲多個階段域再展開(kāi)描述。

在雲和SOA下,更加強調平台+應用構建模式

而兩(liǎng)者之間一般是服務層,通過(guò)SOA平台或API能(néng)力開(kāi)放平台來統一接入和發(fā)布服務,以形成(chéng)一個完整的資源+服務+應用的松耦合架構。同時(shí)一個完整的架構本身就(jiù) 是多視角的,如下:

圖片

功能(néng)架構往往可以給具體用戶和業務人員看,而對(duì)于技術架構往往更多是内部團隊開(kāi)發(fā)人員研讨使用。而設計到資源和平台的架構圖往往又是運維工程人員進(jìn)行部署架構搭建的重要參考。因此不同維度的架構分層屬性本身不能(néng)随意融合使用,而導緻架構圖混亂。


來源: 架構師優雅之道(dào)