今天再講下如何畫架構(gòu)圖。
架構(gòu)圖素材和軟件架構(gòu)構(gòu)圖邏輯概述
而對(duì)于軟件架構(gòu)設(shè)計(jì)分層邏輯在前面我也專門分享了一篇文章進(jìn)行說明，這篇文章給出了核心的架構(gòu)圖制作思路，可以參考。
軟件架構(gòu)設(shè)計(jì)分層模型和構(gòu)圖思考
要完成一個(gè)完整的架構(gòu)圖構(gòu)圖，可以先拆分為兩邊+中間。兩邊一般是放具體的標(biāo)準(zhǔn)，規(guī)范等，比如安全管理，質(zhì)量管理，技術(shù)標(biāo)準(zhǔn)規(guī)范，開發(fā)運(yùn)維規(guī)范等。
中間即是重點(diǎn)需要考慮進(jìn)行分層構(gòu)建的地方。
在前面也談到了中間部分重點(diǎn)參考云計(jì)算和SOA的架構(gòu)分層邏輯。一般來說核心的還是資源層，平臺(tái)層，應(yīng)用層，門戶層。而對(duì)于應(yīng)用層本身又可以考慮業(yè)務(wù)域進(jìn)一步拆分，或者根據(jù)價(jià)值鏈或業(yè)務(wù)生命周期拆分為多個(gè)階段域再展開描述。
在云和SOA下，更加強(qiáng)調(diào)平臺(tái)+應(yīng)用構(gòu)建的模式。而兩者之間一般是服務(wù)層，通過SOA平臺(tái)或API能力開放平臺(tái)來統(tǒng)一接入和發(fā)布服務(wù)，以形成一個(gè)完整的資源+服務(wù)+應(yīng)用的松耦合架構(gòu)。
當(dāng)然對(duì)于領(lǐng)域設(shè)計(jì)架構(gòu)分層實(shí)際也是傳統(tǒng)的三層架構(gòu)模型和SOA架構(gòu)思想的一種融合，同時(shí)獨(dú)立出單獨(dú)的服務(wù)層和應(yīng)用層的概念。
再談分層邏輯
一個(gè)完整的架構(gòu)本身就是多視角的，如下
功能架構(gòu)往往可以給具體用戶和業(yè)務(wù)人員看系統(tǒng)邏輯架構(gòu)圖怎么畫，而對(duì)于技術(shù)架構(gòu)往往更多是內(nèi)部團(tuán)隊(duì)開發(fā)人員研討使用。而設(shè)計(jì)到資源和平臺(tái)的架構(gòu)圖往往又是運(yùn)維工程人員進(jìn)行部署架構(gòu)搭建的重要參考。因此不同維度的架構(gòu)分層屬性本身不能隨意融合使用，而導(dǎo)致架構(gòu)圖混亂。
云計(jì)算分層邏輯
云平臺(tái)的分層邏輯，即標(biāo)準(zhǔn)的IaaS-PaaS-SaaS三層
當(dāng)然在構(gòu)圖的時(shí)候往往會(huì)進(jìn)一步做些擴(kuò)展。
比如構(gòu)建物聯(lián)網(wǎng)應(yīng)用的架構(gòu)，一般會(huì)在底層擴(kuò)展網(wǎng)絡(luò)和感知層。如果要體現(xiàn)平臺(tái)+應(yīng)用的服務(wù)化開發(fā)思路，一般會(huì)增加一個(gè)獨(dú)立的服務(wù)層或能力開放層。
云計(jì)算架構(gòu)分層模型一般用在最頂層的整體架構(gòu)規(guī)劃設(shè)計(jì)，這類架構(gòu)圖重點(diǎn)體現(xiàn)出云架構(gòu)分層，體現(xiàn)平臺(tái)+應(yīng)用化構(gòu)建，體現(xiàn)出各個(gè)應(yīng)用域和具體應(yīng)用。
要明白在這類架構(gòu)圖里面，各個(gè)應(yīng)用一般只會(huì)是一個(gè)小方框而不會(huì)展開。但是從整個(gè)大架構(gòu)規(guī)劃里面又能夠看到基于云平臺(tái)構(gòu)建了哪些具體的應(yīng)用。
類似一個(gè)智慧城市的架構(gòu)圖參考如下：
這類架構(gòu)圖在智慧城市，智慧政務(wù)，企業(yè)整體IT架構(gòu)規(guī)劃中都會(huì)應(yīng)用，一般屬于頂層架構(gòu)設(shè)計(jì)，體現(xiàn)云平臺(tái)分層，體現(xiàn)技術(shù)平臺(tái)能力和各個(gè)IT應(yīng)用即可。而不做展開。
應(yīng)用技術(shù)架構(gòu)
注意常說的類似Java開發(fā)里面的三層架構(gòu)，數(shù)據(jù)訪問層，業(yè)務(wù)邏輯層，展現(xiàn)層。或者類似領(lǐng)域模型中的領(lǐng)域服務(wù)層，應(yīng)用層，界面接口層分層方法。
這些本質(zhì)是偏應(yīng)用技術(shù)架構(gòu)的描述。
技術(shù)架構(gòu)描述的重點(diǎn)不是講清楚應(yīng)用有哪些功能，而是要說清楚應(yīng)用中的每一個(gè)功能是如何通過技術(shù)分層來實(shí)現(xiàn)的。比如你需要先定義數(shù)據(jù)庫(kù)結(jié)構(gòu)，開發(fā)數(shù)據(jù)訪問接口，然后編寫業(yè)務(wù)規(guī)則邏輯，最好實(shí)現(xiàn)前端界面展現(xiàn)設(shè)計(jì)，再將所有分層內(nèi)容連接起來。
所以應(yīng)用技術(shù)架構(gòu)更多是應(yīng)用實(shí)現(xiàn)技術(shù)層面的內(nèi)容，而不是去關(guān)心應(yīng)用實(shí)現(xiàn)用的底層IT基礎(chǔ)設(shè)施資源。在應(yīng)用技術(shù)架構(gòu)里面一般不會(huì)涉及到底層具體的資源或平臺(tái)，如果應(yīng)用技術(shù)架構(gòu)在底層增加了類似IT基礎(chǔ)設(shè)施，存儲(chǔ)等內(nèi)容，就顯得不倫不類了。
類似上圖，實(shí)際就完全沒有必要體現(xiàn)出最底層的基礎(chǔ)層內(nèi)容。
應(yīng)用功能架構(gòu)
簡(jiǎn)單來說應(yīng)用功能架構(gòu)需要的是體現(xiàn)出應(yīng)用有哪些業(yè)務(wù)模塊，有哪些具體的業(yè)務(wù)功能點(diǎn)，而不是關(guān)心應(yīng)用實(shí)現(xiàn)的技術(shù)架構(gòu)分層等內(nèi)容。
但是應(yīng)用功能架構(gòu)最好也體現(xiàn)分層。
簡(jiǎn)單方式就是最下層全部抽象到基礎(chǔ)技術(shù)支撐層里面，這里面包括了具體的和業(yè)務(wù)無關(guān)的基礎(chǔ)技術(shù)支撐功能。中間就是應(yīng)用功能層，最上層是門戶層。
在應(yīng)用功能層的描述中可以分具體的業(yè)務(wù)域再到業(yè)務(wù)功能逐層展開，如果業(yè)務(wù)應(yīng)用本身有一個(gè)完整的生命周期或階段線條，那么還可以按階段來排列具體的功能模塊。而底層一般放具體的基礎(chǔ)數(shù)據(jù)管理，元數(shù)據(jù)管理等功能模塊。
當(dāng)然在應(yīng)用功能架構(gòu)的構(gòu)圖中，有時(shí)候還需要體現(xiàn)出當(dāng)前應(yīng)用和外部應(yīng)用之間的集成，因此可以在縱向再單獨(dú)增加了一個(gè)接口集成的模塊。如下：
集成架構(gòu)的構(gòu)圖
由于我自己經(jīng)常做SOA規(guī)劃咨詢類項(xiàng)目，因此做整個(gè)企業(yè)IT應(yīng)用間集成架構(gòu)和做接口關(guān)系梳理的時(shí)候比較多。一個(gè)集成架構(gòu)不僅僅體現(xiàn)出各個(gè)IT系統(tǒng)，更加重要的是需要體現(xiàn)出各個(gè)IT系統(tǒng)至今的集成關(guān)系和關(guān)鍵的集成點(diǎn)，在集成點(diǎn)上又要體現(xiàn)核心基礎(chǔ)的數(shù)據(jù)流。
對(duì)于這類圖整體可以理解為傳統(tǒng)軟件工程里面的數(shù)據(jù)流圖的一個(gè)演進(jìn)。
構(gòu)圖的難點(diǎn)是在于整體IT系統(tǒng)的布局，各個(gè)系統(tǒng)間接口連接線的設(shè)計(jì)，如果設(shè)計(jì)得不好那么集成架構(gòu)圖就會(huì)顯得很凌亂。
這本身就是一個(gè)不斷優(yōu)化調(diào)整的過程，沒有統(tǒng)一的方法可以遵循。
部署架構(gòu)-物理架構(gòu)還是邏輯架構(gòu)
我們先看一個(gè)常見的網(wǎng)絡(luò)布線和拓?fù)浼軜?gòu)圖。
這個(gè)圖體現(xiàn)了IT基礎(chǔ)設(shè)施架構(gòu)的一個(gè)關(guān)鍵內(nèi)容，即應(yīng)用層，接入層，匯聚層。匯聚后統(tǒng)一進(jìn)入到核心網(wǎng)。核心網(wǎng)通過DMZ區(qū)再連接到互聯(lián)網(wǎng)。
如果你做一個(gè)IT系統(tǒng)的部署架構(gòu)，一般不會(huì)體現(xiàn)最終的應(yīng)用層內(nèi)容。
而是體現(xiàn)你核心系統(tǒng)里面的各個(gè)IT基礎(chǔ)設(shè)施情況，如數(shù)據(jù)庫(kù)服務(wù)器，中間件服務(wù)器，緩存服務(wù)器等。但是所有的資源配置最終仍然是經(jīng)過匯聚層交換機(jī)后進(jìn)入到核心網(wǎng)。
類似如下：
因此在部署架構(gòu)中不會(huì)去體現(xiàn)云平臺(tái)的分層架構(gòu)，也不會(huì)去體現(xiàn)應(yīng)用分層架構(gòu)，只需要列清楚具體的物理資源或邏輯資源，以及資源本身接入和匯聚的情況即可。
應(yīng)用層拆分-前臺(tái)應(yīng)用和中臺(tái)能力層
最近幾年談中臺(tái)和微服務(wù)比較多，注意中臺(tái)本身是一個(gè)業(yè)務(wù)概念。
實(shí)際中臺(tái)層本身是原來應(yīng)用層可共享的共性業(yè)務(wù)能力的下沉，中臺(tái)層能力在原來是屬于應(yīng)用層能力的。因此在中臺(tái)架構(gòu)下，應(yīng)用層進(jìn)一步拆分為前臺(tái)應(yīng)用和中臺(tái)能力。
類似一個(gè)電商的中臺(tái)架構(gòu)如下：
也就是中臺(tái)架構(gòu)下的分層應(yīng)該是：前臺(tái)應(yīng)用+中臺(tái)能力+后臺(tái)
這個(gè)后臺(tái)有人會(huì)理解為技術(shù)平臺(tái)或技術(shù)中臺(tái)，但是更好地理解是后臺(tái)本身也是原來的應(yīng)用層內(nèi)容，也是業(yè)務(wù)能力的實(shí)現(xiàn)。類似在我前面文章中提到過的，企業(yè)傳統(tǒng)的ERP系統(tǒng)就下沉為后臺(tái)應(yīng)用層能力。同時(shí)基于后臺(tái)能力構(gòu)建了一個(gè)抽象服務(wù)適配層，這個(gè)抽象的共享服務(wù)適配層即是中臺(tái)能力。在這種場(chǎng)景下中臺(tái)更類似一個(gè)服務(wù)層。
SOA架構(gòu)分層，體現(xiàn)獨(dú)立的服務(wù)層
對(duì)于SOA架構(gòu)分層系統(tǒng)邏輯架構(gòu)圖怎么畫，重點(diǎn)要體現(xiàn)的就是服務(wù)，對(duì)于組件本身是屬于邏輯資源層的概念，而對(duì)于服務(wù)則是資源對(duì)外暴露的能力抽象。
SOA架構(gòu)分層重點(diǎn)就是要體現(xiàn)出獨(dú)立的服務(wù)層，注意不是畫服務(wù)總線，這里可以單獨(dú)畫出具體提供哪些業(yè)務(wù)服務(wù)能力，技術(shù)服務(wù)能力。在采用SOA架構(gòu)進(jìn)行開發(fā)的時(shí)候，整體業(yè)務(wù)系統(tǒng)拆分為4個(gè)組件，10類服務(wù)域，5類流程，那么在構(gòu)建的時(shí)候重點(diǎn)就是將上述組件，服務(wù)域和流程類體現(xiàn)出來。
這里的數(shù)據(jù)層最好改為標(biāo)準(zhǔn)的組件層，更加貼近SOA架構(gòu)模型。在圖中的服務(wù)層已經(jīng)可以看到一個(gè)個(gè)獨(dú)立的API服務(wù)接口。如果服務(wù)接口數(shù)據(jù)大，一般只會(huì)劃分到服務(wù)域，比如用戶中心服務(wù)，采購(gòu)類服務(wù)等。
多種分層思路的一個(gè)糅合
在前面談到SOA架構(gòu)分層，云平臺(tái)分層，應(yīng)用技術(shù)架構(gòu)分層等多個(gè)分層方法，但是各種分層思路一般不混用，各有各的應(yīng)用場(chǎng)景。
當(dāng)然有時(shí)候也需要多個(gè)分層架構(gòu)的思想融合。
比如需要在一個(gè)分層架構(gòu)中既體現(xiàn)出技術(shù)架構(gòu)分層，又體現(xiàn)出類似SOA和云的平臺(tái)+應(yīng)用架構(gòu)思想，那么就需要多種分層架構(gòu)融合。
比如前面談到云平臺(tái)是一種橫向資源-平臺(tái)-應(yīng)用的分層方式。而對(duì)于技術(shù)架構(gòu)分層僅僅是應(yīng)用的進(jìn)一步展開。那么我們?cè)跇?gòu)圖的時(shí)候就可以橫向+縱向結(jié)合的方式來進(jìn)行構(gòu)圖，同時(shí)體現(xiàn)出兩種分層內(nèi)容，參考如下：
參考上圖，可以將技術(shù)架構(gòu)的分層轉(zhuǎn)變?yōu)榭v向方式進(jìn)行描述。而橫向重點(diǎn)還是體現(xiàn)云和SOA的架構(gòu)分層，整體思路就更加清晰。
個(gè)人原創(chuàng)的架構(gòu)圖構(gòu)圖案例參考如下：