画架构图这件事我干了快十年看过的图比画过的图多得多。但说实话大多数架构图都有同一个问题——画的人使劲看的人费劲。要么一个方框摞一个方框线条缠成一团根本不知道重点在哪儿要么花花绿绿画了一大堆颜色图标全上结果评审会上还是被问“这个框是干嘛的”。这篇文章想聊的就是“如何画架构图”这件事本身从画图前的思路准备到一张图里到底该放什么、怎么摆放再到工具选型、常见坑点把一套能直接落地的经验整理出来。适合刚接触架构设计的新人、需要给别人讲清楚系统的开发或产品同学以及每次画架构图都感觉差点意思、想系统提升一下的老手。1. 先搞清楚你画的到底是什么图1.1 架构图不是“画一个图”是“沟通一种结构”每次有人问我“怎么画架构图”我第一反应都是反问一句你画这张图是想给谁看、用来干什么因为架构图本质上不是一份美术作品而是一个沟通工具。它要做的事情是把一个系统的结构、模块之间的关系、数据流动的方向让另一个人在最短时间内看懂。很多人一上来就打开画图工具憋着画一张“特别完整”的图什么都要放进去。结果图出来了评审会上根本讲不清楚。根本原因不是工具不熟也不是画图水平不行而是没想明白我到底要表达什么。一张好的架构图一定带着明确的意图。比如“我要给项目经理讲清楚这个系统分几个模块”和“我要给后端开发讲清楚订单服务调用了哪些下游接口”这两种图完全不应该画成同一种样子。前者讲究宏观、分层、边界清晰后者讲究细节、调用链路、数据格式两张图的粒度和呈现方式都应该不同。1.2 架构图的两大分类哪一层、给谁看我习惯把架构图先分成两个维度来想。第一个维度是“层级”第二个维度是“受众”。层级决定你画的是哪一层受众决定你画到多细。从层级来说大致可以分为业务架构、系统架构、技术架构、部署架构这么几类。业务架构讲清楚业务领域、流程、角色之间怎么协作一般不带技术细节系统架构讲清楚系统内部有哪些服务、服务之间怎么调用技术架构会深入到中间件、框架、协议层面部署架构则关注物理或云环境下的节点、网络、容器的分布关系。每一层的图用法完全不同。从受众来说给决策层看的图重点是模块边界、成本、风险细节必须收敛给同组开发看的图重点是接口、数据流、依赖关系细节必须到位给运维看的图重点是部署拓扑、实例数量、网络策略。选错了粒度才是架构图最大的失败原因。我给团队分享时常用一个类比画国家地图你会标出省会城市、主干高速画小区地图你会标出每栋楼、每个出入口的位置。不是一张地图能涵盖所有信息而是你要根据用途选择对应的比例尺。1.3 架构图的价值在于“降低认知成本”如果你只是想把系统记在自己的脑子里那根本不需要画图。真正需要架构图的场景是你需要把脑袋里那套复杂的结构传递给别人。认知是有成本的。文字描述一段调用链路读的人要自己脑补半天用一张层次清晰的图几秒就能建立起整体印象。这就是架构图的核心价值把复杂的系统认知成本降下来。所以你在画图时做的每一个决定本质上都是在回答同一个问题这样做能不能让看的人更快看懂这个判断标准一旦定下来很多纠结都迎刃而解。比如“要不要加这个模块”“这条线要不要画”——想一想“对看懂这张图有没有帮助”答案自然就出来了。2. 画图前的准备工作没有想清楚就别动笔2.1 明确三个问题给谁看、看什么、看完干什么很多人的架构图失败不是败在画的过程是败在画之前没想清楚。我给自己定了一个规矩画图前先把三个问题写在纸上想清楚了才开始动笔。第一个问题给谁看。是给自己团队的人看还是给跨部门的人看还是给外部的人看。不同对象掌握的背景知识差很多你得假设他们“什么都不知道”还是“对系统已经比较熟”。第二个问题看什么。你想让对方看完之后脑子里留下什么印象是模块的数量和边界还是服务之间的依赖关系还是流量是怎么从入口打到数据库的重点不同画图的侧重点就完全不同。第三个问题看完干什么。这是最容易被忽略的。如果对方看完这张图是要做技术评审、要批准预算、还是要开始写代码那图上需要呈现的信息类别就完全不同。评审关注风险预算关注边界和资源开发关注接口和依赖。我在实际带新人时经常发现他们的第一版架构图“什么都想画”把接口都写上去结果整体结构被细节淹没。后来我让他们先把这三个问题写下来很多问题自然而然地消失了。2.2 梳理信息清单架构图是“做减法”的艺术明确完受众第二步是列出“这版图涉及的元素清单”。系统里有十几个服务、几十张表、七八个中间件不代表你全都要画上去。架构图是做减法的艺术画上去的每一块内容都必须服务于第一步回答的三个问题。我推荐的做法是先把候选清单全部列出来然后逐个过筛子。筛选时问自己这张图如果没有这个元素读者会不会产生误解不会就删掉。比如你要画一张订单系统的总体架构图三级缓存、消息重试队列这些实现细节如果对理解订单主流程没有帮助就别画。反过来如果图里缺失了“支付回调”这条链路那读者对订单状态流转的理解就会出偏差这种就属于必须保留的。2.3 确定边界和外部依赖画架构图最常见的翻车点之一是边界不清。系统内部的模块三五成群画到一半才发现还要跟外部系统交互。如果你一开始就把外部依赖排除在视野之外图画到后面很容易变形。我的习惯是画之前先明确哪些是系统内部的元素哪些是外部依赖。外部依赖用特殊的样式统一标出来比如用单独的“外部系统区域”或者不同的边框颜色。这样读者第一眼就能知道哪些是我方可控的哪些是不可控的这对接下来的方案讨论特别重要。很多人技术上很好但图里外部依赖和内部模块混在一起评审的时候来回解释半天这个问题完全可以在准备阶段就避开。2.4 一张检查清单开画前逐项核对这里总结一张我常用的检查清单每次开画前花两分钟过一遍基本可以避免大部分返工这张图的阅读对象是谁他们对该系统的熟悉程度如何这张图要传达的核心信息是什么一句话能不能说清楚这张图的重点维度是模块划分、依赖关系还是数据流哪些元素属于“必要信息”哪些属于“锦上添花”系统边界在哪里哪些是外部依赖、哪些内部组件图里信息量的层级关系是否已经梳理出一个大概的结构清单不一定要写得很正式脑子过一遍也行。但我的经验是靠脑子过容易漏写下来反而能逼自己把逻辑厘清。画图这件事功夫往往在图纸之外。3. 一张好架构图的通用拆解元素、连接、层次3.1 元素方框不仅仅是方框架构图最基本的构成单元是元素——通常是一个方框。方框里放的是什么直接决定读者如何理解它。我建议在动笔前确定一套统一的“元素语义”什么形状代表服务什么形状代表数据存储什么形状代表外部系统。不一定要用复杂的图形库但一定要保持一致。举个例子如果一张图里方框代表微服务圆角矩形代表数据库那全图都要遵守这个约定。中途换样式只会让读者困惑。更细一步元素内的文字也要统一规范服务名用名词短语动作用动词短语不要混着来。比如一个方框里写“订单服务”下一个方框里写“处理支付”读者就会在“这是一个组件还是一个动作”之间来回切换。元素粒度也很关键。同一个服务在系统架构图里可能只是一个方框但在组件图里需要展开成几个子模块。不要让一个方框承载过多信息。如果一个方框需要大段文字才能解释清楚说明它该拆层了。3.2 连接线条比框更难画许多新手画架构图把大量精力放在方框的排版上反而对线条随手一拉。这其实弄反了。架构图的信息密度很大程度体现在连接关系上而线条恰恰是最容易画乱的地方。首先你的线条必须有语义。是调用关系、数据流还是部署依赖不同的语义建议用不同的线型区分。调用关系一般用实线箭头数据流用带方向的实线配置或部署关系可以用虚线。线型一旦建立就必须全图统一。很多人画到一半换了一种箭头读者很难追得上。其次线条的走向要尽量有规律。我画图时有一条很朴素的原则依赖方向尽量保持自上而下或从左到右。如果一张图里线条上天入地、横七竖八读者阅读时视线就会来回跳跃认知成本极高。画的时候可以刻意把下游服务放在右侧或下方让箭头方向尽可能一致图的整体阅读感会好很多。线条交叉也无法完全避免但至少要尽量减少交叉。交叉的线条越多图的“辨析度”越低。能用一条直线表达的就不要画成折线绕来绕去。3.3 层次没有分层的架构图没有灵魂一张只有方框和线条的图是流程图不是架构图。架构图的关键在于“层次”的表达。我理解的层次有两种一种是视觉上的分组一种是逻辑上的层级关系。视觉上的分组比如用虚线框圈出“订单域”“用户域”“支付域”或者用泳道把“客户端”“服务端”“数据层”分开这样读者一眼就能看出模块的归属。逻辑上的层级关系则是通过元素的摆放位置来体现。比如接入层在最上面业务层在中间数据层在最下面依赖关系自然就顺着层级传递下来。这种“越往下越基础”的摆放方式符合大多数工程师的阅读直觉。这里很多人会犯一个毛病分组太多框套框反而变成了俄罗斯套娃。分组的目的是让读者快速找到区域归属而不是把每个模块都包一层。如果一个分组里只有一个元素那这个分组大概率是多余的。3.4 排版和配色克制比好看重要漂亮、精致的图确实给人好感但架构图的排版配色一条原则就够克制。我见过太多图一个系统用了七八种颜色图标恨不得每个方框都配一个最后的视觉效果像一幅抽象画信息反而全丢了。我的建议是前期画图只用黑、白、灰最多加一种强调色。先把结构、元素、连接关系都摆清楚。任何多余的修饰都是噪音。等结构完全定稿再考虑用颜色做重点标注比如把“本次改动涉及的模块”标成高亮色。颜色是读者注意力分配的杠杆用好了事半功倍用滥了等于没有重点。让你的图在“内容完整度”和“视觉理解成本”之间找到一个平衡点才叫设计而不是装饰。4. 手把手画一张微服务架构图完整实操过程4.1 明确图谱范围用的是一个典型电商系统的例子后端有用户、商品、订单、支付、库存、营销等服务。假设目标读者是部门新来的后端开发目的很明确让对方在半个小时内建立起对这个系统全貌的认知知道业务请求是如何穿过网关、服务、数据层完成的。基于这个目的图的粒度定在“服务级”不需要画到每个服务内部的类或者表。图的边界外部依赖就是微信支付、物流系统和短信供应商内部就是这几个核心微服务。核心要突出的链路是“下单主链路”客户端 → 网关 → 订单服务 → 各基础服务 → 数据存储。4.2 先搭骨架从上到下、分层摆放准备阶段完成后开始画第一版通常是“骨架版”。我建议在画布上先划分三个泳道区域接入层、业务服务层、基础依赖层。接入层放客户端、网关业务服务层放用户、商品、订单、支付、库存、营销这几个服务基础依赖层放数据库、缓存、消息队列。先把这些方框按层次放好不要急着画线。这一步的目的是让主体结构先在画布上立起来确认每个块的大概位置之后再连线就不会乱。我实操的经验是骨架阶段如果排布满意后面细节填充起来会顺畅很多如果骨架阶段就挤成一团后续怎么调都比较难受。记得给每个层留出足够空白后期加注释、加线条标注都需要空间。4.3 连线并标注方向骨架搭好后开始画调用关系。这一步最关键是图的信息核心。从最上方的客户端画一条线指向网关标注“HTTPS”。从网关分别指向各个服务不过为了图面清晰我通常会省略网关到每个服务的重复箭头而是在图例里注明“所有请求均经过网关鉴权后路由”。这样避免了大量平行线铺满画面。然后从订单服务分别指向用户服务、商品服务、库存服务方向箭头指向被调用的服务线上标注“Feign 调用”或“Dubbo”。画线时遵循“从上到下、从左到右”的原则箭头方向尽量一致。比如订单服务在左侧它调用的用户服务、商品服务放在右侧这样箭头自然朝右下方。支付服务因为跟外部系统交互较多我习惯把它单独放在业务服务层的最右区域靠近外部系统边界。库存服务与订单服务协同紧密放在订单服务正下方两条线一垂到底图面很干净。4.4 加入外部系统和中间件外部依赖不要埋在角落要放在显眼的边界区域。我在图的右侧用了一个不同颜色的“外部系统”分组框放微信支付、物流系统、短信平台然后用清晰的箭头指向他们。颜色在骨架阶段不用涂但分组框我习惯用虚线框区分内外。这样读者一眼可以看到系统内部的依赖走向了哪里哪些是外部不可控因素。中间件的画法要注意归位缓存Redis放在业务服务层下方数据库放在基础依赖层最底部消息队列RocketMQ放在服务层和数据库之间的位置代表它是异步消息通道。整体图面从上到下呈现一种“层层向下、末端落到存储”的视觉引导读起来非常顺。这一步做完图已经能看出系统全貌了。4.5 标注关键信息协议、数据方向、异步链路骨架和线都画清楚以后开始补关键标注。第一步在外部调用线上标注协议信息比如“微信支付 API”在网关入口标“HTTPS”。第二步异步链路单独用虚线表示比如“订单完成 → 发送 MQ → 营销服务”并在虚线上标注“异步”。第三步也是很多人容易漏掉的数据流向。订单服务写入订单库和 Redis 缓存库存服务扣减库存后写库存库。数据流的箭头方向和调用方向可能不一致画的时候一定要留意。标注不是越多越好每一条标注都要能回答“读者可能在这里产生的疑问”。如果一个接口是资损高风险点重点圈出来如果一条链路只是常规查询没必要额外加一堆说明。时刻记住标注是在引导注意力不是在堆砌信息。4.6 评审迭代初稿完成后必须“杀掉自己最爱的细节”很多人的初稿都舍不得删东西。我的习惯是初稿完成后先放一小时再以一个“没参与过这个系统、但懂技术”的第三方视角去读它。凡是读完会卡住的地方都要改凡是“细节很炫但对理解没帮助”的元素果断删掉。实战中我这张电商架构图第一版里放了“服务鉴权中间件”“配置中心”“日志采集”这些支撑组件。后来发现对理解业务主流程没有明显帮助反而干扰了主线。于是把它们收进一个“基础支撑组件”分组框只在边界提到一句“所有服务统一接入配置中心和日志系统”。删完之后图的主干清晰多了。画架构图的时候要敢于“杀掉自己最爱的细节”你设计得很精细的某个点如果跟核心目的无关它在这张图里就是干扰项。5. 工具选型没有最好的工具只有最合适的工具5.1 主流工具横向对比这个领域工具非常多但真正值得长期用的其实就那么几个。我按实际使用体验整理了下面这个表格方便你按场景快速判断选哪个。工具学习成本协作能力适用场景常见痛点draw.io / diagrams.net低强可对接 GitHub、Confluence日常开发、文档配图样式偏素需要手动调排版ProcessOn低较强模板丰富快速出图、国内团队协作免费版文件数有限制Visio中较弱企业内部正式架构文档价格高跨平台差偏重Excalidraw低强实时协作草图、多人讨论、快速头脑风暴手绘风格不适合正式对外文档PlantUML / Mermaid中依赖代码仓库架构图随代码版本管理布局自动生成复杂图调整困难专业建模工具ArchiMate、Enterprise Architect高依产品企业级架构建模、大型项目学习成本高小团队没必要5.2 我推荐的组合方案工具选择应取决于你的实际使用场景我分享一套自己长期使用的组合方案。日常技术方案设计、内部评审图我用 draw.io 配合团队共用的模板文件。原因是免费、跨平台、支持导出 SVG 嵌入文档团队协作时直接把 .drawio 文件丢进代码仓库或者共享盘大家都能改。draw.io 对架构图的支持足够用没必要追求那些用不上的复杂建模能力。对外正式文档、跨部门的架构汇报我会用 ProcessOn 或 Visio 做最后的排版润色。这类场景对视觉细节要求更高ProcessOn 的模板能节省不少时间。如果你做得比较频繁也可以自定义一个符合团队风格的模板统一字体、配色、线宽避免每人画出来的风格天差地别。如果你和我一样喜欢把架构图和代码放在一起同步维护推荐使用 Mermaid 或 PlantUML。它们可以用纯文本描述架构图放在 Git 仓库里代码变更时图也随之演进。对于想确保文档与实现同步的团队这种方式很省心。但复杂图表用代码绘制调整布局确实麻烦我更倾向于用它们画结构相对简单的图。5.3 工具常用的几个习惯工具只是辅助手段但几个使用习惯可以大幅提升效率。第一先建模板。把常用字体、线宽、颜色、图标预设好一套架构图基本就用那么几种元素没必要每次重新调整。第二画图过程中养成“对齐强迫症”。几个方框是否对齐、线条是否垂直或水平、间距是否一致这些细节决定了图的精致程度。draw.io 里用“对齐”和“分布”功能快速整理比手动挪快得多也整齐得多。第三常用图形和图标积累成素材库。比如服务器图标、数据库图标、用户图标放到自定义图库下次一拖即用。6. 常见问题与排查技巧实录6.1 一张图塞下所有内容这个问题在初学者里出现频率最高。表现图上密密麻麻从网关到数据库到定时任务到监控告警什么都画连配置中心都单独占一个框。结果就是图面信息密度过高读者找不到重点问了半天也找不到主链路。解决办法用“分层”代替“堆叠”。同一套系统你可以画三张图一张总体架构图模块级别、一张核心链路图服务调用级别、一张部署架构图基础设施级别。每次只画一个层面信息量自然就降下来了。如果一张图必须包含细节那也应当是分层之后单独把某一层抽出来放大。6.2 方框有含义歧义图例缺失图里所有方框都一个样式读者分不清哪个是服务、哪个是数据库、哪个是外部系统。很多人画的时候心里有一套默认规则但看图的人不知道于是产生误解。解决办法图例一定要有。如果图中出现了三种以上元素类型或者两种以上线型就必须在图例里说明。图例放在图的左下角或右下角简明扼要。这套规则适用于所有正式使用的架构图。内部随手画的草图除外凡是给别人看的图例都不能省。6.3 箭头乱飞、交叉严重线条交叉过多是图面阅读体验的致命伤。交叉线会让读者停下来辨认“这条线是从哪个框出来的”。解决办法画线之前先规划好布局。把有强依赖关系的组件放得近一些、方向一致一些。如果发现交叉无法避免可以通过调整元素位置、引入“总线”比如网关统一连接来减少连线数量。大量服务都调同一个下游时不必每个服务都画一条线指向它可以通过分组或注释表达“所有服务发布消息到 MQ”远比画一堆交叉线清晰。6.4 颜色太花哨很多人在架构图上用五颜六色区分模块红橙黄绿蓝每个服务一个颜色。初看很“酷”看久了累而且打印或者投影时颜色失真后信息更混乱。解决办法回归“黑白优先”用颜色只做强调。默认状态下所有组件用同一种底色重要模块或者关键链路才用强调色。这样读者潜意识里就会把“特殊颜色”和“重要信息”强关联。颜色是需要留给“重点”的资源全图都鲜艳等于没重点。6.5 只画结构不标注关键信息有些图画得结构很清晰但没有任何标注看图的人只能靠猜这条线是同步调用还是异步这个模块在链路里是必经之路还是可选分支数据库上承载的是写流量还是读流量解决办法在关键依赖线上标注协议类型、同步/异步、核心语义。不需要每条线都标但凡是影响读者理解链路走向和依赖强度的都必须标。特别是跨系统调用、核心数据流、异步消息链路这些不标清楚图的信息价值直接砍半。6.6 版本管理混乱改一次内容全丢架构图不是一次性产出系统演进后要持续更新。但很多人画完图就丢在桌面过两个月再打开发现已经是“过期架构图”要么内容对不上要么根本找不到源文件。解决办法建立架构图的版本管理机制。把源文件放到共享目录或者 Git 仓库每次修改记录清楚版本。给文件命名时带上日期或版本号比如“系统架构图_v2.3_202506.drawio”。关键图要放在团队都能访问到的地方并且约定“谁改动谁负责更新”避免出现多份副本内容不一致的情况。7. 架构图只是手段讲清楚才是目的写到最后再分享一个我个人的经验。画图这件事技术含量真的不在“画”而在“想”。你花一晚上打磨了线条和配色远不如花一小时想清楚“这张图必须传达什么信息”。我从新人期到现在踩过最多的坑不是工具不会用而是脑子里一锅粥就急着画图。现在我给自己定了条铁律画图前先默写一遍系统里有哪些组件、它们之间什么关系、这张图想说明的核心问题是什么——想不出来就不动笔。画完图之后找个人讲一遍这个动作比任何美化都重要。讲不通的地方就是图需要改的地方。你会发现自己以为画得很清楚的地方别人看起来完全是另一个意思。这是打磨架构图最有效的方式。这个内容后续还可以往两个方向扩展一是建立一套团队自己的架构图规范和模板让所有人都用同一套视觉语言表达系统二是把架构图和文档、代码关联起来让架构图真正成为演进中的“活文档”而不是一个画完就过期的静态产物。