文/明道雲創始人任向晖

在我們IT行業，經常要畫系統架構圖。這是和客戶，上下遊夥伴進行技術和商務溝通的有效工具。幾乎任何一個複雜企業軟件産品和方案都會把系統架構圖作為商業表達的重點。在技術研讨會上，這些架構圖往往是幻燈片的主角，不僅出現在現場屏幕上，還是現場觀衆舉起手機拍照的重點對象。所以，一副精确且大氣漂亮的系統架構圖能夠同時體現公司産品的架構能力和品牌形象。

IT架構圖看起來總是高大上，複雜的系統有時候不知道從何着手，但隻要掌握幾個關鍵步驟，你就能夠做出驚豔的成果來，讓讀者賞心悅目的同時，增強研讀的興趣。

架構圖表達的就是事物的結構，大多數領域都可以用具象的方式來呈現，比如下圖中的人體器官系統圖就顯得一目了然。但是IT行業幾乎沒有具象表達的可能性。不像人體器官系統的直觀視覺表達那麼有效。所以，設計IT系統架構圖，第一步就是要完成合理的“抽象”。

抽象最重要的目标就是決定用什麼樣的顆粒度來列出事物，而不是巨細無遺。這完全取決于架構圖的受衆和想要表達的系統的規模。越是非技術受衆，越要降低顆粒度，越是大型系統，也要降低顆粒度。雖然我們可以在一個架構圖中表達事物的層次，但是平面空間總是有限，就像人體器官分布圖沒辦法呈現細胞組織一個道理。

IT系統架構圖的受衆通常包括客戶和技術夥伴。兩者都想要了解系統的基本原理，不想面對一個黑盒産品，但是非開發者型客戶通常不需要了解過多的技術細節，所以适合使用較高抽象水平的表達。而參與産品生态的開發者、合作夥伴則希望了解更詳細的系統信息，拓撲結構，因此需要一個顆粒度更高的表達版本。這一版本通常出現在産品技術白皮書中。

舉個操作系統的例子。如果要用一個架構圖呈現Windows的系統架構，對普通用戶隻需要切入到系統内核、内存管理、文件系統、GUI、設備管理這樣的大模塊就行。但對于Windows應用開發者，則需要繼續延伸到DLL庫、注冊表、API等技術細節。對于後者，實踐中可能要拆分成若幹個子系統的架構解析才行，因為要把所有的技術細節都放到一張圖中并不友好。如果搞錯了受衆，用過度技術化的細節架構會讓一般讀者無所适從。

最簡單的操作系統架構圖，隻有四個抽象對象

相比較，一個更加詳細的macOS操作系統架構圖

确定了抽象層級，在架構圖上就要列出需要表達的事物對象。因為缺乏具象的參照，所有的對象表達唯一途徑就是文字标簽，最多加上符号圖标。這就要求制作者必須使用規範或約定俗成的事物命名，否則讀者将無法理解。比如，上例中的操作系統架構圖，File System絕對不能寫成Doc System，因為隻有前者是一個規範名稱。

很多IT産品設計中會有自己的獨特命名組件，甚至這些命名沒有任何的語義元素。這些命名在架構圖中出現必須要附加實際含義的說明，否則沒有讀者會知道“海豚系統“是什麼意思。當然IT行業中也會出現強勢壟斷産品，以自己的獨特命名确定行業标準，以至于你不知道都不好意思，這種情況當然另當别論。

當使用圖标和符号來表達事物對象時，要注意選擇規範和識别性強的圖形。在一些非常專業的領域，比如電子電氣架構圖，甚至有對各種組件規範的标準定義。即使有含義準确的符号圖标，依然建議制作時附加上文本标簽，可以讓架構圖的讀者更明晰地理解。相反，沒有圖形，隻有文字的架構圖是完全可以接受的。

得益于該行業突出的模塊化程度，電子電路也有抽象表達的架構圖，但它有嚴謹的繪制規範。

在進入正式的繪制之前，我們還要确定抽象對象之間的關系。這将決定我們用什麼視覺形式來準确地表達架構。

在抽象系統架構中，各種對象之間的關系隻有三種：包含、并列和聯結。比如操作系統包含用戶模式和内核模式，用戶模式和内核模式是并列的，客戶端和服務器是通過TCP/IP協議連接（聯結）的。無論系統多麼龐大和複雜，對象和對象之間的關系就這麼幾種。而且，在平面空間中，無論怎麼演繹，也隻能有效地表達這些有限的關系類型。

你隻需要稍稍瞥一眼下圖，就知道各個方塊所代表的組件彼此之間的關系了。看罷這個參考，我們就可以開始動手繪制了。

鑒于抽象對象之間有限的關系種類，架構圖無非有三種形态：

分叉模式（Branching Model），表達事物的分支

網絡模式（Network Model），表達事物的聯結

通過空間組合，組合以上兩種模式

所以，不必擔心要表達的系統有多麼複雜。隻要認知到系統對象之間的内在關系性質，就不難選擇一個基本形态來表達。如果空間允許，也完全可以綜合運用分叉和網絡一體化表達更完整的系統。

分叉模式

網絡模式

架構圖既然表達的是一個系統，那麼這個系統必然有一個明确的邊界。計算機網絡的邊界是與上一級網絡的連接網關，一個SaaS軟件的邊界是主體應用、其依賴的開源組件和網絡服務。确定邊界後的系統才能盤點内部所包含的組件對象層次和數量。依據第一步所介紹的抽象過程，我們根據受衆需要，決定最終在畫面上布局那些對象。一般而言，一個系統架構圖不宜超過30-40個對象，超出這個限制則可能要考慮提高抽象層次；反過來，如果一個架構圖隻包含寥寥數個對象，那麼我們也犯不着勞累追求架構圖的高要求，轉而用一些簡單的框圖就能夠搞定，這時候，我們應該降低抽象層次，以反映出更具體和詳細的架構信息。

超出這個既定邊界的對象理論上無需繪制，但有時候我們為了表達與外部系統的連接關系，會用次要色彩在邊界線外繪制部分系統邊界外的對象。這有點像某個行政區的地圖中會把連接其他區域的交通線上标上“通往...”。

假設一個系統包含10個子系統，如果往下鑽取一級，就有可能要表達上百個對象。這時候如果輕重不分，則可能讓最終的産出過于繁複。我們可以依據策略的需要進行選擇，隻分支展開系統的一部分，而讓其他部分粗略表達。不必要的細節展現過多，反而讓讀者無法識别出重點。因為每一張架構圖都有明确的溝通目标和上下文，這樣主次有别的表達不僅是合理的，而且很多時候是必要的。

空間位置是架構圖設計的關鍵。我們要按照易于理解的邏輯關系，把抽象對象放到平面上的合理位置。讀者的視覺焦點就可以被空間關系有效引導，從而更直觀地理解系統結構和原理。

在确定空間位置時，根據不同的架構圖基本形态，有幾個重要準則：

（1）分叉模式下，要注意均衡利用空間，避免畫面一部分過度稀疏，一部分過度稠密。為了實現這一點，需要借助矩形框、連接分叉線的幫助。如果遇到了實在窘迫的空間限制，也可以利用Call-out的局部放大設計來利用獨立的空間詳解一個特定模塊。

（2）分叉模式下，依然要關注邏輯次序。在樹狀分叉下，雖然每個分支的地位都是均等的，但是并不意味着可以随便決定次序。設計者依然可以根據同級别對象的主次關系、先後關系來決定排序。

（3）網絡模式下，根據被聯結組件的性質決定南北向。在IT架構設計中，一般把底層的基礎技術組件定義為北向（North Bound），放在架構圖的下方，把高層級的應用組件定義為南向（South Bound），放在架構圖的上方。把中間的各個技術組件依照高低位性質依序排列聯結。這就是我們經常看到的分層技術架構圖。

典型的分層技術架構圖

當然，南北向也不是絕對的上下結構。隻要條理清晰，左右結構也同樣可以表達這些遞進的層次。例如下圖：

（4）網絡模式下，可以将具備聯結關系的對象放在彼此鄰近的位置上，以方便創建清晰的連接線。比如下圖，在同一級别的層次上，可能存在彼此需要聯結的組件。這時候，是放在左邊，中間，還是右邊就有一定的講究了，否則就無法繪制出簡潔的連線。

最後一部分，我提供一些有用的視覺設計技巧，它可以幫助你繪制出更美觀的架構圖。

在抽象架構圖中，會充滿組件框和連接線。無論使用何種繪圖工具，先要定義出标準的圖形樣式、色彩、文本标簽的字體、字号、連接線樣式等。在真個架構圖中，應該依據這些定義好的基本樣式來重複對象，而不是想到哪裡，畫到哪裡。很多架構圖看起來充滿了完全不同的組件樣式，看起來淩亂不堪，就是因為缺乏了這個範式的約束。像下面這張架構圖，制作者顯然是随意在應用色彩和特效填充。

架構圖上的同性質組件隻能使用單一的圖形樣式，字體、字号和粗細都要統一，影響觀感一緻性的還包括字距、文本框邊距（margin）、文本框間距（padding）、文本對齊模式等細節。這些樣式屬性，稍微有一些不一樣，放到一張架構圖中就會一眼看出來，非常不舒服。

原則上，我們應該最少的樣式差異，不要使用過多數量的色彩，不要為了區别事物，把什麼屬性都重新定義一邊。兩類事物之間，靠色彩能區别，靠标簽字号也能區别，甚至僅僅靠色彩明度就能區别，不需要同時變化兩個屬性。

利用計算機領域約定俗成的符号、專有圖标或三維圖形來增強架構圖設計，可以讓讀者更輕松地閱讀架構圖。而且，精緻的畫面可以給讀者傳遞系統的精密度和高質量感受。

用具象物縮略圖來表達系統組件

用三維圖形來表達組件層次

在技術性較強的架構圖中，有時候我們必須向讀者提供一些重要的技術細節，但是架構圖的空間可能不允許我們這麼做。此時，可以使用編号附注或者Call-out連線的旁注來實現。

使用附注來說明系統組件，一般在有具象特征的架構圖中使用

最後，我送上明道雲的系統架構圖。它設計簡潔，充分使用圖标符号來輔助讀者閱讀，很直觀地說明了一個現代的零代碼APaaS産品的技術實現、運行環境和集成方法。僅為了這個架構圖，我們需要産品、研發和市場營銷團隊的通力協作，因為很少有設計師能夠完全懂得複雜的雲原生架構，也很少有架構師和工程師能夠掌握必要的商業美學。

下載高清PDF

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!