如何畫好技術圖？

Y説

好久沒寫技術文章了，最近也不知道自己一天在忙啥，感覺很忙，但也沒什麼產出。這篇文章從週一開始準備寫，中間大概斷斷續續寫了三次，終於在週六寫完了。

其實自己有很多東西想寫的，但是平時下了班之後就只想躺着，根本不想動腦。早上有時候又起得比較晚，所以沒有太多的時間寫東西。感覺可能還是作息不規律的原因，如果能一直堅持早睡早起可能會好一點，早上的思維比較清醒一點。

但長期堅持對我來説是一件很難的事情，核心原因可能是沒有足夠的動力，我應該深刻反思。

為什麼要寫這篇文章，是因為自己以前覺得會畫圖是一件很簡單的事情，甚至有點鄙視那種只會畫圖，不寫代碼的“資深程序員”。但後來慢慢才發現，想要畫好一張圖其實也不是一件容易的事情，而且畫圖有時候真的比寫代碼重要，它是值得深入學習和掌握的一個技能。

為什麼要畫圖

作為一個技術人員，在很多場合可能會與別人溝通或者交流自己的架構設計、規劃等思路，比如在分享、答辯、溝通需求等場景。

我們往往會寫一個文檔來描述自己的想法，但科學研究表明，很多時候，文字其實並沒有那麼直觀，尤其是在一場會議中，使用大段的文字可能會讓觀眾很容易疲勞，容易走神，GET不到重點等。

所以在文檔中插入一些圖示，能夠幫助觀眾更好地理解自己的想法，也能更清晰地表達整體的設計思路，是開發者非常值得掌握的一個技能。

圖的分類

下面列幾個比較常用的圖的分類。

架構圖

《ThoughtWorks現代企業架構框架白皮書》中，把架構分為了四個層次，分別是業務、應用、數據、技術。

其中最重要的是業務架構，只有梳理清楚了業務，才能指導應用、數據和技術架構，最終支撐業務的快速迭代和發展。業務架構的分析過程是複雜的，最終的產出可能也不僅僅只是一張架構圖。還有更細節的流程、建模等產出物。

在實際工作中，筆者其實很少看到以業務視角產出的一張“架構圖”，更多的是業務流程圖、用例圖。看到更多的是“產品架構”和“技術架構”。

一張好的產品架構圖大概是這樣，分層次、分模塊講清楚了各個產品模塊之間的關係。下圖是一張大型電商產品的全景圖（圖片來自人人都是產品經理）。實際上真正運行的系統遠不止這些，但核心模塊都有所刻畫和體現。

作為技術開發人員，在實際工作中往往會有很多時候需要闡明自己的整體技術設計思路。這個時候可能需要一張“技術架構”圖，從技術的視角剖析各個模塊之間的關係。

我找了好久沒有找到好的一個小型業務系統的技術架構圖，最終找到一個比較宏觀的圖，後面有機會自己找業務畫一個吧。但大體上的結構是類似的，從最底層的存儲，到最上層的接口。右邊是一些通用的運維體系或者支撐服務。

用例圖（操作動線）

傳統的UML用例圖是用於描述角色和行為之間的關係，用例下面可以再拆分用例（或者叫進一步用例），類似這種：

但用例圖只是刻畫業務行為，並沒有刻畫領域模型、單據和領域的劃分，所以信息量其實很少。

流程圖可以刻畫業務的核心流程，也可以在流程圖的節點周圍畫上對應的產品功能、模型或者產生的單據。比如一個典型的流程圖（刻畫產品功能）：

如果在流程圖上再加上“用户角色”，刻畫xx角色在xx階段做了xx操作。就是一張“操作動線”圖：

時序圖

時序圖就是接口調用的時間關係，也是開發人員表達接口內部細節的主要工具。比如大家都熟知的OAuth2的時序圖：

如果不在意色彩等細節的話，時序圖非常推薦使用plant UML來畫，效率比較高。這個工具我們在後面介紹。

系統鏈路圖

系統鏈路圖，有時候也叫服務鏈路圖。表達的是各個微服務之間的調用關係，一個好的微服務系統調用鏈路應該是乾淨的、單向依賴的，呈一個“樹狀”，但現實中如果設計不好，經常會有循環依賴，形成“圖”狀。

實際上好一點的基建平台可以根據現有的服務監控體系，自動生成調用鏈路圖，不過在設計階段肯定是要自己手動畫了。

畫圖工具調研

draw.io 全能

draw.io是一個非常優秀的畫圖軟件，且是開源，免費的。web版本就夠用，通過域名就能直接打開，不需要安裝任何軟件。可以存儲到多種介質： draw.io的優勢是圖表類型非常豐富，可以畫各種各樣的圖，界面也比較自由。還可以從一個url中copy模板。可以説是“全能”，一點也不為過。

缺點是draw.io是國外的網站，要想流暢使用可能需要科學上網工具。不過由於draw.io是開源的，所以可以下載離線版本的軟件，或者部署在自己的服務器上。

process on 適合國內使用

process on是一個國內的類似於draw.io的軟件，免費版創建文件有數量限制，可以開通會員解除限制。也是web版本可以直接使用。process on的組件沒有draw.io豐富，但基本夠用。

它也有幾個優勢。第一個優勢就是它是國內的軟件，不需要科學上網，就能很流暢地使用。同時它有非常豐富的模板市場，你也可以把自己畫得比較好的圖發佈到模板市場，從中賺取收益。也可以免費或者付費從模板市場克隆一個圖，自己在此基礎上修改。

我之前系統梳理過MySQL和Redis的知識點思維導圖，也賺取了幾十個大洋。感興趣的朋友可以翻翻我的公眾號歷史文章，上面有鏈接。

process on的第二個優勢是它可以團隊協作，不過我個人目前還沒遇到過需要團隊協作畫圖的場景。

它的第三個優勢是可以畫思維導圖，有點像xmind那種風格。雖然draw.io也能畫，但是沒有這個用起來方便。

飛書 文檔內嵌

平時我自己因為工作原因，用得比較多的是飛書文檔。飛書文檔有一個自帶的畫圖工具，有點像draw.io的閹割版，能使用的組件比較少，只有常用的一些通用組件。

但飛書文檔內嵌的畫圖工具最大的好處就是它與文檔的無縫集成，可以隨時隨地直接編輯，不用在文檔和畫圖工具之間切換，目前我大多數的圖都是直接在飛書文檔上畫的。

plant uml 時序圖利器

plant uml是一個可以用代碼生成圖片的工具，免費的。其實它可以畫很多圖。包括時序圖、類圖、用例圖等。但整體風格比較樸素，如果要畫得很好看的話還是不適合用它。

但是plant uml有一個最大的優勢就是效率高。尤其是在畫時序圖、UML類圖等場景，如果用draw.io等工具可能要畫很久，但用plant uml可以用幾行代碼很快畫出來。比如：

vscode用plant uml的插件。飛書文檔也可以直接插入plant uml，實際使用起來還是蠻方便的。

excalidraw 手繪風格

前面提到的更多的在日常技術文檔中會用到的架構圖、類圖、時序圖等。但我做一個架構的朋友畫的圖非常有特色，整體非常清晰漂亮，而且有比較明顯的手繪風格。比如這張golang微服務教程，可以用賞心悦目來形容：

他説是用一個叫做excalidraw的工具話的。這也是一個開源的工具，跟draw.io有點類似，可以選擇自己的存儲介質，但官網的因為部署在國外有點慢，可以自己私有化部署。還可以使用github的issue來當cdn，這樣可以用git來做版本管理。比如這樣：http://github.com/Anddd7/architecture-diagram/issues/1

需要注意的是，這個軟件默認是不支持中文的字體。這個fork的倉庫額外安裝了支持中文的字體，大家可以直接拿來部署：http://github.com/Anddd7/excalidraw。

或者一步到位，直接用部署好的線上版本：http://excalidraw-anddd7.vercel.app/

它也有對應的劣勢。比如組件比較少，像圖標這些可能要自己通過圖片的方式粘貼進去。沒有網格和自動吸附，要對齊的話感覺效率會稍微低一點。但是也有分組、對齊和自動分佈等常用的工具，所以用熟練了其實也還行。

畫好圖的核心

上面介紹的一些工具，我覺得更多的是“術”層面的東西。真正要畫好一張圖的核心，還是在“道”的層面要清晰。我總結為兩點：清晰的思考和準確的表達。

清晰的思考

有些人畫圖很快，有些人畫圖很慢。有些人圖一次性就畫好，後面修改得很少，而有些人會反覆修改，怎麼都不滿意。

這背後其實是你對這個圖有沒有一個清晰的思考。比如畫架構圖，需要自己本身對業務和技術有深入的理解，清楚各個模塊、層次之間的關係，才能做到胸有成竹，快速利用軟件把自己心中的圖畫出來。

這裏有一個小技巧，就是剛開始的時候先畫大的模塊和框架，不要扣細節。然後在大的模塊和框架經過反覆推敲確定後，再去完善內部小的細節。這樣整個圖就不容易在以後被大改了。

準確的表達

第二點就是準確的表達。因為圖是給別人看的，要考慮到面向的對象是誰，有沒有了解相關的基礎背景，他關注的是整體框架還是細節。這塊都是需要注意的，可能面向低年級或同層級的分享，與面向老闆的彙報，在圖的表達方式上會有不同。

同樣的架構圖，裏面可能有些模塊比較重要，是自己重點想表達的部分，那這塊可以用面積更大、顏色更醒目等方式來表達出來。

同理，一期、二期、三期，內部的、外部的，已有的、將要建設的等等，也可以用不同的顏色來區分，整個圖應該是一目瞭然的把自己想表達的東西表達出來。

學習優秀案例

技術文章&博客

想要做好一件事，離不開持續的學習。多看看別人是怎麼做的，尤其是優秀的人是怎麼做的，是快速掌握一門技能的捷徑。

有一些質量還不錯的技術網站、論壇、公眾號等，都可以關注起來，沒事的時候看看他們的文章。比如InfoQ、掘金等網站上有大量的個人博客，比如阿里技術、字節技術、美團技術等大公司的技術部門官方文章，都是經過公司精挑細選的優秀博客，非常值得研究和學習。

當然，也可以順便關注一下一個我這個籍籍無名的公眾號“編了個程”(blgcheng)，共同交流學習，哈哈~

開源框架

另一個很不錯的學習渠道是看看開源框架的官方文檔或者源碼解讀文檔。比如spring的架構圖、tomcat的架構圖、k8s的架構圖等。因為文檔在開源社區是一個很重要的東西，文檔寫得好，使用者就能降低理解門檻，快速使用甚至是加入到開源社區中來。很多成熟的開源工具都配有非常優秀的架構圖。

公司內部文檔

稍微大一點的公司應該都有自己內部的知識庫。裏面有很多別的個人、團隊的總結和實踐，也是值得參考和學習的對象，看看他們是怎麼理解自己的業務，並用技術文檔、技術圖來表達出來的。

但這裏可能涉及到公司安全合規的問題，大家學習的時候要注意規避風險。

參考文檔

• http://zhuanlan.zhihu.com/p/342136194
• http://www.cnblogs.com/runningsmallguo/p/14621041.html
• http://www.woshipm.com/pd/5319981.html
• 《ThoughtWorks現代企業架構框架白皮書》

特別説明：本文為了幫助大家理解，有大量的截圖。文中的大多數圖是在網絡上找的，尤其是前面的幾張架構圖。如果涉及版權問題請聯繫作者，會第一時間刪掉。

求個支持

我是Yasin，一個堅持技術原創的博主，我的微信公眾號是：編了個程(blgcheng)

都看到這兒了，如果覺得我的文章寫得還行，不妨支持一下。

文章會首發到公眾號，閲讀體驗最佳，歡迎大家關注。

你的每一個轉發、關注、點贊、評論都是對我最大的支持！

還有學習資源、和一線互聯網公司內推哦