★ FEATURED ARTICLE 很多人觉得画架构图、流程图是最后一步代码写完了补一张图应付文档就行。我过去也这么干过直到有一次在评审会上对着自己上周画的一张大图讲了半天才意识到图形里的某个服务边界画错了而那个错误其实代码里一直存在只是被清晰画出来之后才被发现。从那之后我把diagram-design当成和写代码一样严肃的事来做——先拆结构、再定规范、最后才动手连线。这篇文章把这些年画图的思路、踩坑和可复用的流程完整写出来希望对被画图难、改图更难困扰的人有帮助。1. 内容整体设计与思路拆解1.1 为什么画图是个工程问题而不是艺术问题很多人一提到画架构图就犯怵觉得是设计天赋的事。但我在大量实际项目里得出的结论是画图的核心矛盾从来不是好不好看而是信息准确和观感清晰之间的平衡。或者说绘图更像一场沟通行为而不是美术创作。拿最常见的系统架构图举例一张图里通常要表达几件事系统有哪些核心模块、模块之间怎么调用、数据往哪个方向流动、哪些边界属于哪个团队或环境。这些信息如果只用文字写下来往往几百字都说不清但一张结构好的图能让人十秒内抓住重点。反过来说如果图里只是堆了一堆框和箭头没有层次、没有留白、没有语义明确的配色读者看完之后反而比不看更糊涂。所以我在动手画图之前一定会先问自己三个问题这张图给谁看给决策者看要突出整体链路和关键风险给开发同事看要突出模块边界和接口依赖。这张图回答什么问题是系统怎么跑起来的还是系统哪个部分最容易出问题还是这个新方案长什么样。问题不同图画法完全不同。这张图多久会被改一次一次性汇报图和长期维护的架构图设计标准不是一个级别。把这三个问题想清楚一张图的核心骨架就基本出来了。剩下的配色、图标、线条粗细都是在这套逻辑之上做增量的设计工作而不是反过来先想着怎么画得漂亮。1.2 设计规范让图成为团队协作资产如果说代码有编码规范那绘图就一定要有图面规范。没有规范的团队每个人画图都是各画各的风格五花八门最后文档里的架构图拼在一起像换了三家公司做的。我建议团队至少在图面层面统一几件事统一的颜色语义、统一的图元形状约定、统一的线条样式约定。颜色语义是其中收益最大的一项。比如在一张架构图里可以约定所有基础设施组件用灰色核心业务服务用蓝色外部依赖用橙色异常/告警链路用红色。这样读者不需要看具体文字光看颜色就能知道图里哪部分是核心、哪部分是边缘。颜色语义一旦沉淀成团队约定后面每张图都是在复用同一套视觉字典审图的成本会大幅下降。图元形状方面我常用的约定是圆角矩形代表服务或应用、直角矩形代表存储或静态资源、菱形代表判断或网关、圆柱代表数据库。这不需要严格的某种标准但全团队必须统一。线条上实线表示同步调用虚线表示异步或事件通知粗线表示核心链路上的调用细线表示旁路。这些规范听起来简单实际坚持下去的效果非常明显。就像装修房子之前先定好全屋配色方案一样后面每个房间怎么摆家具都有依据整体不会乱。单一图画得再好看也只是孤例规范之上的每张图才能互相衔接、沉淀成团队知识库。1.3 工具选择背后的取舍逻辑工具是画图绕不开的一环。我见过两类主流画图方案各有明确的使用场景。第一类是可视化拖拽工具优点是上手快、所见即所得适合快速画一次性示意图或与不熟悉的人协作讨论。第二类是图即代码方案也就是用文本描述图的结构和布局再由渲染引擎生成图。这类方案可能刚开始学习成本高一些但一旦掌握版本管理、自动布局、批量修改都变得非常方便。我自己长期依赖的是第二种方案核心原因有两个。一个是可版本化图的源文件可以和代码一样放进仓库里提交记录里能清楚看到这张图的每次变更Review的时候也能像看代码一样逐行审。另一个是可复用一套图元定义可以跨多张图引用改一个公共组件的样式所有引用它的地方会同步更新。这两点在维护大型架构图集时是决定性优势拖拽工具完全没法比。但这不代表拖拽工具没有价值。在实际工作中我经常先用白板或者拖拽工具跟同事快速讨论草图把结构和关系跑通之后再用图即代码的方式落地成正式文档图。两个方案配合使用而不是非此即彼。2. 核心细节解析与实操要点2.1 先把图元分类做清楚容器、实体、连接线、标注一张图看起来复杂拆到底层其实就是四类元素容器、实体、连接线、标注。想通这个分类任何复杂的图都变得可控了。容器是图中用来表达边界的元素比如虚线框表示某个命名空间或某个部署环境不同颜色的分块表示不同团队负责的范围。容器的价值在于让读者第一眼就知道这块归谁管、那部分属于哪个环境。画容器的时候最容易犯的错是嵌套过深两层以下还好三层以上的嵌套会让连线变得很糟心我一般强烈建议最多两层多了就拆子图。实体是图里的节点可以是服务、组件、数据表、外部系统不同语义用不同形状表达前面规范部分已经说过。连接线表达实体之间的关系箭头方向代表调用方向线条样式表达交互类型。很多新手画图只画一条线完全不标注是什么协议或什么动作这往往就是图看了等于没看的根本原因。我在实践中要求自己每条线必须能回答为什么这两个节点之间会有线这个问题。标注是很多人忽略的一类元素但恰恰是标注决定了这张图能否被独立看懂。关键接口的说明、异常分支的备注、链路超时的阈值这些文字信息会让一张图从示意升级成可读文档。我见过太多走了线但看不出怎么走的图加了标注之后就完全不一样了。有一个经验是宁可多一个文字块也不要让读者靠猜来理解一条线。2.2 视觉聚焦主次分明才能传达核心信息一张图如果所有元素一样大、一样粗、一样鲜艳那等于没有重点。人的视觉注意力是有限的画图的人必须替读者提前划好哪里先看、哪里后看的顺序。我用过最有效的方法是三层视觉权重核心链路放在图面最中间、最大、颜色最深支撑组件放在两侧、尺寸适中基础设施和外部依赖放在边缘或底部、颜色最淡。这样读者第一眼看到的一定是图上最重要的那条路径细节可以顺着路径逐步展开。这种视觉引导看起来是很玄的东西其实做起来一点也不复杂——就是控制尺寸、颜色饱和度、位置这三个变量权重高的就大一点、深一点、居中一点。还有一个小技巧在连线密集区域适当增加曲线走向在核心链路上尽量走直线。弯曲的线越多图越显得乱直线越多图越显得有秩序。有一个阶段我画图喜欢加各种曲线觉得圆润好看后来发现读者全都迷失在弯弯绕绕里把非核心连线改成直线或正交折线之后图的可读性立刻提升了。2.3 图即代码方案实操要点布局语法与样式表达图即代码方案的核心优势是用文本把图的结构和样式固化下来。拿一段最常见的图定义来说通常会有节点定义、连线定义、分组定义、样式定义这几块。我见过不少新手上来就堆节点几十个节点堆完之后连线的布局乱成一锅粥根本原因是对布局引擎的机制不够理解。实际上布局引擎遵循就近连接原则两个节点通过一条线连起来就会被尽量放得更靠近。基于这个机制我总结出一个非常实用的绘制顺序先画主链路上的节点和连线再画支链路。如果一上来就把所有边都定义好布局引擎会把图面铺得很散因为它试图同时满足所有靠近关系反而导致没有一个局部是紧凑的。样式表达方面我会尽量用统一的主题变量把颜色、线条、字体都定义成可复用的变量。比如定义主色、辅色、边框色、字体大小、线条粗细在渲染时引用这些变量后面想换整套配色只需要改几行变量定义而不需要逐个节点去改。这跟CSS定义设计变量的思路是类似的一旦用熟了改图效率会高出很多。下面给一个非常精简的示例展示一个订单服务如何依赖用户服务和库存服务并且这两个依赖关系如何区分同步与异步。结构与样式完全分离改起来非常方便。frontend: type: service title: 订单前端 style: color: blue ordersvc: type: service title: 订单服务 usersvc: type: service title: 用户服务 stocksvc: type: service title: 库存服务 frontend - ordersvc: title: HTTP/JSON style: stroke: solid ordersvc - usersvc: title: RPC style: stroke: solid ordersvc - stocksvc: title: MQ style: stroke: dashed这种表达方式的优势在 Review 时特别明显。你不需要打开图形化界面就能靠读文本内容理解图的逻辑谁调谁、用什么方式调、两个调用之间的差异在哪里。一旦团队形成用文本Review图的习惯绘图就不再是一个边缘行为而是融进开发流程里的正事。3. 实操过程与核心环节实现3.1 从需求到草图先写文字版结构很多人画图失败不是画工不行而是根本没想清楚要画什么。我有个习惯是先写文字版结构再开画布。也就是先用几行文字把这张图的核心元素列出来像一个粗粒度的大纲核心入口订单前端核心服务订单服务依赖服务用户服务、库存服务、支付服务数据存储订单库、库存缓存外部边界消息队列、短信网关写清楚这五行以后图的边界就定了。我见过很多图之所以越画越乱就是因为画到一半突然觉得这里可以加个XX组件、那边好像也需要提一下——文字大纲的好处就是把这些冲动挡在外面所有新想法先回到大纲层面评估确实重要再补进结构否则就是无边界扩张。有一个非常经典的案例是某次画跨端同步方案的图本来只涉及三个客户端和一个同步服务后来团队在讨论时反复提到旧版本兼容逻辑。如果直接加进主图主图会变得非常臃肿。后来我把旧版本兼容单独拆成一张子图主图保持清爽子图承载细节两张图分别讲清楚不同层面的事效果比硬塞在一起好很多。这个经验后来我频繁使用主图讲主体思路子图装细节两者用子图引用的方式挂接。草图阶段除了文字结构我也会在白板上画非常潦草的框线稿确认连线和分组位置大约五到十分钟就能完成。这个草稿不需要好看它存在的意义是让手的动作先于完美主义进入状态把结构上的问题在最廉价的阶段暴露出来。3.2 核心绘制步骤搭骨架、连链路、标语义等文字结构和草图都通过之后才进入真正的图面绘制。我的标准流程是固定三步搭骨架、连链路、标语义。这三步不要颠倒前一步没做完之前不要动后一步。第一步搭骨架只放容器和实体节点不画任何连线。这一步的目标是把有哪些东西放清楚相当于在纸上把一堆词汇摆好位置。放节点的时候我会顺手把分组的边界框画出来也就是哪些节点属于同一环境或团队。这一步之后图应该已经能看出分块的轮廓虽然还很空但结构雏形是清楚的。第二步连链路把节点之间的连线建立起来。连线的顺序有讲究先连核心链路的线再连支链路的线最后补边缘依赖。我在第一步就把核心节点放在中间就是为了连线时让最重要的线条短而直。连线时我给每条线配上语义HTTP同步调用、消息事件、数据读取这些语义决定线条用实线还是虚线以及线上要不要加文字标签。第三步标语义给关键节点和关键路径加标注文本。这里我有一条铁律每条标注都必须回答这句话对读者理解系统有什么用。如果一句话只是把代码里的类名抄过来那不加。标注要写的是常量阈值、失败分支、超时设置、协议版本这类看了图不用再去翻代码的信息。完成这三步之后图已经具备完整的信息价值。之后才是美化阶段——调颜色、调字体、调边距。我见过很多新手把顺序反过来先花大量时间调样式再补内容结果结构一变整张图推倒重来时间全浪费掉了。先内容后样式是画图效率的第一准则。3.3 布局优化与检查清单图面绘制完成以后我会按照一个检查清单过一遍专门处理能看清这个问题。这个清单是我自己吃过几次亏之后总结出来的每次出图之前必须跑一遍有没有节点重叠重叠的节点在导出图片时特别难看而且阅读时会产生严重的歧义。有没有线穿过不相关的节点如果有需要调整节点位置或分组边界。文字有没有被截断或挤压换行文本过长时优先缩短文案其次才是扩大图形尺寸。图例是否清晰如果图里用了特殊颜色或线条一定要配图例让读者不至于靠猜。留白是否充足元素四周的空白空间如果不够视觉上会显得非常拥挤也增加误读概率。留白这一点我很想多说一句。很多工程师画图习惯把图面铺得满满当当好像每个像素都要用上。但信息密度过高恰恰是图读不懂的最大原因。留白不是浪费空间而是给读者的眼睛换气的机会。我把留白当作一种主动的设计手法核心区域附近留白多一点读者的视线就更集中边界区域密一点读者就知道这是次要信息。控制留白比例也是控制阅读节奏这一点在实践中比想象中影响大得多。这里我假设一个真实场景来走一遍完整流程。假设要画一个订单系统的核心交易链架构图边界是从用户下单到库存扣减涉及三个核心服务和一个消息队列。文字结构是入口下单API网关核心订单服务依赖库存服务、支付服务存储订单库、库存缓存异步订单事件经MQ到结算服务按照三步法第一步把网关、订单服务、库存服务、支付服务放在中间订单库贴在订单服务旁边MQ放在偏下位置第二步连接网关→订单服务→库存服务和订单服务→MQ→支付服务两条链路第三步给网关→订单服务标创建订单QPS上限XXX给订单服务→库存服务标预扣库存超时200ms走补偿。这样画完的图一个完全不了解系统的人也能说出系统的骨架是什么、主链路在哪里、失败降级方案大概是什么样。4. 常见问题与排查技巧实录4.1 一眼定位问题绘图排障速查表图面出问题之后最怕的就是对着图发呆不知道从哪里下手。我整理了一张速查表遇到问题先对号入座大部分情况都能快速定位。图面现象最可能的根因快速处置方案文字重叠字体设置偏大节点空间不足优先压缩文字内容其次增大节点尺寸布局整体乱散连线过多导致布局引擎尽力平衡拆成多张子图降低单图节点数核心链路不明显所有节点视觉权重一致调大核心节点尺寸加深颜色饱和度线穿过无关节点节点位置和分组边界不够合理调整分组边界框移动支链路节点导出后模糊渲染清晰度参数太低按目标媒介倍率导出文档用至少2倍图改了图但没生效样式变量被局部覆盖检查是否有局部样式优先级更高这里面布局整体乱散是出镜率最高的一个问题。我后来总结了一个比较稳的经验单张图里的节点数量尽量控制在15到25个之间超过这个区间不管手工怎么调阅读体验都会明显下降。如果形态上确实需要展示几十个节点那就拆成多张子图或者用高内聚图全局总览图两层结构。总览图只放大的模块边界细节图分别展开每个模块内部结构两套图的组合传达的信息量远大于一张硬塞的巨图。4.2 几类反复踩的坑与避坑方案坑一文字内容永远是图里最后才调整的元素。实际经验是文字占用的空间往往决定整张图的尺寸。如果一张图画完发现某些区域很空、某些区域挤爆大概率是文字的表述长度差异太大导致的。我现在的做法是画图前先统一标注语言的颗粒度能用三个字说清的就别用十二个字比如订单服务不要写成订单服务组件含状态机与持久化后者放进图例或文末备注里而不是直接堆在图上。坑二只画正常路径而不画失败路径。很多架构图的读者是运维或值班同学他们最关心的恰恰是出问题时链路怎么走。如果图里只画正常调用链看的人遇到故障时根本不能用图做判断。从设计思维上我在画图时会刻意问自己这条路断了会怎样然后决定要不要把降级链路、重试分支、备用通道画出来。如果一张图承载不了这么多层就需要额外画一张故障路由图—为了故障排查而画的图和为了功能说明而画的图本来就是两种不同的图。坑三同步和异步的线条样式不统一。这看起来是个小事但在多人协作时特别容易出乱子。有人用实线表示所有调用、有人用虚线表示弱依赖最后图里意义含糊不清。解决方案很简单任何团队只要定一次规范就够了同步调用一律实线异步消息一律虚线文件读取用点线。把这一条写进团队的文档规范里比每张图都重新解释一遍要省力得多。坑四颜色乱用导致图面廉价感。我有一阵子特别喜欢用高饱和度的颜色画完自己觉得挺醒目发给几个同事看大家的第一反应都是好花啊。后来我引入了统一的调色板限制每张图最多用四到五种颜色并且优先选择低饱和度的底色。这个改变让图的整体观感立刻上升了一个档次。具体操作为主色用蓝色系、辅助色用灰色系、警示色用橙色、危险色用红色其他色彩一律不出现。4.3 一个经验画图是为了少解释最后说一个观念层面的事。画图的终极目的不是为了有张图而是为了少解释。如果一张图画完之后还需要你对着它讲十分钟才能让同事听懂那这张图的表达是不合格的。图片应该自己会说话读者扫一眼就大致知道系统的边界、核心链路和关键依赖关系这才是画图的价值。我在实际工作中有个判断标准把图发给一个不了解上下文的人如果他看完后能提出有质量的问题比如这里挂了怎么办为什么这个依赖是异步的就说明这张图已经画到位了如果他看完后问的是这个框是啥意思这条线代表什么说明图面本身还在失败地传达基本信息。判断标准从讲得清变成不用讲之后我对每张图的质量要求就完全不一样了。最后分享一个小技巧。我出图前会强制自己关掉一切编辑窗口用纯图片视角重新看一遍整张图只在读者视角下检查图面是否清晰。这一步几乎每次都能发现文字挤压或布局不对称的问题。修改完成后再导出往往就是最终的成品。画图这件事没有太多玄学无非是结构想清楚、层次分清楚、细节讲清楚再加上一套自己反复使用的检查机制。
阅读完成 · 觉得有帮助？
