1. 先别急着打开画图工具把这件事想明白很多人问过我架构图怎么画我第一反应通常是反问一句你打算给谁看这不是抬杠。画架构图这事儿百分之八十的问题不是出在工具不熟、模板不够、配色难看而是出在动手之前没想清楚这张图到底要干什么。我见过太多人打开画图软件就开始拖方框拖到一半发现方向不对推倒重来一上午就没了。还有人画完一张自认为非常完整的架构图发到群里结果同事回复一句这图画的是啥问题不在手在脑子。架构图本质上是一种表达工具它是你把脑子里的系统认知用一种别人能看懂的方式传递出去。既然是表达就需要先有内容再有形式。就像写文章之前要先有提纲画架构图之前也要先有一个脑内的图工具只是把你脑内那张图落到画布上而已。如果你脑子里对系统结构本身还是一团浆糊那不管你用多贵的工具、套多好看的模板画出来的东西依然是浆糊。反过来如果你对系统理解得很清楚哪怕用Windows自带的画图也能画出一张让别人秒懂的架构图。所以这篇文章我不打算只跟你聊工具和模板。我要聊的是画架构图的完整思考链路先想清楚给谁看再决定画什么类型然后才是怎么布局、用什么工具、怎么标注。最后我会用几个高频场景——微服务架构、大数据平台、AI智能体——把整套方法走一遍。这对谁有用如果你是刚开始画架构图的开发工程师、刚转岗需要写设计文档的技术人员或者经常要做PPT汇报但没有系统学过画图方法的人这篇文章基本就是给你准备的。如果你已经是老手也可以跳着看看后面的踩坑记录说不定有你没注意到的细节。2. 架构图有哪些类型别把组织架构图当成软件架构图关于架构图大家搜索的时候会出现一个很有意思的现象有人搜的是组织架构图比如某公司、某单位的管理层级有人搜的是系统架构图、软件架构图还有人搜的是微服务架构图、大数据架构图。这些名字里都带架构图三个字但它们要表达的东西完全不同。这就回到第一件事画之前先对齐语境。你拿着画系统架构图的方法去画组织架构图肯定画不对你拿着公司组织架构图的模板去画微服务调用关系那就是灾难。我这里主要讲的是技术类架构图也就是软件、系统、平台这一类的架构图。但为了让你心里有个谱我把几种常见的架构图类型放一起对比一下类型表达的核心内容典型读者关键元素业务架构图业务流程、角色、业务模块产品、业务方、管理层角色、流程节点、单据/数据流组织架构图组织层级、汇报关系管理层、HR部门/岗位框、上下级连线系统/应用架构图系统模块、服务划分、依赖关系开发、测试、架构师模块框、依赖线、调用箭头部署架构图服务器、网络、容器、节点分布运维、SRE、DevOps主机/容器、网络分区、负载均衡数据架构图数据流向、存储、处理链路数据工程师、后端数据源、存储、处理节点、数据线这些图之间不是互斥的一个系统可以同时有系统架构图、部署架构图和数据架构图它们是从不同视角看同一个系统。真正的高手不是把所有这些视角塞进一张图里而是知道每张图该画什么、该藏什么。我记得有一次评审会上有人把系统架构图、部署架构图和时序图揉成一张巨图打印出来字都看不清。当时评审组长只说了一句话这图我数了一下有四十多个框六十多条线你们谁能五分钟之内给我讲清楚它是干嘛的全场沉默。这就是典型的一张图想干所有事结果一件事都没干成。所以在动手之前务必先问自己一个问题这张图是给谁看的希望他看完之后做什么是让领导确认技术选型方向是让新同事知道系统有什么模块是让运维知道服务部署在哪台机器上不同的答案对应的图完全不一样。3. 一张架构图的五大构成要素以及最容易翻车的地方3.1 框和层级先分清楚层再画框画架构图最基础的元素就是框。但框不是随便放的框的位置本身就传达信息。最常见的结构是分层。所谓分层就是把系统按职责从纵向上切开比如经典的四层结构接入层、应用层、数据层、基础设施层。每一层是一个或多个框层与层之间用横线或大片留白隔开。这里有一个非常重要的细节层与层的顺序要符合调用方向。比如用户请求从上往下走那你画图的时候接入层就必须在顶部数据层在底部。反过来如果依赖关系是自下而上的那底层模块画在下方就对了。这个方向感是很多人不重视、但看的人非常敏感的东西。另外同一层内的框要水平对齐不同层的框不要穿插。我看到过一张图应用层的服务框跑到了数据层下面看的人得靠连线猜归属体验极差。对齐是架构图美感的底线不管是左对齐、居中对齐还是网格对齐至少要让人第一眼能看出这是一个整体。3.2 箭头不是装饰方向、实线、虚线、颜色各有含义很多人画架构图时把箭头当装饰随手一拉完全不去想箭头的方向代表什么。这是架构图里最容易被忽略、也最影响理解的问题。箭头方向在技术架构图里通常代表依赖方向或调用方向而且同一个图里只能有一种约定。比如你约定箭头从调用方指向被调用方那全图所有箭头都得遵守这个约定。最怕的是有人一半画调用方向一半画数据流向读者看的时候脑子要不停地切换非常累。我自己的习惯是实线箭头表示同步调用或强依赖比如服务A调服务B的接口虚线箭头表示异步通知、消息事件或弱依赖比如服务A发消息到MQMQ异步推给服务B无箭头连线表示静态配置关系或关联关系比如配置中心管理某服务的配置颜色也是语义的一部分。我建议同一个图里颜色不要超过三种一种表示层的底色比如统一用浅灰一种表示高亮重点模块比如你这次要重点讲的那一个服务一种表示异常或特殊状态比如正在重构的模块。颜色一旦复杂读者就会开始纠结这个颜色是不是有什么特殊含义反而分散注意力。3.3 最小信息量原则不是把所有细节都放上去画架构图最大的坑就是什么都想往图上放。你辛辛苦苦写的代码、做的模块划分你觉得每一个细节都值得展示于是把所有服务、所有表、所有配置项全部铺到图上。结果就是图上一团乱麻谁也不愿意看。正确的做法是只放这个视角下需要出现的东西。如果你是画系统架构图给新同事介绍模块划分那只需要画出服务名、服务之间的调用关系、关键中间件不需要画出数据库里的每一张表。如果你是画部署架构图那核心是机器、网络、端口而不是服务内部的类结构。这里有一个很实用的判断标准如果删掉这个框看图的人会不会产生误解如果不会那就删掉。直到你删到不能再删为止架构图的表达效率才是最高的。提示一张架构图的信息密度应该控制在一屏看完30秒能讲清楚主线的程度。超过这个密度要么拆分视图要么精简内容。4. 实操走一遍从空白画布到一张合格的系统架构图前面讲了很多原则现在我用一个实际的例子把完整流程走一遍。背景是这样的有一个电商后台系统包含用户服务、订单服务、商品服务、支付服务四个核心微服务服务间通过HTTP调用订单和支付之间通过MQ做异步解耦所有服务注册到Nacos配置放在Nacos配置中心数据库用MySQL缓存用Redis前端通过网关统一接入。现在需要画一张微服务系统架构图。4.1 确认读者与目标你的图是给谁看的这一步虽然不产生任何图形但它决定了整张图的取舍。假设这张图是给刚入职的后端工程师看的目标是让他快速了解系统有哪些服务、服务之间怎么调用、数据存在哪里。那这张图的核心就是服务划分 服务间关系不需要画出具体的表结构也不需要画出K8s集群里的每个Pod。假设这张图是给运维同学看的目标是让他知道服务部署了哪些节点、端口、网络如何打通。那这张图核心就是部署拓扑服务的逻辑划分反而是次要的。同一个系统两种目标画出来的是两张完全不同的图。4.2 列出模块清单先写文字再画框在拖第一个框之前先在纸上或文档里把要画的模块列出来。我通常会分成三组接入层网关应用层用户服务、订单服务、商品服务、支付服务数据层MySQL、Redis、MQ中间件单独列出来看它属于哪个层Nacos属于基础设施/注册中心MQ属于应用层与数据层之间的消息通道。画的时候可以把Nacos放在应用层侧边用虚线表示注册与配置关系。这个清单列完之后其实架构图的基本骨架就已经出来了三层结构每层有哪几个框清清楚楚。4.3 从草稿到成图不要一上来就用工具这一步非常关键但我发现很少有人这么做先用纸笔画一遍。纸笔画草图有三个好处第一纸笔没有格式负担你可以随意写写画画不会陷入对齐格子这种细节第二草图阶段你可以快速调整布局把模块的位置理顺了再上工具效率反而更高第三纸笔的尺幅天然约束你的信息量逼着你想清楚什么该画、什么不该画。草图只需要画到能看清哪几个框在一层、箭头怎么连即可。等你把布局调整到舒服了再打开工具照着草图誊写一遍半小时就能出图。很多人是一上来就打开工具拖了删、删了拖半天时间都在跟对齐做斗争这就是典型的流程不对。4.4 字体、配色与导出这些细节决定了别人愿不愿意看图的内容对了剩下就是体面的问题。我的经验是字体统一、字号分层、配色克制。字体统一用一种无衬线字体比如PingFang SC、微软雅黑、Arial框内用普通字重图标题和层名称用加粗字号层名称用14~16号模块框内名称用12~14号备注说明用10~11号。全图最多三级字号不要出现第N种字号配色层底色用低饱和度的浅色浅灰、浅蓝、浅绿模块框用白色底深色边框重点模块用强调色比如橙色边框。同一个层内的模块底色务必一致不要每个模块一个颜色导出尽量导出SVG或PDF保证放大不模糊。如果必须贴到文档里导出PNG时把分辨率拉到2x以上这些细节单独看都不起眼但合在一起直接影响别人看图的耐心。我见过不少内容很扎实的图就因为字体难看或者配色花哨在评审会上被领导一句这图看着不专业给否了。5. 工具怎么选别在工具上内耗工具这块我只说一句核心观点工具是手段不是目的。我见过很多人在选工具这件事上纠结到天荒地老今天听说A工具好明天听B工具香画图本身没花多少时间全用来折腾工具了。真没必要。5.1 主流绘图工具对比我把市面上常用的画架构图工具做了一张对比表你可以直接按场景选工具适用场景优势劣势draw.iodiagrams.net通用架构图免费、开源、支持本地文件界面朴素协作弱Excalidraw草图、快速示意手写风格、上手极快不适合严谨规范图ProcessOn国内团队协作模板多、中文友好免费版有数量限制PlantUML代码生成图适合放代码仓库、版本管理学习曲线样式受限MermaidMarkdown内嵌图与文档同源、极轻量复杂布局画不了Visio企业规范图功能全、老牌贵、笨重、协作差Figma/即时设计UI稿级精细图可做出很精致的图不适合快速画草图偏重如果让我给一句话建议个人画图用draw.io快速示意用Excalidraw团队协作国内用ProcessOn要嵌在代码仓库里用Mermaid或PlantUML。5.2 代码类绘图工具到底适不适合画架构图这里多说两句Mermaid和PlantUML这类写代码画图的工具。它们在开发圈子里有一定声量但我的真实体验是适合画简单的流程图和时序图画复杂架构图非常吃力。为什么因为架构图的核心是布局。你希望用户服务在左上角、订单服务在右边、MQ在中间下方这种精确的位置控制在代码类工具里实现起来非常痛苦。而布局恰恰是架构图表达的重要维度——就像前面说的分层关系靠位置就传达了一大半。那代码类工具就没有用了吗不是。它的价值在于可以作为文档的一部分存在因为图和代码在同一个Markdown文件里改起来方便不会出现图已经更新了但文档里还是旧图的情况。我一般只会在README里用Mermaid画非常简单的系统关系图正式的架构评审还是会用draw.io。所以你要认清工具的使用场景边界临时说明用Mermaid正式输出用可视化工具。两条腿走路别拿一种工具解决所有问题。6. 三种高频场景的实战画法微服务、大数据、AI智能体6.1 微服务架构图怎么画别画成一张蜘蛛网微服务架构图是出现频率最高、翻车率也最高的图型。主要原因在于微服务一多服务间互相调用画出来就像一张蜘蛛网线绕来绕去根本看不清。画微服务架构图我建议你用分层 入口 关键链路的框架第一层接入层网关、负载均衡、前端第二层服务层核心微服务第三层中间件层注册中心、配置中心、消息队列第四层数据层数据库、缓存、对象存储服务之间的调用关系只画关键链路不要把所有调用都画出来。比如订单服务和支付服务是核心链路必须画但用户服务调了一个很边缘的短信服务且当前讨论不涉及可以不画。不是省略事实而是控制信息密度。另外服务间的箭头从调用方指向被调用方这一点要全图统一。注册中心、配置中心与各个服务之间的关系用虚线表示因为那是注册/配置关系不是业务调用关系。这两种关系混在一张图里时务必用线条样式区分开。6.2 大数据架构图怎么画跟着数据流走大数据平台架构图的核心不是模块关系而是数据流向。画大数据架构图先梳理数据从哪来、经过什么处理、最终到哪里去。通常可以按这样的链路来画数据源层业务数据库、日志、埋点数据采集层CDC、日志采集、消息队列Kafka计算层实时计算Flink、离线计算Spark/Hive存储层数仓、数据湖、OLAP引擎应用层报表、大屏、数据接口、机器学习平台画的时候主链路用粗实线箭头从数据源指向最终应用处理节点在主链路上旁边可以画辅助系统调度系统、元数据管理、权限管理用浅色或者独立区域表示。大数据架构图最忌讳的是一上来就画一堆组件Hadoop、Spark、Flink、Kafka、Hive、HBase、ClickHouse全堆上去组件之间的数据流没有主线图显得很大但看的人完全抓不住重点。正确做法是主线先画出来辅助组件按需要补充除非这张图本身就是为了展示全量技术栈。6.3 AI智能体功能架构图怎么画按能力模块组织这两年AI智能体火起来之后智能体功能架构图变成了高频词。这类架构图跟传统系统架构图不太一样它更偏功能而不是部署所以画法上也有些区别。画智能体功能架构图我建议按以下分层来组织交互层用户输入、多模态接入文本/语音/图片能力层意图识别、上下文管理、工具调用Function Call、记忆模块、知识库检索模型层主模型、微调模型、多模型路由基础层向量数据库、外部API、工具集、日志追踪智能体架构图的关键在于表达能力的组合关系而不是依赖关系。比如记忆模块和知识库检索都会影响上下文管理这种关系用虚线箭头表示影响/读取会比实线调用更贴切。另外智能体是一个新型系统画图时不要死守传统三层结构按功能域划分区块往往更清晰。7. 常见问题与排查技巧实录画架构图最容易踩的坑7.1 问题速查表我梳理了一下这些年踩过的、以及帮别人review图时看到的高频问题整理成一张排查表问题现象根因解决方案别人看完不知道重点在哪没有主线所有模块同等强调用颜色或加粗强调1~2个核心模块图上全是交叉线布局没规划框的位置不合理先分层层内左右排布跨层连线尽量走两侧箭头方向看不懂同一张图混用了多种方向约定统一约定箭头从调用方指向被调用方图和PPT文字对不上画图时没和文档同步图定稿前先对照文档确认术语一致图一放大就糊导出的位图分辨率不足导出SVG或PNG至少2x中文字体显示异常工具不支持中文字体统一用系统字体避免特殊字体层与层之间归属不清框的位置没有对齐同一层模块严格水平对齐层间留白把部署细节画进了业务图没有区分视图层级先明确图类型部署细节另开一张部署图服务名写简称别人看不懂没有把术语对齐第一次出现写全称并括注简称一张图画了50个框没有做信息裁剪按能不能删逐框审查删到不能再删这张表你可以直接打印出来画图之前扫一遍基本能避开80%的常见问题。7.2 几个我记了很久的教训最后分享几个偏个人经验的东西。教训一画完图之后一定找一个人过一遍。以前我画完图就直接发出去后来发现自己看着很顺的图别人看完全是另一个理解。我现在习惯把图发给一个不太了解这个系统的人让他讲一遍他看到了什么。如果他讲的和你想要表达的意思差了十万八千里这图多半得改。这是成本最低的评审方式。教训二批量画图之前先定好图层规范。如果你要为一个系统画一组架构图系统架构图、部署架构图、数据架构图一定要先统一规范同一种颜色代表什么、同一个服务在每张图里用什么表达方式、字体字号如何统一。否则你会发现三张图各画各的放在一起就像三个不同人画的。教训三别为了美观牺牲信息准确性。我见过一些画得很好看的架构图颜色协调、排版精美但仔细一看服务A明明调用服务B箭头上却写着HTTP而且方向画反了。这样的图再好看也是废图。架构图不是海报准确永远排在美观前面。教训四关键依赖不要画成一条线带过。有时候为了图面简洁我会把订单服务依赖支付服务、依赖用户服务、依赖MQ画成一根总线和多个分支后来发现这样会让新来的同事误以为这三个依赖是同一种性质。现在我会在关键依赖线上加简短的注释比如标上HTTP同步、MQ异步用几个字把依赖性质说清楚。这个细节在评审时非常加分因为别人一眼就能看出调用链路上的同步阻塞点和异步解耦点在哪里。我在实际画图过程中还有一个习惯每张图都留一个版本号和日期放在图的右下角。架构图是活的系统一迭代图就要更新没有版本管理的架构图时间一长就会变成薛定谔的图——没人知道它画的是现在的系统还是三个月前的系统。加上时间和版本号至少能让看的人有个判断依据。这个习惯救过我不少次。有一次用户反馈某个模块已经没有了我还画在上面我翻了一下版本记录发现是三个月前的图一直没更新。从那以后凡是项目里要长期维护的架构图我都会在图的角落写上最后更新时间每次更新时顺手改一下。别小看这一行字它能帮你避免很多图上画着有代码里已经没了的尴尬。 架构图怎么画？系统架构师教你从思考到落地的完整指南
1. 先别急着打开画图工具把这件事想明白很多人问过我架构图怎么画我第一反应通常是反问一句你打算给谁看这不是抬杠。画架构图这事儿百分之八十的问题不是出在工具不熟、模板不够、配色难看而是出在动手之前没想清楚这张图到底要干什么。我见过太多人打开画图软件就开始拖方框拖到一半发现方向不对推倒重来一上午就没了。还有人画完一张自认为非常完整的架构图发到群里结果同事回复一句这图画的是啥问题不在手在脑子。架构图本质上是一种表达工具它是你把脑子里的系统认知用一种别人能看懂的方式传递出去。既然是表达就需要先有内容再有形式。就像写文章之前要先有提纲画架构图之前也要先有一个脑内的图工具只是把你脑内那张图落到画布上而已。如果你脑子里对系统结构本身还是一团浆糊那不管你用多贵的工具、套多好看的模板画出来的东西依然是浆糊。反过来如果你对系统理解得很清楚哪怕用Windows自带的画图也能画出一张让别人秒懂的架构图。所以这篇文章我不打算只跟你聊工具和模板。我要聊的是画架构图的完整思考链路先想清楚给谁看再决定画什么类型然后才是怎么布局、用什么工具、怎么标注。最后我会用几个高频场景——微服务架构、大数据平台、AI智能体——把整套方法走一遍。这对谁有用如果你是刚开始画架构图的开发工程师、刚转岗需要写设计文档的技术人员或者经常要做PPT汇报但没有系统学过画图方法的人这篇文章基本就是给你准备的。如果你已经是老手也可以跳着看看后面的踩坑记录说不定有你没注意到的细节。2. 架构图有哪些类型别把组织架构图当成软件架构图关于架构图大家搜索的时候会出现一个很有意思的现象有人搜的是组织架构图比如某公司、某单位的管理层级有人搜的是系统架构图、软件架构图还有人搜的是微服务架构图、大数据架构图。这些名字里都带架构图三个字但它们要表达的东西完全不同。这就回到第一件事画之前先对齐语境。你拿着画系统架构图的方法去画组织架构图肯定画不对你拿着公司组织架构图的模板去画微服务调用关系那就是灾难。我这里主要讲的是技术类架构图也就是软件、系统、平台这一类的架构图。但为了让你心里有个谱我把几种常见的架构图类型放一起对比一下类型表达的核心内容典型读者关键元素业务架构图业务流程、角色、业务模块产品、业务方、管理层角色、流程节点、单据/数据流组织架构图组织层级、汇报关系管理层、HR部门/岗位框、上下级连线系统/应用架构图系统模块、服务划分、依赖关系开发、测试、架构师模块框、依赖线、调用箭头部署架构图服务器、网络、容器、节点分布运维、SRE、DevOps主机/容器、网络分区、负载均衡数据架构图数据流向、存储、处理链路数据工程师、后端数据源、存储、处理节点、数据线这些图之间不是互斥的一个系统可以同时有系统架构图、部署架构图和数据架构图它们是从不同视角看同一个系统。真正的高手不是把所有这些视角塞进一张图里而是知道每张图该画什么、该藏什么。我记得有一次评审会上有人把系统架构图、部署架构图和时序图揉成一张巨图打印出来字都看不清。当时评审组长只说了一句话这图我数了一下有四十多个框六十多条线你们谁能五分钟之内给我讲清楚它是干嘛的全场沉默。这就是典型的一张图想干所有事结果一件事都没干成。所以在动手之前务必先问自己一个问题这张图是给谁看的希望他看完之后做什么是让领导确认技术选型方向是让新同事知道系统有什么模块是让运维知道服务部署在哪台机器上不同的答案对应的图完全不一样。3. 一张架构图的五大构成要素以及最容易翻车的地方3.1 框和层级先分清楚层再画框画架构图最基础的元素就是框。但框不是随便放的框的位置本身就传达信息。最常见的结构是分层。所谓分层就是把系统按职责从纵向上切开比如经典的四层结构接入层、应用层、数据层、基础设施层。每一层是一个或多个框层与层之间用横线或大片留白隔开。这里有一个非常重要的细节层与层的顺序要符合调用方向。比如用户请求从上往下走那你画图的时候接入层就必须在顶部数据层在底部。反过来如果依赖关系是自下而上的那底层模块画在下方就对了。这个方向感是很多人不重视、但看的人非常敏感的东西。另外同一层内的框要水平对齐不同层的框不要穿插。我看到过一张图应用层的服务框跑到了数据层下面看的人得靠连线猜归属体验极差。对齐是架构图美感的底线不管是左对齐、居中对齐还是网格对齐至少要让人第一眼能看出这是一个整体。3.2 箭头不是装饰方向、实线、虚线、颜色各有含义很多人画架构图时把箭头当装饰随手一拉完全不去想箭头的方向代表什么。这是架构图里最容易被忽略、也最影响理解的问题。箭头方向在技术架构图里通常代表依赖方向或调用方向而且同一个图里只能有一种约定。比如你约定箭头从调用方指向被调用方那全图所有箭头都得遵守这个约定。最怕的是有人一半画调用方向一半画数据流向读者看的时候脑子要不停地切换非常累。我自己的习惯是实线箭头表示同步调用或强依赖比如服务A调服务B的接口虚线箭头表示异步通知、消息事件或弱依赖比如服务A发消息到MQMQ异步推给服务B无箭头连线表示静态配置关系或关联关系比如配置中心管理某服务的配置颜色也是语义的一部分。我建议同一个图里颜色不要超过三种一种表示层的底色比如统一用浅灰一种表示高亮重点模块比如你这次要重点讲的那一个服务一种表示异常或特殊状态比如正在重构的模块。颜色一旦复杂读者就会开始纠结这个颜色是不是有什么特殊含义反而分散注意力。3.3 最小信息量原则不是把所有细节都放上去画架构图最大的坑就是什么都想往图上放。你辛辛苦苦写的代码、做的模块划分你觉得每一个细节都值得展示于是把所有服务、所有表、所有配置项全部铺到图上。结果就是图上一团乱麻谁也不愿意看。正确的做法是只放这个视角下需要出现的东西。如果你是画系统架构图给新同事介绍模块划分那只需要画出服务名、服务之间的调用关系、关键中间件不需要画出数据库里的每一张表。如果你是画部署架构图那核心是机器、网络、端口而不是服务内部的类结构。这里有一个很实用的判断标准如果删掉这个框看图的人会不会产生误解如果不会那就删掉。直到你删到不能再删为止架构图的表达效率才是最高的。提示一张架构图的信息密度应该控制在一屏看完30秒能讲清楚主线的程度。超过这个密度要么拆分视图要么精简内容。4. 实操走一遍从空白画布到一张合格的系统架构图前面讲了很多原则现在我用一个实际的例子把完整流程走一遍。背景是这样的有一个电商后台系统包含用户服务、订单服务、商品服务、支付服务四个核心微服务服务间通过HTTP调用订单和支付之间通过MQ做异步解耦所有服务注册到Nacos配置放在Nacos配置中心数据库用MySQL缓存用Redis前端通过网关统一接入。现在需要画一张微服务系统架构图。4.1 确认读者与目标你的图是给谁看的这一步虽然不产生任何图形但它决定了整张图的取舍。假设这张图是给刚入职的后端工程师看的目标是让他快速了解系统有哪些服务、服务之间怎么调用、数据存在哪里。那这张图的核心就是服务划分 服务间关系不需要画出具体的表结构也不需要画出K8s集群里的每个Pod。假设这张图是给运维同学看的目标是让他知道服务部署了哪些节点、端口、网络如何打通。那这张图核心就是部署拓扑服务的逻辑划分反而是次要的。同一个系统两种目标画出来的是两张完全不同的图。4.2 列出模块清单先写文字再画框在拖第一个框之前先在纸上或文档里把要画的模块列出来。我通常会分成三组接入层网关应用层用户服务、订单服务、商品服务、支付服务数据层MySQL、Redis、MQ中间件单独列出来看它属于哪个层Nacos属于基础设施/注册中心MQ属于应用层与数据层之间的消息通道。画的时候可以把Nacos放在应用层侧边用虚线表示注册与配置关系。这个清单列完之后其实架构图的基本骨架就已经出来了三层结构每层有哪几个框清清楚楚。4.3 从草稿到成图不要一上来就用工具这一步非常关键但我发现很少有人这么做先用纸笔画一遍。纸笔画草图有三个好处第一纸笔没有格式负担你可以随意写写画画不会陷入对齐格子这种细节第二草图阶段你可以快速调整布局把模块的位置理顺了再上工具效率反而更高第三纸笔的尺幅天然约束你的信息量逼着你想清楚什么该画、什么不该画。草图只需要画到能看清哪几个框在一层、箭头怎么连即可。等你把布局调整到舒服了再打开工具照着草图誊写一遍半小时就能出图。很多人是一上来就打开工具拖了删、删了拖半天时间都在跟对齐做斗争这就是典型的流程不对。4.4 字体、配色与导出这些细节决定了别人愿不愿意看图的内容对了剩下就是体面的问题。我的经验是字体统一、字号分层、配色克制。字体统一用一种无衬线字体比如PingFang SC、微软雅黑、Arial框内用普通字重图标题和层名称用加粗字号层名称用14~16号模块框内名称用12~14号备注说明用10~11号。全图最多三级字号不要出现第N种字号配色层底色用低饱和度的浅色浅灰、浅蓝、浅绿模块框用白色底深色边框重点模块用强调色比如橙色边框。同一个层内的模块底色务必一致不要每个模块一个颜色导出尽量导出SVG或PDF保证放大不模糊。如果必须贴到文档里导出PNG时把分辨率拉到2x以上这些细节单独看都不起眼但合在一起直接影响别人看图的耐心。我见过不少内容很扎实的图就因为字体难看或者配色花哨在评审会上被领导一句这图看着不专业给否了。5. 工具怎么选别在工具上内耗工具这块我只说一句核心观点工具是手段不是目的。我见过很多人在选工具这件事上纠结到天荒地老今天听说A工具好明天听B工具香画图本身没花多少时间全用来折腾工具了。真没必要。5.1 主流绘图工具对比我把市面上常用的画架构图工具做了一张对比表你可以直接按场景选工具适用场景优势劣势draw.iodiagrams.net通用架构图免费、开源、支持本地文件界面朴素协作弱Excalidraw草图、快速示意手写风格、上手极快不适合严谨规范图ProcessOn国内团队协作模板多、中文友好免费版有数量限制PlantUML代码生成图适合放代码仓库、版本管理学习曲线样式受限MermaidMarkdown内嵌图与文档同源、极轻量复杂布局画不了Visio企业规范图功能全、老牌贵、笨重、协作差Figma/即时设计UI稿级精细图可做出很精致的图不适合快速画草图偏重如果让我给一句话建议个人画图用draw.io快速示意用Excalidraw团队协作国内用ProcessOn要嵌在代码仓库里用Mermaid或PlantUML。5.2 代码类绘图工具到底适不适合画架构图这里多说两句Mermaid和PlantUML这类写代码画图的工具。它们在开发圈子里有一定声量但我的真实体验是适合画简单的流程图和时序图画复杂架构图非常吃力。为什么因为架构图的核心是布局。你希望用户服务在左上角、订单服务在右边、MQ在中间下方这种精确的位置控制在代码类工具里实现起来非常痛苦。而布局恰恰是架构图表达的重要维度——就像前面说的分层关系靠位置就传达了一大半。那代码类工具就没有用了吗不是。它的价值在于可以作为文档的一部分存在因为图和代码在同一个Markdown文件里改起来方便不会出现图已经更新了但文档里还是旧图的情况。我一般只会在README里用Mermaid画非常简单的系统关系图正式的架构评审还是会用draw.io。所以你要认清工具的使用场景边界临时说明用Mermaid正式输出用可视化工具。两条腿走路别拿一种工具解决所有问题。6. 三种高频场景的实战画法微服务、大数据、AI智能体6.1 微服务架构图怎么画别画成一张蜘蛛网微服务架构图是出现频率最高、翻车率也最高的图型。主要原因在于微服务一多服务间互相调用画出来就像一张蜘蛛网线绕来绕去根本看不清。画微服务架构图我建议你用分层 入口 关键链路的框架第一层接入层网关、负载均衡、前端第二层服务层核心微服务第三层中间件层注册中心、配置中心、消息队列第四层数据层数据库、缓存、对象存储服务之间的调用关系只画关键链路不要把所有调用都画出来。比如订单服务和支付服务是核心链路必须画但用户服务调了一个很边缘的短信服务且当前讨论不涉及可以不画。不是省略事实而是控制信息密度。另外服务间的箭头从调用方指向被调用方这一点要全图统一。注册中心、配置中心与各个服务之间的关系用虚线表示因为那是注册/配置关系不是业务调用关系。这两种关系混在一张图里时务必用线条样式区分开。6.2 大数据架构图怎么画跟着数据流走大数据平台架构图的核心不是模块关系而是数据流向。画大数据架构图先梳理数据从哪来、经过什么处理、最终到哪里去。通常可以按这样的链路来画数据源层业务数据库、日志、埋点数据采集层CDC、日志采集、消息队列Kafka计算层实时计算Flink、离线计算Spark/Hive存储层数仓、数据湖、OLAP引擎应用层报表、大屏、数据接口、机器学习平台画的时候主链路用粗实线箭头从数据源指向最终应用处理节点在主链路上旁边可以画辅助系统调度系统、元数据管理、权限管理用浅色或者独立区域表示。大数据架构图最忌讳的是一上来就画一堆组件Hadoop、Spark、Flink、Kafka、Hive、HBase、ClickHouse全堆上去组件之间的数据流没有主线图显得很大但看的人完全抓不住重点。正确做法是主线先画出来辅助组件按需要补充除非这张图本身就是为了展示全量技术栈。6.3 AI智能体功能架构图怎么画按能力模块组织这两年AI智能体火起来之后智能体功能架构图变成了高频词。这类架构图跟传统系统架构图不太一样它更偏功能而不是部署所以画法上也有些区别。画智能体功能架构图我建议按以下分层来组织交互层用户输入、多模态接入文本/语音/图片能力层意图识别、上下文管理、工具调用Function Call、记忆模块、知识库检索模型层主模型、微调模型、多模型路由基础层向量数据库、外部API、工具集、日志追踪智能体架构图的关键在于表达能力的组合关系而不是依赖关系。比如记忆模块和知识库检索都会影响上下文管理这种关系用虚线箭头表示影响/读取会比实线调用更贴切。另外智能体是一个新型系统画图时不要死守传统三层结构按功能域划分区块往往更清晰。7. 常见问题与排查技巧实录画架构图最容易踩的坑7.1 问题速查表我梳理了一下这些年踩过的、以及帮别人review图时看到的高频问题整理成一张排查表问题现象根因解决方案别人看完不知道重点在哪没有主线所有模块同等强调用颜色或加粗强调1~2个核心模块图上全是交叉线布局没规划框的位置不合理先分层层内左右排布跨层连线尽量走两侧箭头方向看不懂同一张图混用了多种方向约定统一约定箭头从调用方指向被调用方图和PPT文字对不上画图时没和文档同步图定稿前先对照文档确认术语一致图一放大就糊导出的位图分辨率不足导出SVG或PNG至少2x中文字体显示异常工具不支持中文字体统一用系统字体避免特殊字体层与层之间归属不清框的位置没有对齐同一层模块严格水平对齐层间留白把部署细节画进了业务图没有区分视图层级先明确图类型部署细节另开一张部署图服务名写简称别人看不懂没有把术语对齐第一次出现写全称并括注简称一张图画了50个框没有做信息裁剪按能不能删逐框审查删到不能再删这张表你可以直接打印出来画图之前扫一遍基本能避开80%的常见问题。7.2 几个我记了很久的教训最后分享几个偏个人经验的东西。教训一画完图之后一定找一个人过一遍。以前我画完图就直接发出去后来发现自己看着很顺的图别人看完全是另一个理解。我现在习惯把图发给一个不太了解这个系统的人让他讲一遍他看到了什么。如果他讲的和你想要表达的意思差了十万八千里这图多半得改。这是成本最低的评审方式。教训二批量画图之前先定好图层规范。如果你要为一个系统画一组架构图系统架构图、部署架构图、数据架构图一定要先统一规范同一种颜色代表什么、同一个服务在每张图里用什么表达方式、字体字号如何统一。否则你会发现三张图各画各的放在一起就像三个不同人画的。教训三别为了美观牺牲信息准确性。我见过一些画得很好看的架构图颜色协调、排版精美但仔细一看服务A明明调用服务B箭头上却写着HTTP而且方向画反了。这样的图再好看也是废图。架构图不是海报准确永远排在美观前面。教训四关键依赖不要画成一条线带过。有时候为了图面简洁我会把订单服务依赖支付服务、依赖用户服务、依赖MQ画成一根总线和多个分支后来发现这样会让新来的同事误以为这三个依赖是同一种性质。现在我会在关键依赖线上加简短的注释比如标上HTTP同步、MQ异步用几个字把依赖性质说清楚。这个细节在评审时非常加分因为别人一眼就能看出调用链路上的同步阻塞点和异步解耦点在哪里。我在实际画图过程中还有一个习惯每张图都留一个版本号和日期放在图的右下角。架构图是活的系统一迭代图就要更新没有版本管理的架构图时间一长就会变成薛定谔的图——没人知道它画的是现在的系统还是三个月前的系统。加上时间和版本号至少能让看的人有个判断依据。这个习惯救过我不少次。有一次用户反馈某个模块已经没有了我还画在上面我翻了一下版本记录发现是三个月前的图一直没更新。从那以后凡是项目里要长期维护的架构图我都会在图的角落写上最后更新时间每次更新时顺手改一下。别小看这一行字它能帮你避免很多图上画着有代码里已经没了的尴尬。