很多同學技術能力很強，架構設計也做得很好，但是在給別人講解的時候，總感覺像是“茶壺裡煮餃子，有貨倒不出”。 其實，在為新員工培訓系統架構、給領導彙報技術規劃、上技術大會做演講或者向晉升評委介紹工作貢獻的時候，如果你能畫出一張優秀的 軟體系統架構圖，就可以大大提升自己的講解效果，讓對方輕鬆地理解你想表 ...
很多同學技術能力很強，架構設計也做得很好，但是在給別人講解的時候，總感覺像是“茶壺裡煮餃子，有貨倒不出”。
其實，在為新員工培訓系統架構、給領導彙報技術規劃、上技術大會做演講或者向晉升評委介紹工作貢獻的時候，如果你能畫出一張優秀的 軟體系統架構圖，就可以大大提升自己的講解效果，讓對方輕鬆地理解你想表達的關鍵點。
今天，我就會為你分享軟體系統架構圖的畫圖技巧。
4+1視圖
說起軟體系統架構圖，你可能會想到 4+1視圖，畢竟很多學習資料上都說它是架構圖的標準。那麼，到底什麼是4+1視圖呢？是不是只要按照4+1視圖的標準去畫，就沒有問題呢？
我們還是從它的由來說起。1995年，Philippe Kruchten在 論文 中指出了過去用單一視圖描述軟體系統架構的問題，並提出了4+1視圖作為解決方案。
有時，軟體架構的問題來源於系統設計者過早地劃分軟體或者過分地強調軟體開發的某一個方面，比如數據工程、運行時效率、開發策略或團隊組織。此外，軟體架構往往不能解決它的所有“用戶”的問題。……作為補救措施，我們建議使用幾個併發視圖來組織對軟體架構的描述，其中每個視圖分別解決一組特定的問題。
不同視圖之間的關係如下圖所示：
4+1視圖的核心理念是從不同的角度去剖析系統，看看系統的結構是什麼樣的，具體每個視圖的含義是：
-
邏輯視圖：從終端用戶角度看系統提供給用戶的 功能，對應 UML的 class 和 state diagrams。 -
處理視圖：從動態的角度看系統的 處理過程，對應 UML 的 sequence 和 activity diagrams。 -
開發視圖：從程式員角度看系統的 邏輯組成，對應 UML 的 package diagrams。 -
物理視圖：從系統工程師角度看系統的 物理組成，對應 UML 的 deployment diagrams。 -
場景視圖：從用戶角度看系統需要實現的 需求，對應 UML 的 use case diagrams。
（備註：邏輯視圖看到的“功能”和場景視圖看到的“需求”是一回事嗎？答案是否定的。一個需求可能涉及多個功能，例如“取款”這個場景涉及“插卡”“密碼驗證”“出鈔”等功能；而多個需求可能涉及同一個功能，例如“取款”和“轉賬”是兩個不同的需求，但是都涉及“密碼驗證”這個功能。）
我們可以看到，4+1視圖本身很全面也很規範，但是為什麼在實際工作中，真正按照這個標準來畫架構圖的公司和團隊並不多呢？
我認為原因主要有三點：
-
架構複雜度增加：1995年的時候，系統大部分還是單體系統，而現在分散式系統越來越多。如果我們用4+1視圖來表示分散式系統的話，就會遇到困難，比如微服務架構下有那麼多的微服務，Development view 就不好表示。
-
綁定 UML 圖：UML 圖畫架構圖存在問題，主要問題是不美觀，表達能力弱。
（備註：左圖是用UML工具畫的，右圖是用Visio畫的，對比之下，UML圖的缺點十分明顯。）
-
理解困難：邏輯視圖、開發視圖和處理視圖比較容易混淆。比如說，有人把邏輯視圖理解為軟體開發的類結構圖，也有人把處理視圖和開發視圖等同，還有人認為邏輯視圖就是開發視圖。
這些原因導致4+1視圖在目前的實際工作中並不是很實用。那麼，我們到底要怎麼畫軟體系統架構圖呢？
核心指導思想：4R架構定義
其實，很多人之所以畫不好架構圖，最大的痛點就是不好把握到底要畫哪些內容，畫得太少擔心沒有展現關鍵信息，畫得太多又覺得把握不住重點。
所以現在的問題變成了： 應該按照什麼樣的標準來明確架構圖要展現的內容呢？
按照之前講過的4R架構定義
軟體架構指軟體系統的頂層（Rank）結構，它定義了系統由哪些角色（Role）組成，角色之間的關係（Relation）和運作規則（Rule）。
4R是指4個關鍵詞：Rank，Role，Relation和Rule。既然可以通過4R來定義軟體系統的架構，那麼按照4R架構定義的思路來畫架構圖也是很合情合理的，具體步驟如下：
-
第一步，明確Rank：也就是說，不要事無巨細地把一個大系統的方方面面都在一張架構圖中展現出來，而應該明確你要闡述的系統所屬的級別（L0～L4），然後只描述這個級別的架構信息。 -
第二步，畫出Role：從不同的角度來分解系統，看看系統包含哪些角色，角色對應架構圖中的區塊、圖標和節點等。 -
第三步，畫出Relation：有了角色後，畫出角色之間的關係，對應架構圖中角色之間的連接線，不同的連接線可以代表不同的關係。 -
第四步，最後畫出Rule：挑選核心場景，畫出系統角色之間如何協作來完成某項具體的業務功能，對應系統序列圖。
我把描述Role和Relation的架構圖稱為靜態架構圖，描述Rule的系統序列圖稱為動態架構圖。
從某一個角度去看，靜態架構圖的數量跟系統複雜度有關，一般是1～2張，如果比較簡單，用一張圖就夠了，如果比較複雜，就要分別用兩張圖來展現；而動態架構圖是一般是多張，因為核心場景數量不止一個，對應的系統序列圖有多張。
常見架構圖
剛纔介紹4+1視圖的時候，我提到過，從不同的角度去剖析系統，就會得到不同的視圖。其實按照4R架構定義來畫架構圖也是這樣，用不同的方式去劃分系統，就會得到不同類型的架構，分別對應不同類型的架構圖。常見的類型整理如下：
接下來，我就為你詳細地講解每一類架構圖的特點。
1. 業務架構圖
【定義】
描述系統對用戶提供了什麼業務功能，類似於 4+1 視圖的場景視圖。
【使用場景】
-
產品人員規劃業務：比如說我們經常在產品規劃和彙報會議上看到產品人員會用業務架構圖來展現業務全局狀態。 -
給高 P 彙報業務：對於P7+以上級別的技術人員，在彙報的時候不能光講技術，也要講業務的發展情況，用業務架構圖就比較容易的展現業務整體情況。 -
給新員工培訓業務。
【畫圖技巧】
-
通過不同顏色來標識業務狀態：比如說哪些業務發展狀態好，哪些問題比較多，哪些比較穩定，哪些競爭比較激烈等。 -
業務分組管理：將類似的業務放在一個分組裡面展現，用虛線框或者相同背景將其標識出來。 -
區塊對齊：為了美觀，可以改變不同區塊的長短大小進行對齊，讓整體看起來更美觀。
【參考案例】
AlipayHK的一個業務架構圖如下所示：
這張業務架構圖有三點關鍵信息：
-
“MTR”區塊是淺紅色的，“人傳人”區塊是綠色的，淺紅色代表正在進行的，綠色代表明年規劃的。 -
分了4組：錢包業務、第三方業務、商家服務和用戶管理。 -
“轉賬”和“社交紅包”等區塊比較長，只是為了對齊後更美觀，不代表業務本身的量級或者重要程度，如果要表示這樣的信息，那麼可以用顏色來表示。
註意，千萬不要畫得五顏六色，一般一張圖的顏色數量控制在3種以內是比較好的。所以在畫圖的時候你要想清楚，到底哪些信息是要放在業務架構圖中重點展示的關鍵信息，哪些信息順帶講一下就可以了。
2. 客戶端和前端架構圖
【定義】
描述客戶端和前端的領域邏輯架構，關註的是從邏輯的角度如何分解客戶端或者前端應用。
【使用場景】
-
整體架構設計：由客戶端或者前端架構師完成本領域的架構設計。 -
架構培訓。
【畫圖技巧】
-
通過不同顏色來標識不同角色。 -
通過連接線來表示關係，如果有多種關係，例如有的是直接調用，有的是事件通知，那麼可以用不同形狀的線條來表示。 -
分層或分組：將類似的角色分層或者分組管理。
【參考案例】
微信客戶端架構3.x的架構圖如下所示：
這張客戶端架構圖有三點關鍵信息：
-
圖中用了灰色（app:UI等）、藍色（Net Scene等）、深灰色（Storage）、淺藍色（Network）來表示不同類型的模塊。 -
圖中有兩類連接線：雙向的（WebViewUI和app:UI），單向的（app:UI和Net Scene等）。 -
整體上分為4組，對應圖中背景色不同的四個大的區塊。
3. 系統架構圖
【定義】
描述後端的邏輯架構，又叫“後端架構”或“技術架構”，不管是業務系統、中間件系統，還是基礎的操作系統、資料庫系統等，系統架構都是軟體系統架構的核心。
【使用場景】
-
整體架構設計。 -
架構培訓。
【畫圖技巧】
-
通過不同顏色來標識不同角色。 -
通過連接線來表示關係。 -
邏輯分組。
【參考案例】
如果系統比較簡單，可以參考MongoDB Sharding的系統架構圖，如下所示：
如果系統相對複雜，建議首先用一張圖來展示系統架構裡面的角色（Role）以及每個角色的核心功能；然後再用一張圖來展示角色之間的關係（Relation），可以參考一個支付中台的系統架構圖，如下所示：
4. 應用架構圖
【定義】
描述後端系統由哪些應用組成，一個應用就是一個可部署發佈運行的程式，它是項目開發過程中，開發測試運維團隊協作的基礎。
【使用場景】
-
項目開發、測試。 -
運維部署發佈。 -
子域架構設計。
【畫圖技巧】
-
通過不同顏色來標識不同角色。 -
通過連接線來表示關係。 -
複雜系統分域來畫。
【參考案例】
如果系統比較簡單，那麼基本上應用架構和系統架構是等價的，可以參考MongoDB Sharding的應用架構圖，如下所示：
我們可以看到，這張圖中的Router（mongos）、Config Servers 和 Shard（replica set），既包含了系統架構的角色信息（Router、Config Servers 和 Shard），又包含了應用信息（mongos、Config Servers 和 Shard）。
如果系統比較複雜，按照架構分層的角度來看，應用架構已經到了可執行程式這一層，例如支付中台這一類的系統，包含的應用可能有幾百上千個，如果把整個支付中台所有的應用都在一張圖裡面展示出來，信息太多太密，可能會導致架構圖都看不清。
這種情況下，應用架構一般都是按照子域來畫應用架構圖，可以參考支付中台的會員域的應用架構圖，如下所示：
5. 部署架構圖
【定義】
描述後端系統具體是如何部署的，主要包含機房信息、網路信息和硬體信息等。
【使用場景】
-
總體架構設計。 -
運維規劃和優化。
【畫圖技巧】
用圖標代替區塊，這樣看起來更加美觀和容易理解。
【參考案例】
一個簡單的支付系統的部署架構圖如下所示：
6. 系統序列圖
【定義】
描述某個業務場景下，系統各個角色如何配合起來完成業務功能。
【使用場景】
結合“系統架構、應用架構和部署架構”來使用。
【畫圖技巧】
使用UML的序列圖來畫。
【參考案例】
掃碼支付這個支付核心場景的系統序列圖如下所示：
補充說明
如果你曾經研究過架構圖的標準，那麼除了4+1視圖以外，你可能還看到過TOGAF的“業務架構、數據架構（不是指大數據平臺架構，而是指數據資產的架構）、應用架構和技術架構”這種說法，或者還看到過C4架構模型（Context、Container、Component和Code）等等。
但其實目前業界並沒有就架構圖標準達成共識，剛纔提到的TOGAF是企業級的架構，基本上要到CTO這個級別才能接觸的，而C4模型的表達能力又不夠。
總結
今天我介紹了畫軟體系統架構圖的總體思路，以及常見架構圖的應用場景和畫圖技巧，整理如下：
作者|易安
本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/How-to-draw-architecture-design.html
