如何畫好技術(shù)圖？

Y說

好久沒寫技術(shù)文章了，最近也不知道自己一天在忙啥，感覺很忙，但也沒什么產(chǎn)出。這篇文章從周一開始準(zhǔn)備寫，中間大概斷斷續(xù)續(xù)寫了三次，終于在周六寫完了。

其實(shí)自己有很多東西想寫的，但是平時(shí)下了班之后就只想躺著，根本不想動(dòng)腦。早上有時(shí)候又起得比較晚，所以沒有太多的時(shí)間寫東西。感覺可能還是作息不規(guī)律的原因，如果能一直堅(jiān)持早睡早起可能會(huì)好一點(diǎn)，早上的思維比較清醒一點(diǎn)。

但長期堅(jiān)持對(duì)我來說是一件很難的事情，核心原因可能是沒有足夠的動(dòng)力，我應(yīng)該深刻反思。

為什么要寫這篇文章，是因?yàn)樽约阂郧坝X得會(huì)畫圖是一件很簡單的事情，甚至有點(diǎn)鄙視那種只會(huì)畫圖，不寫代碼的“資深程序員”。但后來慢慢才發(fā)現(xiàn)，想要畫好一張圖其實(shí)也不是一件容易的事情，而且畫圖有時(shí)候真的比寫代碼重要，它是值得深入學(xué)習(xí)和掌握的一個(gè)技能。

為什么要畫圖

作為一個(gè)技術(shù)人員，在很多場合可能會(huì)與別人溝通或者交流自己的架構(gòu)設(shè)計(jì)、規(guī)劃等思路，比如在分享、答辯、溝通需求等場景。

我們往往會(huì)寫一個(gè)文檔來描述自己的想法，但科學(xué)研究表明，很多時(shí)候，文字其實(shí)并沒有那么直觀，尤其是在一場會(huì)議中，使用大段的文字可能會(huì)讓觀眾很容易疲勞，容易走神，GET不到重點(diǎn)等。

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

圖的分類

下面列幾個(gè)比較常用的圖的分類。

架構(gòu)圖

《ThoughtWorks現(xiàn)代企業(yè)架構(gòu)框架白皮書》中，把架構(gòu)分為了四個(gè)層次，分別是業(yè)務(wù)、應(yīng)用、數(shù)據(jù)、技術(shù)。

其中最重要的是業(yè)務(wù)架構(gòu)，只有梳理清楚了業(yè)務(wù)，才能指導(dǎo)應(yīng)用、數(shù)據(jù)和技術(shù)架構(gòu)，最終支撐業(yè)務(wù)的快速迭代和發(fā)展。業(yè)務(wù)架構(gòu)的分析過程是復(fù)雜的，最終的產(chǎn)出可能也不僅僅只是一張架構(gòu)圖。還有更細(xì)節(jié)的流程、建模等產(chǎn)出物。

在實(shí)際工作中，筆者其實(shí)很少看到以業(yè)務(wù)視角產(chǎn)出的一張“架構(gòu)圖”，更多的是業(yè)務(wù)流程圖、用例圖。看到更多的是“產(chǎn)品架構(gòu)”和“技術(shù)架構(gòu)”。

一張好的產(chǎn)品架構(gòu)圖大概是這樣，分層次、分模塊講清楚了各個(gè)產(chǎn)品模塊之間的關(guān)系。下圖是一張大型電商產(chǎn)品的全景圖（圖片來自人人都是產(chǎn)品經(jīng)理）。實(shí)際上真正運(yùn)行的系統(tǒng)遠(yuǎn)不止這些，但核心模塊都有所刻畫和體現(xiàn)。

作為技術(shù)開發(fā)人員，在實(shí)際工作中往往會(huì)有很多時(shí)候需要闡明自己的整體技術(shù)設(shè)計(jì)思路。這個(gè)時(shí)候可能需要一張“技術(shù)架構(gòu)”圖，從「技術(shù)的視角」剖析各個(gè)模塊之間的關(guān)系。

我找了好久沒有找到好的一個(gè)小型業(yè)務(wù)系統(tǒng)的技術(shù)架構(gòu)圖，最終找到一個(gè)比較宏觀的圖，后面有機(jī)會(huì)自己找業(yè)務(wù)畫一個(gè)吧。但大體上的結(jié)構(gòu)是類似的，從最底層的存儲(chǔ)，到最上層的接口。右邊是一些通用的運(yùn)維體系或者支撐服務(wù)。

用例圖（操作動(dòng)線）

傳統(tǒng)的UML用例圖是用于描述角色和行為之間的關(guān)系，用例下面可以再拆分用例（或者叫進(jìn)一步用例），類似這種：

但用例圖只是刻畫業(yè)務(wù)行為，并沒有刻畫領(lǐng)域模型、單據(jù)和領(lǐng)域的劃分，所以信息量其實(shí)很少。

流程圖可以刻畫業(yè)務(wù)的核心流程，也可以在流程圖的節(jié)點(diǎn)周圍畫上對(duì)應(yīng)的產(chǎn)品功能、模型或者產(chǎn)生的單據(jù)。比如一個(gè)典型的流程圖（刻畫產(chǎn)品功能）：

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

時(shí)序圖

時(shí)序圖就是接口調(diào)用的時(shí)間關(guān)系，也是開發(fā)人員表達(dá)接口內(nèi)部細(xì)節(jié)的主要工具。比如大家都熟知的OAuth2的時(shí)序圖：

如果不在意色彩等細(xì)節(jié)的話，時(shí)序圖非常推薦使用plant UML來畫，效率比較高。這個(gè)工具我們?cè)诤竺娼榻B。

系統(tǒng)鏈路圖

系統(tǒng)鏈路圖，有時(shí)候也叫服務(wù)鏈路圖。表達(dá)的是各個(gè)微服務(wù)之間的調(diào)用關(guān)系，一個(gè)好的微服務(wù)系統(tǒng)調(diào)用鏈路應(yīng)該是干凈的、單向依賴的，呈一個(gè)“樹狀”，但現(xiàn)實(shí)中如果設(shè)計(jì)不好，經(jīng)常會(huì)有循環(huán)依賴，形成“圖”狀。

實(shí)際上好一點(diǎn)的基建平臺(tái)可以根據(jù)現(xiàn)有的服務(wù)監(jiān)控體系，自動(dòng)生成調(diào)用鏈路圖，不過在設(shè)計(jì)階段肯定是要自己手動(dòng)畫了。

畫圖工具調(diào)研!

draw.io 全能

draw.io是一個(gè)非常優(yōu)秀的畫圖軟件，且是開源，免費(fèi)的。web版本就夠用，通過域名就能直接打開，不需要安裝任何軟件?？梢源鎯?chǔ)到多種介質(zhì)：draw.io的優(yōu)勢(shì)是圖表類型非常豐富，可以畫各種各樣的圖，界面也比較自由。還可以從一個(gè)url中copy模板?？梢哉f是“全能”，一點(diǎn)也不為過。

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

process on 適合國內(nèi)使用

process on是一個(gè)國內(nèi)的類似于draw.io的軟件，免費(fèi)版創(chuàng)建文件有數(shù)量限制，可以開通會(huì)員解除限制。也是web版本可以直接使用。process on的組件沒有draw.io豐富，但基本夠用。

它也有幾個(gè)優(yōu)勢(shì)。第一個(gè)優(yōu)勢(shì)就是它是國內(nèi)的軟件，不需要科學(xué)上網(wǎng)，就能很流暢地使用。同時(shí)它有非常豐富的模板市場，你也可以把自己畫得比較好的圖發(fā)布到模板市場，從中賺取收益。也可以免費(fèi)或者付費(fèi)從模板市場克隆一個(gè)圖，自己在此基礎(chǔ)上修改。

我之前系統(tǒng)梳理過MySQL和Redis的知識(shí)點(diǎn)思維導(dǎo)圖，也賺取了幾十個(gè)大洋。感興趣的朋友可以翻翻我的公眾號(hào)歷史文章，上面有鏈接。

process on的第二個(gè)優(yōu)勢(shì)是它可以團(tuán)隊(duì)協(xié)作，不過我個(gè)人目前還沒遇到過需要團(tuán)隊(duì)協(xié)作畫圖的場景。

它的第三個(gè)優(yōu)勢(shì)是可以畫思維導(dǎo)圖，有點(diǎn)像xmind那種風(fēng)格。雖然draw.io也能畫，但是沒有這個(gè)用起來方便。

飛書 文檔內(nèi)嵌

平時(shí)我自己因?yàn)楣ぷ髟颍玫帽容^多的是飛書文檔。飛書文檔有一個(gè)自帶的畫圖工具，有點(diǎn)像draw.io的閹割版，能使用的組件比較少，只有常用的一些通用組件。

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

plant uml 時(shí)序圖利器

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

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

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

excalidraw 手繪風(fēng)格

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

他說是用一個(gè)叫做excalidraw的工具話的。這也是一個(gè)開源的工具，跟draw.io有點(diǎn)類似，可以選擇自己的存儲(chǔ)介質(zhì)，但官網(wǎng)的因?yàn)椴渴鹪趪庥悬c(diǎn)慢，可以自己私有化部署。還可以使用github的issue來當(dāng)cdn，這樣可以用git來做版本管理。比如這樣：https://github.com/Anddd7/architecture-diagram/issues/1

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

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

它也有對(duì)應(yīng)的劣勢(shì)。比如組件比較少，像圖標(biāo)這些可能要自己通過圖片的方式粘貼進(jìn)去。沒有網(wǎng)格和自動(dòng)吸附，要對(duì)齊的話感覺效率會(huì)稍微低一點(diǎn)。但是也有分組、對(duì)齊和自動(dòng)分布等常用的工具，所以用熟練了其實(shí)也還行。

畫好圖的核心

上面介紹的一些工具，我覺得更多的是“術(shù)”層面的東西。真正要畫好一張圖的核心，還是在“道”的層面要清晰。我總結(jié)為兩點(diǎn)：清晰的思考和準(zhǔn)確的表達(dá)。

清晰的思考

有些人畫圖很快，有些人畫圖很慢。有些人圖一次性就畫好，后面修改得很少，而有些人會(huì)反復(fù)修改，怎么都不滿意。

這背后其實(shí)是你對(duì)這個(gè)圖有沒有一個(gè)清晰的思考。比如畫架構(gòu)圖，需要自己本身對(duì)業(yè)務(wù)和技術(shù)有深入的理解，清楚各個(gè)模塊、層次之間的關(guān)系，才能做到胸有成竹，快速利用軟件把自己心中的圖畫出來。

這里有一個(gè)小技巧，就是剛開始的時(shí)候先畫大的模塊和框架，不要扣細(xì)節(jié)。然后在大的模塊和框架經(jīng)過反復(fù)推敲確定后，再去完善內(nèi)部小的細(xì)節(jié)。這樣整個(gè)圖就不容易在以后被大改了。

準(zhǔn)確的表達(dá)

第二點(diǎn)就是準(zhǔn)確的表達(dá)。因?yàn)閳D是給別人看的，要考慮到面向的對(duì)象是誰，有沒有了解相關(guān)的基礎(chǔ)背景，他關(guān)注的是整體框架還是細(xì)節(jié)。這塊都是需要注意的，可能面向低年級(jí)或同層級(jí)的分享，與面向老板的匯報(bào)，在圖的表達(dá)方式上會(huì)有不同。

同樣的架構(gòu)圖，里面可能有些模塊比較重要，是自己重點(diǎn)想表達(dá)的部分，那這塊可以用面積更大、顏色更醒目等方式來表達(dá)出來。

同理，一期、二期、三期，內(nèi)部的、外部的，已有的、將要建設(shè)的等等，也可以用不同的顏色來區(qū)分，整個(gè)圖應(yīng)該是一目了然的把自己想表達(dá)的東西表達(dá)出來。

學(xué)習(xí)優(yōu)秀案例

技術(shù)文章&博客

想要做好一件事，離不開持續(xù)的學(xué)習(xí)。多看看別人是怎么做的，尤其是優(yōu)秀的人是怎么做的，是快速掌握一門技能的捷徑。

有一些質(zhì)量還不錯(cuò)的技術(shù)網(wǎng)站、論壇、公眾號(hào)等，都可以關(guān)注起來，沒事的時(shí)候看看他們的文章。比如InfoQ、掘金等網(wǎng)站上有大量的個(gè)人博客，比如阿里技術(shù)、字節(jié)技術(shù)、美團(tuán)技術(shù)等大公司的技術(shù)部門官方文章，都是經(jīng)過公司精挑細(xì)選的優(yōu)秀博客，非常值得研究和學(xué)習(xí)。

當(dāng)然，也可以順便關(guān)注一下一個(gè)我這個(gè)籍籍無名的公眾號(hào)“編了個(gè)程”(blgcheng)，共同交流學(xué)習(xí)，哈哈~

開源框架

另一個(gè)很不錯(cuò)的學(xué)習(xí)渠道是看看開源框架的官方文檔或者源碼解讀文檔。比如spring的架構(gòu)圖、tomcat的架構(gòu)圖、k8s的架構(gòu)圖等。因?yàn)槲臋n在開源社區(qū)是一個(gè)很重要的東西，文檔寫得好，使用者就能降低理解門檻，快速使用甚至是加入到開源社區(qū)中來。很多成熟的開源工具都配有非常優(yōu)秀的架構(gòu)圖。

公司內(nèi)部文檔

稍微大一點(diǎn)的公司應(yīng)該都有自己內(nèi)部的知識(shí)庫。里面有很多別的個(gè)人、團(tuán)隊(duì)的總結(jié)和實(shí)踐，也是值得參考和學(xué)習(xí)的對(duì)象，看看他們是怎么理解自己的業(yè)務(wù)，并用技術(shù)文檔、技術(shù)圖來表達(dá)出來的。

但這里可能涉及到公司安全合規(guī)的問題，大家學(xué)習(xí)的時(shí)候要注意規(guī)避風(fēng)險(xiǎn)。

參考文檔

• https://zhuanlan.zhihu.com/p/342136194
• https://www.cnblogs.com/runningsmallguo/p/14621041.html
• https://www.woshipm.com/pd/5319981.html
• 《ThoughtWorks現(xiàn)代企業(yè)架構(gòu)框架白皮書》
  
  
  
  

  
  

  特別說明：本文為了幫助大家理解，有大量的截圖。文中的大多數(shù)圖是在網(wǎng)絡(luò)上找的，尤其是前面的幾張架構(gòu)圖。如果涉及版權(quán)問題請(qǐng)聯(lián)系作者，會(huì)第一時(shí)間刪掉。