1. 为什么一张“架构流程图”值得单独拿出来讲很多人第一次听到“架构流程图”这五个字第一反应是不就是画个框框图吗Visio 拖几个方块、连几条线半小时搞定。我刚开始做项目的时候也是这么想的直到有一次给一个跨团队的系统做评审我拿着自己画的“架构图”讲了二十分钟台下一位资深工程师问了一句“你这个箭头代表的是数据流还是调用关系这条虚线是异步还是同步”我当时就卡住了——因为我自己也没想清楚。这件事之后我才明白架构流程图不是美术作品而是一种精确的沟通工具。它要回答的核心问题只有几个系统由哪些部分组成、这些部分之间怎么交互、数据往哪里流、边界在哪里、出问题的时候责任落在谁头上。一张好的架构流程图能让新加入的同事在十分钟内理解系统全貌能让运维在半夜排障时快速定位到故障域也能让产品经理看懂“为什么这个需求要改三个服务”。这篇文章适合几类人看刚接手一个陌生系统、需要快速梳理现状的开发者准备做技术方案评审、需要把设计讲清楚的架构师还有那些画了图却被吐槽“看不懂”的同学。我会从为什么要画、画之前想清楚什么、怎么分层画、常见符号怎么用、工具怎么选、评审时怎么讲这几个角度把“架构流程图”这件事拆透。全程都是我自己踩过坑之后总结的实操经验不是教科书式的定义罗列。先给一个我自己的判断标准如果一张架构图拿掉所有文字说明一个没参与过项目的人还能大致说出系统的数据流向和主要模块那这张图就及格了。后面所有的技巧都是围绕这个标准展开的。2. 画图之前必须先想清楚的四个问题2.1 这张图是给谁看的决定了它的抽象层级我见过最常见的错误就是一张图想同时满足所有人。给老板看的图里塞满了 Redis 集群分片细节给运维看的图里又只有“业务层、服务层、数据层”三个大框。结果两边都不满意。正确的做法是先定读者再定粒度。我一般把架构流程图分成三个层级来画层级读者关注点粒度示例系统上下文图老板、产品、外部团队系统边界、外部依赖本系统 vs 支付系统 vs 用户端容器/服务图架构师、开发、测试服务划分、调用关系订单服务、库存服务、网关组件/部署图运维、SRE、核心开发进程、端口、中间件Nginx、Tomcat、MySQL 主从我自己的习惯是任何一次评审至少准备上下文图和服务图两张。上下文图用来对齐“我们在做什么”服务图用来讨论“怎么做”。如果评审涉及部署和容量再加一张部署图。千万不要指望一张图打天下。这里有个经验给非技术同学讲的时候上下文图里的框不要超过 7 个。超过 7 个人的短期记忆就装不下了他们会开始走神。如果外部依赖确实很多就做聚合比如把“短信、邮件、推送”合并成一个“消息通道”。2.2 先明确“画的是什么流”别把数据流和控制流混在一起这是我在评审里被问倒的那次之后痛定思痛总结出来的。架构流程图里其实混着好几种“流”数据流数据从 A 传到 B比如用户下单请求从网关到订单服务。控制流谁调用谁比如订单服务调用库存服务扣减库存。依赖流编译期或部署期的依赖比如服务 A 依赖服务 B 的 SDK。部署流进程部署在哪台机器、哪个机房。这几种流如果画在同一张图里用同一种箭头必然混乱。我的做法是一张图只突出一种主流其他流用不同线型或颜色弱化。比如主图画数据流用实线粗箭头控制流用细实线异步消息用虚线部署关系干脆不画放到另一张图。提示如果你发现一张图里箭头类型超过三种基本可以判定这张图需要拆了。读者的认知负担已经过载。2.3 边界要画出来否则责任永远扯不清架构图里最容易被忽略、但最重要的元素是边界。系统边界、团队边界、信任边界、故障边界这些不画出来出了问题就是互相甩锅。我习惯用不同颜色的背景框来表示边界。比如蓝色背景本团队负责的服务灰色背景其他团队负责的服务红色虚线框外部第三方系统黄色背景需要重点关注的故障域有一次我们排查一个超时问题就是因为架构图上没画清楚“这个缓存是跨机房共享的还是本机房独享的”导致两个团队各自以为是对方的问题查了一整天才发现是缓存穿透。后来我在图上专门加了一条注释“本机房独享不跨机房同步”。就这么一句话省了后面无数次扯皮。2.4 图例和注释不是可选项是必选项我见过太多图箭头没有图例框没有说明颜色全靠猜。这种图发到群里下面必然跟着一串“这个绿色是什么意思”“这条虚线是啥”。我的硬性要求是任何一张要发出去的架构图必须带图例。图例至少包含框的形状含义矩形服务圆柱数据库圆角矩形外部系统线的类型含义实线同步调用虚线异步消息点线依赖颜色的含义如果有颜色区分关键缩写的全称比如 MQ、LB、GW注释方面我会在关键路径上标注协议和端口比如HTTP:8080、gRPC:9090、TCP:6379。别小看这个排障的时候能省很多事。还有数据量级比如“日均 100 万条”这能帮助读者判断这个链路的压力等级。3. 从零画一张架构流程图的完整实操链路3.1 第一步用白纸或白板做“信息倾倒”别急着开工具我强烈建议不要在还没想清楚的时候打开画图工具。工具会诱导你去调对齐、调颜色反而干扰思考。我的做法是拿一张 A3 白纸或者会议室白板先把所有能想到的模块、系统、中间件、外部依赖全部写下来不管顺序不管层级先倒出来。这个阶段的目标是穷举不是整理。比如我会写下网关、用户服务、订单服务、库存服务、支付回调、消息队列、Redis、MySQL、配置中心、日志收集、监控告警、第三方支付、短信通道……写完之后再开始归类。归类的时候问自己三个问题哪些是我方能控制的哪些是外部依赖哪些是同步链路哪些是异步链路哪些是核心链路挂了就影响主流程哪些是旁路挂了只影响体验这三个问题的答案直接决定了图上的布局和视觉权重。核心链路放中间、用粗线旁路放边上、用细线外部依赖用不同颜色标出来。3.2 第二步确定布局方向从左到右还是从上到下布局方向看起来是小事其实影响很大。我的经验是数据流图用从左到右符合阅读习惯用户请求从左边进来数据往右边流。调用关系图用从上到下上层调用下层层次感强。部署图用从上到下接入层在上数据层在下。如果一张图里既有数据流又有调用关系我一般以数据流为主方向调用关系用垂直方向辅助。比如主链路从左到右某个服务内部再往下展开子调用。还有一个技巧把最频繁交互的模块放在相邻位置。这样连线最短图最干净。如果两个模块之间连线要绕一大圈说明布局有问题要么调整位置要么考虑它们之间是不是真的需要直接交互。3.3 第三步先画主干再补分支最后加装饰我画图的顺序固定是三步第一步画主干。就是那条最核心的链路比如“用户请求 → 网关 → 订单服务 → 库存服务 → 数据库”。这条链路用最粗的线、最醒目的颜色画出来。主干画完整张图的骨架就有了。第二步补分支。主干之外的分支链路比如“订单服务 → 消息队列 → 通知服务”用细一点的线补上。异步链路用虚线和同步链路区分开。第三步加装饰。图例、注释、边界框、颜色这些最后加。装饰加早了改起来麻烦而且容易喧宾夺主。这里有个我踩过的坑不要一开始就追求完美对齐。我见过有人为了把两个框对齐调了半小时。先大致摆好最后统一用工具的对齐功能批量处理。思考的时间应该花在“这个模块该不该画”上而不是“这个框往左移 2 像素”上。3.4 第四步用“反向验证法”检查图的完整性图画完了怎么知道它是不是完整、准确我用一个方法叫反向验证假设现在线上出了故障我拿着这张图能不能顺着图找到故障点具体做法是从用户入口开始沿着主干链路走一遍每到一个节点问自己这个节点挂了图上能看出来影响范围吗这个节点的上游和下游分别是谁图上标清楚了吗这个节点有没有旁路或降级方案图上体现了吗如果走一遍发现某个问题答不上来说明图缺信息回去补。我一般会走三条链路正常链路、异常链路、降级链路。三条都能走通这张图才算合格。注意反向验证的时候最好找一个没参与画图的同事一起走。自己画的图自己有思维盲区别人一眼就能看出“这个箭头到底指向谁”。4. 架构流程图里那些符号和线型的门道4.1 框的形状不是随便选的每种形状有约定俗成的含义虽然不同团队有自己的习惯但行业内有一些通用的约定。我整理了一张表是我自己在用的规范形状含义示例矩形服务/应用/进程订单服务、网关圆柱数据库/存储MySQL、Redis圆角矩形外部系统/第三方支付平台、短信通道平行四边形消息队列/异步通道Kafka、RocketMQ菱形判断/网关路由鉴权判断、灰度路由云形外部网络/公网用户端、CDN这套规范不是强制的但一个团队内部必须统一。我见过一个团队有人用圆柱表示服务有人用圆柱表示数据库评审的时候直接吵起来。后来他们定了一份“画图规范”贴在 wiki 上新人都照着来效率高了很多。4.2 线型承载的信息量比你想象的大线型是架构图里信息密度最高的元素。我用线型的规则是实线粗箭头核心同步调用主链路实线细箭头非核心同步调用虚线箭头异步消息/事件点线箭头依赖关系编译期、部署期双向箭头双向通信慎用容易让人误解为循环依赖这里重点说双向箭头。很多人在画“服务 A 和服务 B 互相调用”的时候直接画一条双向箭头。但这样画有个问题读者不知道是 A 调 B 多还是 B 调 A 多也不知道是不是有循环依赖。我的做法是画两条单向箭头错开一点并在旁边标注调用方向的主次。如果确实是循环依赖那更要用两条线画出来因为循环依赖本身就是需要重点关注的架构问题。还有一个细节箭头指向的是“被调用方”还是“数据接收方”这个必须在图例里说清楚。我一般约定箭头指向数据接收方也就是“数据往哪流箭头往哪指”。这样最符合直觉。4.3 颜色用得好是加分用不好是灾难颜色在架构图里的作用只有一个区分类别。不是用来好看的。我用颜色的原则是最多用4 种颜色超过 4 种人就记不住了每种颜色对应一个明确的类别比如蓝色本团队服务灰色外部服务绿色数据存储橙色中间件不要用红色表示“重要”红色在架构图里通常表示“告警/故障/高风险”容易引起误解色盲友好避免红绿搭配可以用蓝橙搭配我见过一张图用了十几种颜色每个框颜色都不一样问作者为什么他说“这样好看”。结果评审的时候没人看得懂全部注意力都被颜色分散了。颜色是信息不是装饰这个观念一定要建立起来。4.4 文字标注的“三写三不写”框里的文字怎么写也有讲究。我的经验是“三写三不写”三写写服务名不写机器名写“订单服务”不写“order-svc-01”写关键协议和端口写“HTTP:8080”不写“接口”写数据量级或频率写“日均 100 万”不写“大量”三不写不写实现细节不写“用了 Spring Boot”那是代码层面的事不写无意义的缩写不写“SVC”写“服务”不写过长的描述框里超过 10 个字就考虑拆行或加注释我自己的习惯是框里只放名词动词放在线上。比如框里写“订单服务”线上写“创建订单”。这样读起来就是“订单服务 → 创建订单 → 库存服务”非常顺畅。5. 工具选型别在工具上纠结太久5.1 我用过的几类工具和它们的适用场景画架构图的工具大致分四类我分别说说我的使用体验第一类通用绘图工具如 draw.io、ProcessOn。优点是自由度高想怎么画怎么画缺点是容易画得乱七八糟因为没有约束。适合画一次性、非标准的图。我一般用 draw.io 画评审用的草图因为它免费、离线可用、导出格式多。第二类代码化绘图工具如 PlantUML、Mermaid。优点是可以版本控制改起来方便风格统一缺点是需要学语法调整布局不直观。我一般用 PlantUML 画需要长期维护的架构图因为它可以跟着代码一起提交到 Git改一行代码就能更新图。第三类专业架构工具如 C4 模型相关的工具。优点是强制分层符合架构方法论缺点是学习成本高画简单图反而麻烦。适合大型系统的架构文档。第四类白板协作工具。优点是实时协作适合远程评审缺点是画复杂图时精度不够。我一般用在头脑风暴阶段。我的建议是日常评审用 draw.io长期维护用 PlantUML团队协作看情况。不要为了选工具纠结超过半天工具只是手段图的内容才是核心。5.2 代码化绘图的一个实操示例如果你决定用代码化工具这里给一个 PlantUML 的最小示例画一个简单的订单链路startuml skinparam componentStyle rectangle actor 用户 as User component API 网关 as Gateway component 订单服务 as Order component 库存服务 as Stock database 订单库 as OrderDB queue 消息队列 as MQ component 通知服务 as Notify User -- Gateway : HTTPS Gateway -- Order : HTTP:8080 Order -- Stock : gRPC:9090 Order -- OrderDB : SQL Order -- MQ : 异步消息 MQ -- Notify : 消费 enduml这段代码生成的图风格统一改起来也方便。比如要把“库存服务”改成“库存中心”只改一行就行。而且它可以提交到 Git每次架构变更都有记录比图片文件强太多。提示代码化绘图的一个坑是布局不可控。PlantUML 自动布局有时候会把线绕得很乱。我的经验是节点超过 15 个就别用自动布局了手动调或者换工具。5.3 工具之外更重要的是“图的版本管理”这一点很多人忽略。架构图是会变的今天画完下个月可能就过时了。如果图没有版本管理过时的图流传出去比没有图还危险——因为会误导人。我的做法是架构图和代码放在同一个仓库用 Markdown 或 PlantUML 源文件维护。每次架构变更提交代码的同时更新图。评审的时候看 Git 记录就知道这张图是什么时候、为什么改的。如果团队用不了代码化工具至少要做到图上标注版本号和更新日期并且指定一个负责人。我见过太多“三年前的架构图”还在被新人当参考里面的服务早就下线了。6. 评审现场怎么把一张架构图讲明白6.1 讲图的顺序先讲边界再讲主干最后讲细节很多人讲图是从左上角开始一个框一个框地念。这样讲听众很快就迷失了。我讲图的顺序固定是第一步讲边界。“这张图里蓝色是我们团队负责的灰色是外部依赖红色虚线是第三方。”一句话听众就知道该重点关注哪块。第二步讲主干。“用户请求从左边进来经过网关到订单服务再到库存服务最后落库。”沿着主干走一遍听众就有了全局观。第三步讲细节。“这里有个异步消息订单创建后发到队列通知服务消费后发短信。”细节放在最后讲因为这时候听众已经有上下文了容易理解。第四步讲异常和降级。“如果库存服务挂了订单服务会走降级逻辑先记录待扣减后续补偿。”这一步最能体现架构的成熟度也是评审时最容易被问到的。6.2 预判评审时最容易被问的三个问题根据我的经验架构评审时被问得最多的三个问题是“这个服务的边界为什么这么划”—— 回答要点职责单一、数据归属清晰、团队边界对齐。“这个链路挂了怎么办”—— 回答要点有没有降级、有没有重试、有没有熔断、影响范围多大。“为什么用这个中间件不用那个”—— 回答要点性能、成本、团队熟悉度、运维复杂度四个维度对比。提前准备好这三个问题的答案评审基本不会翻车。我一般会在图旁边附一页“设计决策记录”把关键选择的理由写下来评审时直接引用。6.3 评审后的动作把口头结论落到图上评审会上讨论出来的结论如果不落到图上过两周就忘了。我的习惯是评审结束后 24 小时内更新架构图并在图上用注释标出“评审结论”。比如“2024-06 评审库存服务拆分为独立服务Q3 完成”。这样下次再看这张图就知道当时的决策是什么、什么时候做的。架构图不只是描述现状也是记录决策历史的载体。7. 几个我踩过的坑和对应的解法7.1 坑一图太复杂没人看我最开始画的架构图恨不得把每个类都画上去。结果发出去没人看因为太复杂了。后来我学乖了一张图只讲一件事。要讲部署就画部署图要讲调用就画调用图。不要混在一起。如果确实需要在一张图里表达多个维度用分层的方式底层画部署上层画服务用不同颜色区分。但即使这样也要控制总节点数在 20 个以内。7.2 坑二图更新不及时变成“历史文物”前面提过架构图必须跟着代码走。我的解法是把图纳入 Definition of Done一个需求做完如果涉及架构变更必须更新架构图否则不算完成。这个规则一开始有人抵触但坚持两个月后大家就习惯了因为受益的是所有人。7.3 坑三符号不统一各画各的团队里每个人画图习惯不一样合并的时候就很痛苦。我的解法是制定一份团队画图规范不用很长一页纸就够框的形状、线的类型、颜色的含义、图例的格式。新人入职第一周就学这个后面省很多事。7.4 坑四只画了“正常情况”没画“异常情况”这是最隐蔽的坑。正常链路的图大家都画得好但异常链路、降级链路、补偿链路往往被忽略。而这些恰恰是排障和评审时最需要的。我的解法是每张核心架构图必须配一张异常流程图至少标出三个关键故障点的处理方式。8. 关于架构流程图我最后想分享的几点体会画了这么多年架构图我最大的体会是图是思考的产物不是思考的替代品。如果你对系统理解不深画出来的图一定是乱的反过来画图的过程本身就是在逼你把系统想清楚。我经常在画图的过程中发现“这两个服务之间的数据流我居然说不清楚”然后回去看代码、问同事把这块补上。另一个体会是架构图的价值在于沟通不在于好看。我见过很多漂亮的图配色讲究、对齐完美但看完不知道系统怎么工作。也见过手绘的草图歪歪扭扭但一眼就能看懂数据怎么流。后者才是好图。最后一个实用建议每次画完图找一个没参与的人看五分钟然后让他复述一遍系统怎么工作。如果他复述得八九不离十这张图就成功了如果他一脸茫然别怪他回去改图。这个“五分钟复述测试”是我用过最有效的图质量检验方法没有之一。架构流程图这件事说到底就是把脑子里的系统模型用别人能看懂的方式画出来。工具、符号、颜色都是手段核心是你对系统的理解以及你站在读者角度思考的能力。这两点做到了图自然就清楚了。