简介软件系统架构图是软件开发中连接业务与技术的重要设计产物。这份参考案例以共享平台为例面向软件架构师、系统设计师及需要绘制架构图的开发人员系统讲解架构设计中的三类核心视图逻辑架构突出子系统间的业务关系技术架构强调模块自身技术与接口关联整体架构则从基础层、数据层、支撑层、管理层和展现层还原系统全貌。资源为单一PDF文件仅2.75MB便于随时查阅。其中对应用系统建设、结构化与非结构化资源采集、数据分析与展现、内外部门户发布以及标准规范体系、接口管理等环节均有明确图文说明适合用于编写技术方案、汇报材料或课程案例。目前已有1243人学习浏览是一份可直接借鉴的架构图绘制与讲解范例尤其适合需要快速理解架构分层和模块划分的读者。1. 软件系统架构图不只是画框连线参考案例 PDF 到底在参考什么很多开发第一次拿到名为软件系统架构图_参考案例.pdf的文件是在评审会前夜。手里只有一个模糊的系统雏形想找现成的图做参考却说不清到底要参考什么是参考图的样子还是参考别人怎么划分模块、怎么处理依赖。我的答案是后者。架构图最重要的是信息准确不是画得好看。一张配色再舒服的图如果别人看不出系统边界、数据流向和依赖方向评审时就会被连环追问最后不得不回到白板重画。这篇笔记不会去复述某份参考文档的页码而是从一线画图的角度拆解案例文档里常见的架构图类型、五步绘制流程、三张容易被漏掉的图以及五个真实翻车现场。读完你至少能判断手上的图到底能不能拿去交付。2. 先决定画什么再决定怎么画案例文档里最常见的四种架构图2.1 单体、分层、微服务、事件驱动先认清自己属于哪种风格很多参考案例文档的第一页往往是一张系统整体架构图。很多人拿到后的第一反应是照着最漂亮的样例改把网关、注册中心、消息队列全部堆上去。但这是本末倒置。架构图画出来是要落到部署和代码结构上的画之前先回答三个问题系统是几个进程数据库是几个模块间是同步调用还是异步消息回答完架构风格基本就确定了。架构风格图面特征典型场景常见误用单体一个大框包着多个模块中小规模业务、内部系统明明是单体硬画微服务分层横向条带分层上层依赖下层大部分 Web 业务系统层之间出现反向依赖微服务多个独立服务框带网关/注册中心团队大、独立部署需求明确服务拆得比团队人数还多事件驱动异步消息中间件、虚线连接异构系统、削峰填谷同步调用画成消息流误导排查我一般这样判断部署在一个进程里优先画单体或分层有独立部署和扩缩容需求才画微服务如果系统里有明显的队列、订阅发布模式再考虑事件驱动。画图不是目标目标是让看图的人一眼就能知道系统是怎么组织的。新手最容易犯的错误是拿微服务架构图的模板硬套一个简单单体系统结果评审会上被问这个网关在代码仓库里对应哪个工程答不上来整张图的信任度就崩了。判断架构风格时还可以看系统里的中间件密度如果图里出现注册中心、配置中心、网关三个组件同时存在基本可以断定是微服务风格如果只有应用服务器和数据库那就是分层或单体。这个判断不需要读代码从部署清单和配置文件数量就能看出来。画图前花十分钟梳理部署单元比画完之后返工一小时划算得多。2.2 从连线识别架构实线同步、虚线异步、粗线数据流参考案例里的连线通常是有含义的。我平时画图的约定是实线表示同步调用典型的是 HTTP 接口或 RPC虚线表示异步消息典型的是 MQ 投递或事件订阅粗线表示核心数据流比如订单状态流转、同步链路。为什么要把线型约定得这么细因为架构图本质上是一张可执行的沟通图别人要能根据连线判断两个模块之间到底是什么关系。如果连线含义混乱会出现一个很典型的场景运维看到两条线一条实线一条虚线分不清哪些依赖是强依赖、哪些是弱依赖扩容的时候不知道该把哪个服务优先拉起来。所以在图例里明确线型比调整颜色重要得多。我这里给出一个最简单的约定普通同步调用用实线加箭头指向被调用方异步消息用虚线加箭头指向消费方如果需要强调数据量大的链路把主线加粗并在旁边标注每秒请求量或数据量级。这个约定不需要多复杂但必须全图统一并且在图例里写清楚。另外箭头方向要慎重。架构图上最常见的误解就是箭头方向。我通常把箭头指向被调用方A 调用 B箭头指向 B。这样拆链路时顺着箭头就是一次请求的路径。如果反过来画成数据流方向看图的开发要去猜这到底是调用关系还是数据流动。如果两种关系都有就用两种线形区分并在图例里注明实线箭头是调用方向虚线箭头是消息方向。2.3 不同读者看不同图逻辑视图、组件视图、部署视图一份好的参考案例通常不是只有一张图而是至少三张逻辑视图、组件视图、部署视图。逻辑视图给产品和业务同事看画的是模块和业务能力不需要出现具体的服务名和端口组件视图给开发看画出服务、数据库、缓存、消息队列这些实际组件部署视图给运维看画出每台机器、容器、网络区域标注端口和域名。这三张图的关系是层层细化的。逻辑视图回答系统有哪些业务能力组件视图回答能力由哪些组件实现部署视图回答组件跑在哪里。我见过很多团队只画一张组件视图然后拿着它去应付所有场合结果给产品讲业务功能时说不清楚给运维讲部署时又缺主机信息。画图之前先问自己一句这张图是给谁看的同一个系统画给不同人应该是不同的图。还有一个容易忽略的视图安全视图。在涉及用户权限、外部接口的案例里安全边界一般用一条红色虚线表示跨越这条线的请求要经过鉴权。这个图不一定要单独画可以在逻辑视图上用一条边界带出来。但有没有这个边界影响很大。没有标注安全边界的架构图在安全性评审时几乎一定会被挑战。你能把模块关系讲清楚只是及格能画出安全边界、部署边界和数据归属才是一份可以拿去评审的参考案例。3. 照着参考案例画图五步可复现的绘制流程3.1 第一步先画系统边界和外部依赖再画内部模块很多人在空白画布上的第一笔是画内部模块我建议反过来。先画一个大的虚线框代表系统边界然后画框外的东西用户、第三方服务、上下游系统。这个顺序的价值在于强制你思考系统是开放给谁用的。画外部依赖清单时至少要有四列外部对象标注内容示例外部用户入口协议、终端类型浏览器、iOS APP第三方服务调用方向、超时时间支付网关、短信平台上游系统数据来源、输入格式订单中心下游系统数据去向、消费方式财务系统画完外部依赖后再画内部模块会发现系统的左边和右边自然留出了入口和出口内部模块的排布就有了约束。很多人忽略这一步架构图如果没有边界看的人就分不清哪些东西属于系统哪些属于外部。一个没有边界的架构图评审时最常见的提问是这个服务到底是不是我们团队维护的一问你就得现场解释半天图本身没有起到任何作用。3.2 第二步统一定义图例颜色和线型都有含义很多参考案例里真正专业的图第一眼就能看出来因为它有图例。图例不需要复杂但必须覆盖系统边界、模块、服务、数据库、中间件、外部系统、同步调用、异步消息、数据流。推荐一套图例图形元素形状颜色建议含义系统边界大虚线框灰色系统控制范围业务模块圆角矩形蓝色系内部逻辑单元服务/组件直角矩形绿色系独立部署单元数据库圆柱体橙色系存储资源消息中间件队列符号紫色系异步通信枢纽外部系统矩形加粗边框灰色/白色非本系统控制同步调用实线箭头黑色请求/响应异步消息虚线箭头蓝色事件/消息这里有几个细节容易被忽略颜色要在一个色系里选深浅不要红绿蓝紫乱用否则打印成黑白后完全无法区分线宽保持一致细线是辅助线粗线是主线文字大小统一不要让某些框的文字特别大这会暗示优先级。图例做出来后建议先给自己的图打一次草稿再正式画因为很多人画着画着就开始改线型最后图和图例对不上。图例不是画完后再补的而是画之前定的这一点很重要。3.3 第三步从核心调用链开始布局先有主干再长枝叶布局顺序对图的可读性影响非常大。我一般先找一条最核心的业务调用链比如电商里的下单链路用户端 - 网关 - 订单服务 - 库存服务 - 支付回调。先把这条链上的节点画在纸面中央从上到下或从左到右排开然后再把其他模块挂在旁边。这样做的好处是看图的人第一眼就能跟随主链路而不是在二十个框里自己找重点。很多人画图失败不是因为信息不全而是因为把所有模块均等排列主次不分。核心链路要突出可以用加深的背景色或者在旁边标注主链路字样。挂枝叶的时候遵循就近原则跟订单服务强相关的账务、优惠、消息通知放在订单服务旁边跟商品服务强相关的分类、库存、索引放在商品服务旁边。同层级的模块尽量水平对齐这样视觉上会形成清晰的横向分层。连线在布局阶段就应该提前预留位置不要让线跨过其他框。如果两条线必须交叉尽量让交叉出现在空白区域并且用绕行方式表达而不是直接十字交叉。3.4 第四步标注协议、端口与数据流方向让图可以指导开发一张架构图如果只有框和名字开发拿到后还是得去翻代码才能知道用什么协议调用。建议在每个连线或关键节点旁标注最小但必要的信息协议类型、端口、数据流方向。具体标注方式服务间调用在连线上写HTTP :8080或gRPC :9090。异步消息在虚线上写MQ topic: order_event注明消费方。数据库访问在数据库图元旁写MySQL 8.0读写分离。外部接口在外部系统旁写HTTPS超时 3s需签名。这一步要克制不要什么细节都标。我从实际评审经验看标注超过五个就很容易遮挡连线。优先标注三类信息协议、端口、关键 topic。至于接口路径、参数结构、鉴权方式让开发去看接口文档架构图上不需要承载这么多。架构图的精度目标是让人能正确理解系统形状而不是代替 API 文档。如果这张图用于指导新人我还会在图的底部加一行图上端口为默认配置实际以配置中心为准避免新人照着图里的端口去连测试环境然后发现问题。这句话经常能省下很多答疑时间属于低成本高收益的一步。3.5 第五步控制篇幅一页最多十五个主节点参考案例里常见的另一个问题是信息过载。一张 A4 纸塞了二十多个框、三十多条线打印出来字只有蚂蚁大投到屏幕上还是一团乱。建议一张架构图的主要节点控制在十个到十五个之间。如果超过做三件事第一合并只属于同一部署单元内的细粒度模块比如把订单查询和订单创建合并成订单服务第二把次要依赖放到备注区用一张小表列出不在图上连线第三按视图拆分把这张图拆成逻辑视图和部署视图分别给不同人看。一页能讲清一个核心主题就是成功的架构图。强行把所有信息放一页表面上省了翻页实际上因为看不清所有人还是要停下来问。我现在的习惯是画完第一版后截图缩小到原来的三分之一如果缩小时后还能流畅看出主链路才放行。这个方法也是从某次评审翻车里总结出来的那次图缩到投影上连字都看不清评审直接变成了靠嘴讲。4. 只有一张总览图是不够的案例文档里那三张容易被忽略的图4.1 部署架构图让运维看着图就能搭出环境很多开发画架构图只画逻辑组件但实际运维要部署的时候还是会问这几个服务跑在几台机器上。参考案例里成熟的团队会补一张部署架构图。它的核心信息是物理或虚拟资源与组件的映射关系。画法要点从下往上或从上往下分区域外部网络区域、接入区域、应用区域、数据区域。每个区域下方标注网络策略比如仅开放 443 入口运维跳板机独立。在应用区域把每个服务框放进对应的主机框内主机框上标注 IP 或主机名、配置CPU/内存、所属 Kubernetes 命名空间如有。如果用了容器编排还可以在主机框内部画一层 Pod 边界标注副本数。这张图的价值在排障时特别明显。有一次某系统出现调用超时开发从逻辑架构图上判断是 A 服务的问题但运维看部署图后发现 A 服务和 B 服务在同一台物理机上资源竞争导致延迟把两个服务拆开后问题直接消失。逻辑架构图看不出这种部署耦合部署架构图一眼就能看到。这就是参考案例里为什么不只放一张图的原因。4.2 数据架构图存储、缓存、同步关系一目了然数据架构图回答的问题是数据在哪里产生、在哪里存储、如何流动。它是架构图参考案例里另一张高价值图。很多系统出现脏数据问题源头就是数据流向不清晰。画数据架构图时不要重复组件图里的服务节点而是重点画存储节点和它们之间的同步关系。比如主数据库 MySQL、只读从库、Redis 缓存、ES 索引、消息队列里的数据管道。用实线画数据同步比如 binlog 同步到从库用虚线画异步写入在每条线上标注数据量级和延迟容忍度比如实时同步延迟 1s或每天凌晨批量回刷。还有一个关键点是数据所有权。很多系统因为两个服务共享同一张表导致变更时互相踩脚。数据架构图上建议用不同的底色区分表归属一眼就能看出哪些库表是多个服务共享的这类共享往往是后续改造的起点。数据架构图还有一个实践技巧在图的角落放一个小数据量列表标注核心表的大致行数和增长速率比如订单表约 1200 万行/月年增长约 1.5 亿。这个列表很廉价却能让评审者快速评估分库分表、归档的必要性。4.3 补充一张关键路径时序图把动态过程画出来静态架构图表达的是系统结构表达不了动态过程。参考案例里经常出现明明架构图看着没问题但评审时还是有人对不上调用顺序的场面这通常就是缺少一张关键路径时序图。时序图不必画复杂只画最重要的三到五步。比如用户下单请求到达网关网关鉴权后路由到订单服务订单服务调用库存锁库存支付成功回调后发送 MQ 事件。把每一步标注参与者、动作、返回结果。时序图能暴露架构图上画不出来的问题是否存在环形调用是否存在不必要的串行是否同一个事务里调用了外部服务如果有评审时几乎一定会被抓住。我一般在每次架构评审前把主链路时序图单独画出来作为整个文档的第一附录。讲架构图时先从时序图讲动态流程再从架构图讲静态结构两种图互补评审效率会高很多。时序图不建议画太细如果把每个方法调用都画出来就没有人愿意看了。我通常只跨模块或跨服务的调用服务内部的方法不画。画到函数级别的时序图是开发设计文档的任务不是架构图参考案例的任务。5. 画架构图最容易翻车的五个坑现象、原因、解决方式翻车这事画多了谁都躲不开。下面的五个现场不是从哪份标准文档抄来的都是实际评审和排障里反复出现的共性问题每一条我都按现象、原因、解法写清楚方便你直接对照排查。5.1 把业务流程图当成架构图现象整张图按业务流程从左到右画了一堆步骤比如用户发起请求 - 校验参数 - 查询数据库 - 返回结果看起来也能看懂流程但根本不是架构图。原因混淆了流程和结构。架构图的核心是展示系统由哪些组件组成、依赖关系如何流程图展示的是某条业务路径的时间顺序。两者解决的是不同的问题业务步骤不能替代组件结构。解决先画结构图再决定是否补充时序图。如果你发现自己画的是步骤序列停下来回到组件视图重新组织。流程图可以作为附加图存在比如第四章里说的关键路径时序图但不能把主架构图的位置让给流程图。判断标准很简单删掉箭头如果剩下的框还能表达系统有哪些部分就是架构图如果删掉箭头什么都不剩那只是流程图。5.2 图例缺失线型颜色全靠猜现象图上七八种颜色红蓝绿紫都有没有任何注释打印成黑白后完全分不清哪条线是调用、哪条线是消息哪个框是服务、哪个框是数据库。原因画图时只顾着好看忽略了信息传递。很多画图工具默认给了丰富配色反而掩盖了图中信息结构的问题。解决画之前先定图例把颜色控制在两到三个色系的深浅变化内。一个常见的做法是只用蓝色系表示内部组件用橙色系表示外部系统用灰色系表示基础资源。黑白打印是一个很实用的检验标准如果你的图在黑白模式下信息完全无法区分配色方案就要返工。不要相信评审时用彩色投影所以没关系这种话因为评审纪要的照片、发到群里截图很多都是灰蒙蒙的。5.3 连线交叉成蜘蛛网现象服务之间连线乱七八糟交叉多到没法看鼠标指到某条线还要用放大镜一路追才能找到它是从哪个框发出来的。原因布局时没有按核心链路组织而是想到哪画到哪外部依赖和内部依赖混在一起。解决布局阶段先排主干再排分支连线尽量短短距离意味着相邻的模块应该画在一起如果两条线必须交叉把其中一条画成折线绕行空白区域。还有一个技巧所有跨部门或跨域的服务交互统一放在图的边缘区域不要穿插在内部连线里这样至少能保证内部区域是干净的。如果你发现交叉点已经超过十个不要试图修补接线直接重排布局修修补补反而更乱。5.4 为了美观牺牲信息删了装饰等于没图现象图做得很漂亮用了渐变、阴影、立体图标但把装饰去掉后剩下的信息少得可怜连系统边界都没有。原因把架构图当成了宣传海报而不是技术沟通工具。很多做展示的人习惯先追求视觉冲击力结果牺牲了信息密度。解决画完第一版后把图上所有装饰去掉只保留线条、文字和边界看看信息是否还完整。如果你的架构图去掉图标就不成立说明核心信息没画出来。这个黑白测试也符合我在第三章说的习惯缩小三分之一后主链路如果还能看清才做视觉美化。图标可以辅助识别但不能代替文字标注渐变可以增加层次但不能让图例失效。5.5 只画成功路径不画降级和依赖关系现象图上只有一条顺风顺水的调用链没有超时、降级、重试、故障转移。比如订单服务调用库存服务图里只有一条实线完全没有库存服务不可用时怎么办。原因画图的人只表达了自己知道的内容或者怕复杂不想画。另一个原因是为了让图显得干净主动省略了异常路径这是最危险的。解决在关键服务旁用小字标注降级逻辑比如订单服务依赖库存服务库存超时则降级返回可下单状态并在后台回补。如果选项较多用一张备注表列出。虽然这会让架构图变复杂但这是评审和运维真正需要的信息。否则架构图在故障发生时帮不上忙就是一张参考了个寂寞的图。排查的时候我会专门问自己一句这张图里有没有任何一个节点发生故障时看图的人知道下一步该做什么如果答不上来说明图没画完。6. 进阶画完架构图后用一份自检清单给架构图做体检画完不等于能交付。我现在每次画完架构图都会做一次体检不查代码只查图本身。这份清单是从一次次评审里磨出来的每一条背后都对应过真实翻车。检查项通过标准边界清晰能在图上圈出系统边界外部依赖全部在边界外图例完整有图例且图上出现的每种线型、颜色都能在图例里找到方向正确每条线都有箭头且箭头方向统一表达调用方向或消息方向主链路可见缩小到原图三分之一后还能一眼看出核心调用链黑白可读转成灰度图后信息不丢失不同节点仍可区分关键信息标注主要服务间至少标注协议或端口数据库旁标注类型降级有交代关键依赖旁有超时、降级或重试说明视角匹配知道这张图给谁看且内容与读者匹配还有一个我养成的习惯每次画完把图发给一个不了解该系统的人请他用三分钟讲出系统由哪些部分组成、数据怎么流动。如果讲不出问题不在他而在图。这个方法比任何工具检查都有效。我早期画架构图也喜欢堆装饰直到某次评审时被运维问这个缓存挂了之后服务怎么办我看着图上那条干干净净的连线答不上来才真正明白架构图的价值是让人在需要的时候能信你。从那以后每张图都先问自己这张图能不能帮我解释清楚一次线上事故如果再给我一次机会我会把这张参考案例式的架构图画得再朴素一点信息再扎实一点。希望帮到你。本文还有配套的精品资源点击获取