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