今天再講下如何畫架構圖。

架構圖素材和軟件架構構圖邏輯概述

我在前面有篇文章專門分享了我制作的一些架構圖的素材ppt材料，如果沒有下載到，可以先關注我私信獲取下載地址。

具體素材的內容可以參考：

個人實踐中PPT常用構圖案例分享

而對于軟件架構設計分層邏輯在前面我也專門分享了一篇文章進行說明，這篇文章給出了核心的架構圖制作思路，可以參考。

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

要完成一個完整的架構圖構圖，可以先拆分為兩邊+中間。兩邊一般是放具體的標準，規范等，比如安全管理，質量管理，技術標準規范，開發運維規范等。

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

在前面也談到了中間部分重點參考云計算和SOA的架構分層邏輯。一般來說核心的還是資源層，平臺層，應用層，門戶層。而對于應用層本身又可以考慮業務域進一步拆分，或者根據價值鏈或業務生命周期拆分為多個階段域再展開描述。

在云和SOA下，更加強調平臺+應用構建的模式。而兩者之間一般是服務層，通過SOA平臺或API能力開放平臺來統一接入和發布服務，以形成一個完整的資源+服務+應用的松耦合架構。

當然對于領域設計架構分層實際也是傳統的三層架構模型和SOA架構思想的一種融合，同時獨立出單獨的服務層和應用層的概念。

再談分層邏輯

一個完整的架構本身就是多視角的，如下：

功能架構往往可以給具體用戶和業務人員看，而對于技術架構往往更多是內部團隊開發人員研討使用。而設計到資源和平臺的架構圖往往又是運維工程人員進行部署架構搭建的重要參考。因此不同維度的架構分層屬性本身不能隨意融合使用，而導致架構圖混亂。

云計算分層邏輯

云平臺的分層邏輯，即標準的IaaS-PaaS-SaaS三層

• IaaS層：資源層，計算，存儲，網絡
• PaaS層：各種平臺可以放到這層，包括技術平臺，集成平臺，數據平臺等
• SaaS層：對應到應用即服務

當然在構圖的時候往往會進一步做些擴展。

比如構建物聯網應用的架構，一般會在底層擴展網絡和感知層。如果要體現平臺+應用的服務化開發思路，一般會增加一個獨立的服務層或能力開放層。

云計算架構分層模型一般用在最頂層的整體架構規劃設計，這類架構圖重點體現出云架構分層，體現平臺+應用化構建，體現出各個應用域和具體應用。

要明白在這類架構圖里面，各個應用一般只會是一個小方框而不會展開。但是從整個大架構規劃里面又能夠看到基于云平臺構建了哪些具體的應用。

類似一個智慧城市的架構圖參考如下：

這類架構圖在智慧城市，智慧政務，企業整體IT架構規劃中都會應用，一般屬于頂層架構設計，體現云平臺分層，體現技術平臺能力和各個IT應用即可。而不做展開。

應用技術架構

注意常說的類似JAVA開發里面的三層架構，數據訪問層，業務邏輯層，展現層。或者類似領域模型中的領域服務層，應用層，界面接口層分層方法。

這些本質是偏應用技術架構的描述。

技術架構描述的重點不是講清楚應用有哪些功能，而是要說清楚應用中的每一個功能是如何通過技術分層來實現的。比如你需要先定義數據庫結構，開發數據訪問接口，然后編寫業務規則邏輯，最好實現前端界面展現設計，再將所有分層內容連接起來。

所以應用技術架構更多是應用實現技術層面的內容，而不是去關心應用實現用的底層IT基礎設施資源。在應用技術架構里面一般不會涉及到底層具體的資源或平臺，如果應用技術架構在底層增加了類似IT基礎設施，存儲等內容，就顯得不倫不類了。

類似上圖，實際就完全沒有必要體現出最底層的基礎層內容。

應用功能架構

簡單來說應用功能架構需要的是體現出應用有哪些業務模塊，有哪些具體的業務功能點，而不是關心應用實現的技術架構分層等內容。

但是應用功能架構最好也體現分層。

簡單方式就是最下層全部抽象到基礎技術支撐層里面，這里面包括了具體的和業務無關的基礎技術支撐功能。中間就是應用功能層，最上層是門戶層。

在應用功能層的描述中可以分具體的業務域再到業務功能逐層展開，如果業務應用本身有一個完整的生命周期或階段線條，那么還可以按階段來排列具體的功能模塊。而底層一般放具體的基礎數據管理，元數據管理等功能模塊。

當然在應用功能架構的構圖中，有時候還需要體現出當前應用和外部應用之間的集成，因此可以在縱向再單獨增加了一個接口集成的模塊。如下：

集成架構的構圖

由于我自己經常做SOA規劃咨詢類項目，因此做整個企業IT應用間集成架構和做接口關系梳理的時候比較多。一個集成架構不僅僅體現出各個IT系統，更加重要的是需要體現出各個IT系統至今的集成關系和關鍵的集成點，在集成點上又要體現核心基礎的數據流。

對于這類圖整體可以理解為傳統軟件工程里面的數據流圖的一個演進。

構圖的難點是在于整體IT系統的布局，各個系統間接口連接線的設計，如果設計得不好那么集成架構圖就會顯得很凌亂。

這本身就是一個不斷優化調整的過程，沒有統一的方法可以遵循。

部署架構-物理架構還是邏輯架構

我們先看一個常見的網絡布線和拓撲架構圖。

這個圖體現了IT基礎設施架構的一個關鍵內容，即應用層，接入層，匯聚層。匯聚后統一進入到核心網。核心網通過DMZ區再連接到互聯網。

如果你做一個IT系統的部署架構，一般不會體現最終的應用層內容。

而是體現你核心系統里面的各個IT基礎設施情況，如數據庫服務器，中間件服務器，緩存服務器等。但是所有的資源配置最終仍然是經過匯聚層交換機后進入到核心網。

類似如下：

因此在部署架構中不會去體現云平臺的分層架構，也不會去體現應用分層架構，只需要列清楚具體的物理資源或邏輯資源，以及資源本身接入和匯聚的情況即可。

應用層拆分-前臺應用和中臺能力層

最近幾年談中臺和微服務比較多，注意中臺本身是一個業務概念。

實際中臺層本身是原來應用層可共享的共性業務能力的下沉，中臺層能力在原來是屬于應用層能力的。因此在中臺架構下，應用層進一步拆分為前臺應用和中臺能力。

類似一個電商的中臺架構如下：

也就是中臺架構下的分層應該是：前臺應用+中臺能力+后臺

這個后臺有人會理解為技術平臺或技術中臺，但是更好地理解是后臺本身也是原來的應用層內容，也是業務能力的實現。類似在我前面文章中提到過的，企業傳統的ERP系統就下沉為后臺應用層能力。同時基于后臺能力構建了一個抽象服務適配層，這個抽象的共享服務適配層即是中臺能力。在這種場景下中臺更類似一個服務層。

SOA架構分層，體現獨立的服務層

對于SOA架構分層，重點要體現的就是服務，對于組件本身是屬于邏輯資源層的概念，而對于服務則是資源對外暴露的能力抽象。

SOA架構分層重點就是要體現出獨立的服務層，注意不是畫服務總線，這里可以單獨畫出具體提供哪些業務服務能力，技術服務能力。在采用SOA架構進行開發的時候，整體業務系統拆分為4個組件，10類服務域，5類流程，那么在構建的時候重點就是將上述組件，服務域和流程類體現出來。

這里的數據層最好改為標準的組件層，更加貼近SOA架構模型。在圖中的服務層已經可以看到一個個獨立的API服務接口。如果服務接口數據大，一般只會劃分到服務域，比如用戶中心服務，采購類服務等。

多種分層思路的一個糅合

在前面談到SOA架構分層，云平臺分層，應用技術架構分層等多個分層方法，但是各種分層思路一般不混用，各有各的應用場景。

當然有時候也需要多個分層架構的思想融合。

比如需要在一個分層架構中既體現出技術架構分層，又體現出類似SOA和云的平臺+應用架構思想，那么就需要多種分層架構融合。

比如前面談到云平臺是一種橫向資源-平臺-應用的分層方式。而對于技術架構分層僅僅是應用的進一步展開。那么我們在構圖的時候就可以橫向+縱向結合的方式來進行構圖，同時體現出兩種分層內容，參考如下：

參考上圖，可以將技術架構的分層轉變為縱向方式進行描述。而橫向重點還是體現云和SOA的架構分層，整體思路就更加清晰。