軟體系統架構設計的目標不在於設計本身,而在於架構設計意圖的傳達。圖形化有助於在團隊間進行高效的信息同步,但不同的圖形化方式需要語義一致性和效率間實現平衡。C4模型通過不同的抽象層級來表達系統的靜態結構,並提供了最小集的抽象建模元素,為設計人員提供了一種低認知負載、易於學習和使用的高效建模方式。 ...
軟體系統架構設計的目標不在於設計本身,而在於架構設計意圖的傳達。圖形化有助於在團隊間進行高效的信息同步,但不同的圖形化方式需要語義一致性和效率間實現平衡。C4模型通過不同的抽象層級來表達系統的靜態結構,並提供了最小集的抽象建模元素,為設計人員提供了一種低認知負載、易於學習和使用的高效建模方式。
1 為什麼要進行架構可視化?
軟體系統架構設計的目標不在於設計本身,而在於架構設計意圖的傳達。如果不能清晰、一致的在干係人間進行設計意圖的同步,即使再好的設計也只是空中樓閣。軟體架構設計本質上也是一種抽象和建模的過程(對模型和抽象的本質參考文章《 領域驅動設計開篇 》),軟體架構設計模型的表達有多種方式:圖形化、語言和文字。絕大部分場景下,圖形化在架構設計的表現力層面效果更佳。因此,對於軟體系統架構進行可視化表達是有價值,且是必要的。
軟體架構可視化的方式有多種,不同的團隊有不同的實踐方式,最為常見的由如下幾種:
•線框圖:通過線框圖和連線表達架構元素及之間的關係 •UML:統一建模語言,表達系統的靜態結構和動態行為 •草圖:非正式的圖形不同的可視化方式各有優劣,以下部分將對不同的表現形式進行說明
1.1 可視化方式-線框圖
線框圖是最為通用的可視化表達方式之一,架構師或設計人員大量的架構圖,比如技術架構、功能架構、數據架構、邏輯架構等等都通過線框圖的形式表達。該種可視化方式的優勢是:
•建模工具多樣化:你可以基於Viso、Drawio、PPT等任何一款支持線框圖的軟體進行建模工作 •學習成本低:設計人員幾乎不需要進行專門的建模語言以及建模工具的學習,門檻較低但,基於線框圖表達軟體系統架構存在的問題也非常明顯:語義的一致性問題
你可能自己畫過很多軟體系統架構圖,也可能參與評審過其他團隊的架構圖,我相信,對你而言並不是的所有的圖都是“清晰且易於理解的”。舉個簡單的場景,如果我們在百度搜索 “架構圖” ,你可能得到以下結果:
各式各樣的 “架構圖”:不同形狀和顏色的圖形元素、不同形狀和顏色的連線、不同的意圖。
我們可以看出:線框圖雖然簡單,但其其圖形化的語義一致性是大問題。雖然都是通過線框表達軟體系統架構,但不同的人可能使用不同的元素、不同的顏色、不同的連線和分層等等,線框自由表達的靈活性和圖形化語義的一致性存在潛在衝突,最終都會阻礙架構設計意圖傳達。
1.2 可視化方式-UML
UML是統一建模語言,相比於線框圖而言,其優勢是在軟體建模層面提供了一致性的建模元語言。簡單來說,UML提供了大家達成一致的(UML支持擴展的場景除外)建模元素。如果團隊成員比較熟悉UML,那麼通過UML表達的系統架構圖天然具有認知一致性。
豐富靈活的建模元語言在提升語義一致性的同時,也必然會導致複雜性的上升。掌握UML具有一定的學習成本,而熟練的應用對研發人員也提出了更高的要求。基於 Simon Brown給出的數據,實際情況只有少數團隊真正使用UML。不論是UML的複雜度和學習成本原因,還是敏捷化下對UML的排斥,很多團隊都放棄了UML。
我們不能否認UML的價值,基於統一建模語言能夠更有效的進行架構設計的信息傳遞和溝通,也能基於UML提供的詳細的模型圖元素進行充分的設計表達。團隊中是否要基於UML進行溝通需要權衡,雖然UML不能表達你所要傳達的全部的架構信息,但其在某些維度的表達相對比較適合。
•表達流程和工作流可以採用UML活動圖 •表達運行時的交互可以採用UML時序圖 •表達領域模型或者設計模式可以採用UML類圖 •表達狀態轉換可以採用UML狀態機 •表達系統的部署結構可以使用UML部署圖1.3 可視化方式-草圖
架構可視化另一個非常常見的方式是:草圖。草圖是一種非正式的、易於快速溝通的圖形化方式。團隊基於特定的場景,可以通過草圖的形式進行快速的溝通,以便高效的在干係人間拉齊關鍵信息。
但,草圖的劣勢與線框圖一樣:語義一致性低
我們可以在白板上 “隨心所欲” 的畫各式各樣的草圖,草圖上的元素、連線,又或者佈局都可能是涌現式的、臨時性的,這些草圖的價值在於 “會話周期內的高效溝通”。如果干係人沒有完全參與到草圖的討論,又或是後置查看,大概也很難精準捕獲這些草圖所要表達的設計意圖。
2 C4 模型
2.1 C4模型的統一抽象
團隊需要統一語言進行高效溝通 !!!
C4模型在不同的級別提供了統一的抽象以表達軟體系統的靜態結構。如下圖所示:
•軟體系統:最頂層的抽象,其對用戶提供價值。包含待構建的系統以及外部依賴的系統 •容器:表示一個應用或者數據存儲,容器需要運行以支持系統的正常運轉。每個容器都是獨立部署或運行的單元,容器間的通信一般式跨進程交互 •組件:提供一定能力封裝的單元。在C4模型上下文中,組件不是獨立部署的單元,一般情況下運行於容器之中。 •代碼:系統的實現細節相關 •人:系統的使用用戶
2.2 上下文圖:System Context Diagram
我們要構建的系統不會孤立存在,都會依賴現有的IT設施。要明確我們構建的系統是什麼,巨集觀上需要回答:我們的系統如何融入到現有的IT設施。
系統上下文圖正是從高層視角表述待構建系統與當前IT設施的交互及邊界。通過上下文圖:
•展示與軟體系統交互的各方及相互關係 •展示軟體系統與外部環境的邊界 •作為瞭解系統架構的切入點 •確保所有人都理解、認可系統的工作範圍
2.3 容器圖:Container Diargram
更進一步的剖析核心系統,回答:系統由哪些容器組成?容器的職責是什麼?以及相關的高層的技術選型是什麼?
與Docker的容器概念不同,C4模型的容器是在 “系統” 作用域之下,其表達的是組成系統的可獨立可部署的物理單元。以下圖為例:單個容器元素重包含了名稱、職責描述、技術選型,同時,容器間的連線及標註標識了其高層的交互協議及交互形式。
2.4 組件圖:Component Diagram
進一步的剖析容器,回答:容器由哪些組件組成?這些組件的職責及組件間的交互形式是什麼?
具體到每個容器內部,通過多個組件及組件間的關係表達容器的組成。“組件” 本身是一個泛化的概念,C4模型的組件是在 “容器” 的作用域之下,其表現形式可能是獨立的Jar包,或者是應用內獨立的包,也可能是類級別,但邏輯上都能夠表達一個組件的概念。對於組件圖關鍵的是要表示清楚組件的實現選型、組件職責以及組件間的交互關係。
2.5 代碼
代碼處於C4模型的最低層,且是可選的,其關註的是實現相關。C4模型並沒有對實現層面的可視化進行統一抽象,開發人員可以選擇UML類圖、E-R圖等進行可視化。是否需要提現代碼層面研發人員基於具體情況具體分析,一般情況下,如果系統中需要重點關註的部分可以考慮一些代碼級別的圖支持,比如,我們非常關註系統設計的可擴展性,則關鍵部分可能需要一些類圖表達;又或者非常關註底層數據模型,則E-R圖可以納入考慮範圍。
3 C4模型實踐中的決策和問題
連線表達依賴關係還是數據流向 ?
都可以,C4模型中的連線既可以表達依賴方向,也可以表達數據流向。原則上,設計人員需要保證其清晰且無歧義。實踐中一般通過合理的文字說明來明確的表達元素間的關係。
Jar或類庫應該建模為“容器”? “組件” ?
Jar包或類庫一般是鏈接到調用方的進程中,作為進程中的一部分存在,這種依賴一般不表示為容器,而是組件。當然,是否要將Jar,比如SDK表示為組件並體現在組件圖上需要設計人員具體情況具體分析。
數據存儲系統應該建模為 “軟體系統” 還是 “容器” ?
數據存儲系統,比如MySQL、DFS等一般是作為獨立的外部存儲集群存在,集群的運維可能歸屬於公司的運維團隊。以OSS為例,但從應用角度而言,即使集群的運維不歸屬當前開發團隊,團隊也會申請租戶隔離的專屬空間,因此,在C4模型中這種情況應該表述為 “容器”。
消息系統應該如何建模 ?
消息系統一般作為兩個容器間的交互媒介,因此在C4模型中消息系統的建模存在兩種方式:
•依賴消息系統的容器都顯示與消息系統交互,明確的表達各自與消息系統的依賴關係或數據流向 •屏蔽消息系統,只提現容器間的依賴關係,並對依賴進行明確說明圖形化的過期問題
C4模型本身也是一種文檔化機制,同樣也存在過期問題。只不過C4模型通過對系統在不同的層級進行抽象,每個抽象層級的過期頻率不同,由上到下逐漸增大,上下文圖的變化頻率最小,而代碼級則變化最大。
為什麼C4不涉及業務流、狀態機、數據模型等建模
C4模型僅對系統的靜態結構進行建模,並不試圖囊括或替代其它建模方式,C4模型並不適合所有維度的可視化表達。對於業務流可以基於BPML、UML活動圖進行表達,狀態機可以基於UML狀態機圖進行表達,而數據模型可以通過E-R圖表達,不同建模語言相互補充。
4 系統架構設計關註不同維度
作為架構師或系統設計人員,在進行系統架構設計時一般會關註不同維度,一般情況下,對於業務系統建設而言,會關註以下維度。在架構設計(架構和設計)過程中,基於C4模型、UML及BPML等多種建模方式相互補充,不同表現維度下可以採用不同的建模方式
•業務流程:泳道圖或UML活動圖,表達核心的業務流 •業務用例、系統用例:UML用例圖 •領域模型:UML類圖 •系統邊界:C1,系統上下文圖 •高層技術選型:C2,容器圖 •系統職責分配:用線框圖表示功能架構 •關鍵部分的實現:C3,組件圖 •系統關鍵的交互邏輯:UML時序圖 •數據模型:E-R圖 •關鍵實體的狀態機:UML狀態機圖 •不同的高優先順序架構屬性的設計:比如,緩存方案、冪等性設計方案、定時任務補償策略、降級限流策略等等,這些都與具體的需求所關註的高優先順序的架構屬性相關。 •部署架構:UML部署圖5 總結
軟體架構設計的終極目標不在於設計本身,而在於架構設計意圖的傳達。圖形化有助於在團隊間進行高效的信息同步,但不同的圖形化方式在語義一致性和效率間存在平衡。C4模型通過不同的抽象層級來表達系統的靜態結構,並提供了最小及的抽象建模元素,為設計人員提供了一種低認知負載、易於學習和使用的高效的建模方式。在實際項目落地過程中,結合C4模型以及UML、線框圖等組合方式對架構設計進行可視化表達,一定程度上能夠提升團隊對架構設計認知的一致性以及建模效率。
作者:倪新明