★ FEATURED ARTICLE 前阵子评审会上同事把画了一下午的系统架构图投到屏幕上六十多个方框红橙蓝绿全用上了箭头从右上角拐到左下角再从中间穿回来。他讲了十分钟底下的问题还是那几个——“这个请求到底先打到哪”“这个服务挂了影响什么”图本身在技术上没错可会议室里没人看得懂。我看了一眼问题就出在“设计”上他画的是“所有知识点”不是“一张图”。diagram-design 不是什么高深理论它就是一门“把复杂结构变成别人能一眼看懂的画面”的手艺。不管你是后端开发、前端工程师、架构岗还是做产品梳理、技术文档总有一天要面对一张必须画清楚的结构图。这篇文章想分享的是我过去这些年画图踩过的坑以及沉淀下来的方法先想清楚再动手、用秩序组织画面、用视觉编码传达语义还有一套能长期维护的绘图工作流。适合所有觉得自己“画得出来但讲不清楚”的人。我会尽量把每个判断背后的理由也讲透这样你就不只是拿到几个结论而是能自己判断下一张图该怎么画。1. 一张让人看不懂的架构图问题通常出在设计而不在工具先说一个反直觉的结论大部分难懂的图不是绘图水平不够也不是工具不给力而是作者把“画图”理解成了“把系统摆上去”。一个系统有三四十个组件、五六种依赖关系原样平铺到画布上结果必然是乱。图表设计的本质是信息设计——决定什么该出现、什么该消失、什么该突出、什么该弱化。1.1 图表设计的第一性原理降低读图成本任何技术图都有一个共同目标让读者用最小的脑力获得最大的信息量。我管这叫“读图成本”。读图成本高表现为读者需要反复确认线条的指向、猜测框的含义、计算箭头经过的路径才能真正理解内容。读图成本低的图读者视线顺着一条主线往下扫重点自然浮现。把概念说直白一点一张架构图就是一张系统说明书的地图。地图的价值不在于画得有多精细而在于它替读者完成了“筛选”。没有人会在一张世界地图上寻找某个小区的早餐店。同样一张给运维看的高可用部署图也不该混入业务方法的调用细节。筛选做得越狠图越好用。这就解释了为什么有些图“看起来什么都没少但就是看不懂”。它缺的往往不是元素而是取舍。1.2 我见过最多的三种失败图我把这些年评审里见过的失败图归纳成三类列成一张表方便你对照自查。失败形态典型症状常见根因调整方向信息过载一张图塞了几十个节点字小到要放大才能看没划清比例尺想把所有细节一次说尽拆成多张图每张只讲一个层级没有方向任意两点之间都有箭头路径相互交叉没确立主流程把所有关联画成平等的线先画主干链路弱化或删掉次要关联视觉噪音每个框带阴影、圆角、渐变、高饱和底色把装饰当设计想让图“看起来专业”固定色板和样式让视觉服务于语义还有一种更隐蔽的失败图中的术语和观众不匹配。给业务方看的图写满了内部服务缩写给开发看的图却用业务黑话。这类问题工具救不了只能是动笔之前先想清楚读者是谁。1.3 三分钟读图法自我检查的硬标准我画完一张图会先不发给任何人给自己设一个三分钟倒计时然后假装自己是第一次看到这张图的人试着回答三个问题这个系统的边界在哪哪些是我方系统哪些是外部依赖数据或请求的主路径是哪条从哪个入口进来最终落到哪里这张图里哪个组件最关键如果我只能记住一个东西该记住什么如果三分钟内答不上来这张图就得回到草稿阶段重做。这个方法看起来很简单但它非常有效因为它模拟了读者真实的行为没人会在评审会上花十分钟仔细辨认每根线。抓住这三点图就成功了一大半。2. 动笔之前先回答四个问题而不是先打开绘图软件很多人画图的第一动作是打开工具、拖一个框出来这恰恰是最大的错误。工具的便利性会让人过早进入“表达阶段”而跳过“思考阶段”。我现在的习惯是先拿一张白纸或用文本编辑器写几个问题想清楚了再碰画布。这四个问题决定了整张图的比例尺、信息密度和呈现方式。2.1 这张图给谁看、在什么场合用读者不同图就不同。给技术委员会做架构评审的图要在系统边界、关键技术选型上做文章给新同学 onboarding 用的图要画请求主链路和核心模块职责给业务方确认流程的图要突出角色、动作和结果弱化技术组件。我自己的经验是一张图只服务于一种读者。如果一份文档里有架构师、运维、新人三类读者那就画三张图而不是画一张“万能图”。万能图等于谁都看不舒服。2.2 读者看完图之后要做什么这一步很少人想但其实比上一步更关键。图的本质是一个决策工具。读者看完后要批准一个方案要定位一个故障要理解一段代码的调用关系还是要在会议上对某个流程表态这个“行动”直接决定了图的内容重点。举个例子。如果是给故障演练用就必须把依赖关系画得清清楚楚哪条链路断了会影响哪块业务每根线的含义都不能模糊如果是给采购审批用重点就变成了系统模块划分和部署形态至于请求怎么走反而可以省略。先想清楚“看完图做什么”再看“图上放什么”顺序不能反。2.3 描述的范围是系统、模块还是组件我习惯把技术图分成四档比例尺全系统语境、系统内部模块、单个模块内部、以及类或接口级别的细节。这四档对应着从“业务负责人”到“一线开发”的不同视角。动笔前先确认你要画的是哪一档。最典型的错误是比例尺漂移明明想画系统模块图画着画着就开始纠结某个服务内部的两个类怎么调结果整张图两头不靠。控制比例尺的方法是规定这一张图里“最小的元素是什么”。如果最小元素是服务那就不要出现数据库表如果最小元素是类那就不要出现跨系统的复杂链路。2.4 这张图要活多久会不会持续演进临时看一眼的草图和要长期维护的架构图画法完全不一样。临时图怎么快怎么来画得糙一点没关系长期图则要考虑源文件如何保存、如何版本化、如何让后来的人改得动。我过去最大的教训就是手工排版的图形文件改一次要花半小时。后来凡是标记了“长期有效”的图我都尽量用可文本化的方式绘制把图形描述以代码形式存档改一行文字就能重新出图。这一点后面工具选型部分会详细展开。现在只要记住先判断图的寿命再决定投入多少设计成本。这四个问题的答案会直接导出图的价值主张。我把它们整理成了一张速查表画图前可以扫一眼。问题答案不同图就不同导出结果给谁看老板 / 同事 / 新人 / 客户术语、粒度、详略看完做什么审批 / 排障 / 学习 / 确认流程内容重点与信息焦点什么比例尺系统 / 模块 / 组件 / 类最小元素与边界活多久一次性 / 长期维护工具选型与存管方式3. 二维平面上组织信息的六条秩序规则想清楚画什么之后真正考验设计能力的就是“怎么摆”。同样一组节点有人摆出来一目了然有人摆出来像毛线团。区别不在审美而在秩序。我总结出六条秩序规则每一条都是实操得出的经验。3.1 流向一致性让视线沿固定方向移动人的阅读习惯天然自带方向。横向图从左到右纵向图从上到下符合直觉。如果非要混着用也要有明确的区块分割——比如上半部分从左到右、下半部分从右到左并分别用容器框住否则读者视线会被掰来掰去。箭头方向必须统一表达“时间”或“依赖”。我通常规定左边是调用方右边是被调方上边是入口下边是出口。在画布上主流程尽量保持一条线贯通分支靠容器边缘展开不要让主路径反复折返。折返一次读图成本就翻一倍。3.2 分层与分块用边界和留白建立“信息容器”人类理解复杂画面靠的是分组。看到三个框靠在一起会自动把它们当作一个整体。你可以主动利用这一点用背景容器、泳道或大括号把节点分成若干组。分组的依据可以是层接入层、业务层、数据层也可以是子系统订单域、支付域、库存域。我常用的做法是先分大区再在大区里排节点。绘制时让同组的节点共享一个背景色或底框视觉上立刻有了层级。容器本身要留足内边距不要让节点贴边否则读者会分不清“框内”和“框外”。3.3 对齐与间距统一图才算“被设计过”很多图乱不是节点多而是节点位置可以随意漂移。同一列节点左边缘不对齐同一行节点上下不齐整间距忽大忽小视觉上就像随意拖出来的。解决方法是给自己上一把尺子用网格对齐至少做到同一列或同一行的节点中心对齐同类节点使用相同宽度相邻间距至少保持一个固定基准值。这个细节不需要专业设计能力只需要强迫症。一张图只要对齐和间距统一了哪怕配色平平也会显得“正规”。相反内容再正确排得歪歪扭扭观众潜意识里就会觉得不可信。3.4 三层次标注标题、图例、编号一张正经的技术图至少要三层标注。最顶层是标题说明“这是什么图、描述的范围、适用于哪个版本”第二层是图例把颜色、线型、箭头样式的含义写清楚第三层是节点编号便于在文档正文中引用比如“模块 N1 收到请求后调用模块 N3”。图例是很多人懒得写的一步但它特别重要。你定义的红色是“外部系统”读者可能理解为“故障”。只要图例在歧义就能消除大半。至于编号长文档里的图务必加上否则正文写“上图中的订单服务”时读者根本没法精准定位。3.5 焦点控制用灰度表达主次一张图只能有一个视觉焦点。想要突出某条链路就把这条链路用高饱和色和粗线表示其余元素统一降级为浅灰或细线。这样读者的视线第一眼落在线索上而不是被五颜六色的节点平均分摊。我画故障链路图时习惯把告警源头涂成警示色把受影响的下游全部用灰色加虚线处理——焦点立刻浮现。焦点控制还意味着敢于删东西如果一个次要关联会让主线变乱宁可删掉用脚注补一句“另有若干配置关系见附录”。3.6 密度控制一张图只承担一个叙事任务最后是总量控制。我的经验法则一张宽屏画布上超过四五十个节点无论怎么设计都会开始难读更好的做法是拆分。不是所有内容都必须放在一张图里也不是所有内容都必须展示在“完整上下文”中才说得清。密度高的图拆分原则通常有两个抓手按层拆——把接入层、业务层、数据层各画一张按链路拆——把主路径和异常分支各画一张。这六条规则组合使用效果最好。先用分层和流向确定骨架再用对齐和间距打磨细节最后用焦点和密度控制做减法。设计感不是灵感是一连串可执行的选择。4. 视觉编码的细节颜色、线条、字体和图标的语义化使用图一旦超过十个元素视觉编码就必须统一。所谓视觉编码就是用颜色、线型、字体、形状这些视觉属性去承载信息。编码越一致读者越省力编码越混乱读者越容易误读。这一节我把四个最关键的编码维度逐一过一遍。4.1 颜色的语义分配与数量上限给颜色赋予固定语义全图保持一致是图表设计性价比最高的一件事。我常用的分配方案是颜色语义典型对象蓝色系我方核心组件应用服务、功能模块绿色系数据存储数据库、缓存、消息队列橙色系外部依赖第三方通道、外部系统红色系异常、高风险告警路径、故障点灰色系次要、弱相关辅助组件、未来规划项色板里的颜色总数不要超过五到七种。颜色一旦超过七个人的短期记忆就撑不住了读者会反复回看图例反而增加负担。同一色系里的深浅变化可以表达严重程度或层级但不要用两个完全不同的色相去表达同一类东西。此外阴影、渐变这类装饰属性要克制它们不承载语义时只会增加视觉噪音。4.2 线条与箭头区分“关联”“依赖”和“数据流”线条是图表里语义最容易被忽略的部分。我认为至少要做三档区分实线箭头表示请求、数据或控制的主要流动方向。虚线箭头表示异步调用、事件订阅、配置引用等弱关系。无箭头实线表示静态关联或对等通信方向不敏感。箭头方向必须单一且明确。双向依赖要么拆成两条线要么在线上注明“相互调用”。一个常见的坏习惯是随手画虚线却不说明虚线的含义结果读者只能猜。图例在这里的价值最大——把线型表写清楚等于给读者发了解码器。4.3 字体与文字排版图里的文字也是设计元素文字在图上承担的是“命名”功能能少就别多。一个节点标题尽量控制在一行内超过十个字的标题需要同时配上缩写或编号正文里再做解释。全图字体统一使用一种无衬线字体别混用衬线和无衬线——那会让注意力从内容跳到“这个字怎么长这样”。字号建议分三级图标题最大容器名次之节点名最小。最小字号也要保证投影后能看清通常不小于 10 到 12 像素对应的显示大小。另外图上文字一律避免长篇说明真想写注释用脚注编号放到图下方或文档正文里。4.4 图标与框型克制使用统一风格图标可以帮助快速识别但代价是引入额外的视觉复杂度和风格问题。第一原则是“要么全用统一风格图标要么全不用”混用不同来源的图标会让图瞬间变得廉价且难读。第二原则是“图标是辅助编码不是主角”。一个节点即使有图标也必须配文字标签不能只放图标。框型方面圆角矩形用于组件、矩形用于实体存储、六边形或菱形用于判断分支这类映射一旦定下就全图一致。很多人喜欢每个节点换一种形状看起来像是为了“有趣”实则让读者需要重新学习每一种形状的含义。4.5 可访问性色弱、打印与深色背景视觉编码做得再好也要过可访问性这关。首先不要只靠颜色区分信息红色和绿色并行使用时部分色弱读者会直接把两者看成一个颜色。因此最好同时用线型、文字或形状做冗余编码。比如故障链路既用红色也加粗线宽外部依赖既用橙色也加大括号。其次考虑黑白打印场景。如果你预感到这张图会被打印出来先转成灰阶看一眼确认灰度层次还能区分主次。最后深色背景下深蓝和黑色会糊在一起如果你要放进深色主题的幻灯片务必提前切换画布背景检查对比度。5. 工具选型与工作流从涂鸦到可维护图表资产的路径工具是绕不开的话题。我不打算做产品推荐而是把我长期用下来的工具类别、取舍逻辑和工作流讲清楚。这里最关键的认知是工具只有适合场景之分没有绝对好坏。你需要的不是最强大的一把锤子而是一套能支撑你完成“草稿—结构化—视觉化—归档”这四步的完整流程。5.1 三类工具分别解决什么问题我把绘图工具粗略分成三大类每一类的优缺点都很明显。类型优点缺点适合的阶段桌面级图形化绘图工具所见即所得、导出格式多、模板丰富大图排版耗时文件版本难管理精细调整、复杂图形的最终出图在线无限画布协作白板上手快、多人实时编辑、适合头脑风暴严谨性不足颜色和形状容易乱早期构思、远程讨论、快速草图基于文本的 DSL 绘图源文件可版本化、可复用、改动高效有学习成本实时预览依赖编辑器长期维护的架构图、大型图表的自动生成从我个人的实践来看一个成熟团队的“图表资产”应该尽量落在第三类上。为什么呢因为第一类工具产出的图形文件本质上是“二进制文档”没法 diff没法合并没法治代码评审流程。而一个系统架构图是要活的——这周加了缓存、下周拆了服务跟着改的图才是资产改不动的一次性文件只是交差。5.2 我目前固定的绘图工作流无论用哪类工具我画一张正式图都会走四步草图阶段先在白板或纸上画粗略的框和箭头这个阶段只谈结构不谈美观。目的是验证我前面提到的四个问题读者是谁、看完做什么、什么比例尺、图活多久。结构化阶段把草图落到 DSL 或图形工具中先不管样式只把节点、分组、连线放全。这个阶段坚持数据与样式分离先把内容铺对。视觉化阶段统一调整颜色、线型、对齐、间距加上标题和图例。这是把“内容正确”升级为“表达清晰”的关键一步。评审与归档阶段让一个不了解上下文的人预览问那三个读图问题。通过后导出 SVG/PNG 产物同时把源文件提交到文档仓库。还有一个细节容易被忽略DSL 源文件和导出的图片要放在同一个目录文件名一一对应。否则几个月后想改图你会对着 PNG 干瞪眼后悔当初没留个 .dsl 文本。5.3 一个文本化 DSL 的示例下面是用类 DSL 的写法描述一个订单核心链路方便你感受“文本化绘图”的样子。实际语法因工具而异但结构大同小异。diagram 订单核心链路 actor 用户 frame 接入层 node 网关 end frame 业务层 node 订单服务 node 库存服务 node 通知服务 end frame 数据层 node 业务库 node 消息队列 end frame 外部依赖 node 支付通道 end 用户 - 网关 : 提交订单 网关 - 订单服务 : 校验并下发 订单服务 - 库存服务 : 锁定库存 订单服务 - 消息队列 : 发布订单事件 通知服务 - 消息队列 : 消费事件 订单服务 - 支付通道 : 发起支付这种写法最大的优点是你可以用代码评审的方式去 review 架构图。有同事说“这里少了一条消息”他会直接指出第几行缺什么而不是对着图片画红圈。改动时也只需要替换一行文字再重新生成图片效率提升非常明显。5.4 版本管理与文档嵌入的实操心得凡是要长期维护的图我都会把它当作代码一样对待进仓库、做版本记录、在提交说明里写清楚“本次图改动的原因”。这样做的好处是三个月后有人问“这张图为什么这么画”git history 会替你还原当时的决策。嵌入文档时也要注意文档里保存的应该是渲染后的静态图加一份指向源文件的链接而不是只粘一张图。这样读者看文档没问题维护者想改图也有入口。另一个实用细节是导出的静态图要控制尺寸太宽的直接在文档里缩略显示点击放大查看大图避免长图把整个页面撑爆。6. 一个真实案例把一团乱麻的业务流程整理成一张可维护的图表理论讲了不少最后用一个我真实处理过的例子把完整链路串一遍。这个案例很适合当作模板原始需求并不复杂但如果处理不当足够画出一张让所有人头晕的图。6.1 原始需求与凌乱的初始草图需求方给的描述大致是这样用户在商城下单系统要检查库存、扣减库存、生成订单、发送通知如果金额达到阈值还要走审批支付成功后要更新订单状态同时通知物流系统发货如果支付失败则自动取消订单并释放库存。此外还有售后流程用户发起退款系统要校验订单状态然后调用原路退回。我第一次在草稿纸上画的时候把所有动作全部画进一张图结果出现了十条互相交叉的箭头——下单流程、审批流程、支付流程、取消流程、退款流程搅在一起根本分不清主次。那一刻我意识到这不是“把流程画出来”的问题是这张图试图同时表达“业务链路”和“状态流转”两件事。6.2 结构化的过程拆节点、定层级、标数据流我做的第一件事是拆分主题词。每一张图只讲一件事所以我决定第一张画“订单正向主流程”第二张画“支付异常与退款流程”第三张画“售后服务子流程”。这里用到的判断标准就是我前面写的“密度控制”——一张图只承担一个叙事任务。以正向主流程为例我先定了三组节点入口动作用户、网关、业务处理订单、库存、通知、外部依赖支付通道、物流。然后把“数据流”和“控制流”分开用户下单是控制流订单状态回写是数据流在图上分别用实线和虚线表达。分层排布之后主路径变成了一条不做折返的横向直线阅读体验立刻清晰。6.3 视觉化调整遮挡、标注、配色结构确定后我开始叠视觉编码。核心链路用高饱和蓝色和粗线库存、支付这些关键依赖用橙色异常分支用灰色虚线但要保留可见。同时在左上角写清楚“主流程版本号 v1.2仅覆盖下单到发货”把图例放在右下角列明线型和颜色的含义。这张图在视觉化阶段最重要的改动是“隐藏了大量条件分支”。审批、退款这些内容全部收到脚注里主图只保留最基本的 happy path 和单点异常回退。这样读者三分钟就能讲清楚主流程而细节依然在配套的辅助图中找得到。6.4 事后复盘这张图后来被改动过六次为什么还能用这张图后来的演进过程很有意思半年内因为业务规则调整改了六次。因为源文件是文本化的每次改动都很快——加一个节点、加一段连线、改一行标签重新出图全程不超过五分钟。如果当初用的是手工排版的大画布这六次改动加起来可能要耗掉一整天。更重要的是图里的视觉语义从第一天就被固定下来后面每次修改都在这套契约里做增量没有出现“为了塞新需求就乱加颜色”的情况。改动记录在仓库里也清清楚楚哪次加了“预售”逻辑、哪次改了“拆单”规则翻历史一目了然。6.5 避坑清单可以直接抄走的经验从这次的案例里我把最容易踩的几个坑整理成清单供你画图前自查。坑后果对策一张图塞下所有流程没有主线读者抓不住重点一个叙事一张图拆成多张控制流和数据流混画箭头含义模糊依赖关系失真用实线/虚线区分并在图例说明条件分支全部展开主路径被截断成碎片分支收进脚注或辅助图图例缺失读者反复猜测颜色和线型含义每张正式图必须配图例源文件不存档横向改动不可维护文本化源文件与渲染产物一起入库避坑不等于不犯错而是犯错之后能及时意识到“这里的设计决策有问题”。我画到现在也经常会在第一版草图里犯错但有了这套流程错误会在结构化阶段就被发现而不是等到评审会上被全屋人围观。最后再分享一点个人体会。做了这么多年 diagram-design我最大的收获不是图好看而是“画图的过程本身就是思考的过程”。很多时候系统设计的缺陷不是在代码 review 里发现的而是在画图时发现的——某个服务没人调用、某个依赖画不出理由、某条链路闭合不上这些都会在你试图把它排成一张有秩序的画面时自己暴露出来。所以每次觉得图难画的时候别急着怪工具也别怀疑自己审美不行大概率是系统本身或你对系统的理解还有一块地方没想通。先把那部分想明白图自然就顺了。这套方法不一定让你一夜之间变成视觉大师但它能保证你画出的每一张图至少讲得清楚、改得动、放得久。
阅读完成 · 觉得有帮助？
