如何畫出優秀的軟體架構圖

源碼精品專欄

原創 | Java 2020 超神之路，很肝~

中文詳細注釋的開源項目

RPC 架構 Dubbo 源碼解析

網絡應用架構 Netty 源碼解析

消息中間件 RocketMQ 源碼解析

資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析

作業排程中間件 Elastic-Job 源碼解析

分布式事務中間件 TCC-Transaction 源碼解析

Eureka 和 Hystrix 源碼解析

Java 并發源碼

來源：三畫（阿裡巴巴中間件）

先厘清一些基礎概

1、什麼是架構

2、什麼是架構圖

3、架構圖的作用

4、架構圖分類

怎樣的架構圖是好的架構圖

1、方框代表什麼？

2、虛線、實線什麼意思？箭頭什麼意思？顔色什麼意思？

3、運作時與編譯時沖突？層級沖突？

本文推薦的畫圖方法

1、語境圖(System Context Diagram)

2、容器圖(Container Diagram)

3、元件圖(Component Diagram)

4、類圖(Code/Class Diagram)

案例分享

參考資料：

技術傳播的價值，不僅僅展現在通過商業化産品和開源項目來縮短我們建構應用的路徑，加速業務的上線速率，也展現在優秀工程師在工作效率提升、産品性能優化和使用者體驗改善等經驗方面的分享，以提高我們的專業能力。

當我們想用一張或幾張圖來描述我們的系統時，是不是經常遇到以下情況：

對着畫布無從下手、删了又來？

用一張圖描述我的系統，并且讓産品、營運、開發都能看明白？

畫了一半的圖還不清楚閱聽人是誰？

畫出來的圖到底是産品圖功能圖還是技術圖又或是大雜燴？

圖上的框框有點少是不是要找點兒框框加進來？

布局怎麼畫都不滿意……

如果有同樣的困惑，本文将介紹一種畫圖的方法論，來讓架構圖更清晰。

架構就是對系統中的實體以及實體之間的關系所進行的抽象描述，是一系列的決策。

架構是結構和願景。

系統架構是概念的展現，是對物/資訊的功能與形式元素之間的對應情況所做的配置設定，是對元素之間的關系以及元素同周邊環境之間的關系所做的定義。

做好架構是個複雜的任務，也是個很大的話題，本篇就不做深入了。有了架構之後，就需要讓幹系人了解、遵循相關決策。

系統架構圖是為了抽象的表示軟體系統的整體輪廓和各個元件之間的互相關系和限制邊界，以及軟體系統的實體部署和軟體系統的演進方向的整體視圖。

一圖勝千言。要讓幹系人了解、遵循架構決策，就需要把架構資訊傳遞出去。架構圖就是一個很好的載體。那麼，畫架構圖是為了：

解決溝通障礙

達成共識

減少歧義

圖檔

搜集了很多資料，分類有很多，有一種比較流行的是4+1視圖，分别為場景視圖、邏輯視圖、實體視圖、處理流程視圖和開發視圖。

場景視圖

場景視圖用于描述系統的參與者與功能用例間的關系，反映系統的最終需求和互動設計，通常由用例圖表示。

邏輯視圖

邏輯視圖用于描述系統軟體功能拆解後的元件關系，元件限制和邊界，反映系統整體組成與系 統如何建構的過程,通常由UML的元件圖和類圖來表示。

實體視圖

實體視圖用于描述系統軟體到實體硬體的映射關系，反映出系統的元件是如何部署到一組可 計算機器節點上，用于指導軟體系統的部署實施過程。

處理流程視圖

處理流程視圖用于描述系統軟體元件之間的通信時序，資料的輸入輸出，反映系統的功能流程 與資料流程,通常由時序圖和流程圖表示。

開發視圖

開發視圖用于描述系統的子產品劃分群組成，以及細化到内部包的組成設計，服務于開發人員，反映系統開發實施過程。

以上 5 種架構視圖從不同角度表示一個軟體系統的不同特征，組合到一起作為架構藍圖描述系統架構。

上面的分類是前人的經驗總結，圖也是從網上摘來的，那麼這些圖畫的好不好呢？是不是我們要依葫蘆畫瓢去畫這樣一些圖？

先不去管這些圖好不好，我們通過對這些圖的分類以及作用，思考了一下，總結下來，我們認為，在畫出一個好的架構圖之前， 首先應該要明确其閱聽人，再想清楚要給他們傳遞什麼資訊 ，是以，不要為了畫一個實體視圖去畫實體視圖，為了畫一個邏輯視圖去畫邏輯視圖，而應該根據閱聽人的不同，傳遞的資訊的不同，用圖準确地表達出來，最後的圖可能就是在這樣一些分類裡。那麼，畫出的圖好不好的一個直接标準就是：閱聽人有沒有準确接收到想傳遞的資訊。

明确這兩點之後，從閱聽人角度來說，一個好的架構圖是不需要解釋的，它應該是自描述的，并且要具備一緻性和足夠的準确性，能夠與代碼相呼應。

畫架構圖遇到的常見問題

為什麼适用方框而不是圓形，它有什麼特殊的含義嗎？随意使用方框或者其它形狀可能會引起混淆。

随意使用線條或者箭頭可能會引起誤會。

架構是一項複雜的工作，隻使用單個圖表來表示架構很容易造成莫名其妙的語義混亂。

C4 模型使用容器（應用程式、資料存儲、微服務等）、元件和代碼來描述一個軟體系統的靜态結構。這幾種圖比較容易畫，也給出了畫圖要點，但最關鍵的是，我們認為，它明确指出了每種圖可能的閱聽人以及意義。

下面的案例來自C4官網，然後加上了一些我們的了解，來看看如何更好的表達軟體架構

這是一個想象的待建設的網際網路銀行系統，它使用外部的大型機銀行系統存取客戶賬戶、交易資訊，通過外部電郵系統給客戶發郵件。可以看到，非常簡單、清晰，相信不需要解釋，都看的明白，裡面包含了需要建設的系統本身，系統的客戶，和這個系統有互動的周邊系統。

用途

這樣一個簡單的圖，可以告訴我們，要建構的系統是什麼；它的使用者是誰，誰會用它，它要如何融入已有的IT環境。這個圖的閱聽人可以是開發團隊的内部人員、外部的技術或非技術人員。即：

建構的系統是什麼

誰會用它

如何融入已有的IT環境

怎麼畫

中間是自己的系統，周圍是使用者和其它與之互相作用的系統。這個圖的關鍵就是梳理清楚待建設系統的使用者和高層次的依賴，梳理清楚了畫下來隻需要幾分鐘時間。

容器圖是把語境圖裡待建設的系統做了一個展開。

上圖中，除了使用者和外圍系統，要建設的系統包括一個基于java\spring mvc的web應用提供系統的功能入口，基于xamarin架構的手機app提供手機端的功能入口，一個基于java的api應用提供服務，一個mysql資料庫用于存儲，

各個應用之間的互動都在箭頭線上寫明了。

看這張圖的時候，不會去關注到圖中是直角方框還是圓角方框，不會關注是實線箭頭還是虛線箭頭，甚至箭頭的指向也沒有引起太多注意。

我們有許多的畫圖方式，都對框、線的含義做了定義，這就需要畫圖的人和看圖的人都清晰的了解這些定義，才能讀全圖裡的資訊，而現實是，這往往是非常高的一個要求，是以，很多圖隻能看個大概的含義。

這個圖的閱聽人可以是團隊内部或外部的開發人員，也可以是運維人員。用途可以羅列為：

展現了軟體系統的整體形态

展現了高層次的技術決策

系統中的職責是如何分布的，容器間的是如何互動的

告訴開發者在哪裡寫代碼

用一個框圖來表示，内部可能包括名稱、技術選擇、職責，以及這些框圖之間的互動，如果涉及外部系統，最好明确邊界。

元件圖是把某個容器進行展開，描述其内部的子產品。

這個圖主要是給内部開發人員看的，怎麼去做代碼的組織和建構。其用途有：

描述了系統由哪些元件/服務組成

厘清了元件之間的關系和依賴

為軟體開發如何分解傳遞提供了架構

這個圖很顯然是給技術人員看的，比較常見，就不詳細介紹了。