很多人在画架构图这件事上栽过跟头产品或研发负责人丢给你一句“把系统架构画一下”你打开画图工具对着屏幕发呆半小时不知道第一笔该落在哪里好不容易画出来评审会上一屋子人各执一词有人说“这根本不是架构图这是部署图”有人说“这个框框代表什么这个箭头又代表什么”最后架构图变成了一张谁都看不懂的“涂鸦”。我这些年画过的架构图少说也有几百张从手绘草图到正式评审稿都有踩过的坑足够写一本书今天就把从0开始画出一张优秀架构图的完整思路、实操方法和避坑经验一次说清楚。1. 画架构图的第一步其实是拒绝画图大多数人拿起工具就开画这是最大的误区。架构图本质上是一种沟通工具不是艺术品它的价值在于“让看图的人在最短时间内理解系统长什么样、怎么运转”。所以画之前必须先搞清楚三件事想不清楚这三点画出来的图大概率是废图。1.1 先问清楚这张图给谁看、用来干什么给不同的人看的架构图内容完全不同。给老板汇报用的架构图重点强调系统的价值、规模和关键能力业务模块画清楚就行技术细节能省则省给开发团队做技术设计用的架构图必须细化到模块职责、接口关系、数据流转连异常处理路径都要有体现给运维团队做部署和维护用的架构图重点在组件实例、网络区域、端口协议、依赖关系。同样一个系统面向不同受众可以画三张完全不同的图。我自己的习惯是动笔前先问四个问题这张图的读者是谁他们的技术背景是什么他们看完这张图之后要做什么决策或采取什么行动需要重点强调的信息是什么哪些信息对他们来说是噪音这张图要在什么场合用评审会投影、技术文档、还是新人培训举个真实例子我曾经负责过一个订单中台项目给业务方看的架构图只画了三层接入层、能力层、业务层每个层用代表性模块标注给研发团队看的架构图则有十多个服务节点标注了同步调用和异步消息两种交互方式还标了关键数据表的位置。两张图都是“架构图”但信息密度和侧重点完全不同。1.2 明确架构图的边界和层级很多架构图画得混乱根本原因是边界不清。你要画的到底是整个公司的业务架构、某个系统的应用架构、还是某个服务的技术架构同一套系统站在不同层级去看画出来的图是截然不同的。边界问题可以从两个维度界定一是系统边界即这张图涵盖哪些系统模块、哪些外部依赖二是抽象层级即你要画的是业务流程图、系统模块图、进程部署图还是代码层面的类图。这四个层级从高到低分别是业务架构、系统架构、部署架构、代码架构绝大多数场景下画的是前三个层级代码架构图除非做专项设计评审否则不需要画。判断边界是否清晰有个土办法画完之后找一个不了解这个项目的同事来看如果他能在不询问你的情况下说出“这个系统的核心模块有哪些、数据是怎么流的、部署在哪里”说明边界是清楚的如果他问“这个模块算不算系统内部的”“这个外部系统是必须的吗”说明边界没定好。1.3 先写文字骨架再翻译成图形我不建议一上来就开画图软件。我的习惯是先用纯文本把架构的“骨架”写出来包括核心角色或系统模块清单模块之间的调用关系或依赖关系谁调用谁、谁依赖谁、是同步还是异步数据流转的关键路径外部依赖和交互对象部署环境信息如有需要这段文字骨架就是架构图的“剧本”后续所有绘图动作都是把这段剧本翻译成图形语言。你别小看这一步它能提前过滤掉很多逻辑问题。有一次我画一个支付系统的架构图写文字骨架的时候发现“对账服务”和“账务服务”的依赖关系我根本没想清楚如果直接画图画到一半才发现逻辑不通返工成本高得多。文字骨架还有个副产品可以直接作为架构评审说明文档的底稿。图给人直观印象文字给人精确理解两者配合才能把架构讲透。2. 架构图的核心要素和表达规范把文字骨架翻译成图形这一步最考验功力。架构图不是简单地把方框和箭头堆在一起它有自己的语法和语义。我总结了一套“不管什么架构风格都能套用”的表达规范这套规范让不同项目、不同团队之间沟通时几乎零成本。2.1 统一的图形语义方框、箭头、颜色、线型架构图的“语法”由四类基本元素构成容器、组件、连接关系、标注。容器表达系统的边界比如整个系统、某个子系统、一个运行环境组件表达具体的功能模块或服务连接关系表达依赖、调用或数据流转标注则补充说明关键信息。在图形语义上我有一套默认约定团队内部长期统一使用实线方框代表一个系统或应用圆角方框代表一个服务或模块实线箭头代表同步调用或强依赖虚线箭头代表异步消息或弱依赖箭头方向和依赖方向必须一致都指向被依赖方红色或者暖色标注关键路径、核心链路灰色一般不参与核心流程不同颜色只能代表特定维度比如不同业务域或不同环境不能为美观而滥用这套约定最核心的原则是图和图之间、模块和模块之间的视觉语言必须一致。否则读者每看到一个新图形都要猜“这是什么意思”理解成本一下就上去了。2.2 构图布局的三种经典模式根据系统的特点架构图的布局模式可以选三种这也是我实践中用得最多、效果最好的分层模式从上往下或从下往上分层常见的是展示层、业务层、服务层、数据层。这种模式最直观适合绝大多数业务系统尤其是前后端分离、服务分层清晰的情况。每层内部用矩形包起来标注层名层与层之间用箭头表达调用关系。分层架构图容易画出图效果好是默认首选方案。中心辐射模式以某个核心模块为圆心外围模块围绕它分布用箭头表达与核心模块的关系。适合网关类、注册中心类、核心数据平台这类中心化系统。画的时候注意外围模块尽量按业务相关性分组摆放不要散成一圈均匀分布那样看不出亲疏关系。网状模式适用于微服务数量较多、服务间交互关系密集的系统。这种模式最考验功力因为没有明确的层次结构服务节点摆位和连线规划需要反复调整。我的经验是先按业务域聚簇再画域间交互最后画域内交互层次感就出来了。2.3 颗粒度控制信息分层和“不清不楚”原则颗粒度是架构图最难的平衡点。信息太粗等于没画信息太细又变成部署图或流程图。我心中的判断标准是架构图表达的是“模块之间”的关系而不是“模块内部”的实现。不要试图在一张图里既表达系统间关系又表达模块内部类结构那是两张图的工作。当系统复杂度较高时我采用“分层画法”先画一张总体架构图表达系统的主要模块和它们之间的交互然后针对关键子系统单独画局部架构图在局部图中再细化。总体图给全景视角局部图给深入细节读者可以根据需要选择看图深度。这里我有个“不清不楚原则”如果某个细节画上去会让主线模糊那就坚决不画留到局部图中去表达。一张架构图的信息密度是有限度的一次讲清楚一个主题比一次硬塞五个主题要有效得多。3. 实操走一遍从空白画布到成型架构图的完整流程理论讲了一堆我们来走一遍完整实操。这里我以一个典型的中小规模电商系统为例从确定范围开始带着你一步步画出一张能上评审会的应用架构图。这个例子覆盖了大多数业务系统的常见模式画法可以直接套用到你自己的项目上。3.1 第一步确定范围和元素清单我先列元素清单。假设这个电商系统经过前期调研和讨论边界已经确定——包含用户端、商家端、订单、商品、支付、库存这些核心域不包含推荐系统和客服系统它们属于后续迭代范围。元素清单如下前端C端用户App/H5、B端商家后台Web接入层API网关后台服务用户服务、商品服务、订单服务、支付服务、库存服务、消息服务数据层主库MySQL集群、缓存Redis集群、搜索引擎Elasticsearch外部依赖第三方支付渠道微信支付、支付宝、短信服务商基础设施类注册中心、配置中心、日志系统这些元素要分清楚哪些是“系统内的容器/组件”哪些是“外部依赖”。外部依赖我会在图中用单独的区域或特殊的颜色标出来因为它和内部服务的关键区别是外部依赖的可用性你控制不了是风险点评审时要重点讨论。3.2 第二步确定架构风格和布局方向这个系统是典型的业务导向系统模块划分清晰逻辑上是“前端访问后台、后台访问数据”的单向流动我选择分层模式。布局从上到下依次是第一层客户端C端用户端、B端商家后台第二层接入层API网关第三层核心服务层用户、商品、订单、支付、库存、消息服务第四层数据层MySQL、Redis、Elasticsearch左侧或右侧单独区域外部依赖支付渠道、短信服务商画大框的时候我习惯先把每层的位置框出来然后往里填模块。这样模块的摆放位置天然表达了它的层次归属看图的人一眼就能判断“这是接入层的、这是数据层的”层次信息通过布局而不是颜色就传递出来了。3.3 第三步画模块、连箭头、加标注具体画图时我按“先主链、后次要”的顺序。先把核心调用链路的箭头连出来用户端→网关→订单服务→支付服务→支付渠道这条链路是整个系统的主动脉必须清晰。再连次要链路订单服务→商品服务、订单服务→库存服务、支付服务→用户服务查询余额等。连接关系画完后检查一遍重点看有没有循环依赖。所谓循环依赖就是A依赖B、B又依赖A这在模块划分上是一个需要警惕的信号。如果发现循环依赖我通常的处理方案是要么引入消息中间件把其中一个方向的同步调用改成异步解耦要么把公共逻辑抽出来下沉到更底层的一个公共服务保证箭头方向从上层指向下层、不出现反向。标注是很多人忽略的细节。我在关键位置会加三类标注协议说明C端用户访问网关那根线上标注“HTTPS”消息服务线上标注“RocketMQ”关键数据流文字说明比如订单服务写入订单库后发送“订单已创建”消息这条消息同时被库存服务和消息服务消费重要配置或环境信息比如在注册中心旁边标注“Nacos 2.x3节点集群”标注的原则是有价值的才标每一条标注都是读者理解系统时的一个线索不是装饰。3.4 第四步评审、修改、回归第一版架构图画完后不要急着发出去我建议按下面流程做一轮自查逻辑自查所有标号、箭头、方框是否都有明确含义是否存在标注不清或冲突的地方模块名称是否用词统一比如同一个服务在图中叫“订单服务”在代码中叫“order-service”需不要在图里加上代码标识读者测试找一个不了解背景的同事给他5分钟看这张图然后让他复述他理解到的系统结构和逻辑。他复述不出来的地方就是这张图表达不清的地方。评审修改根据反馈修改后找项目核心成员正式过一遍重点确认模块划分、依赖方向和数据流是否和实际一致有没有遗漏关键外部依赖。这套流程走完架构图基本是合格的。我见过很多团队画完图从来不做“读者测试”都是画完就丢到文档库里吃灰然后三个月后发现图已经和实际系统完全对不上了。架构图不是画完就结束的东西它需要持续维护。4. 架构图工具选型不同场景下我用什么画工具选型这件事我踩过的坑不少。最典型的坑是团队里每个人用不同工具画出来的图格式不统一放到一起风格完全对不上。下面我按实用性角度把主流的架构图工具排个序方便你直接选。4.1 免费轻量型工具draw.iodiagrams.net是我最常用的工具没有之一。理由很简单完全免费、开源、支持本地部署、支持桌面版和在线版、导出格式丰富SVG、PNG、PDF都支持。它的图库里有基础图形元素云厂商图标、网络设备、UML类图、ER图可以直接拖拽使用。团队协作可以通过Web版共享文件也可以配合Git版本管理。Excalidraw是手绘风格的白板工具适合快速画草图、构思阶段用、评审讨论时现场改图。它的优点是画出来的图有一种“临时草稿”的心理暗示大家不会对布局吹毛求疵注意力集中在逻辑讨论上。缺点是图形的规范性不够不适合作为正式文档终稿。ProcessOn是国内团队比较熟悉的在线工具支持架构图、流程图、思维导图操作习惯符合国内用户模板资源也比较丰富。但免费版有文件数量上限协作功能需要付费团队使用时需要评估一下成本。4.2 专业付费型工具Microsoft Visio是老牌经典功能全面标准规范强。适合企业级正式文档、IDC机房部署图、网络拓扑图这类需要精准形状库的场景。缺点是价格不便宜且缺乏在线协作能力最新的Visio for the Web体验也就一般。Enterprise Architect是UML和建模工具适合做严谨的软件架构模型。如果你的团队要遵循TOGAF架构方法论或者在做正式的架构资产登记这类工具是专业的。但学习成本非常高普通团队画一张架构图杀鸡用牛刀了。云厂商自带的架构图工具比如阿里云架构图工具、腾讯云架构图工具、AWS架构图工具在画云上部署架构时很方便因为自带云图标库图标就是对应云产品的官方样式评审部署方案时非常直观。缺点是一旦迁移到混合云或者多云架构这种工具会绑手绑脚。4.3 我给团队定的工具规范在我带的团队里我定的规范是构思和讨论阶段用Excalidraw或白板正式架构图用draw.io所有人统一使用同一套自建的图库和样式模板图标、颜色、线型都有约定保证每张图长得“像一家人”。工具统一带来的好处是协作成本直线下降任何人打开别人的图都能直接编辑不需要花时间习惯不同的操作逻辑。如果你刚开始搭工具生态我给你一个建议先选一个大多数成员有经验的工具而不是选一个功能最强的工具。团队协作里最大的成本永远是“沟通和习惯差异”不是工具本身的性能差距。5. 常见问题和避坑经验这些坑我替你踩过了最后整理几个我见过最多、自己也踩过的架构图大坑。这些问题一旦出现架构图的作用就大打折扣甚至会产生负面效果——误导读者、拖慢评审、导致错误决策。5.1 一张图画所有最后变成“蜘蛛网”这是最经典的新手错误。把所有模块和所有关系塞进一张图箭头上百条最后谁看谁晕。我见过最夸张的一张图上有两百多个节点缩放到1%才能看到全貌放大后又完全不知所云。解决思路拆分——按视图拆总体图局部详图按业务域拆订单域、支付域、库存域各一张按视图类型拆应用架构图、部署架构图、数据架构图。一张图的信息密度极限大约是20到30个节点超过这个数就要考虑拆图了。5.2 只画静态结构不画动态交互静态的架构图展示的是“系统有哪些部分”但架构评审中大家真正关心的问题是“系统怎么运转”。一张只有模块和静态依赖线的架构图读者能知道有哪些服务但不知道数据的来龙去脉不知道关键链路的时序关系。解决思路在架构图边上配合时序图或流程图把关键业务链路比如下单、支付回调、库存扣减按时间顺序画出来与架构图配合阅读。如果只能在架构图上画就标注关键数据的流转路径和流转条件。5.3 图标和颜色滥用视觉噪音淹没信息有些团队画架构图喜欢“追求好看”每个模块用不同颜色、每类交互用不同线型、每个图标又要3D效果画完确实花哨但读者根本无法快速聚焦到核心结构上。解决思路颜色只用在一个维度上通常用来区分业务域或环境线型只用两种实线同步、虚线异步图标统一风格。视觉语言越简单信息传达越精准。我常常说架构图的视觉设计是“做减法”而不是“做加法”。5.4 架构图不更新几个月后就成“历史文物”架构图最容易被诟病的问题就是“和实际代码脱节”。需求变更、服务重构、数据库拆分每发生一次架构图就失真一分。等到新同学入职拿着过期的架构图了解系统被误导的次数多了大家对架构图的信任感就没了。解决思路把架构图变更纳入研发流程和代码变更挂钩。模块调整、接口变更、依赖关系变动时需要同步更新对应的架构图。我还建议每个季度做一次架构图专项审核对照实际系统检查图的准确性发现偏差当场修正。这个习惯长期坚持下来能避免大量沟通成本。5.5 不写图例和说明全靠作者口头讲解这个问题在团队协作中最容易引发矛盾。作者看着自己的图讲得眉飞色舞听众看着投影仪一头雾水。没有图例、没有颜色含义说明、没有作者联系方式这张图一旦流传出去后面的读者只能靠猜。解决思路在架构图的左下角或右下角固定放一个图例区域写明“实线框应用系统、圆角框公共服务、实线箭头同步调用、虚线箭头异步消息、黄色外部依赖”。这段图例看着不起眼但它是一张图作为独立文档存在的基础。写在最后画架构图这件事说到底是技术能力和沟通能力的化学反应。我自己画了这么多年最大的感受是一幅优秀的架构图不是画出来的是“想清楚”之后自然呈现出来的。先把逻辑理清再谈绘图技巧先考虑读者需求再考虑视觉美观先保证信息准确再考虑布局优雅。如果你正准备画自己项目的第一张架构图我建议你先别打开任何画图软件拿出纸笔把“有哪些模块、模块之间什么关系、数据怎么流转”这三件事写清楚想明白再动手。这一步省下来的返工时间会比你想的多得多。
画架构图实战指南：从空白画布到优秀架构设计的完整流程
很多人在画架构图这件事上栽过跟头产品或研发负责人丢给你一句“把系统架构画一下”你打开画图工具对着屏幕发呆半小时不知道第一笔该落在哪里好不容易画出来评审会上一屋子人各执一词有人说“这根本不是架构图这是部署图”有人说“这个框框代表什么这个箭头又代表什么”最后架构图变成了一张谁都看不懂的“涂鸦”。我这些年画过的架构图少说也有几百张从手绘草图到正式评审稿都有踩过的坑足够写一本书今天就把从0开始画出一张优秀架构图的完整思路、实操方法和避坑经验一次说清楚。1. 画架构图的第一步其实是拒绝画图大多数人拿起工具就开画这是最大的误区。架构图本质上是一种沟通工具不是艺术品它的价值在于“让看图的人在最短时间内理解系统长什么样、怎么运转”。所以画之前必须先搞清楚三件事想不清楚这三点画出来的图大概率是废图。1.1 先问清楚这张图给谁看、用来干什么给不同的人看的架构图内容完全不同。给老板汇报用的架构图重点强调系统的价值、规模和关键能力业务模块画清楚就行技术细节能省则省给开发团队做技术设计用的架构图必须细化到模块职责、接口关系、数据流转连异常处理路径都要有体现给运维团队做部署和维护用的架构图重点在组件实例、网络区域、端口协议、依赖关系。同样一个系统面向不同受众可以画三张完全不同的图。我自己的习惯是动笔前先问四个问题这张图的读者是谁他们的技术背景是什么他们看完这张图之后要做什么决策或采取什么行动需要重点强调的信息是什么哪些信息对他们来说是噪音这张图要在什么场合用评审会投影、技术文档、还是新人培训举个真实例子我曾经负责过一个订单中台项目给业务方看的架构图只画了三层接入层、能力层、业务层每个层用代表性模块标注给研发团队看的架构图则有十多个服务节点标注了同步调用和异步消息两种交互方式还标了关键数据表的位置。两张图都是“架构图”但信息密度和侧重点完全不同。1.2 明确架构图的边界和层级很多架构图画得混乱根本原因是边界不清。你要画的到底是整个公司的业务架构、某个系统的应用架构、还是某个服务的技术架构同一套系统站在不同层级去看画出来的图是截然不同的。边界问题可以从两个维度界定一是系统边界即这张图涵盖哪些系统模块、哪些外部依赖二是抽象层级即你要画的是业务流程图、系统模块图、进程部署图还是代码层面的类图。这四个层级从高到低分别是业务架构、系统架构、部署架构、代码架构绝大多数场景下画的是前三个层级代码架构图除非做专项设计评审否则不需要画。判断边界是否清晰有个土办法画完之后找一个不了解这个项目的同事来看如果他能在不询问你的情况下说出“这个系统的核心模块有哪些、数据是怎么流的、部署在哪里”说明边界是清楚的如果他问“这个模块算不算系统内部的”“这个外部系统是必须的吗”说明边界没定好。1.3 先写文字骨架再翻译成图形我不建议一上来就开画图软件。我的习惯是先用纯文本把架构的“骨架”写出来包括核心角色或系统模块清单模块之间的调用关系或依赖关系谁调用谁、谁依赖谁、是同步还是异步数据流转的关键路径外部依赖和交互对象部署环境信息如有需要这段文字骨架就是架构图的“剧本”后续所有绘图动作都是把这段剧本翻译成图形语言。你别小看这一步它能提前过滤掉很多逻辑问题。有一次我画一个支付系统的架构图写文字骨架的时候发现“对账服务”和“账务服务”的依赖关系我根本没想清楚如果直接画图画到一半才发现逻辑不通返工成本高得多。文字骨架还有个副产品可以直接作为架构评审说明文档的底稿。图给人直观印象文字给人精确理解两者配合才能把架构讲透。2. 架构图的核心要素和表达规范把文字骨架翻译成图形这一步最考验功力。架构图不是简单地把方框和箭头堆在一起它有自己的语法和语义。我总结了一套“不管什么架构风格都能套用”的表达规范这套规范让不同项目、不同团队之间沟通时几乎零成本。2.1 统一的图形语义方框、箭头、颜色、线型架构图的“语法”由四类基本元素构成容器、组件、连接关系、标注。容器表达系统的边界比如整个系统、某个子系统、一个运行环境组件表达具体的功能模块或服务连接关系表达依赖、调用或数据流转标注则补充说明关键信息。在图形语义上我有一套默认约定团队内部长期统一使用实线方框代表一个系统或应用圆角方框代表一个服务或模块实线箭头代表同步调用或强依赖虚线箭头代表异步消息或弱依赖箭头方向和依赖方向必须一致都指向被依赖方红色或者暖色标注关键路径、核心链路灰色一般不参与核心流程不同颜色只能代表特定维度比如不同业务域或不同环境不能为美观而滥用这套约定最核心的原则是图和图之间、模块和模块之间的视觉语言必须一致。否则读者每看到一个新图形都要猜“这是什么意思”理解成本一下就上去了。2.2 构图布局的三种经典模式根据系统的特点架构图的布局模式可以选三种这也是我实践中用得最多、效果最好的分层模式从上往下或从下往上分层常见的是展示层、业务层、服务层、数据层。这种模式最直观适合绝大多数业务系统尤其是前后端分离、服务分层清晰的情况。每层内部用矩形包起来标注层名层与层之间用箭头表达调用关系。分层架构图容易画出图效果好是默认首选方案。中心辐射模式以某个核心模块为圆心外围模块围绕它分布用箭头表达与核心模块的关系。适合网关类、注册中心类、核心数据平台这类中心化系统。画的时候注意外围模块尽量按业务相关性分组摆放不要散成一圈均匀分布那样看不出亲疏关系。网状模式适用于微服务数量较多、服务间交互关系密集的系统。这种模式最考验功力因为没有明确的层次结构服务节点摆位和连线规划需要反复调整。我的经验是先按业务域聚簇再画域间交互最后画域内交互层次感就出来了。2.3 颗粒度控制信息分层和“不清不楚”原则颗粒度是架构图最难的平衡点。信息太粗等于没画信息太细又变成部署图或流程图。我心中的判断标准是架构图表达的是“模块之间”的关系而不是“模块内部”的实现。不要试图在一张图里既表达系统间关系又表达模块内部类结构那是两张图的工作。当系统复杂度较高时我采用“分层画法”先画一张总体架构图表达系统的主要模块和它们之间的交互然后针对关键子系统单独画局部架构图在局部图中再细化。总体图给全景视角局部图给深入细节读者可以根据需要选择看图深度。这里我有个“不清不楚原则”如果某个细节画上去会让主线模糊那就坚决不画留到局部图中去表达。一张架构图的信息密度是有限度的一次讲清楚一个主题比一次硬塞五个主题要有效得多。3. 实操走一遍从空白画布到成型架构图的完整流程理论讲了一堆我们来走一遍完整实操。这里我以一个典型的中小规模电商系统为例从确定范围开始带着你一步步画出一张能上评审会的应用架构图。这个例子覆盖了大多数业务系统的常见模式画法可以直接套用到你自己的项目上。3.1 第一步确定范围和元素清单我先列元素清单。假设这个电商系统经过前期调研和讨论边界已经确定——包含用户端、商家端、订单、商品、支付、库存这些核心域不包含推荐系统和客服系统它们属于后续迭代范围。元素清单如下前端C端用户App/H5、B端商家后台Web接入层API网关后台服务用户服务、商品服务、订单服务、支付服务、库存服务、消息服务数据层主库MySQL集群、缓存Redis集群、搜索引擎Elasticsearch外部依赖第三方支付渠道微信支付、支付宝、短信服务商基础设施类注册中心、配置中心、日志系统这些元素要分清楚哪些是“系统内的容器/组件”哪些是“外部依赖”。外部依赖我会在图中用单独的区域或特殊的颜色标出来因为它和内部服务的关键区别是外部依赖的可用性你控制不了是风险点评审时要重点讨论。3.2 第二步确定架构风格和布局方向这个系统是典型的业务导向系统模块划分清晰逻辑上是“前端访问后台、后台访问数据”的单向流动我选择分层模式。布局从上到下依次是第一层客户端C端用户端、B端商家后台第二层接入层API网关第三层核心服务层用户、商品、订单、支付、库存、消息服务第四层数据层MySQL、Redis、Elasticsearch左侧或右侧单独区域外部依赖支付渠道、短信服务商画大框的时候我习惯先把每层的位置框出来然后往里填模块。这样模块的摆放位置天然表达了它的层次归属看图的人一眼就能判断“这是接入层的、这是数据层的”层次信息通过布局而不是颜色就传递出来了。3.3 第三步画模块、连箭头、加标注具体画图时我按“先主链、后次要”的顺序。先把核心调用链路的箭头连出来用户端→网关→订单服务→支付服务→支付渠道这条链路是整个系统的主动脉必须清晰。再连次要链路订单服务→商品服务、订单服务→库存服务、支付服务→用户服务查询余额等。连接关系画完后检查一遍重点看有没有循环依赖。所谓循环依赖就是A依赖B、B又依赖A这在模块划分上是一个需要警惕的信号。如果发现循环依赖我通常的处理方案是要么引入消息中间件把其中一个方向的同步调用改成异步解耦要么把公共逻辑抽出来下沉到更底层的一个公共服务保证箭头方向从上层指向下层、不出现反向。标注是很多人忽略的细节。我在关键位置会加三类标注协议说明C端用户访问网关那根线上标注“HTTPS”消息服务线上标注“RocketMQ”关键数据流文字说明比如订单服务写入订单库后发送“订单已创建”消息这条消息同时被库存服务和消息服务消费重要配置或环境信息比如在注册中心旁边标注“Nacos 2.x3节点集群”标注的原则是有价值的才标每一条标注都是读者理解系统时的一个线索不是装饰。3.4 第四步评审、修改、回归第一版架构图画完后不要急着发出去我建议按下面流程做一轮自查逻辑自查所有标号、箭头、方框是否都有明确含义是否存在标注不清或冲突的地方模块名称是否用词统一比如同一个服务在图中叫“订单服务”在代码中叫“order-service”需不要在图里加上代码标识读者测试找一个不了解背景的同事给他5分钟看这张图然后让他复述他理解到的系统结构和逻辑。他复述不出来的地方就是这张图表达不清的地方。评审修改根据反馈修改后找项目核心成员正式过一遍重点确认模块划分、依赖方向和数据流是否和实际一致有没有遗漏关键外部依赖。这套流程走完架构图基本是合格的。我见过很多团队画完图从来不做“读者测试”都是画完就丢到文档库里吃灰然后三个月后发现图已经和实际系统完全对不上了。架构图不是画完就结束的东西它需要持续维护。4. 架构图工具选型不同场景下我用什么画工具选型这件事我踩过的坑不少。最典型的坑是团队里每个人用不同工具画出来的图格式不统一放到一起风格完全对不上。下面我按实用性角度把主流的架构图工具排个序方便你直接选。4.1 免费轻量型工具draw.iodiagrams.net是我最常用的工具没有之一。理由很简单完全免费、开源、支持本地部署、支持桌面版和在线版、导出格式丰富SVG、PNG、PDF都支持。它的图库里有基础图形元素云厂商图标、网络设备、UML类图、ER图可以直接拖拽使用。团队协作可以通过Web版共享文件也可以配合Git版本管理。Excalidraw是手绘风格的白板工具适合快速画草图、构思阶段用、评审讨论时现场改图。它的优点是画出来的图有一种“临时草稿”的心理暗示大家不会对布局吹毛求疵注意力集中在逻辑讨论上。缺点是图形的规范性不够不适合作为正式文档终稿。ProcessOn是国内团队比较熟悉的在线工具支持架构图、流程图、思维导图操作习惯符合国内用户模板资源也比较丰富。但免费版有文件数量上限协作功能需要付费团队使用时需要评估一下成本。4.2 专业付费型工具Microsoft Visio是老牌经典功能全面标准规范强。适合企业级正式文档、IDC机房部署图、网络拓扑图这类需要精准形状库的场景。缺点是价格不便宜且缺乏在线协作能力最新的Visio for the Web体验也就一般。Enterprise Architect是UML和建模工具适合做严谨的软件架构模型。如果你的团队要遵循TOGAF架构方法论或者在做正式的架构资产登记这类工具是专业的。但学习成本非常高普通团队画一张架构图杀鸡用牛刀了。云厂商自带的架构图工具比如阿里云架构图工具、腾讯云架构图工具、AWS架构图工具在画云上部署架构时很方便因为自带云图标库图标就是对应云产品的官方样式评审部署方案时非常直观。缺点是一旦迁移到混合云或者多云架构这种工具会绑手绑脚。4.3 我给团队定的工具规范在我带的团队里我定的规范是构思和讨论阶段用Excalidraw或白板正式架构图用draw.io所有人统一使用同一套自建的图库和样式模板图标、颜色、线型都有约定保证每张图长得“像一家人”。工具统一带来的好处是协作成本直线下降任何人打开别人的图都能直接编辑不需要花时间习惯不同的操作逻辑。如果你刚开始搭工具生态我给你一个建议先选一个大多数成员有经验的工具而不是选一个功能最强的工具。团队协作里最大的成本永远是“沟通和习惯差异”不是工具本身的性能差距。5. 常见问题和避坑经验这些坑我替你踩过了最后整理几个我见过最多、自己也踩过的架构图大坑。这些问题一旦出现架构图的作用就大打折扣甚至会产生负面效果——误导读者、拖慢评审、导致错误决策。5.1 一张图画所有最后变成“蜘蛛网”这是最经典的新手错误。把所有模块和所有关系塞进一张图箭头上百条最后谁看谁晕。我见过最夸张的一张图上有两百多个节点缩放到1%才能看到全貌放大后又完全不知所云。解决思路拆分——按视图拆总体图局部详图按业务域拆订单域、支付域、库存域各一张按视图类型拆应用架构图、部署架构图、数据架构图。一张图的信息密度极限大约是20到30个节点超过这个数就要考虑拆图了。5.2 只画静态结构不画动态交互静态的架构图展示的是“系统有哪些部分”但架构评审中大家真正关心的问题是“系统怎么运转”。一张只有模块和静态依赖线的架构图读者能知道有哪些服务但不知道数据的来龙去脉不知道关键链路的时序关系。解决思路在架构图边上配合时序图或流程图把关键业务链路比如下单、支付回调、库存扣减按时间顺序画出来与架构图配合阅读。如果只能在架构图上画就标注关键数据的流转路径和流转条件。5.3 图标和颜色滥用视觉噪音淹没信息有些团队画架构图喜欢“追求好看”每个模块用不同颜色、每类交互用不同线型、每个图标又要3D效果画完确实花哨但读者根本无法快速聚焦到核心结构上。解决思路颜色只用在一个维度上通常用来区分业务域或环境线型只用两种实线同步、虚线异步图标统一风格。视觉语言越简单信息传达越精准。我常常说架构图的视觉设计是“做减法”而不是“做加法”。5.4 架构图不更新几个月后就成“历史文物”架构图最容易被诟病的问题就是“和实际代码脱节”。需求变更、服务重构、数据库拆分每发生一次架构图就失真一分。等到新同学入职拿着过期的架构图了解系统被误导的次数多了大家对架构图的信任感就没了。解决思路把架构图变更纳入研发流程和代码变更挂钩。模块调整、接口变更、依赖关系变动时需要同步更新对应的架构图。我还建议每个季度做一次架构图专项审核对照实际系统检查图的准确性发现偏差当场修正。这个习惯长期坚持下来能避免大量沟通成本。5.5 不写图例和说明全靠作者口头讲解这个问题在团队协作中最容易引发矛盾。作者看着自己的图讲得眉飞色舞听众看着投影仪一头雾水。没有图例、没有颜色含义说明、没有作者联系方式这张图一旦流传出去后面的读者只能靠猜。解决思路在架构图的左下角或右下角固定放一个图例区域写明“实线框应用系统、圆角框公共服务、实线箭头同步调用、虚线箭头异步消息、黄色外部依赖”。这段图例看着不起眼但它是一张图作为独立文档存在的基础。写在最后画架构图这件事说到底是技术能力和沟通能力的化学反应。我自己画了这么多年最大的感受是一幅优秀的架构图不是画出来的是“想清楚”之后自然呈现出来的。先把逻辑理清再谈绘图技巧先考虑读者需求再考虑视觉美观先保证信息准确再考虑布局优雅。如果你正准备画自己项目的第一张架构图我建议你先别打开任何画图软件拿出纸笔把“有哪些模块、模块之间什么关系、数据怎么流转”这三件事写清楚想明白再动手。这一步省下来的返工时间会比你想的多得多。
