简介：软件系统架构图是软件开发中连接业务与技术的重要设计产物。这份参考案例以共享平台为例，面向软件架构师、系统设计师及需要绘制架构图的开发人员，系统讲解架构设计中的三类核心视图：逻辑架构突出子系统间的业务关系，技术架构强调模块自身技术与接口关联，整体架构则从基础层、数据层、支撑层、管理层和展现层还原系统全貌。资源为单一PDF文件，仅2.75MB，便于随时查阅。其中对应用系统建设、结构化与非结构化资源采集、数据分析与展现、内外部门户发布，以及标准规范体系、接口管理等环节均有明确图文说明，适合用于编写技术方案、汇报材料或课程案例。目前已有1243人学习浏览，是一份可直接借鉴的架构图绘制与讲解范例，尤其适合需要快速理解架构分层和模块划分的读者。

1. 软件系统架构图不只是画框连线：参考案例 PDF 到底在参考什么

很多开发第一次拿到名为"软件系统架构图_参考案例.pdf"的文件，是在评审会前夜。手里只有一个模糊的系统雏形，想找现成的图做参考，却说不清到底要参考什么：是参考图的样子，还是参考别人怎么划分模块、怎么处理依赖。我的答案是后者。架构图最重要的是信息准确，不是画得好看。一张配色再舒服的图，如果别人看不出系统边界、数据流向和依赖方向，评审时就会被连环追问，最后不得不回到白板重画。这篇笔记不会去复述某份参考文档的页码，而是从一线画图的角度拆解：案例文档里常见的架构图类型、五步绘制流程、三张容易被漏掉的图，以及五个真实翻车现场。读完你至少能判断手上的图到底能不能拿去交付。

2. 先决定画什么再决定怎么画：案例文档里最常见的四种架构图

2.1 单体、分层、微服务、事件驱动：先认清自己属于哪种风格

很多参考案例文档的第一页，往往是一张"系统整体架构图"。很多人拿到后的第一反应，是照着最漂亮的样例改，把网关、注册中心、消息队列全部堆上去。但这是本末倒置。架构图画出来是要落到部署和代码结构上的，画之前先回答三个问题：系统是几个进程？数据库是几个？模块间是同步调用还是异步消息？回答完，架构风格基本就确定了。

我一般这样判断：部署在一个进程里，优先画单体或分层；有独立部署和扩缩容需求，才画微服务；如果系统里有明显的队列、订阅发布模式，再考虑事件驱动。画图不是目标，目标是让看图的人一眼就能知道系统是怎么组织的。

新手最容易犯的错误，是拿微服务架构图的模板硬套一个简单单体系统，结果评审会上被问"这个网关在代码仓库里对应哪个工程"，答不上来，整张图的信任度就崩了。判断架构风格时，还可以看系统里的"中间件密度"：如果图里出现注册中心、配置中心、网关三个组件同时存在，基本可以断定是微服务风格；如果只有应用服务器和数据库，那就是分层或单体。这个判断不需要读代码，从部署清单和配置文件数量就能看出来。画图前花十分钟梳理部署单元，比画完之后返工一小时划算得多。

2.2 从连线识别架构：实线同步、虚线异步、粗线数据流

参考案例里的连线通常是有含义的。我平时画图的约定是：实线表示同步调用，典型的是 HTTP 接口或 RPC；虚线表示异步消息，典型的是 MQ 投递或事件订阅；粗线表示核心数据流，比如订单状态流转、同步链路。为什么要把线型约定得这么细？因为架构图本质上是一张"可执行的沟通图"，别人要能根据连线判断两个模块之间到底是什么关系。

如果连线含义混乱，会出现一个很典型的场景：运维看到两条线，一条实线一条虚线，分不清哪些依赖是强依赖、哪些是弱依赖，扩容的时候不知道该把哪个服务优先拉起来。所以在图例里明确线型，比调整颜色重要得多。我这里给出一个最简单的约定：普通同步调用用实线加箭头指向被调用方；异步消息用虚线加箭头指向消费方；如果需要强调数据量大的链路，把主线加粗，并在旁边标注每秒请求量或数据量级。这个约定不需要多复杂，但必须全图统一，并且在图例里写清楚。

另外，箭头方向要慎重。架构图上最常见的误解就是箭头方向。我通常把箭头指向被调用方：A 调用 B，箭头指向 B。这样拆链路时，顺着箭头就是一次请求的路径。如果反过来画成数据流方向，看图的开发要去猜这到底是调用关系还是数据流动。如果两种关系都有，就用两种线形区分，并在图例里注明：实线箭头是"调用方向"，虚线箭头是"消息方向"。

2.3 不同读者看不同图：逻辑视图、组件视图、部署视图

一份好的参考案例通常不是只有一张图，而是至少三张：逻辑视图、组件视图、部署视图。逻辑视图给产品和业务同事看，画的是模块和业务能力，不需要出现具体的服务名和端口；组件视图给开发看，画出服务、数据库、缓存、消息队列这些实际组件；部署视图给运维看，画出每台机器、容器、网络区域，标注端口和域名。

这三张图的关系是层层细化的。逻辑视图回答"系统有哪些业务能力"，组件视图回答"能力由哪些组件实现"，部署视图回答"组件跑在哪里"。我见过很多团队只画一张组件视图，然后拿着它去应付所有场合，结果给产品讲业务功能时说不清楚，给运维讲部署时又缺主机信息。画图之前先问自己一句：这张图是给谁看的？同一个系统，画给不同人应该是不同的图。

还有一个容易忽略的视图：安全视图。在涉及用户权限、外部接口的案例里，安全边界一般用一条红色虚线表示，跨越这条线的请求要经过鉴权。这个图不一定要单独画，可以在逻辑视图上用一条边界带出来。但有没有这个边界，影响很大。没有标注安全边界的架构图，在安全性评审时几乎一定会被挑战。你能把模块关系讲清楚，只是及格；能画出安全边界、部署边界和数据归属，才是一份可以拿去评审的参考案例。

3. 照着参考案例画图：五步可复现的绘制流程

3.1 第一步：先画系统边界和外部依赖，再画内部模块

很多人在空白画布上的第一笔是画内部模块，我建议反过来。先画一个大的虚线框，代表系统边界，然后画框外的东西：用户、第三方服务、上下游系统。这个顺序的价值在于强制你思考系统是开放给谁用的。

画外部依赖清单时，至少要有四列：

画完外部依赖后再画内部模块，会发现系统的左边和右边自然留出了"入口"和"出口"，内部模块的排布就有了约束。很多人忽略这一步：架构图如果没有边界，看的人就分不清哪些东西属于系统，哪些属于外部。一个没有边界的架构图，评审时最常见的提问是"这个服务到底是不是我们团队维护的"，一问，你就得现场解释半天，图本身没有起到任何作用。

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. 进阶：画完架构图后，用一份自检清单给架构图做体检

画完不等于能交付。我现在每次画完架构图，都会做一次"体检"，不查代码，只查图本身。这份清单是从一次次评审里磨出来的，每一条背后都对应过真实翻车。

还有一个我养成的习惯：每次画完，把图发给一个不了解该系统的人，请他用三分钟讲出系统由哪些部分组成、数据怎么流动。如果讲不出，问题不在他，而在图。这个方法比任何工具检查都有效。我早期画架构图也喜欢堆装饰，直到某次评审时被运维问"这个缓存挂了之后服务怎么办"，我看着图上那条干干净净的连线答不上来，才真正明白架构图的价值是让人在需要的时候能信你。从那以后，每张图都先问自己：这张图能不能帮我解释清楚一次线上事故？如果再给我一次机会，我会把这张参考案例式的架构图画得再朴素一点，信息再扎实一点。希望帮到你。

本文还有配套的精品资源，点击获取