做了这么多年技术方案和产品梳理我越来越觉得画图这件事被很多人低估了。diagram-design 听起来只是把东西画出来可真正上手你会发现有人三分钟画出一张别人看不懂的图也有人花三个小时磨出一张能让评审会顺利通过的图差距全在细节和思路上。这篇内容我想把图表设计这摊事从头到尾梳理一遍好图的标准是什么、动手前要做哪些决策、一张架构图从零到一的完整流程以及我这些年踩过的坑。不管你是工程师、产品经理、技术写手还是团队管理者只要日常需要输出流程图、架构图、时序图这类东西这篇应该都能用得上。1. 先搞清楚一张好图到底好在哪很多人拿到需求就打开工具直接开画结果画出来的图要么是给自己看的要么是给全人类看的最后谁看了都抓不住重点。我自己也经历过那个阶段后来才慢慢想明白一件事动手之前最先要回答的问题不是用什么工具而是这张图给谁看、在什么场合看。这听起来像废话但绝大多数废图的病根都出在这一步没想清楚。1.1 图表不是装饰品先明确受众和场景先举个典型的例子。同一套微服务系统你分别画三张图面对三种人内容完全可以大不一样。给研发看架构图重点在服务边界、服务依赖、协议类型、数据存储归属给运维看部署图重点在节点数量、网络分区、容器编排、端口映射给业务方看系统总览重点在请求链路、核心路径、故障影响范围。同一个技术事实因为受众不同呈现的取舍完全不同。这里说的场合也很关键。如果是放在技术方案文档里图是用来辅助论证的信息要完整、逻辑要严密别人能顺着图检查每一条依赖对不对。如果是做评审汇报的PPT图是用来引导注意力的必须砍掉旁枝末节只保留主线。如果是贴在团队Wiki里的长期参考文档图得有自解释能力新同学看一眼就该知道系统大概长什么样而不是拉着老员工讲十分钟才能看懂。我先给自己定了一条死规矩如果一张图不能在一分钟内讲明白核心信息这张图就不算画完。讲不明白不是观众的问题是图的问题。1.2 好图的三个硬指标准确、清晰、可维护准确是第一位的也是最容易被忽视的。很多图乍一看很规整配色协调、排版对齐但你逐条核对里面的连线发现服务A调服务B的方向画反了或者数据库的主从关系标错了这种图放到文档里就是定时炸弹。我后来养成一个习惯每张图交付前会逼自己对着代码或配置逐条过一遍特别是箭头方向、调用关系、数据流向这三类最容易出错的地方。清晰指的是信息密度合理。一张图的最佳状态是增之一分则太长减之一分则太短可惜大多数人都是往长里画。常见的清晰度杀手有三个一是节点太多一屏挤了几十个框字号小到要贴屏幕看二是线网太密横七竖八的交叉线直接织成蜘蛛网三是文字又长又啰嗦一个节点标题写了两行半读者光拆解文字就要花掉大半精力。解决思路其实不复杂要么拆分多图要么把次要信息收进折叠区域或者附录。可维护性是我最近两年特别看重的一项指标。图是活物系统一变它就得跟着变但现实中大部分图都死在改一次的成本太高。想想看你是不是也经历过画图花了三小时后来需求改了你实在懒得重排干脆在图旁边加个文字说明这里已废弃以代码为准。等到再过三个月图就成了历史遗迹。所以现在但凡要长期维护的图我会优先选能跟代码版本库放一起的方案后面专门讲。2. 动手前的设计决策图型、层级与布局画图的真正功夫其实在打开工具之前。一个合格的设计过程至少要经历选图型、做信息分层、定布局流向这三道工序。把这三件事想明白了真正操作起来反而很快。反过来脑子里一团浆糊就上手拖框连线画出来的东西大概率也是一团浆糊。2.1 图型怎么选别再一张流程图打天下图型选错表达效果直接打折。举个最直观的例子你想表达用户下单后系统做了什么用流程图是合理的但如果想表达订单服务依赖哪些下游服务用流程图硬画就非常别扭这时架构图才是正解。我把日常高频的图型整理了一下大致分成几类。流程图表达流程、分支、结束条件适合业务流转、任务执行、异常处理。架构图表达组件、模块、子系统之间的静态关系适合系统设计、服务拆解、技术选型说明。时序图/调用链图表达多个对象之间按时间的交互顺序适合接口设计、跨系统协作、排查问题链路。数据模型图ER图表达实体、属性、关系适合数据库设计、数仓建模。部署图/拓扑图表达物理或逻辑节点的分布和连网方式适合运维、网络规划。选型的时候可以问自己一个问题这张图的核心信息到底是先后顺序还是依赖结构如果是先后顺序优先流程图或者时序图如果是依赖结构优先架构图或者拓扑图。另一个判断点是读者需要从中获得什么他们要看清谁先谁后就给顺序类图他们要看清谁依赖谁就给结构类图。混着画的图通常只能两头不讨好。2.2 信息分层从一堆信息到图上的节点选定图型之后下一步是把脑海里或者文档里的那堆信息整理成可以放进图里的元素。我习惯按四步走。第一步先列清单把所有相关的东西全部倒出来。不要有筛选意识想到什么写什么。第二步做归类把清单里的条目按逻辑分组比如这些是入口、这些是核心服务、这些是数据存储、这些是外部依赖。第三步定关系明确组与组、项与项之间到底是调用、依赖、包含还是继承。第四步划边界决定哪些元素必须出现在主图中哪些可以收进折叠区域或者暂时不放。举个例子画一张用户下单的架构图。先说清单用户端App、Nginx网关、订单服务、支付服务、库存服务、用户服务、消息队列、订单数据库、商品数据库、第三方支付渠道、后台管理端。归类之后入口是用户端App和管理端核心服务是订单、支付、库存、用户中间件是消息队列存储是订单库、商品库外部依赖是第三方支付。关系上用户端通过网关访问订单服务订单服务同步调用库存服务扣减库存异步通过消息队列通知支付服务支付服务再对接第三方支付渠道。边界划分的时候用户端和管理端必须出现第三方支付可以只画一个块不展开内部细节。到这一步图蓝本已经出来了剩下只是把它画好看的问题。2.3 布局与流向让视线顺着你想的方向走图和信息流一样是有阅读顺序的。最常见的绘图习惯是自上而下或者从左到右。选哪个取决于图的复杂度和你希望读者最先看到什么。如果是一张纵向的业务流程图从上到下最自然如果是一张水平展开的系统架构图从左侧入口到右侧出口最直观。但方向一旦定了就别中途变卦最怕一张图前面从左往右画到一半突然又改成从上往下读者视线像走迷宫看完很容易迷路。布局上还有几个小原则。主线要明显核心链路可以放在图的黄金位置也就是中上偏左这一带辅线放两侧或者下方。次要细节用环绕的方式展开比如把日志、监控、配置中心这类支撑组件放在核心服务外面一圈用虚线连接降低它们对主线的干扰。同类元素要对齐同一层的服务尽量放在一个水平线上避免错落无序。留白也很重要节点之间别挤成罐头适当留白反而让结构更清晰。3. 手把手复现从零到一画一张架构图理论讲了一堆现在上一段完整的实操。我拿最典型的微服务架构图举例把从工具选型、草稿到成图的整个过程走一遍。这套流程不只适用于架构图换成流程图、时序图或者其他图型一样通用只是换一下元素类型而已。3.1 工具选型代码派、画布派和手绘派的取舍先说工具因为很多人在这一步就开始纠结。工具本身没有绝对的好坏只有适不适合当前场景。我把主流方案大致分成三派。代码派代表是 Mermaid、PlantUML、D2。优点是文本即图可以进代码仓库、代码评审、版本回滚协作友好缺点是排版可控性弱复杂布局容易画得丑。适合长期维护、团队协作、写在文档和Wiki里的图。画布派代表是 draw.iodiagrams.net、Figma、Visio。优点是所见即所得排版自由度高可以精细调整每一个坐标缺点是文件是二进制或者独立格式不容易跟代码仓库做文本级别的diff。适合一次性汇报、精细打磨、复杂交互的高阶图表。手绘派代表是 Excalidraw以及各种白板工具。优点是风格轻松草稿感强特别适合头脑风暴和早期讨论降低画得丑的心理压力缺点是不够正式不适合作为长期技术文档的主图。我最常用的组合是需要长期维护的图用代码派写进仓库渲染图作为文档附件一次性汇报图用画布派精细调讲究排版和配色脑暴阶段的图直接开白板不做任何修饰。你可以按团队的习惯选主工具但建议至少保留一个画布派和一个代码派覆盖不同场景。3.2 完整实操步骤以订单服务架构图为例现在开始画图。假设需求是画一张用户下单微服务架构图阅读对象是刚入职的研发新人目的是让他快速理解系统的核心链路。整体流程如下。第一步列清单我通常用文本文件先铺一遍用户端App、Nginx网关、订单服务、支付服务、库存服务、用户服务、消息队列、订单数据库、商品数据库、第三方支付渠道共10个元素。这一步不追求格式重点是别漏。第二步画主链在画布中间拉一条主线App - Nginx - 订单服务 - 库存服务/消息队列 - 支付服务 - 第三方支付。主链要占最大空间元素之间的间距也要留足后面肯定还要插入新节点。箭头方向沿着调用方向走不要用无箭头线条糊弄过去。第三步加配套存储和依赖。订单服务下面挂订单数据库库存服务下面挂商品数据库支付服务接到第三方支付渠道。这里要顺手做一个小决定数据库用圆柱体还是普通矩形我个人偏好圆柱体一眼就能区分存储和计算节点。第四步分组和容器化。用一个大虚线框把订单、支付、库存、用户这些服务包在一起标注核心业务服务区再在外面画一个框放Nginx标注接入层数据库单独拉一个区域叫数据存储层。分组的意义是让读者先看到宏观分层再深入细节。第五步加标注和图例。比如在订单服务和支付服务之间用异步消息队列就在线上标注MQ 异步通知订单服务调用库存服务标注同步扣减库存。图例里说明实线是同步调用、虚线是异步消息、灰色框是外部依赖。第六步校准和简化。退后一步看整张图问三个问题主线是否一眼能找出来有没有多余节点可以收进分组里文字是否有歧义这一步我通常会删掉一两个非必要节点或者把它们归入支撑组件的分组里。至此一张能用的架构图就出来了。全程如果熟练画布派大概20分钟代码派大概15分钟。3.3 配色、字体、线型与标注的细节规范图能看懂只是及格看着舒服是加分项。这方面有几个细节是我对比了很多好图和烂图之后总结出来的。配色上主色别超过三种。黑白灰打底选一个强调色标记核心链路再选一个警示色标记异常或外部边界。别做彩虹图每种颜色都喊看我等于没人被看到。字体上标题、节点名、注释至少要有大小层级通常节点名16到18号注释12到13号图标题更大一号这样视觉重心自然落在节点名上注释只是补充。线型也要有语义别乱用。实线表示强依赖或者同步调用虚线表示弱依赖或者异步通知双线可以表示双向交互。一旦定了规矩整张图就必须贯彻到底不能时而实线时而虚线。标注文字放在线中段偏上的位置避免压住线的关键拐点线多的时候可以给线标上编号在图例里集中解释避免在线旁边堆太多字。网格对齐是我最后一步一定会做的动作把所有节点按网格吸附一遍错位的东西立刻看起来整齐很多。4. 踩坑实录高频问题与排查技巧画图这件事表面上是个体力活实际上是个试错活。我这几年前前后后画了几百张图踩过的坑比起画废的图只多不少。这一章把高频问题集中抖出来附带排查思路能帮你少走不少弯路。4.1 常见问题速查表问题原因解决思路节点堆成毛线球看不清主次信息没有分层所有内容平铺先分组后布局核心链路居中次要内容收进折叠区域交叉线多到没法看布局顺序不对没有规划好节点位置调整节点顺序让连线尽量走竹节式路径同一层节点对齐图一放大就模糊用了低分辨率导出或位图格式用SVG等矢量格式导出图表设计规范里统一要求矢量图看完图不知道重点在哪缺少强调手段所有元素视觉权重一样用颜色、字号、线宽区分主次核心链路必须一眼可见颜色太多太花没有配色规范凭感觉选色主色控制在三种以内柔和的中性色做底团队成员风格不统一没有约定工具和规范建立简单的制图规范固定工具、图例语义、配色规则排查的时候有个顺序先看方向对不对再看层级清不清晰最后才谈好不好看。很多新手一上来就调颜色结果箭头都是反的属于典型的舍本逐末。4.2 团队协作中的图表维护经验图上最容易被忽略的成本是维护成本。一个团队里如果每个成员各画各的文件名五花八门格式乱七八糟三个月后基本就是一团乱账。我参与过的项目里最终能长期活下来的图都有几个共同特征。第一图和代码放在同一个仓库。不管是代码派工具直接写文本还是画布派工具导出的源文件只要文件能进Git仓库就能做版本管理、分支评审、历史回溯。图随代码变更而更新这种图文一致的约束能倒逼大家把图当代码维护。第二把图嵌入到文档体系中。架构图的读者往往不是画图的人所以建议把关键图直接贴进API文档、架构说明、上线检查单里让图成为流程的一部分而不是躺在角落里的孤儿文件。第三建立最小化的制图规范。不需要定太多条条框框但至少要有五条——文件放哪、用什么工具、主色是什么、实线虚线什么含义、导出格式是什么。规范越简单越容易执行写满三页纸的规范基本没人看。最后说一个我自己的习惯遇到特别复杂的系统图我会刻意拆成总览图细节图两层。总览图只显示模块和它们之间的关系细节图再针对单个模块深入展开。总览图保持在一屏能看完的程度细节图交给需要深入的人去翻。这个习惯帮我解决了很多一张图画不下、画下又看不清的死结。每次回看自己画过的图其实都能看到当时的思考方式。diagram-design 这门手艺表面上玩的是线条和色块底下拼的是抽象能力和对业务的理解深度。工具会不断换代规范也可以随手调整但先想清楚再动手这件事永远是画图里最值钱的一步。希望这篇东西能让你下次打开画图工具之前多花那三分钟想一想。