為什么要寫這篇文章，是因?yàn)樽约阂郧坝X得會畫圖是一件很簡單的事情，甚至有點(diǎn)鄙視那種只會畫圖，不寫代碼的“資深程序員”。但后來慢慢才發(fā)現(xiàn)，想要畫好一張圖其實(shí)也不是一件容易的事情，而且畫圖有時候真的比寫代碼重要，它是值得深入學(xué)習(xí)和掌握的一個技能。
作為一個技術(shù)人員，在很多場合可能會與別人溝通或者交流自己的架構(gòu)設(shè)計(jì)、規(guī)劃等思路，比如在分享、答辯、溝通需求等場景。
我們往往會寫一個文檔來描述自己的想法，但科學(xué)研究表明，很多時候，文字其實(shí)并沒有那么直觀，尤其是在一場會議中，使用大段的文字可能會讓觀眾很容易疲勞，容易走神，GET不到重點(diǎn)等。
所以在文檔中插入一些圖示，能夠幫助觀眾更好地理解自己的想法，也能更清晰地表達(dá)整體的設(shè)計(jì)思路，是開發(fā)者非常值得掌握的一個技能。
下面列幾個比較常用的圖的分類。
《ThoughtWorks現(xiàn)代企業(yè)架構(gòu)框架白皮書》中，把架構(gòu)分為了四個層次，分別是業(yè)務(wù)、應(yīng)用、數(shù)據(jù)、技術(shù)。
^架構(gòu)的四個層次^
其中最重要的是業(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ù)流程圖、用例圖?？吹礁嗟氖恰爱a(chǎn)品架構(gòu)”和“技術(shù)架構(gòu)”。
一張好的產(chǎn)品架構(gòu)圖大概是這樣，分層次、分模塊講清楚了各個產(chǎn)品模塊之間的關(guān)系。下圖是一張大型電商產(chǎn)品的全景圖（圖片來自人人都是產(chǎn)品經(jīng)理）。實(shí)際上真正運(yùn)行的系統(tǒng)遠(yuǎn)不止這些，但核心模塊都有所刻畫和體現(xiàn)。
^產(chǎn)品架構(gòu)^
作為技術(shù)開發(fā)人員，在實(shí)際工作中往往會有很多時候需要闡明自己的整體技術(shù)設(shè)計(jì)思路。這個時候可能需要一張“技術(shù)架構(gòu)”圖，從「技術(shù)的視角」剖析各個模塊之間的關(guān)系。
我找了好久沒有找到好的一個小型業(yè)務(wù)系統(tǒng)的技術(shù)架構(gòu)圖，最終找到一個比較宏觀的圖，后面有機(jī)會自己找業(yè)務(wù)畫一個吧。但大體上的結(jié)構(gòu)是類似的，從最底層的存儲，到最上層的接口。右邊是一些通用的運(yùn)維體系或者支撐服務(wù)。
^技術(shù)架構(gòu)^
傳統(tǒng)的UML用例圖是用于描述角色和行為之間的關(guān)系，用例下面可以再拆分用例（或者叫進(jìn)一步用例），類似這種：
但用例圖只是刻畫業(yè)務(wù)行為，并沒有刻畫領(lǐng)域模型、單據(jù)和領(lǐng)域的劃分，所以信息量其實(shí)很少。
流程圖可以刻畫業(yè)務(wù)的核心流程，也可以在流程圖的節(jié)點(diǎn)周圍畫上對應(yīng)的產(chǎn)品功能、模型或者產(chǎn)生的單據(jù)。比如一個典型的流程圖（刻畫產(chǎn)品功能）：
^流程圖^
如果在流程圖上再加上“用戶角色”，刻畫xx角色在xx階段做了xx操作。就是一張“操作動線”圖：
^操作動線^
時序圖就是接口調(diào)用的時間關(guān)系，也是開發(fā)人員表達(dá)接口內(nèi)部細(xì)節(jié)的主要工具。比如大家都熟知的OAuth2的時序圖：
如果不在意色彩等細(xì)節(jié)的話，時序圖非常推薦使用plant UML來畫，效率比較高。這個工具我們在后面介紹。
系統(tǒng)鏈路圖，有時候也叫服務(wù)鏈路圖。表達(dá)的是各個微服務(wù)之間的調(diào)用關(guān)系，一個好的微服務(wù)系統(tǒng)調(diào)用鏈路應(yīng)該是干凈的、單向依賴的，呈一個“樹狀”，但現(xiàn)實(shí)中如果設(shè)計(jì)不好，經(jīng)常會有循環(huán)依賴，形成“圖”狀。
實(shí)際上好一點(diǎn)的基建平臺可以根據(jù)現(xiàn)有的服務(wù)監(jiān)控體系，自動生成調(diào)用鏈路圖，不過在設(shè)計(jì)階段肯定是要自己手動畫了。
^系統(tǒng)鏈路^
draw.io是一個非常優(yōu)秀的畫圖軟件，且是開源，免費(fèi)的。web版本就夠用，通過域名就能直接打開，不需要安裝任何軟件?？梢源鎯Φ蕉喾N介質(zhì)：
draw.io的優(yōu)勢是圖表類型非常豐富，可以畫各種各樣的圖，界面也比較自由。還可以從一個url中copy模板?？梢哉f是“全能”，一點(diǎn)也不為過。
缺點(diǎn)是draw.io是國外的網(wǎng)站，要想流暢使用可能需要科學(xué)上網(wǎng)工具。不過由于draw.io是開源的，所以可以下載離線版本的軟件，或者部署在自己的服務(wù)器上。
process on是一個國內(nèi)的類似于draw.io的軟件，免費(fèi)版創(chuàng)建文件有數(shù)量限制，可以開通會員解除限制。也是web版本可以直接使用。process on的組件沒有draw.io豐富，但基本夠用。
它也有幾個優(yōu)勢。第一個優(yōu)勢就是它是國內(nèi)的軟件，不需要科學(xué)上網(wǎng)，就能很流暢地使用。同時它有非常豐富的模板市場，你也可以把自己畫得比較好的圖發(fā)布到模板市場，從中賺取收益。也可以免費(fèi)或者付費(fèi)從模板市場克隆一個圖，自己在此基礎(chǔ)上修改。
我之前系統(tǒng)梳理過MySQL和Redis的知識點(diǎn)思維導(dǎo)圖，也賺取了幾十個大洋。感興趣的朋友可以翻翻我的公眾號歷史文章，上面有鏈接。
process on的第二個優(yōu)勢是它可以團(tuán)隊(duì)協(xié)作，不過我個人目前還沒遇到過需要團(tuán)隊(duì)協(xié)作畫圖的場景。
它的第三個優(yōu)勢是可以畫思維導(dǎo)圖，有點(diǎn)像xmind那種風(fēng)格。雖然draw.io也能畫，但是沒有這個用起來方便。
平時我自己因?yàn)楣ぷ髟?，用得比較多的是飛書文檔。飛書文檔有一個自帶的畫圖工具，有點(diǎn)像draw.io的閹割版，能使用的組件比較少，只有常用的一些通用組件。
但飛書文檔內(nèi)嵌的畫圖工具最大的好處就是它與文檔的無縫集成，可以隨時隨地直接編輯，不用在文檔和畫圖工具之間切換，目前我大多數(shù)的圖都是直接在飛書文檔上畫的。
plant uml是一個可以用代碼生成圖片的工具，免費(fèi)的。其實(shí)它可以畫很多圖。包括時序圖、類圖、用例圖等。但整體風(fēng)格比較樸素，如果要畫得很好看的話還是不適合用它。
但是plant uml有一個最大的優(yōu)勢就是效率高。尤其是在畫時序圖、UML類圖等場景，如果用draw.io等工具可能要畫很久，但用plant uml可以用幾行代碼很快畫出來。比如：
vscode用plant uml的插件。飛書文檔也可以直接插入plant uml，實(shí)際使用起來還是蠻方便的。
前面提到的更多的在日常技術(shù)文檔中會用到的架構(gòu)圖、類圖、時序圖等。但我做一個架構(gòu)的朋友畫的圖非常有特色，整體非常清晰漂亮，而且有比較明顯的手繪風(fēng)格。比如這張golang微服務(wù)教程，可以用賞心悅目來形容：
他說是用一個叫做excalidraw的工具話的。這也是一個開源的工具，跟draw.io有點(diǎn)類似，可以選擇自己的存儲介質(zhì)，但官網(wǎng)的因?yàn)椴渴鹪趪庥悬c(diǎn)慢，可以自己私有化部署。還可以使用github的issue來當(dāng)cdn，這樣可以用git來做版本管理。比如這樣：
https://github.com/Anddd7/architecture-diagram/issues/1
需要注意的是，這個軟件默認(rèn)是不支持中文的字體。這個fork的倉庫額外安裝了支持中文的字體，大家可以直接拿來部署：
https://github.com/Anddd7/excalidraw。
或者一步到位，直接用部署好的線上版本：
https://excalidraw-anddd7.vercel.app/
它也有對應(yīng)的劣勢。比如組件比較少，像圖標(biāo)這些可能要自己通過圖片的方式粘貼進(jìn)去。沒有網(wǎng)格和自動吸附，要對齊的話感覺效率會稍微低一點(diǎn)。但是也有分組、對齊和自動分布等常用的工具，所以用熟練了其實(shí)也還行。
上面介紹的一些工具，我覺得更多的是“術(shù)”層面的東西。真正要畫好一張圖的核心，還是在“道”的層面要清晰。我總結(jié)為兩點(diǎn)：清晰的思考和準(zhǔn)確的表達(dá)。
有些人畫圖很快，有些人畫圖很慢。有些人圖一次性就畫好，后面修改得很少，而有些人會反復(fù)修改，怎么都不滿意。
這背后其實(shí)是你對這個圖有沒有一個清晰的思考。比如畫架構(gòu)圖，需要自己本身對業(yè)務(wù)和技術(shù)有深入的理解，清楚各個模塊、層次之間的關(guān)系，才能做到胸有成竹，快速利用軟件把自己心中的圖畫出來。
這里有一個小技巧，就是剛開始的時候先畫大的模塊和框架，不要扣細(xì)節(jié)。然后在大的模塊和框架經(jīng)過反復(fù)推敲確定后，再去完善內(nèi)部小的細(xì)節(jié)。這樣整個圖就不容易在以后被大改了。
第二點(diǎn)就是準(zhǔn)確的表達(dá)。因?yàn)閳D是給別人看的，要考慮到面向的對象是誰，有沒有了解相關(guān)的基礎(chǔ)背景，他關(guān)注的是整體框架還是細(xì)節(jié)。這塊都是需要注意的，可能面向低年級或同層級的分享，與面向老板的匯報，在圖的表達(dá)方式上會有不同。
同樣的架構(gòu)圖，里面可能有些模塊比較重要，是自己重點(diǎn)想表達(dá)的部分，那這塊可以用面積更大、顏色更醒目等方式來表達(dá)出來。
同理，一期、二期、三期，內(nèi)部的、外部的，已有的、將要建設(shè)的等等，也可以用不同的顏色來區(qū)分，整個圖應(yīng)該是一目了然的把自己想表達(dá)的東西表達(dá)出來。
想要做好一件事，離不開持續(xù)的學(xué)習(xí)。多看看別人是怎么做的，尤其是優(yōu)秀的人是怎么做的，是快速掌握一門技能的捷徑。
有一些質(zhì)量還不錯的技術(shù)網(wǎng)站、論壇、公眾號等，都可以關(guān)注起來，沒事的時候看看他們的文章。比如InfoQ、掘金等網(wǎng)站上有大量的個人博客，比如阿里技術(shù)、字節(jié)技術(shù)、美團(tuán)技術(shù)等大公司的技術(shù)部門官方文章，都是經(jīng)過公司精挑細(xì)選的優(yōu)秀博客，非常值得研究和學(xué)習(xí)。
當(dāng)然，也可以順便關(guān)注一下一個我這個籍籍無名的公眾號“編了個程”(blgcheng)，共同交流學(xué)習(xí)，哈哈~
另一個很不錯的學(xué)習(xí)渠道是看看開源框架的官方文檔或者源碼解讀文檔。比如spring的架構(gòu)圖、tomcat的架構(gòu)圖、k8s的架構(gòu)圖等。因?yàn)槲臋n在開源社區(qū)是一個很重要的東西，文檔寫得好，使用者就能降低理解門檻，快速使用甚至是加入到開源社區(qū)中來。很多成熟的開源工具都配有非常優(yōu)秀的架構(gòu)圖。
稍微大一點(diǎn)的公司應(yīng)該都有自己內(nèi)部的知識庫。里面有很多別的個人、團(tuán)隊(duì)的總結(jié)和實(shí)踐，也是值得參考和學(xué)習(xí)的對象，看看他們是怎么理解自己的業(yè)務(wù)，并用技術(shù)文檔、技術(shù)圖來表達(dá)出來的。
但這里可能涉及到公司安全合規(guī)的問題，大家學(xué)習(xí)的時候要注意規(guī)避風(fēng)險。
原文：
https://mp.weixin.qq.com/s/tR-tWIakE0f4DMKklYJO6w
如果感覺本文對你有幫助，點(diǎn)贊關(guān)注支持一下
