👉 目錄
1 架構圖的目的
2 怎樣的架構圖是好的架構圖
3 什麽時候畫架構圖
4 架構圖分類
5 如何畫架構圖
6 業務/產品架構圖
7 套用架構圖
8 技術架構圖
9 程式碼架構圖
10 數據架構圖
在上一篇文章【4款親測好用的開發畫圖工具】中，有讀者在後台留言提到想了解如何畫好一張架構圖？本文作者從架構圖的目的、怎樣的架構圖是好的架構圖、如何畫好架構圖，以及各類經典架構圖的分類和範例都做了詳盡解析，是一篇不可多得的幹貨文章，建議點贊收藏！
畫架構圖是架構師的一門必修功課。
對於架構圖是什麽這個問題，我們可以按以下等式進行概括：
架構圖 = 架構的表達 = 架構在不同抽象角度和不同抽象層次的表達，這是一個自然而然的過程。
不是先有圖再有業務流程、系統設計和領域模型等，而是相反，用圖來表達抽象的思考和內容。
01
架構圖的目的
A picture is worth a thousand words （一圖勝千言）。
架構圖是架構師、產品經理、開發工程師、測試工程師等各種角色之間進行溝通的語言和橋梁，讓整個團隊更能有效地協調工作。設計圖不單單是架構師要掌握的，在一個產品的開發過程中，任何一個環節和角色都可以透過掌握不同的設計圖來完成溝通。
明確架構方向： 架構圖可以幫助技術團隊明確產品和技術的方向和目標，避免在開發過程中迷失方向或者偏離主題。
降低溝通成本： 將系統邏輯關系以圖形化的形式呈現出來，具有圖形化、視覺化的特點，使得團隊更加直觀地了解產品的設計和功能，盡快達成共識、減少歧義；
提升協作效率： 團隊內部和團隊之間的協作、溝通、願景和指導。透過架構圖可以更好地給計畫成員進行宣講。開發人員可以更加清晰地了解產品的整體結構和各個模組之間的關系，從而提升開發效率。
方便協同工作： 架構圖可以讓團隊成員快速了系統的全貌和細節，方便不同部門之間的協同工作。
架構圖的目標使用者至少有幾類：
參與計畫的各團隊各角色（業務、產品、開發、測試等）；
計畫之外的客戶（外部客戶，外部評審專家）；
各層次 TL（匯報，跨 BU，跨團隊協作溝通）。
02
怎樣的架構圖是好的架構圖
架構圖的好壞標準（個人拙見僅供參考）：一張圖片勝過千言萬語。
結構清晰：觀點明確、層次分明、內容清晰。使用者輕易看出架構圖表達的觀點/關系/思想/邏輯 。 透過架構圖，各個團隊了解業務、套用整體大局。
外表美觀：使用者看得舒服，有更多的瀏覽欲/閱讀欲，透過不同顏色和布局來體現美觀：圖例清晰，顏色型別統一，美觀。
內容完整明確：一張圖內容自閉環，獲取到業務/功能/模組的主要內容。
內容術語一致、資訊粒度大小一致。
具體實施：
1、設計感：設計四大原則。
親密性：實作組織性（讓有關系的元素挨在一起，有區別的元素分開）；
對齊：使頁面統一而且有條理（元素與元素之間存在一些對齊效果）；
對比：增強頁面的效果、有助於資訊的組織（元素與元素之間存在一些對比效果）；
重復：更統一，增強視覺效果（讓類似的元素存在一樣的效果/樣式）。
將這些原則套用到圖的線、塊、面上。
2、美感：色輪的運用。
美術三原色：紅黃藍（在三色場景下，套用最多最廣泛的顏色）；
互補色：一種作為主色，另一種作為強調（在二色場景下，用互補色）；
等距三色組：會讓人愉悅的顏色組合（在三色場景下，使用等距三色組具有愉悅感）；
采用同層級的顏色：具有和諧感的顏色組合（在多色場景下，采用同層級的顏色更具和諧）。
3、美感：黃金分割構圖法。
黃金分割：0.618（圖的整體大小采用長1.618寬1的黃金比）；
婓波那契數列：1，1，2，3，5，8，13，21，34，55，89……，當趨向於無窮大時，前一項與後一項的比值越來越逼近黃金分割0.618。
4、完整感：以終為始的設計
思考先行：以終為始的設計。
列出所有要素：所有能幫助看圖人理解的元素都要有，包括圖例標註、箭頭順序、標題、註解。
使用者為先：把自己當作看圖人，在沒有上下文的情況下能獲取到圖中多少資訊。
03
什麽時候畫架構圖
1）在復雜計畫開始前畫
當要開始設計一個系統性、完整性的系統時，需要透過套用架構圖、技術架構圖明確系統的組成時候。
2）當你覺得是該畫的時候（do it）
如果計畫已經進行了一半，或者計畫都已經結束了，但自己卻從未畫過架構圖。那麽從此刻開始，動手開始畫吧。有一句話「種一棵樹最好的時間是十年前，其次是現在」。
04
架構圖分類
【鵝廠架構師談：如何做好架構設計？】已經從不同的視角，不同的抽象角度去做好架構分類：業務架構、套用架構、技術架構、程式碼架構、數據架構等。
從架構級別來分類，使用金字塔的說明，上層級別包含下層：系統級、套用級、模組級、程式碼級。
系統級，即整個系統內各部份的關系以及如何治理：分層。
套用級，即單個套用的整體架構，及其與系統內單個套用的關系等。
模組級，即套用內部的模組架構，如程式碼的模組化、數據和狀態的管理等。
程式碼級，即從程式碼級別保障架構實施。
業務架構圖：業務規劃、業務模組、業務流程等。
套用架構：微服務拆分的套用和層次劃分。
技術架構：涉及哪些元件以及它們之間的聯系。
程式碼架構：套用內部包圖、類圖 ；
某個領域：實體圖、時序圖、狀態圖、用例圖等等。
05
如何畫架構圖
5.1 架構圖的大方向思路：分層、分治、抽象思維。
橫向分層構建： 按照功能處理順序劃分套用，比如把系統分為 web 前端/中間服務/後台任務，這是面向業務深度的劃分。
縱向是模組劃分和跨層統一相關規範流程： 規範流程一般是放具體的標準、規範等，比如安全管理、品質管理、技術標準規範、開發運維規範等。
抽象思維： 架構構圖中的層次如何劃分？邊界在哪裏？套用模組邊界如何確定，怎樣才能做到高內聚，低耦合。這些都需要抽象思維。
架構抽象有兩種方法，一種是自頂向下，另一種是自底向上；
業務建模，是從小到大，從局部到整體，自底向上的歸納、演繹的抽象過程；
系統建模，是從大到小，從整體到局部，自頂向下的拆解、切分的抽象過程；
但不絕對，自上而下和自下而上，往往在過程中是隨意切換的。
來自於【Thinking in UML】：
5.2 架構圖核心要素：分層、分模組、分功能
橫向分層，縱向切分模組。
分層： 分層也是我們應對和管理復雜性的基本思維武器，目的是為了解耦。將業務按照層級區分，每個層級為獨立的邏輯模組層，每一層專註解決某個領域的問題。下層更抽象，上層更具體 。層級需要有邏輯上的關聯，如下層為上層服務或者提供能力支撐。
分模組： 是在同一邏輯層中，有哪些獨立模組。一個模組代表一個完整的業務或者同型別的業務聚合。每個模組之間相互獨立，且模組之間也會存在依賴或者關聯。
分功能： 在同一個模組內，將獨立的功能劃分出來，該功能可以代表一個業務入口，簡單理解就是一個模組體系中的功能，比較具有代表性，使用者比較關註的功能抽象出來。
在畫架構圖前，有必要對整個業務體系進行系統性思考，將窮舉所有涉及到的套用、功能、系統、模組、能力、平台羅列出來。然後進行提煉、歸納、分類、總結，然後分類構建代替框架思路，最後按照分層、分模組、分功能的維度將具體的內容填充。
5.3 畫圖的細節
總體思路：
透過不同顏色來標識不同角色。
透過連線線來表示關系。
邏輯分組。
我們都用過 UML 畫過類圖，涉及泛化、聚合、組合、依賴等等關系，分別用不同的虛實線、箭頭樣式進行表達。
畫架構圖需要考慮架構圖的組成元素，要保證符合一貫理解，架構圖的組成元素可能涉及：
方框、各種形狀、虛實線、箭頭、顏色（不同顏色代表什麽意思）和文字內容；
虛實線表達什麽？元件型別，模組型別，層，服務，需要考慮是否已經實作等？不同狀態的標識怎麽傳遞？
箭頭表達什麽？數據流或關聯關系？
互動型別可以是同步或異步的；關聯型別可以是指依賴、繼承、實作。
保持架構圖的結構一致性和語意一致性：
架構圖之間應該在方框、形狀、邊框、線條、顏色等方面保持一致。架構圖的結構外觀應該是一樣的，團隊不同成員建立的架構圖不應該給任何一個利益相關者造成理解上的障礙。理想情況下，可以在所有計畫裏使用相同的建模工具。
從語意角度來看，所有的架構圖與最新的程式碼變更之間以及架構圖與架構圖之間都應該定期保持同步，因為一個架構圖的變更可能會影響到其他架構圖。同步可以透過手動進行，也可以透過建模工具自動觸發。透過建模工具自動觸發會更好一些，不過這也取決於具體的計畫。最終的目的是要保持架構圖和程式碼之間的一致性，至於使用什麽樣的方法或工具可以自行決定。Simon Brown 說，「如果架構圖與程式碼失去了聯系，那麽就無法用來改進架構」。他的話其實是在強調保持語意一致性的重要性。
方框、圓角方框、圓球形、橢圓形、圓角方框：
可以參考 E-R 圖也稱實體-聯系圖
方框： 一般表示 實體功能 ，可以用來表達層次。
圓角方框 ： 一般是加工處理、套用服務、 流程規範的模組。
圓形： 一般表示連線點。
橢圓形： 表示一種狀態或者一種活動過程。 也可以表示模組或者實體的內容。
虛線和實線、箭頭： 一般實線框表示的關系強烈程度高於虛線框，虛線框更重於邏輯上的關聯。線條或箭頭可以被理解為數據流（比如從系統 A 到系統 B 的數據流）或元素間的關系（比如元件 A 依賴元件 B）。
方框之間的直線表示模組的呼叫關系；
尾部是空心圓箭頭表示傳遞的是數據；
尾部實心圓箭頭表示傳遞的是控制資訊。
顏色什麽意思？
一個使用了多種顏色的架構圖卻沒有適當的文件說明很容易引起誤解（比如為什麽有些方框是綠色的，而其他是紅色的？為什麽有些線條是黑色的，而有些是藍色的？）。顏色在架構圖裏的作用不是非常大，添加太多的顏色並不會給架構圖帶來更多有價值的資訊。一個僅僅使用了黑白兩色的架構圖也應該是不言自明的，除非非常有必要使用特定的顏色來強調圖中的某些部份。在任何情況下都要保持顏色的簡單性，如果一定要用多種顏色，不要忘了添加說明。
06
業務/產品架構圖
業務架構是從業務、產品視角，描述整個平台、或某個產品的實作。包括業務規劃，業務模組、業務流程，對整個系統的業務進行拆分，對領域模型進行設計，把現實的業務轉化成抽象物件。
6.1 首先要制定業務架構原則
業務架構原則結合實際業務來制定，例如參考電商平台業務：
（1）將業務平台化：
業務平台化，相互獨立，例如交易平台、物流平台、支付平台、廣告平台等。
基礎業務下沈、可復用：例如使用者、商品、類目、促銷、時效等。
（2）將核心業務和非核心業務分離。將電商系統的核心業務和非核心業務如主交易服務和通用交易服務分離，將核心業務精簡（利於穩定），並將非核心業務多樣化。
（3）隔離不同型別的業務。
交易平台的作用是讓買家和賣家簽訂交易合約，所以需要優先保證高可用，讓使用者能快速下單。
履約業務對可用性沒有太高要求，但要優先保證一致性。
秒殺業務對高並行要求很高，應該和常規業務分離。
（4）區分主流程和輔助流程。要清楚哪些是電商系統的主流程，在執行時優先保證主流程的順利完成；對輔助流程可以采用後台異步的方式，避免輔助流程的失敗影響主流程的失敗回流。
6.2 業務/產品模組劃分，即產品架構圖
對產品功能模組的抽象劃分，產品架構主要用於講明白這個產品做什麽的、需要有什麽功能。對需求全盤理解之後，進行高度的抽象分類，然後對各個分類進行對應的產品設計，完成抽象的邏輯梳理和數據梳理，邏輯和數據最終組成一個有機體，成為產品架構。
如何畫產品架構圖？
梳理業務流程，形成閉環：
梳理業務閉環和理清邏輯關系；
業務閉環：使用者使用產品的閉環流程基於使用者的某個需求或問題，梳理使用者使用的業務流程，梳理參與此模組的使用者、角色、場景，將核心流程完整的表述出來，形成閉環。
提取業務需求：
基於核心業務流程，根據使用者的使用場景列出功能模組。關鍵是想清楚每個功能模組解決什麽核心問題。
確定功能模組的邏輯關系：
基於以上梳理出來的功能模組，將類似的、相關聯的功能以模組化的形式形成一張簡單的矩陣圖，將功能模組進行聚合分類。通常按照互動層（入口）、業務層（具體業務環節）、基礎服務層（登入、設定等）、數據層（底層服務或數據）進行歸納整理。
以下是一些產品架構圖的範例：
6.3 業務流程圖
業務流程圖又稱為泳道圖，就是描述哪些個體在什麽條件下做了什麽事情，他們之間有何關聯。主要分三個方面：
涉及到哪些主體？
每個主體都有哪些任務？
各個主體之間怎麽聯系的？一般涉及到多個主體，每個主體之間有聯系。
流程圖鍵的範例，其中包含圖表中使用的一些常見符號：
6.4 任務/功能流程圖
泳道圖一般是從戰略上分析整個業務流程，讓你對公司所做的業務有個大概的了解，而任務流程圖就是在你的產品操作上，使用者透過什麽樣的操作來完成它的目標，比如你去銀行 ATM 機器上取錢，你是如何一步步操作把錢取出來的：
6.5 【畫圖技巧】
透過不同顏色來標識業務狀態：比如說哪些業務發展狀態好，哪些問題比較多，哪些比較穩定，哪些競爭比較激烈等。
業務分組管理：將類似的業務放在一個分組裏面展現，用虛線框或者相同背景將其標識出來。
區塊對齊：為了美觀，可以改變不同區塊的長短大小進行對齊，讓整體看起來更美觀。
註意，千萬不要畫得五顏六色，一般一張圖的顏色數量控制在 3 種以內是比較好的。所以在畫圖的時候你要想清楚，到底哪些資訊是要放在業務架構圖中重點展示的關鍵資訊，哪些資訊順帶講一下就可以了。
07
套用架構圖
套用架構承接業務和技術，是對整個系統實作的總體架構：描述應用程式的邏輯結構和組成，以及各個功能模組之間的關聯和互動關系，用於更好地理解應用程式的設計和實作。
主要內容：
套用原則： 套用架構設計原則或者開發原則。
系統分解： 橫向分層：明確系統的階層設計。縱向功能分解：系統各個層次包含的哪些套用服務。在進行系統耦合性拆分時，要平衡業務和技術的復雜度，保證系統形散神不散。系統采用什麽樣的套用架構，則受到業務復雜度的影響，包括企業的發展階段和業務特點；同時受技術復雜度的影響，包括 IT 技術的發展階段和內部技術人員的水平。業務的復雜度（包括業務量大）必然帶來技術的復雜度，套用架構的目標是在解決業務復雜度的同時避免技術太復雜，確保業務架構落地。
7.1 套用之間的協作
（1）穩定原則：
一切以穩定為中心。
架構盡可能簡單、清晰，追求小而美，不要大而全。
不過度設計。
（2）解耦
將穩定部份與易變部份分離。
將核心業務與非核心業務分離。
將電商主流程和輔助流程分離。
將套用與數據分離。
將服務和實作細節分離。
（3）抽象
套用抽象化：套用只依賴服務抽象，不依賴服務實作的細節和位置。
資料庫抽象化：套用只依賴邏輯資料庫，不需要關心物理庫的位置和分片。
服務抽象化：套用虛擬化部署，不需要關心實體機的配置，動態調配資源。
（4）松耦合
跨域呼叫異步化：在不同的業務域之間盡量異步解耦。
非核心業務盡量異步化：在核心業務和非核心業務之間盡量異步化。
在必須同步呼叫時，需要設定超時時間和任務佇列的長度。
（5）容錯設計
服務自治：服務能彼此獨立修改、部署、釋出和管理，避免引發連鎖反應。
集群容錯：套用系統集群部署，避免單點服務。
多機房容災：多機房部署、多活。
套用架構圖可以分為套用功能/模組架構圖和單個套用技術架構圖。
7.2 套用功能架構圖
站在整個系統的視角，描述整個系統邏輯架構。
簡單來說套用功能架構需要的是體現出套用有哪些業務模組，有哪些具體的業務功能點，而不是關心套用實作的技術內容。可以按照功能處理順序劃分套用層次。
如果系統比較復雜，包含的套用可能有幾百上千個，如果把所有的套用都在一張圖裏面展示出來，資訊太多太密，可能會導致架構圖都看不清。這種情況下，套用架構一般都是按照子體來畫套用架構圖。
7.3 單個套用技術架構圖
套用技術架構描述的重點不是講清楚套用有哪些功能，而是要說清楚套用中的每一個功能是如何透過技術分層來實作的。比如你需要先定義資料庫結構，開發數據存取介面，然後編寫業務規則邏輯，最好實作前端界面展現設計，再將所有分層內容連線起來。
所以套用技術架構更多是套用實作技術層面的內容，而不是去關心套用實作用的底層 IT 基礎設施資源。在套用技術架構裏面一般不會涉及到底層具體的資源或平台，如果套用技術架構在底層增加了類似 IT 基礎設施，儲存等內容，就顯得不倫不類了。
7.4 時序圖，也稱為順序圖、序列圖
描述應用程式模組之間的每一步呼叫過程。有時候某個業務功能的流程會比較復雜，涉及到多種角色或者模組，這時就可以使用時序圖來梳理這個業務邏輯。這樣會使業務看起來非常清晰，程式碼寫起來也是水到渠成的事情了。
08
技術架構圖
技術架構：確定組成套用系統的實際執行元件（lvs，nginx，tomcat，php-fpm 等），這些執行元件之間的關系，以及部署到硬體的策略。突出技術實作，重點描述系統的關鍵技術元件，例如分層、核心技術元件、上下遊通訊方式、數據流向等。
技術架構主要考慮系統的非功能性特征，對系統的高可用、高效能、擴充套件、安全、伸縮性、簡潔等做系統級的把握。
技術架構的設計原則如下：
（1）無狀態，即盡量不要把狀態數據保存在本機上。
（2）可復用。
復用粒度是有業務邏輯的抽象服務，不是服務的實作細節。
服務參照只依賴服務抽象。
（3）松耦合
跨業務域呼叫，盡可能異步解耦。
在同步呼叫時設定超時時間和佇列大小。
將相對穩定的基礎服務與易變流程服務分離。
（4）可治理原則
服務可降級。
服務可限流。
服務可開關。
服務可監控。
白名單機制。
制定服務契約。
（5）基礎服務
基礎服務下沈、可復用，例如時效、庫存和價格計算。
基礎服務自治、相對獨立。
對基礎服務的實作要精簡，並可水平擴充套件。
對基礎服務的實作要進行物理隔離，包括基礎服務相關的數據。
參考的技術架構圖：（圖的通訊層最好是叫接入層），這是典型技術架構圖（主要關註技術元件），每個層涉及到技術的點都羅列出來：
其他摘錄網上相關的圖：
09
程式碼架構圖
代分碼層，讓不同層次的程式碼做不同的動作。層次清晰的程式碼，提高可讀性，從程式碼結構就大概能了解到程式碼是如何分層，每層大概功能是什麽。例如常用的 Controller、Service、Mapper/Dao 三層程式碼結構，其各層的程式碼邏輯範圍。
程式碼架構圖也涉及到 uml 圖：
10
數據架構圖
數據架構是對儲存數據（資源）的架構。描述核心數據模型設計、數據同步和備份的機制等。
其設計原則和套用架構設計大同小異，在設計時需要考慮系統的業務場景，需要根據不同的業務場景對數據進行異構設計、資料庫讀寫分離、分布式數據儲存策略等。如圖是電商系統中數據架構的一個概要。
數據架構的設計原則參考如下：
（1）統一數據檢視，即保證數據的及時性、一致性、準確性和完整性。
（2）數據一致性原則：
明確哪些系統允許弱一致性，但要求透過補償機制保證最終一致性。
（3）數據和套用分離。
套用系統只依賴邏輯資料庫。
套用系統不直接存取其他套用的資料庫，只能透過介面存取。
（4）數據異構，即在源數據和目標數據內容相同時做索引異構，在商品庫不同維度的內容不同時（如訂單數據中的買家庫和賣家庫）做資料庫異構。
（5）資料庫讀寫分離。
將存取量大的資料庫做讀寫分離，例如訂單庫。
將數據量大的資料庫做分庫分表。
將不同業務域的資料庫做分區隔離。
對重要的數據配置備庫。
（6）采用關聯式資料庫。除成本因素外，MySQL 的資料庫擴充套件性和高並行支持能力較強，也比較容易招聘到相關的研發人員和運維人員。
（7）合理利用 NoSQL 資料庫。在資料庫有能力支撐時，盡量不要引入緩存。另外，要合理利用緩存做容災。
-End-
原創作者｜黃規速
