上周帮一个团队做架构评审对方在投影上放出一张架构图密密麻麻全是框和线。我连着问了三个问题系统对外开放了哪些接口一次下单请求的数据流怎么走的生产环境到底部署了几个实例对方翻了半天一个都答不上来。图看着信息量很大真正想传达的信息却全部被淹没了。这是绝大多数架构图的通病。架构图本质上是把系统的结构、职责和运作逻辑“翻译”给别人看。不管你要画的是系统架构图、微服务架构图、平台架构图还是最近高频出现的智能体功能架构图、安全架构图背后都是同一套方法论先明确给谁看再决定画哪一层最后控制好粒度。这篇文章把我在实际项目中反复用过的方法、工具和踩过的坑完整整理出来适合后端开发、架构师、技术负责人也适合需要配合技术团队画图的产品经理和运维同学。1. 先分清你画的到底是什么图架构图的五大常见类型关于架构图的分类很多新人一开始就栽在这里。“架构图”三个字其实不是一种图而是一个家族。网络热词里搜出来的那些名字五花八门系统架构图、软件架构图、大数据架构图、微服务架构图、组织架构图、芯片架构图……如果不先分清自己到底要画哪一类后面选工具、定粒度、排版全都会跑偏。1.1 业务架构图给不懂代码的人看业务架构图是最容易被误会成“系统架构图”的类别。它表达的是业务模块、业务流程和组织职责之间的关系画面里不应该出现任何一个技术组件。典型场景是立项汇报、产品规划、和业务方的评审会。我见过最典型的错误是把Redis这种中间件画进业务架构图里结果业务方全程只盯着那个没见过的单词提问业务主线反而没人关心。所以画业务架构图之前先立一个规矩技术名词一律不出现出现一个就说明这张图画错了类型。1.2 系统架构图给团队内部协作和研发评审看这才是大多数人嘴上说的“架构图”也就是软件架构图、系统架构图。它表达的是模块划分、服务拆分、依赖关系和调用链。以最常见的微服务架构图为例画面上一般包含接入网关、服务中心、业务服务、数据存储等要素。这类图的难点在粒度我也见过有人把几十个微服务全部平铺在一张图里最后线条密度比电路板还高评审会上根本没法看。我的做法是粒度只画到“能讲清一次完整业务请求经过的每个黑盒”为止黑盒内部怎么实现是代码的事。1.3 部署架构图给运维和上线评审看部署架构图回答的是“这些东西跑在哪、怎么跑”。它需要体现环境边界、网络隔离、服务实例数量和高可用设计。很多人不习惯画这种图觉得离业务很远但系统出故障的时候部署图就是救火地图哪个节点挂了、流量该切到哪、哪一层要扩容一眼就能看出来。画部署图的诀窍是别省实例数量逻辑上一个服务是“订单服务”物理上它部署了三个副本图里就写×3否则永远说不清“是不是还有一个节点活着”。1.4 组织架构图和数据架构图两种特殊的架构图热搜词里出现频率极高的“组织架构图”其实是管理视角的图表画的是部门、岗位和汇报关系和软件架构完全是两个物种。数据架构图则是画数据从哪来、经过哪些加工、落到哪些存储典型的就是数仓分层图ODS/DWD/ADS。这两种图虽然也叫“架构图”但画法差异非常大。如果是冲着它们来搜的千万别照搬系统架构图的画法否则你画出来的组织架构图里会莫名其妙多出数据库。1.5 功能架构图和智能体架构图AI应用带来的新物种“智能体功能架构图”这种图能上热搜说明很多人开始接触AI应用设计了。它介于业务架构图和系统架构图之间既要拆功能模块比如意图识别、工具调用、记忆管理又要画清楚“感知—决策—行动”的交互路径。我的经验是画这类图最容易犯的毛病是过度设计把一个AI应用画成宇宙飞船。核心还是先把“输入是什么、中间经过哪些处理、输出是什么”这条主路径画明白再逐渐添加边界条件。2. 工具矩阵从白板到代码化绘图选哪个不纠结工具不要迷信但也不能不讲究。画架构图这件事工具选错了轻则浪费时间重则让团队根本不想维护。我按不同阶段把工具分成四类每一种都有自己的适用场景。2.1 白板/纸笔头脑风暴阶段无可替代画架构图的第一步不是打开任何一个软件而是先找一块白板。架构评审、方案讨论遇到争议时几个人围着白板画最有效率因为白板天然支持快速修改和多人协作。但是白板有两个致命问题容易丢、不好存档。所以我的习惯是白板上讨论定方案讨论一结束立刻派一个人用电子工具把最终版本画出来这个过程跑完才算真正完成。直接跳过白板去拖组件的做法通常会导致返工因为思路还没收敛软件里的组件搬来搬去特别费劲。2.2 通用绘图工具draw.io、Visio、ProcessOn怎么选通用绘图工具是画架构图的主力。我用过不少这里给一张真实的对比表工具优点缺点最适合的场景draw.io免费、本地/网页都能用、和多平台集成好默认样式朴素需要自己调日常系统架构图、文档配图Visio模板多、企业环境里很正规收费、跨平台支持一般企业规范图纸、对外交付文档ProcessOn网页协作方便、分享链接省事免费版有文件数量限制团队在线评审、快速草稿我个人用得最多的是draw.io。别嫌它样式朴素架构图要的就是信息清晰不是花哨。真正需要用样式撑场面的时候再考虑Visio。2.3 代码化绘图PlantUML这类文本图形语言的独特优势如果你的架构图需要持续迭代和多人维护我非常建议把图表纳入代码仓库管理。用PlantUML这类文本图形语言画图最大的好处是版本可diff、内容可review谁改了什么一眼就能看见评审的时候不用再对着截图猜“这两版到底差在哪”。代码化绘图的短板是排版控制不如拖拽工具精细复杂布局需要调坐标或依赖工具自动排布。下面是我常写的一个微服务架构图示例startuml node 接入层 { component API Gateway as gw } node 服务层 { component 用户服务 as user component 订单服务 as order } node 存储层 { database MySQL as db database Redis as cache } gw -- user gw -- order user -- db order -- db order -- cache enduml这段文本画出来就是完整的架构图。因为图是用文本生成的代码进Git仓库之后每次修改都有迹可循。我认为对于重视工程质量的中大型项目来说代码化绘图是性价比最高的维护方式。它可能不适合做很炫的展示图但非常适合当“持续更新的活文档”。2.4 专业架构建模工具要不要上ArchiMate这类体系如果团队真的很重视架构治理还有一类更“重”的工具比如支持ArchiMate建模语言的各种企业架构工具。这类工具的好处是有标准化建模规范能支撑架构资产的全生命周期管理。但对大多数中小团队来说性价比并不高学习成本大、上手慢很容易变成“为了建模而建模”画出来的图又重又难懂。我的建议是先把手上的通用工具用熟等到架构资产多到需要治理时再评估这类工具也不迟。3. 打开软件之前先回答这四个问题否则图必乱我见过太多人拿到需求就打开工具开始拖拽最后画出来一张看起来啥都有、实际上谁都看不懂的图。根本原因是少了前置思考。画架构图的真正功夫在打开软件之前。这四个问题不回答清楚后面怎么画都是错的。3.1 给谁看开发、领导、客户三者看到的世界不一样同一套系统给三类人讲画法完全不同。领导关心的是全局、边界、成本和风险所以给他的图要把服务聚合成业务域突出系统的范围和相互依赖开发关心的是模块、接口和数据库所以给他的图要拆到服务级别甚至标注关键接口协议客户关心的是需求怎么被满足所以给他的图应该更像业务流程图。最忌讳用同一张图通吃所有场合。我处理微服务架构图时有个习惯给领导的版本把几十个服务合并成十几个服务组给开发的版本展开到单个服务两者分文件保存。3.2 想表达什么结构、交互、数据、部署一次只能选一个主视角一张架构图只能有一个主视角。是想表达系统的静态组成那就画容器和包含关系是想表达服务之间怎么调用那就画接口和调用方向是想表达数据怎么加工和流转那就画存储和流经路径是想表达跑在哪儿那就画机器和环境。很多人画图乱就是把多个视角硬塞进一张图既要画模块组成又要画数据库表关系还要画网络分区结果图变成一团乱麻。一张图只服务一个目的这不是限制是保护。3.3 边界划到哪儿先写一句“本图范围”再动手每张架构图都得有明确边界。画之前用一句话把边界定义出来比如“本图展示用户中心、订单中心、商品中心之间的调用关系不包含支付的外部通道细节”。这句话最好直接写在图的角落里。有了边界看图的人就不会钻牛角尖追问“网关为什么没画全”“这个第三方为什么不展开”这类问题。我见过不少团队因为图没有边界评审会开成了“补图大会”越补越乱。提前定义边界能省掉大量沟通成本。3.4 粒度多细讲得清一次请求闭环就是上限决定粒度是画图过程的灵魂决策。我推荐的上限标准是这张图能讲清一次完整业务请求从进来到出去经过的每个黑盒。超过这个上限的细节比如某个服务内部用什么设计模式、某张表有几个字段一律留给代码和详细设计文档。为什么因为图的粒度越细依赖越多每次代码变动都可能让图作废最后的结果一定是没人维护。保持一个可维护的粒度比追求“面面俱到”重要得多。4. 一套可以复用的五步流程从素材收集到反向校验不管画什么类型的架构图我基本都走同一套流程。这套流程不是花架子每一步解决的都是实际会翻车的问题。下面以微服务架构图为例展开。4.1 第一步列素材清单先把参与者都摆出来打开画布之后别急着连线先把所有相关的参与者列出来客户端、各个服务、中间件、数据库、外部依赖全部写出来能多不能少。这一步允许重复和乱序目的是不遗漏。我见过太多图连不下去的原因就是画到一半发现“哦原来还有个消息队列没画”。先把素材铺满整个画布再谈组织和连线。4.2 第二步分层摆放把模块归到正确的层和域素材列完后开始分类摆放。常见的做法是横向分层接入层、应用层、服务层、数据层。也可以按业务域纵向切分用户域、订单域、商品域。更成熟的做法是两者结合横向画分层纵向画业务域形成二维网格。这一步看起来只是排版实际上是在检验你的架构理解——如果某个组件不知道该放哪一层多半是职责划分本来就有问题。4.3 第三步连线之前先约定统一的箭头语义好多人画图乱问题出在连线上实线、虚线、箭头、无箭头混着用含义全凭感觉。我的约定很简单实线表示同步调用虚线表示异步消息箭头方向就是数据或请求的流动方向无向线坚决不用。每张图开始连线前先用图例写明这套语义。有了统一约定团队评审时每个人看到的图都是同一套“语言”讨论效率会高很多。4.4 第四步连完线拿着图走一遍关键路径连线只是画完了一半真正检验图对不对的方法是走查。从头理一遍用户发起一次请求先到达哪个组件然后调到哪个服务服务再访问哪个存储中间经过哪个消息队列最后结果怎么返回。走不通说明要么漏了依赖要么方向画反了。我见过大量方向反了的架构图数据库指向服务看起来像数据库在调用业务代码。走查这一步花五分钟省掉评审时被所有人围攻的二十分钟。4.5 第五步落款写上版本、日期和维护人最后一步是很多人忽略的在图角落写明版本号、最后更新时间和维护人。架构图是活文档它会跟着系统一起演变没有版本信息的图三个月后就没人敢动等于废纸。写上维护人是明确责任下次谁改了图、改得好不好都能找到人复盘。这一步看似琐碎恰恰是架构图能长期活下去的关键。5. 版面与视觉为什么你的图看着“很乱”怎么改就好了内容正确但版面很乱是另一个高频问题。判断一张架构图是否专业很多人的第一印象来自版面。这里分享四个我一直在用的视觉控制原则按重要程度排序。5.1 布局方向顺着阅读习惯从上到下或从左到右除非有特殊原因比如数据流向是从下往上否则默认采用从上到下或从左到右的布局。业务架构图我习惯用自上而下的分层结构部署架构图则用从左到右展示外部环境、生产环境、测试环境的边界。顺着阅读习惯走看图的人不需要反复转头认知负担会小很多。这里还涉及一个容易被忽略的细节方向一旦定下来整张图要贯彻到底不要画到右下角又跳回左上角否则读者会在图上走来走去。5.2 对齐与间距最便宜的提升专业感的方式很多图内容其实不错败在框不对齐、间距忽大忽小。解决办法一点技术含量都没有画完最后用工具里的“对齐”和“等间距”按钮一键整理。这个动作的成本几乎为零效果却立竿见影。我对团队的要求是图里不允许出现两个框离得忽远忽近的情况宁可密一点也要均匀。间距均匀的图哪怕配色朴素看上去也像个专业产出的工程图而不是临时拼出来的草稿。5.3 颜色最多三种主色其余靠图形和文字表达颜色是架构图里最容易被滥用的元素。一次评审见到全图十六种颜色的情况也不稀奇问题是颜色多了寓意就没有了。我的规范是最多三种主色一种颜色负责一个维度。比如蓝色表示前端相关绿色表示后端服务橙色表示外部依赖然后在图例里写明。其余的模块一律用中性色。颜色一旦被赋予了规则看图的人就能快速分类而不是被颜色吸引注意力。5.4 文字只保留必要信息长描述放进文档图上的文字是给人快速扫描用的不是给人阅读论文用的。模块名称用名词短语连线标注用短动词加关键协议比如“HTTP调用”“异步事件”。大段解释一律放到配套文档里图上只留索引级别的信息。我有个经验如果一张图上出现了超过三句完整句子那一定是该精简了。图能让人在三秒内看出整体结构这段文字就算写到位了。6. 六个最容易踩的坑我画了十年图仍会遇到最后说坑。这些都是真实发生过的翻车现场。我不止一次在这些坑里待过把它们写出来希望你能直接绕开。6.1 把架构图当成一次性“截图”画完就不再回看这个坑的本质是没把架构图当工程文档而当成一次性的交流工具。架构图真正的价值是在系统的整个生命周期里持续发挥作用。修正方法很简单把架构图纳入交接文档、评审文档的必选附件每次架构迭代、模块变更时强制要求同步更新。我见过最好的团队甚至把架构图更新写进了提测清单。把更新动作绑定到已有流程里而不是依赖个人责任心这个图才能活下来。6.2 同一含义用了不同样式看图全靠猜框的样式应该是稳定的语言这个框代表服务那个框却用了数据库的圆柱体同样是服务这边是圆角矩形那边又是直角矩形。看图的人会开始猜形状背后的含义这完全是浪费注意力。修正方法是图例先行同一张图里同一类组件的样式必须完全一致。画完后再扫一遍样式不一致的地方全部统一。很多人以为自己画的图不会犯这个错但等你面对三四十个组件时很难控制住手滑。6.3 把逻辑组件和物理实例混在一张图里这是系统架构图里最隐蔽、也最容易引发事故的坑。逻辑上一个“订单服务”物理上可能部署了三个副本如果你画的是逻辑架构图那画一个框没有问题但如果是部署架构图就必须把三个实例画出来或明确标注×3。混着画的后果是线上服务扩容缩容时看图的人根本不知道几个实例才是正常状态排查故障时可能误判。好记的办法是逻辑图回答“有什么”部署图回答“各有多少”不要指望一张图同时回答两个问题。6.4 只画成功路径把降级、熔断、边界情况全藏起来人脑在画图时默认倾向于“一切顺利”的路径所以画出来的图总是主链路完整但降级方案、熔断逻辑、超时处理统统没画。等线上真正出问题需要靠图找备用路径时图上一片空白。修正办法是在画完主路径之后强迫自己问一句如果这个服务挂了请求会走哪条路把那个分支补上。哪怕只是画一个“降级到本地缓存”的虚线框关键时刻都能救命。6.5 画得太艺术PPT味太重信息反而丢了阴影、渐变、立体按钮、大标题、半透明叠层——这些都是架构图的反面教材。我不是反对美观而是反对用美观牺牲准确。工程图的第一目标是信息无损、歧义最小一个组件就是画得再漂亮如果含义不清它就是噪声。我的审美原则是先保证图准确在这个前提下可以适度统一配色和间距但不能让装饰抢了内容的风头。记住架构图是图纸不是海报。6.6 图没有人维护三个月后活文档变历史遗物这个坑的根源是收益和成本不对等画图的收益是当下的维护的成本是长期的所以天然没人愿意干。应对方法我前面也提到过责任人落实到人同时尽量用代码化绘图并纳入Git仓库让更新变成反复查看diff的流程而不是靠自觉。如果这两点都做不到至少要保证每半年review一次架构图过期组件直接标灰避免新同学照着废弃架构图开发。我之前也特别爱把图画得满满的觉得信息层级多显得专业。后来被一起评审的同事问了一句“你说的这个组件到底跑在哪台机器上”我盯着图看了半天才发现图上根本没有这个维度的信息。从那次之后我很坚持一件事画完一张图先放三天三天后如果自己还能一眼看懂再给别人看。架构图不是画完就结束的交付物它是跟着系统一起长大的活文档。如果你现在准备动手画第一张架构图也别想着把上面所有规范一次性全用上先按照第四节那套流程出一版再用第六节逐项自查慢慢就会形成自己的画图手感。
架构图怎么画才不翻车？从分类到工具再到避坑全指南
上周帮一个团队做架构评审对方在投影上放出一张架构图密密麻麻全是框和线。我连着问了三个问题系统对外开放了哪些接口一次下单请求的数据流怎么走的生产环境到底部署了几个实例对方翻了半天一个都答不上来。图看着信息量很大真正想传达的信息却全部被淹没了。这是绝大多数架构图的通病。架构图本质上是把系统的结构、职责和运作逻辑“翻译”给别人看。不管你要画的是系统架构图、微服务架构图、平台架构图还是最近高频出现的智能体功能架构图、安全架构图背后都是同一套方法论先明确给谁看再决定画哪一层最后控制好粒度。这篇文章把我在实际项目中反复用过的方法、工具和踩过的坑完整整理出来适合后端开发、架构师、技术负责人也适合需要配合技术团队画图的产品经理和运维同学。1. 先分清你画的到底是什么图架构图的五大常见类型关于架构图的分类很多新人一开始就栽在这里。“架构图”三个字其实不是一种图而是一个家族。网络热词里搜出来的那些名字五花八门系统架构图、软件架构图、大数据架构图、微服务架构图、组织架构图、芯片架构图……如果不先分清自己到底要画哪一类后面选工具、定粒度、排版全都会跑偏。1.1 业务架构图给不懂代码的人看业务架构图是最容易被误会成“系统架构图”的类别。它表达的是业务模块、业务流程和组织职责之间的关系画面里不应该出现任何一个技术组件。典型场景是立项汇报、产品规划、和业务方的评审会。我见过最典型的错误是把Redis这种中间件画进业务架构图里结果业务方全程只盯着那个没见过的单词提问业务主线反而没人关心。所以画业务架构图之前先立一个规矩技术名词一律不出现出现一个就说明这张图画错了类型。1.2 系统架构图给团队内部协作和研发评审看这才是大多数人嘴上说的“架构图”也就是软件架构图、系统架构图。它表达的是模块划分、服务拆分、依赖关系和调用链。以最常见的微服务架构图为例画面上一般包含接入网关、服务中心、业务服务、数据存储等要素。这类图的难点在粒度我也见过有人把几十个微服务全部平铺在一张图里最后线条密度比电路板还高评审会上根本没法看。我的做法是粒度只画到“能讲清一次完整业务请求经过的每个黑盒”为止黑盒内部怎么实现是代码的事。1.3 部署架构图给运维和上线评审看部署架构图回答的是“这些东西跑在哪、怎么跑”。它需要体现环境边界、网络隔离、服务实例数量和高可用设计。很多人不习惯画这种图觉得离业务很远但系统出故障的时候部署图就是救火地图哪个节点挂了、流量该切到哪、哪一层要扩容一眼就能看出来。画部署图的诀窍是别省实例数量逻辑上一个服务是“订单服务”物理上它部署了三个副本图里就写×3否则永远说不清“是不是还有一个节点活着”。1.4 组织架构图和数据架构图两种特殊的架构图热搜词里出现频率极高的“组织架构图”其实是管理视角的图表画的是部门、岗位和汇报关系和软件架构完全是两个物种。数据架构图则是画数据从哪来、经过哪些加工、落到哪些存储典型的就是数仓分层图ODS/DWD/ADS。这两种图虽然也叫“架构图”但画法差异非常大。如果是冲着它们来搜的千万别照搬系统架构图的画法否则你画出来的组织架构图里会莫名其妙多出数据库。1.5 功能架构图和智能体架构图AI应用带来的新物种“智能体功能架构图”这种图能上热搜说明很多人开始接触AI应用设计了。它介于业务架构图和系统架构图之间既要拆功能模块比如意图识别、工具调用、记忆管理又要画清楚“感知—决策—行动”的交互路径。我的经验是画这类图最容易犯的毛病是过度设计把一个AI应用画成宇宙飞船。核心还是先把“输入是什么、中间经过哪些处理、输出是什么”这条主路径画明白再逐渐添加边界条件。2. 工具矩阵从白板到代码化绘图选哪个不纠结工具不要迷信但也不能不讲究。画架构图这件事工具选错了轻则浪费时间重则让团队根本不想维护。我按不同阶段把工具分成四类每一种都有自己的适用场景。2.1 白板/纸笔头脑风暴阶段无可替代画架构图的第一步不是打开任何一个软件而是先找一块白板。架构评审、方案讨论遇到争议时几个人围着白板画最有效率因为白板天然支持快速修改和多人协作。但是白板有两个致命问题容易丢、不好存档。所以我的习惯是白板上讨论定方案讨论一结束立刻派一个人用电子工具把最终版本画出来这个过程跑完才算真正完成。直接跳过白板去拖组件的做法通常会导致返工因为思路还没收敛软件里的组件搬来搬去特别费劲。2.2 通用绘图工具draw.io、Visio、ProcessOn怎么选通用绘图工具是画架构图的主力。我用过不少这里给一张真实的对比表工具优点缺点最适合的场景draw.io免费、本地/网页都能用、和多平台集成好默认样式朴素需要自己调日常系统架构图、文档配图Visio模板多、企业环境里很正规收费、跨平台支持一般企业规范图纸、对外交付文档ProcessOn网页协作方便、分享链接省事免费版有文件数量限制团队在线评审、快速草稿我个人用得最多的是draw.io。别嫌它样式朴素架构图要的就是信息清晰不是花哨。真正需要用样式撑场面的时候再考虑Visio。2.3 代码化绘图PlantUML这类文本图形语言的独特优势如果你的架构图需要持续迭代和多人维护我非常建议把图表纳入代码仓库管理。用PlantUML这类文本图形语言画图最大的好处是版本可diff、内容可review谁改了什么一眼就能看见评审的时候不用再对着截图猜“这两版到底差在哪”。代码化绘图的短板是排版控制不如拖拽工具精细复杂布局需要调坐标或依赖工具自动排布。下面是我常写的一个微服务架构图示例startuml node 接入层 { component API Gateway as gw } node 服务层 { component 用户服务 as user component 订单服务 as order } node 存储层 { database MySQL as db database Redis as cache } gw -- user gw -- order user -- db order -- db order -- cache enduml这段文本画出来就是完整的架构图。因为图是用文本生成的代码进Git仓库之后每次修改都有迹可循。我认为对于重视工程质量的中大型项目来说代码化绘图是性价比最高的维护方式。它可能不适合做很炫的展示图但非常适合当“持续更新的活文档”。2.4 专业架构建模工具要不要上ArchiMate这类体系如果团队真的很重视架构治理还有一类更“重”的工具比如支持ArchiMate建模语言的各种企业架构工具。这类工具的好处是有标准化建模规范能支撑架构资产的全生命周期管理。但对大多数中小团队来说性价比并不高学习成本大、上手慢很容易变成“为了建模而建模”画出来的图又重又难懂。我的建议是先把手上的通用工具用熟等到架构资产多到需要治理时再评估这类工具也不迟。3. 打开软件之前先回答这四个问题否则图必乱我见过太多人拿到需求就打开工具开始拖拽最后画出来一张看起来啥都有、实际上谁都看不懂的图。根本原因是少了前置思考。画架构图的真正功夫在打开软件之前。这四个问题不回答清楚后面怎么画都是错的。3.1 给谁看开发、领导、客户三者看到的世界不一样同一套系统给三类人讲画法完全不同。领导关心的是全局、边界、成本和风险所以给他的图要把服务聚合成业务域突出系统的范围和相互依赖开发关心的是模块、接口和数据库所以给他的图要拆到服务级别甚至标注关键接口协议客户关心的是需求怎么被满足所以给他的图应该更像业务流程图。最忌讳用同一张图通吃所有场合。我处理微服务架构图时有个习惯给领导的版本把几十个服务合并成十几个服务组给开发的版本展开到单个服务两者分文件保存。3.2 想表达什么结构、交互、数据、部署一次只能选一个主视角一张架构图只能有一个主视角。是想表达系统的静态组成那就画容器和包含关系是想表达服务之间怎么调用那就画接口和调用方向是想表达数据怎么加工和流转那就画存储和流经路径是想表达跑在哪儿那就画机器和环境。很多人画图乱就是把多个视角硬塞进一张图既要画模块组成又要画数据库表关系还要画网络分区结果图变成一团乱麻。一张图只服务一个目的这不是限制是保护。3.3 边界划到哪儿先写一句“本图范围”再动手每张架构图都得有明确边界。画之前用一句话把边界定义出来比如“本图展示用户中心、订单中心、商品中心之间的调用关系不包含支付的外部通道细节”。这句话最好直接写在图的角落里。有了边界看图的人就不会钻牛角尖追问“网关为什么没画全”“这个第三方为什么不展开”这类问题。我见过不少团队因为图没有边界评审会开成了“补图大会”越补越乱。提前定义边界能省掉大量沟通成本。3.4 粒度多细讲得清一次请求闭环就是上限决定粒度是画图过程的灵魂决策。我推荐的上限标准是这张图能讲清一次完整业务请求从进来到出去经过的每个黑盒。超过这个上限的细节比如某个服务内部用什么设计模式、某张表有几个字段一律留给代码和详细设计文档。为什么因为图的粒度越细依赖越多每次代码变动都可能让图作废最后的结果一定是没人维护。保持一个可维护的粒度比追求“面面俱到”重要得多。4. 一套可以复用的五步流程从素材收集到反向校验不管画什么类型的架构图我基本都走同一套流程。这套流程不是花架子每一步解决的都是实际会翻车的问题。下面以微服务架构图为例展开。4.1 第一步列素材清单先把参与者都摆出来打开画布之后别急着连线先把所有相关的参与者列出来客户端、各个服务、中间件、数据库、外部依赖全部写出来能多不能少。这一步允许重复和乱序目的是不遗漏。我见过太多图连不下去的原因就是画到一半发现“哦原来还有个消息队列没画”。先把素材铺满整个画布再谈组织和连线。4.2 第二步分层摆放把模块归到正确的层和域素材列完后开始分类摆放。常见的做法是横向分层接入层、应用层、服务层、数据层。也可以按业务域纵向切分用户域、订单域、商品域。更成熟的做法是两者结合横向画分层纵向画业务域形成二维网格。这一步看起来只是排版实际上是在检验你的架构理解——如果某个组件不知道该放哪一层多半是职责划分本来就有问题。4.3 第三步连线之前先约定统一的箭头语义好多人画图乱问题出在连线上实线、虚线、箭头、无箭头混着用含义全凭感觉。我的约定很简单实线表示同步调用虚线表示异步消息箭头方向就是数据或请求的流动方向无向线坚决不用。每张图开始连线前先用图例写明这套语义。有了统一约定团队评审时每个人看到的图都是同一套“语言”讨论效率会高很多。4.4 第四步连完线拿着图走一遍关键路径连线只是画完了一半真正检验图对不对的方法是走查。从头理一遍用户发起一次请求先到达哪个组件然后调到哪个服务服务再访问哪个存储中间经过哪个消息队列最后结果怎么返回。走不通说明要么漏了依赖要么方向画反了。我见过大量方向反了的架构图数据库指向服务看起来像数据库在调用业务代码。走查这一步花五分钟省掉评审时被所有人围攻的二十分钟。4.5 第五步落款写上版本、日期和维护人最后一步是很多人忽略的在图角落写明版本号、最后更新时间和维护人。架构图是活文档它会跟着系统一起演变没有版本信息的图三个月后就没人敢动等于废纸。写上维护人是明确责任下次谁改了图、改得好不好都能找到人复盘。这一步看似琐碎恰恰是架构图能长期活下去的关键。5. 版面与视觉为什么你的图看着“很乱”怎么改就好了内容正确但版面很乱是另一个高频问题。判断一张架构图是否专业很多人的第一印象来自版面。这里分享四个我一直在用的视觉控制原则按重要程度排序。5.1 布局方向顺着阅读习惯从上到下或从左到右除非有特殊原因比如数据流向是从下往上否则默认采用从上到下或从左到右的布局。业务架构图我习惯用自上而下的分层结构部署架构图则用从左到右展示外部环境、生产环境、测试环境的边界。顺着阅读习惯走看图的人不需要反复转头认知负担会小很多。这里还涉及一个容易被忽略的细节方向一旦定下来整张图要贯彻到底不要画到右下角又跳回左上角否则读者会在图上走来走去。5.2 对齐与间距最便宜的提升专业感的方式很多图内容其实不错败在框不对齐、间距忽大忽小。解决办法一点技术含量都没有画完最后用工具里的“对齐”和“等间距”按钮一键整理。这个动作的成本几乎为零效果却立竿见影。我对团队的要求是图里不允许出现两个框离得忽远忽近的情况宁可密一点也要均匀。间距均匀的图哪怕配色朴素看上去也像个专业产出的工程图而不是临时拼出来的草稿。5.3 颜色最多三种主色其余靠图形和文字表达颜色是架构图里最容易被滥用的元素。一次评审见到全图十六种颜色的情况也不稀奇问题是颜色多了寓意就没有了。我的规范是最多三种主色一种颜色负责一个维度。比如蓝色表示前端相关绿色表示后端服务橙色表示外部依赖然后在图例里写明。其余的模块一律用中性色。颜色一旦被赋予了规则看图的人就能快速分类而不是被颜色吸引注意力。5.4 文字只保留必要信息长描述放进文档图上的文字是给人快速扫描用的不是给人阅读论文用的。模块名称用名词短语连线标注用短动词加关键协议比如“HTTP调用”“异步事件”。大段解释一律放到配套文档里图上只留索引级别的信息。我有个经验如果一张图上出现了超过三句完整句子那一定是该精简了。图能让人在三秒内看出整体结构这段文字就算写到位了。6. 六个最容易踩的坑我画了十年图仍会遇到最后说坑。这些都是真实发生过的翻车现场。我不止一次在这些坑里待过把它们写出来希望你能直接绕开。6.1 把架构图当成一次性“截图”画完就不再回看这个坑的本质是没把架构图当工程文档而当成一次性的交流工具。架构图真正的价值是在系统的整个生命周期里持续发挥作用。修正方法很简单把架构图纳入交接文档、评审文档的必选附件每次架构迭代、模块变更时强制要求同步更新。我见过最好的团队甚至把架构图更新写进了提测清单。把更新动作绑定到已有流程里而不是依赖个人责任心这个图才能活下来。6.2 同一含义用了不同样式看图全靠猜框的样式应该是稳定的语言这个框代表服务那个框却用了数据库的圆柱体同样是服务这边是圆角矩形那边又是直角矩形。看图的人会开始猜形状背后的含义这完全是浪费注意力。修正方法是图例先行同一张图里同一类组件的样式必须完全一致。画完后再扫一遍样式不一致的地方全部统一。很多人以为自己画的图不会犯这个错但等你面对三四十个组件时很难控制住手滑。6.3 把逻辑组件和物理实例混在一张图里这是系统架构图里最隐蔽、也最容易引发事故的坑。逻辑上一个“订单服务”物理上可能部署了三个副本如果你画的是逻辑架构图那画一个框没有问题但如果是部署架构图就必须把三个实例画出来或明确标注×3。混着画的后果是线上服务扩容缩容时看图的人根本不知道几个实例才是正常状态排查故障时可能误判。好记的办法是逻辑图回答“有什么”部署图回答“各有多少”不要指望一张图同时回答两个问题。6.4 只画成功路径把降级、熔断、边界情况全藏起来人脑在画图时默认倾向于“一切顺利”的路径所以画出来的图总是主链路完整但降级方案、熔断逻辑、超时处理统统没画。等线上真正出问题需要靠图找备用路径时图上一片空白。修正办法是在画完主路径之后强迫自己问一句如果这个服务挂了请求会走哪条路把那个分支补上。哪怕只是画一个“降级到本地缓存”的虚线框关键时刻都能救命。6.5 画得太艺术PPT味太重信息反而丢了阴影、渐变、立体按钮、大标题、半透明叠层——这些都是架构图的反面教材。我不是反对美观而是反对用美观牺牲准确。工程图的第一目标是信息无损、歧义最小一个组件就是画得再漂亮如果含义不清它就是噪声。我的审美原则是先保证图准确在这个前提下可以适度统一配色和间距但不能让装饰抢了内容的风头。记住架构图是图纸不是海报。6.6 图没有人维护三个月后活文档变历史遗物这个坑的根源是收益和成本不对等画图的收益是当下的维护的成本是长期的所以天然没人愿意干。应对方法我前面也提到过责任人落实到人同时尽量用代码化绘图并纳入Git仓库让更新变成反复查看diff的流程而不是靠自觉。如果这两点都做不到至少要保证每半年review一次架构图过期组件直接标灰避免新同学照着废弃架构图开发。我之前也特别爱把图画得满满的觉得信息层级多显得专业。后来被一起评审的同事问了一句“你说的这个组件到底跑在哪台机器上”我盯着图看了半天才发现图上根本没有这个维度的信息。从那次之后我很坚持一件事画完一张图先放三天三天后如果自己还能一眼看懂再给别人看。架构图不是画完就结束的交付物它是跟着系统一起长大的活文档。如果你现在准备动手画第一张架构图也别想着把上面所有规范一次性全用上先按照第四节那套流程出一版再用第六节逐项自查慢慢就会形成自己的画图手感。
