一張好看又易懂的架構圖往往能起到“一圖勝千言”的效果，但有時候，對著畫布無處著手也是很多技術人員真實存在的困境。
縱然畫圖工具十分多樣，各色模板也令人眼花繚亂，但要真正實踐起來似乎還是游離在架構圖的本質之外。
如何用一張圖來描述系統，讓系統的各個參與方都能一目了然？給不同的人看，架構圖的要素有何不同？如何修煉架構思維？日前，就架構圖的制作問題，51CTO技術交流群展開了熱議。本文將從架構圖要表達什么、如何畫好架構圖、怎樣修煉架構思維這三部分進行觀點整理、展開論述。
明確架構圖要表達的是什么
架構圖是什么？是為了抽象地表示軟件系統的整體輪廓、各個組件之間的相互關系以及軟件系統的演進方向的整體視圖。簡言之，是架構在不同抽象角度和不同抽象層次的表達。
從公司層面看，上至戰略與業務架構，下至應用、數據、技術架構，都可以通過架構圖來表示。好的架構圖可以讓各方關系者理解架構決策，解決溝通障礙，盡量減少歧義，達成共識，提升協作效率。
不過在討論中，多數人提到，工作中不同的人群角色對于架構圖的需求是不同的。比如：
老板可能關注的是戰略目標的實現，如何直觀展示出資源整合的情況、企業盈利的方向就是重點；
業務更關注實現業務目標的各項資源支持，就會考慮各職能部門的配合與賦能；
技術需要理解的是架構設計在需求目標上高效、安全、穩定的實現，以及后續風險的規避和靈活的調整。
因此，有人提出，如果只是需要讓架構圖“被理解”，事實上并不復雜。
“對于產品，給出模型圖，標記各個部分的功用。對于運營，給出電路圖，通路和原理不要落下。對于開發，給出零件圖，各項指標要清晰。”
但問題在于，正因為面向人群不同，分層邏輯不同，要想畫出一張人人都懂的架構圖幾乎是不可能的。而且具體到個人，根據看圖的人工作經驗和知識儲備的不同，架構圖能做到的只可能是讓“懂的人一看就懂，并且熟悉環境現有的東西”。
觀點摘要
【邊城浪子】不同層次的溝通需要畫不同的架構圖，實際操作中包括業務架構圖、產品架構圖、開發架構圖、系統架構圖。按照不同的層次可以分L0，L1，L2，L3等，可根據場合進行細化。向領導和客戶匯報，一般畫業務架構圖或產品架構圖，總體設計或部署使用系統架構圖，開發過程中使用開發架構圖。
【Signx】要看懂架構圖，首先要有架構思想，比如為什么用邏輯分層加解耦的方式，為什么有5大設計原則，為什么要搞設計模式。具備了這樣的思想，再去看架構圖就不會如盲人摸象了。當不理解這些基本的思想，再高深的架構圖放到面前也是一堆條條框框，還阻礙了軟件開發人員的發揮。
常見架構圖的分類
軟件開發的流程一般是：需求——開發——測試——發布上線。在其整個生命周期來說，畫架構圖本身是設計工作，屬于前期工作。作圖是為了讓相關協作者有一個共同的具象的參照物，同時也為后續的軟件迭代提供有益的決策依據。
下圖是一個簡單的單體應用架構示意圖。Tomcat里面就包含了所有的邏輯和模塊。通過這種圖，能迅速了解用戶整體的訪問流程。
當然，架構千差萬變，架構圖的類型更是紛繁多樣，業務架構、軟件架構、調用架構、物理架構等等，每一種架構圖都有其特殊的目的，為不同的受眾服務。架構圖本身不需要固定某種形式，但一定要畫的清楚，講的明白。常見的架構圖類型包括：
（一）用例圖：主要用于描述系統的參與者與功能用例間的關系,反映系統的最終需求和交互設計。
（二）邏輯視圖：用于描述系統軟件功能拆解后的組件關系，反映系統整體組成與系統如何構建的過程。面向人群一般是架構師、技術Leader、業務人員，重點突出技術如何組合實現業務藍圖。
（三）物理視圖：用于描述系統軟件到物理硬件的映射關系，比如哪部分軟件跑在哪個硬件上，用于指導軟件系統的部署實施過程。面向人群一般是運維，重點突出如何部署。
（四）進程視圖：用于描述系統軟件組件之間的通信時序，數據的輸入輸出，反映系統的功能流程與數據流程，通常由時序圖和流程圖表示。主要面向開發人員，重點突出業務流程下技術如何跑通。
（五）開發視圖：重點描述軟件在其開發環境中的靜態組織結構，包括系統要分解為哪些模塊、子系統，這些模塊和子系統在代碼庫中怎么組織？如何進行配置管理？主要面向開發人員，反映系統開發實施過程。
需要注意的是，正因為不同的圖是給不同的崗位和工種看的，所以不要苛求去畫一張全方位覆蓋、人人都懂、極其完美的圖。
【PcGhost】看圖的人也需要具備相關的知識和經驗，只可能讓“懂的人一看就懂，并且熟悉環境現有的東西”。不可能做到同時讓產品、運營、開發都看明白。
這是某公司的調用架構，對于了解調用過程很有用。但是，不懂的人就肯定看不懂，而且脫離公司現有環境，這個架構圖的現狀就是個布滿了坑的垃圾……
在討論中，【PcGhost】多次提到，不要總是期待畫出一張滿分的架構圖，架構圖的目的是讓“看圖的人盡快了解現狀”。需要的人能最快地提取到信息就是好圖。在他看來：
1、架構覆蓋的面非常廣泛，不同公司不同時期的不同場景，圖都不一樣。如果是同一個公司，應該從大往小畫，且能做到詳略得當，切忌圖全，不要把所有細節都堆積在一張圖里，這只會增加看圖成本。“就像畫地圖，不是為了畫的好看，而是為了到達目的地。如果地標變了，地圖如何改變，有沒有必要把哪里有棵樹也標出來。”
2、架構設計非常復雜，牽涉到上上下下很多部門，但實際上每個部門都有屬于自己的圖，產品、開發、測試、運維、運營各個部門很多時候看到的都是自己的“一畝三分地”。加上跨部門溝通協調很難，看圖的人的水平也參差不齊，所以更要實際一點，把握好自己畫圖的目標。
3、業務需求總處在動態變化中，架構也需要場景的檢驗，再牛的架構方案如果脫離了實際的業務需求都是空談。“花100萬帶100用戶和花100塊帶100用戶顯然是天壤之別。用戶量只有那么多，架構再高級又有什么用？好的架構師是能‘減少各種風險’的，尤其是能做到‘符合預期+成本最優’。之后，架構可以在符合當前場景的前提下逐步演進。”
如何畫好一張架構圖
架構圖很復雜，要畫出讓人一目了然的圖，首先，要擅長拆解、抽象，一定程度上對業務和技術能融匯貫通；其次，能從各個維度梳理架構邏輯和思維，能針對人群繪制出恰如其分的圖，對受眾而言，好的架構圖應該是不言自明的；最后，架構圖本身是由多種視覺元素構成，無論是形狀、顏色、線條都應該有清晰的語義表示，要防范雜亂無章導致的語義混亂。
具體到如何畫好一張架構圖，在討論中大家提到了多種方法論，其中“C4視圖”較為典型。
【田思源】C4 Model 是Simon Brown提出的一種軟件架構的可視化模型。所謂C4指的是Context（上下文），Containers（容器）， Component（組件），Code（代碼），指代不同Level的架構圖，可以用這些圖表來描述不同縮放級別的軟件架構，每種圖表都適用于不同的受眾。
1、系統上下文圖（System Context Diagram）
Context即系統上下文，這是最高Level的架構圖，也是可以向所有人展示的架構圖，包括技術人員與非技術人員。
所展現的是：
- 本系統的用戶是誰
- 與哪些外部系統有交互
“系統上下文圖”示意圖@C4 model官網
系統上下文圖可以說是一個系統的外觀，不是站在系統內部，而是抽離出來，將本系統看作一個黑盒，站在系統外部來看，來展現與用戶、外部系統間的關系。換句話說，這是顯示系統全景圖的縮小視圖，不暴露系統的內部細節，因此，重點應該放在用戶和軟件系統上，而不是技術和其他實現細節。
2、容器圖（Container Diagram）
這里的“容器”概念，有別于Docker容器，指的是在一個軟件系統中可獨立部署/獨立運行的單元，可以是服務器端 Web 應用、單頁應用、桌面應用、移動應用、數據庫等。
所展現的是：
- 軟件系統的整體形態
- 系統中的職責是如何分布的，容器間是如何交互的
“容器圖”示意圖@C4 model官網
如果說系統上下文圖將本系統看作一個黑盒，那么容器圖則是把這個黑盒打開，這個時候看到的是系統內部的所有容器，及各個容器盤根錯節的交互關系，可以展現容器的主要技術棧，容器間如何通信。這是一個以技術為重點的簡單圖表，對軟件開發人員、支持和運維人員都很有用。
3、組件圖（Component Diagram）
組件圖則是放大和分解某個容器，顯示了容器是如何由多個“組件”組成的，每個組件是什么，它們的職責以及技術/實現細節。
所展現的是：
- 系統由哪些組件/服務組成
- 厘清了組件之間的關系和依賴
“組件圖”示意圖@C4 model官網
組件圖主要供內部開發人員去看，怎么去做代碼的組織和構建，為軟件開發分解交付提供了框架。
4、代碼圖/類圖(Code/Class Diagram)
代碼層則是放大每個組件以顯示它是如何作為代碼實現的。理想情況下，該圖將使用工具（例如 IDE 或 UML 建模工具）自動生成，你應該考慮僅顯示那些想要展示的屬性和方法。
“代碼圖”示意圖@C4 model官網
除了C4視圖之外，還有“4+1視圖”也是較為流行的分類方法。當然，照本宣科不一定有用，但至少這些經典視圖為我們提供了一些常規的打開思路的途徑。
觀點摘要
【喜東東】在畫出一個好的架構圖之前， 首先應該要明確其受眾，再想清楚要給他們傳遞什么信息，所以，不要為了畫一個物理視圖去畫物理視圖，為了畫一個邏輯視圖去畫邏輯視圖，而應該根據受眾的不同，傳遞的信息的不同，用圖準確地表達出來。
【淡漠安然】畫架構圖可以分四步走：
1，搞清楚要畫的架構圖的類型；
2，確認架構圖中的關鍵要素（比如產品、技術、服務）；
3，梳理關鍵要素之間的關聯：包含、支撐、同級并列等；
4，輸出關聯關系清晰的架構圖。
【張業貴】架構圖是一套圖，從不同的視角展示軟件結構。如果繪成一張復雜的全圖，那就只有架構師能看明白。可以有一張面對任何人的總體架構圖，幫助大家快速了解基本信息。其中最不容易看懂的就是分層的表現方式，各個部分的關系并不清楚，就像原子中的電子一樣，你知道它應該存在，但是具體在哪個軌道，還得具體觀察。
如何鍛煉架構思維
架構圖成型后，如何評判其好壞？
就圖本身來說，阿里云產品生態高級技術專家簫逸曾經談到了這樣幾條標準：
- 內容術語一致、信息粒度大小一致，圖例清晰，顏色類型統一，美觀；
- 圖中的信息與相應的抽象級別相關，且滿足利益相關者(合作方)的需求；
- 一張好的架構圖不需要多余的文字解釋！受眾有沒有準確接收到想傳遞的信息；如果它所導致的疑問比它能解釋的問題還要多，那么它就不是一張好的架構圖；
- 架構圖應該幫助每個人看到大局，了解周圍的環境，適當的上下文信息；
- 架構圖應該避免“只見樹木，不見森林”。
不過歸根結底，真正的進步還是要在實踐中獲得。只有開始畫了，才有前行和頓悟的可能。
當然無論是畫架構圖還是讀架構圖，要深化理解，都需要錘煉自身的架構思維。之前在??《史海峰：在時代節點上順勢而為是一種幸運 | 技術人訪談錄》??一文中，史海峰曾提到，培養架構思維，要注意以下三點：
第一，抽象總結的能力。簡言之如何在深刻理解某個復雜的系統后，化繁為簡，用比較簡單的圖或語言，將其描述清楚。不過，鑒于架構是對系統的一種看法，這也就意味著它的答案并非唯一。從不同的視角來看架構，會有不同的理解，也會帶來不同的設計。
第二，由于面向的業務場景是不斷變化的，而在當下的架構設計中，往往需要在非常有限的資源條件內作出取舍，完成比較明確的需求目標，因此在衡量架構設計成敗的時候，往往也沒有定論。
第三，架構的本質一定是圍繞業務目標的，需要考慮業務核心目標是什么、產品核心目標是什么，到技術實現的時候，架構如何能更好地滿足這兩點。同時也要注意業務未來的變化趨向，而不只是自得于在技術層面用了哪些很牛的方案，“因為業務價值不是以技術難度來衡量的”。
最后希望以上內容能對你有所助益，在下一次面對畫布時，心中有丘壑，下筆如有神。
參考鏈接：
