當咱們想用一張或幾張圖來描述咱們的系統時，是否是常常遇到如下狀況：數據庫
-
對着畫布無從下手、刪了又來?架構
-
如何用一張圖描述個人系統，而且讓產品、運營、開發都能看明白?併發
-
畫了一半的圖還不清楚受衆是誰?框架
-
畫出來的圖究竟是產品圖功能圖仍是技術圖又或是大雜燴?運維
-
圖上的框框有點少是否是要找點兒框框加進來?微服務
-
佈局怎麼畫都不滿意…高併發
若是有一樣的困惑，本文將介紹一種畫圖的方法論，來讓架構圖更清晰。工具
先釐清一些基礎概念佈局
什麼是架構?url
架構就是對系統中的實體以及實體之間的關係所進行的抽象描述，是一系列的決策。
架構是結構和願景。系統架構是概念的體現，是對物/信息的功能與形式元素之間的對應狀況所作的分配，是對元素之間的關係以及元素同周邊環境之間的關係所作的定義。
作好架構是個複雜的任務，也是個很大的話題，本篇就不作深刻了。有了架構以後，就須要讓干係人理解、遵循相關決策。
什麼是架構圖?
系統架構圖是爲了抽象地表示軟件系統的總體輪廓和各個組件之間的相互關係和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的總體視圖。
架構圖的做用
一圖勝千言。要讓干係人理解、遵循架構決策，就須要把架構信息傳遞出去。架構圖就是一個很好的載體。
那麼，畫架構圖是爲了：
-
解決溝通障礙
-
達成共識
-
減小歧義
架構圖分類
蒐集了不少資料，分類有不少，有一種比較流行的是 4+1 視圖，分別爲場景視圖、邏輯視圖、物理視圖、處理流程視圖和開發視圖。
①場景視圖
場景視圖用於描述系統的參與者與功能用例間的關係，反映系統的最終需求和交互設計，一般由用例圖表示。
②邏輯視圖
邏輯視圖用於描述系統軟件功能拆解後的組件關係，組件約束和邊界，反映系統總體組成與系統如何構建的過程，一般由 UML 的組件圖和類圖來表示。
③物理視圖
物理視圖用於描述系統軟件到物理硬件的映射關係，反映出系統的組件是如何部署到一組可計算機器節點上，用於指導軟件系統的部署實施過程。
④處理流程視圖
處理流程視圖用於描述系統軟件組件之間的通訊時序，數據的輸入輸出，反映系統的功能流程與數據流程，一般由時序圖和流程圖表示。
⑤開發視圖
開發視圖用於描述系統的模塊劃分和組成，以及細化到內部包的組成設計，服務於開發人員，反映系統開發實施過程。
以上 5 種架構視圖從不一樣角度表示一個軟件系統的不一樣特徵，組合到一塊兒做爲架構藍圖描述系統架構。
怎樣的架構圖是好的架構圖
上面的分類是前人的經驗總結，圖也是從網上摘來的，那麼這些圖畫的好很差呢?是否是咱們要依葫蘆畫瓢去畫這樣一些圖?
先不去管這些圖好很差，咱們經過對這些圖的分類以及做用，思考了一下，總結下來。
咱們認爲，在畫出一個好的架構圖以前， 首先應該要明確其受衆，再想清楚要給他們傳遞什麼信息 。
因此，不要爲了畫一個物理視圖去畫物理視圖，爲了畫一個邏輯視圖去畫邏輯視圖，而應該根據受衆的不一樣，傳遞的信息的不一樣，用圖準確地表達出來，最後的圖可能就是在這樣一些分類裏。
那麼，畫出的圖好很差的一個直接標準就是：受衆有沒有準確接收到想傳遞的信息。
明確這兩點以後，從受衆角度來講，一個好的架構圖是不須要解釋的，它應該是自描述的，而且要具有一致性和足夠的準確性，可以與代碼相呼應。
畫架構圖遇到的常見問題
①方框表明什麼?
爲何適用方框而不是圓形，它有什麼特殊的含義嗎?隨意使用方框或者其餘形狀可能會引發混淆。
②虛線、實線什麼意思?箭頭什麼意思?顏色什麼意思?
隨意使用線條或者箭頭可能會引發誤會。
③運行時與編譯時衝突?層級衝突?
架構是一項複雜的工做，只使用單個圖表來表示架構很容易形成莫名其妙的語義混亂。
本文推薦的畫圖方法
C4 模型使用容器(應用程序、數據存儲、微服務等)、組件和代碼來描述一個軟件系統的靜態結構。
這幾種圖比較容易畫，也給出了畫圖要點，但最關鍵的是，咱們認爲，它明確指出了每種圖可能的受衆以及意義。
下面的案例來自 C4 官網，而後加上了一些咱們的理解，來看看如何更好的表達軟件架構。
①語境圖(System Context Diagram)
這是一個想象的待建設的互聯網銀行系統，它使用外部的大型機銀行系統存取客戶帳戶、交易信息，經過外部電郵系統給客戶發郵件。
能夠看到，很是簡單、清晰，相信不須要解釋，都看的明白，裏面包含了須要建設的系統自己，系統的客戶，和這個系統有交互的周邊系統。
這樣一個簡單的圖，能夠告訴咱們，要構建的系統是什麼;它的用戶是誰，誰會用它，它要如何融入已有的 IT 環境。
這個圖的受衆能夠是開發團隊的內部人員、外部的技術或非技術人員。即：
-
構建的系統是什麼
-
誰會用它
-
如何融入已有的 IT 環境
怎麼畫?中間是本身的系統，周圍是用戶和其餘與之相互做用的系統。這個圖的關鍵就是梳理清楚待建設系統的用戶和高層次的依賴，梳理清楚了畫下來只須要幾分鐘時間。
②容器圖(Container Diagram)
容器圖是把語境圖裏待建設的系統作了一個展開。
上圖中，除了用戶和外圍系統，要建設的系統包括一個基於 Java\Spring MVC的 Web 應用提供系統的功能入口，基於 Xamarin 架構的手機 App 提供手機端的功能入口，一個基於 Java 的 API 應用提供服務，一個 MySQL 數據庫用於存儲，各個應用之間的交互都在箭頭線上寫明瞭。
看這張圖的時候，不會去關注到圖中是直角方框仍是圓角方框，不會關注是實線箭頭仍是虛線箭頭，甚至箭頭的指向也沒有引發太多注意。
咱們有許多的畫圖方式，都對框、線的含義作了定義，這就須要畫圖的人和看圖的人都清晰的理解這些定義，才能讀全圖裏的信息。
而現實是，這每每是很是高的一個要求，因此，不少圖只能看個大概的含義。
這個圖的受衆能夠是團隊內部或外部的開發人員，也能夠是運維人員。用途能夠羅列爲：
-
展示了軟件系統的總體形態。
-
體現了高層次的技術決策。
-
系統中的職責是如何分佈的，容器間是如何交互的。
-
告訴開發者在哪裏寫代碼。
怎麼畫?用一個框圖來表示，內部可能包括名稱、技術選擇、職責，以及這些框圖之間的交互，若是涉及外部系統，最好明確邊界。
③組件圖(Component Diagram)
組件圖是把某個容器進行展開，描述其內部的模塊。
這個圖主要是給內部開發人員看的，怎麼去作代碼的組織和構建。其用途有：
-
描述了系統由哪些組件/服務組成
-
釐清了組件之間的關係和依賴
-
爲軟件開發如何分解交付提供了框架
④類圖(Code/Class Diagram)
這個圖很顯然是給技術人員看的，比較常見，就不詳細介紹了。
案例分享
下面是內部的一個實時數據工具的架構圖。做爲一個應該自描述的架構圖，這裏很少作解釋了。若是有看不明白的，那確定是還畫的不夠好。
畫好架構圖可能有許多方法論，本篇主要介紹了 C4 這種方法，C4 的理論也是不斷進化的。
但不管是哪一種畫圖方法論，咱們回到畫圖初衷，是爲了更好的交流，咱們在畫的過程當中沒必要被條條框框所限制。簡而言之，畫以前想好：畫圖給誰看，看什麼，怎麼樣不解釋就看懂。
畫圖的工具備：
-
Keynote
-
Xmind
-
EdrawMax
-
Visio
-
OmniGraffle
-
Process On
-
…
文中物理視圖 Download 地址：
-
Win：http://t.cn/EXAGBDW
-
Mac：http://t.cn/EXAqtxI
做者：三畫
簡介：阿里巴巴技術專家，梓敬、鵬升和餘樂對此文亦有貢獻。三畫曾多年從事工做流引擎研發工做，現專一於高併發移動互聯網應用的架構和開發。