架构图怎么画才有用？订单场景下的分层、部署与评审实践

架构评审会上最尴尬的一幕往往不是方案被否而是投影仪打出一张图底下有人问了一句这个框是干什么的画图的人自己愣了三秒。我见过太多次这种场面图里塞满了方块和箭头配色讲究线条笔直看着挺专业可真正要拿它做决策、做交接、做故障定位的时候没人能用得上。问题不在画图工具也不在审美而在于画图之前没想清楚这张图要回答什么问题。这篇内容聊的是实际场景下的架构图实例与详细说明重点不在怎么用某个软件画得好看而在一张图怎么从零构思到能落地使用。我会拿一个订单交易场景做完整拆解把应用架构、部署架构、数据流转这几个视角分别摊开讲中间穿插图元规范、工具取舍、评审清单和几个踩过的坑。适合正在写技术方案、做系统交接、准备架构评审的开发者、技术负责人和刚接手陌生系统的同学看。哪怕你之前只在纸上画过框框图按这套思路走一遍也能画出别人看得懂、用得上、三个月后自己还能认出来的图。1. 架构图失效的三种典型现场先把失败案例摆出来比空谈原则有用。我整理过手上十几份被判定为没起到作用的架构图问题高度集中在三类而且这三类往往同时出现互相放大。1.1 一张图塞下所有组件信息密度失控最常见的做法是把数据库、缓存、消息队列、网关、几十个微服务、第三方接口全塞进一张画布然后疯狂连线。这种图初看很震撼细看全是问题连线交叉成蜘蛛网箭头方向分不清谁调谁同一个服务在图里出现两次因为要凑连线有些组件被画在空白处没有归属层。我印象很深的一次某团队交付了一份系统全景图画布大约两米宽缩放比例降到 30% 才能看全。图上节点数量我数了一下八十多个。评审时有人提了个非常朴素的问题线上出故障时我从哪里开始看这张图没人答得上来。这张图的信息量是够了但没有阅读路径它对任何一个具体问题都不构成答案。判断一张图是否信息密度失控有个很直接的标准如果不能在 10 秒内指出请求从哪进来、经过哪几层、数据落在哪那就是失控了。治理办法也简单按照读者关心的问题把图拆开一张图只服务一个问题。拆完之后单张图的节点数建议控制在 15 到 25 个之间超过 30 个就该考虑分图了。1.2 没有视角切换用部署图回答业务问题第二类问题更隐蔽图画得挺清楚但视角错位。典型表现是拿一张机房部署图去讲业务能力划分或者拿一张业务流程去讲网络分区。听众在脑子里做视角转换转着转着就跟丢了。举个具体例子。某项目要做一次大促容量评估会上放的是一张应用架构图服务拆分、依赖关系画得很细但没有画实例数量、没有画数据库主从、没有画缓存集群规模。结论是我们的服务拆分很合理可容量问题根本没被回答。第二次会议换成部署视图标了每层集群的节点数和规格问题立刻暴露某个核心服务的实例数只有两个且两个实例部署在同一个可用区。这就是视角的价值。业务视角回答系统提供什么能力应用视角回答能力被拆成哪些服务、怎么互相调用部署视角回答这些东西跑在哪里、资源怎么分数据视角回答数据从哪来到哪去、存在哪。四个视角对应四种读者、四类决策混在一起就都讲不清楚。1.3 图例和命名各自为政看图像破译密码第三类问题看起来是小事实际沟通成本最高。同一个系统里有人用圆角矩形表示服务有人用直角矩形有人用虚线表示异步调用有人用虚线表示预留未实现服务命名一会儿是中文业务名一会儿是英文模块名一会儿是缩写。我接手过一个交接项目前同事留下的架构图里有个叫OMS-Core的方块图例里没写。我花了大半天才确认它对应的是订单主流程服务而不是订单管理系统本身。这种成本是隐性的但在人员流动频繁的团队里会不断累积。解决方式不复杂每张图必须带图例图例里至少写清形状含义、连线含义、颜色含义。命名统一走一套规则要么全用业务语义名要么全用服务标识不要混。这个投入大概十分钟省下的是后面每个人的半小时。2. 落笔前先定读者四类架构图的分工拆图之前得先知道有哪些图可拆。我把实际工作中用到的架构图归成四类每类的读者、回答的问题、必备元素都不一样。这个分类不是学术定义纯粹是按谁看、看什么来切的实操性更强。2.1 业务架构图讲清能力边界与上下游业务架构图的读者是产品、运营、业务方和技术负责人。它要回答的问题是这个系统承担哪些业务能力和外部系统之间的边界在哪谁给我数据我把数据给谁。这类图里不该出现数据库、缓存、中间件这些技术组件出现就是越界。节点应该是业务域或者业务能力比如订单履约库存管理结算对账风控审核。连线表示业务上的数据流转或者依赖方向箭头上要写清楚流转的是什么比如订单状态变更事件结算明细。我通常会在业务架构图上额外标两种信息一个是能力的新旧状态已有、在建、规划中用不同的边框样式区分另一个是跨团队边界用一条粗虚线把不同负责团队隔开。后者的价值在跨部门项目里非常明显一眼就能看出哪些环节需要协调。2.2 应用架构图讲清服务拆分与调用关系应用架构图的读者是开发、测试、架构评审人员。它要回答系统被拆成哪些服务或模块它们之间怎么调用同步还是异步依赖方向是什么。这张图是所有图里最容易画崩的因为大家习惯把所有东西都往上堆。我的建议是严格分层一般分四层接入层网关、负载均衡、BFF、应用层面向场景的编排服务、领域层核心业务能力服务、基础设施层中间件、存储。层与层之间只允许上层依赖下层同层之间如果要调用必须显式画出并标注原因因为同层横向调用往往是耦合的信号。连线类型必须区分。同步调用用实线加实心箭头异步消息用虚线加开放箭头批量定时任务用点划线。这个区分不是形式主义排查问题时它能直接告诉你这个链路的失败会不会阻塞上游。我曾经靠一条虚线的标注定位到一个隐藏的耦合点两个服务本来是异步解耦的后来有人改成了同步调用但没更新图故障时上游被拖垮按图排查时走了不少弯路。2.3 部署架构图讲清网络分区与资源分布部署架构图的读者是运维、SRE、负责容量和稳定性的同学。它要回答服务跑在哪些环境跨几个可用区每层集群的规模和规格网络分区和访问策略是什么。这张图必须带数字。节点上写清楚实例数量、规格、存储容量集群要标明是主从还是多副本。区域划分要画出来比如接入区、应用区、数据区区域之间的访问策略要标注允许哪些端口、走内网还是专线。有个细节容易被忽略不要把逻辑部署和物理部署混在一张图。逻辑部署图讲的是应用集群、数据库主从、缓存集群这种抽象形态物理部署图讲的是具体机房、机柜、网段。前者用于方案评审后者用于运维操作混在一起两边都不好用。实际场景中方案阶段画逻辑部署图就够了上线前再补物理部署图。2.4 数据流图与时序图讲清一次请求的完整旅程业务、应用、部署三张图都是静态的缺一张能讲清一次请求怎么走完的动态图。数据流图或者时序图补的就是这块。数据流图适合讲批处理、数据同步、报表链路这类场景重点是数据在哪些存储之间流动、经过哪些加工环节、时效性要求是什么。时序图适合讲一次交互的完整调用链重点是参与方、调用顺序、同步异步、异常分支。这两类图我最看重的是异常路径的标注。大部分图只画成功路径但排查问题时异常路径才是关键。比如下单链路库存扣减失败怎么办、支付超时怎么办、消息重复消费怎么处理这些在图上标出来图的实用价值立刻上一个台阶。具体的画法可以简化用一条带叉的分支线加一行文字说明即可不需要画完整的异常流程。3. 订单场景实例一套图从需求到成稿理论说完了拿一个具体场景走一遍。为了讲清楚我虚构一个交易系统的改造项目下文简称模拟项目 T业务是订单创建到履约完成的全链路。这个场景足够典型大部分互联网系统都能套用。3.1 划定边界这次到底画哪一段动手前第一个动作不是打开画图工具是确定边界。模拟项目 T 的改造范围是订单创建与支付确认那架构图就聚焦这一段。上游的商品详情、下游的仓储发货、财务结算都只画成一个外部系统方框不展开内部结构。边界划定的作用是控制图的范围避免无限膨胀。实际操作中我一般会在图的一角画一个淡淡的矩形框把本次改造范围内的节点框起来旁边写一句改造范围。这个动作看起来很土但对评审非常有效听众的注意力会自然聚焦。另一个要说清楚的是不在范围内的东西。比如这次不改动风控那图上就把风控画成外部依赖并标注本期不变更。明确说不改什么比说改什么更能降低沟通成本因为大家最担心的往往是你动了不该动的地方。3.2 应用架构分层与依赖方向应用架构图按四层来画下面是模拟项目 T 的分层说明我把它整理成表格实际画图时每一层对应一行横向的节点组。层级主要节点职责关键约束接入层统一网关、场景聚合层鉴权、限流、协议转换、场景编排不允许写业务逻辑应用层下单编排服务、支付确认服务串联领域服务处理事务边界只做编排不承载领域规则领域层订单服务、库存服务、优惠计算服务、支付适配服务领域规则、状态机、幂等控制不允许跨领域直接读写对方数据基础设施层关系库、缓存集群、消息队列、配置中心、日志与监控数据持久化、异步通信、可观测性按用途分实例不共用主库这张表画成图之后节点数大约 20 个在可控范围内。依赖方向从上往下唯一的横向依赖是下单编排服务和支付确认服务之间通过消息队列做状态同步用虚线标注箭头上写订单支付完成事件。有几个具体的设计取舍值得说明。为什么把支付适配单独拆一层因为对接的支付渠道不止一个且渠道侧的接口规范和超时特性差异大拆出来之后渠道变更不会影响订单主流程也方便单独做重试和降级。为什么优惠计算是独立服务而不是订单服务里的一个模块因为优惠规则变更频率高且计算过程需要读取多个数据源放在订单服务里会让主流程变得不稳定拆出来后可以独立做缓存和限流。这些取舍都要在图上用一句话注释出来。图不是只给结论还要传递理由否则下次评审时同样的争论会再来一遍。3.3 部署视图可用区、集群与网络分区部署架构图承接应用架构图把逻辑节点映射到物理资源上。模拟项目 T 的部署视图分三个区。接入区包含负载均衡和网关集群网关集群按最小三节点部署跨两个可用区分布前面挂一个负载均衡做流量分发。应用区包含编排服务集群和领域服务集群每类服务最小三实例强制跨可用区打散。数据区包含数据库主从集群、缓存集群、消息队列集群数据库采用一主两从主从分布在不同可用区缓存集群采用多分片多副本。分区组件部署形态跨区策略关注指标接入区负载均衡、网关集群最小 3 节点跨 2 个可用区连接数、转发延迟应用区编排服务、领域服务集群每服务最小 3 实例强制打散QPS、P99 延迟、错误率数据区数据库、缓存、消息队列主从 / 多副本主从跨区连接数、慢查询、堆积量部署图上有一个地方我特别建议标出来故障域。用浅色底纹把每个可用区圈出来一眼就能看出某个区整体挂掉会损失多少实例。模拟项目 T 第一版方案里订单服务三个实例全在同一个可用区图上画出来之后讨论省了半小时直接改。另外分区之间的访问策略要标在连线上比如应用区到数据区走内网仅开放指定端口。这类信息运维同学最关心写在图上比写在文档正文里更容易被看到。3.4 关键链路时序与数据落点静态图讲完用一张时序说明把下单主链路串起来。参与方依次是客户端、网关、下单编排服务、订单服务、库存服务、优惠计算服务、支付适配服务、消息队列、通知服务。正常路径是客户端发起下单请求网关做鉴权和限流后转发到编排服务编排服务调用优惠计算拿到最终价格调用库存服务做预占调用订单服务创建订单并置为待支付状态返回订单号和支付参数给客户端。用户完成支付后支付渠道回调支付适配服务适配服务校验签名并发出支付成功事件到消息队列订单服务和库存服务各自消费这个事件前者推进订单状态后者把预占转为实扣最后通知服务发送结果消息。异常路径至少要在图上标出三条。库存预占成功但订单创建失败编排服务发起库存释放释放动作走补偿重试最多三次超过则落异常单据由人工处理。支付成功事件重复投递订单服务和库存服务都做幂等以订单号加事件类型作为幂等键。支付回调超时支付适配服务定时主动查询支付状态做状态对齐。这些异常路径不需要画成完整的流程图在时序图旁边用带叉的短线加一行文字说明就够了。判断标准是新人拿着这张图能不能自己回答库存占到一半系统挂了会怎样。能回答图就是合格的。4. 图元、连线与命名的硬规范图画得好不好看是次要的可读性和一致性才是关键。这一节讲的是团队内部应该固定下来的规范投入不大收益长期。4.1 形状语义表让每个框都有固定含义形状的含义必须固定不能一张图一个样。我常用的映射关系是这样的形状含义使用场景圆角矩形应用服务 / 业务能力应用架构图、业务架构图直角矩形基础设施组件数据库、缓存、消息队列圆柱存储数据库、对象存储平行四边形外部系统第三方接口、上下游系统六边形网关 / 代理统一入口虚线框规划中或范围外标注状态和边界这套映射不唯一团队里定一套统一用就行。关键是必须写进图例且图例放在图的固定角落我习惯放右下角每次位置一致看多了就形成肌肉记忆。有个小技巧如果一张图里同类节点超过八个在图例之外再加一个分组框用浅灰底色把同类节点框在一起框的左上角写组名。这样即便节点多阅读时也是分块处理的认知负担小很多。4.2 连线的方向、虚实与标注连线的规矩比形状更重要因为它承载的是关系信息。基本规则三条。第一方向统一表示依赖方向也就是谁调用谁或者谁依赖谁不表示数据流向。这条容易搞混约定死之后就不乱了。如果确实需要表达数据流向用另一张数据流图。第二虚实表示同步异步。实线加实心箭头是同步调用虚线加开放箭头是异步消息点划线表示定时任务。这个区分在排查故障时价值极高一眼就能看出哪些链路会阻塞。第三关键连线必须标注。标注内容包括协议、数据内容、频率。比如HTTP/JSON订单创建请求同步消息队列支付成功事件异步。全标会很挤我的做法是只标跨层和跨分区的连线同层内部的连线不标。连线交叉是绕不开的问题控制手段是布局时按调用方向纵向排布让大部分连线保持同向。实在交叉的用跳线弧线跨过而不是直接穿过。如果一张图里交叉超过十处说明节点排布有问题考虑拆图。4.3 命名与版本图也要能追溯命名规则定两条就够了节点名统一使用一种语言和一种粒度。要么全用中文业务名订单服务、库存服务要么全用英文服务标识order-service、stock-service不要混着来。层级上同一个图里的节点名保持同一抽象层级不要一个叫订单服务旁边一个叫优惠券满减计算模块。图必须带版本和日期格式建议放在标题下方的一行小字里比如模拟项目 T 应用架构图 v1.2 / 2024-06 / 变更增加支付适配服务。变更说明这一条很关键它让看图的人知道这次改了什么不用每次都从头看一遍。图源文件的管理同样重要。可编辑文件绘图工具的原文件或者代码化描述文件必须进版本库和文档放在一起。只存导出图片的做法一定会出问题后面想改一个字都改不动最后只能重画。5. 工具选型与协作流程工具这块没有绝对优劣只有场景匹配。我把实际用过的三类工具按适用场景列一下都是通用类型不绑定具体品牌。5.1 手绘、代码生成、专业绘图三类工具的取舍拖拽式绘图工具适合一次性交付、对视觉要求高的场合比如方案汇报、对外材料。优点是排版自由、样式可控缺点是修改成本高节点一多容易失控多人协作时冲突难处理。代码化描述工具适合需要频繁变更、需要进版本库的图。用文本描述节点和连线渲染出图改起来快diff 清晰多人协作天然友好。缺点是布局由工具自动决定复杂图的排版不一定理想需要花时间调整。白板类工具适合早期讨论、快速对齐。随手画几个框边聊边改效率最高。缺点是画完不能直接用需要有人整理成正式版本。我的实际做法是三段式讨论阶段用白板定稿后转成代码化描述存进版本库对外汇报时再导出成图片贴进材料。三者的源文件都保留白板截图也留一份方便回溯当时讨论了什么。需要提醒一点不要为了工具而工具。我见过团队花两周搭建一套自动生成架构图的流水线结果图的维护还是靠人自动化的部分只覆盖了目录结构收益有限。图的准确性取决于人是否持续维护工具只影响维护成本。5.2 评审会上的提问清单架构图评审最容易变成看着挺好的过场。为了让评审有抓手我整理了一份提问清单评审前发给参与人会上按清单过。检查项提问方式不合格的信号边界这张图覆盖哪一段哪些明确不在范围内答不上来或范围含糊分层每条依赖是否都是上层到下层存在大量同层横向调用且无说明同步异步关键链路里哪些是同步阻塞的全部用同一种线型故障域某个可用区整体失效损失多少图上没有分区标识单点哪些节点只有一份实例答不上来数据落点核心数据存在哪主从怎么分只画了数据库一个框异常路径关键环节失败后如何补偿只画了成功路径图例形状和连线含义是否完整图例缺失或与实际不符这八个问题过一遍大部分图的硬伤都能暴露出来。清单的价值在于把感觉不对变成具体哪一项不符合讨论效率完全不同。5.3 让图跟代码一起变更的机制图最大的敌人不是画得丑是画完就烂。三个月后代码改了三轮图还停在第一版这时候图不仅没用还有害因为它会误导人。让图保持新鲜靠自觉不行得靠机制。我实践下来有效的做法有三条。第一条把图纳入变更流程。凡是涉及服务拆分、依赖关系、部署形态变更的需求验收清单里加一条架构图已更新。这条写进模板比口头强调管用得多。第二条图与代码放在同一个仓库。改代码和改图在同一个提交里评审时一起看。代码化描述工具在这件事上有天然优势图片格式做不到。第三条定期做图与实际的比对。我一般每个季度挑核心系统过一遍方法很土拿图对着监控面板和部署清单逐项核对把不一致的地方标出来修正。这个过程大概半天能发现不少已经悄悄变化但没人提的地方。判断一张图是否已经开始腐烂有几个早期信号图上出现临时待定之类的标注超过三个月没变某个节点在图上有但查不到对应的部署连线上的协议标注和实际抓包不一致新人看完图还是要问一堆问题。出现任意一条就该安排一次核对了。6. 几个容易被忽略的细节前面讲的是主干这一节补几处实操中的细节都是踩过坑之后才意识到的。6.1 颜色与视觉层级的克制用法配色是最容易过度发挥的地方。见过不少图用七八种颜色区分节点结果看图的人得反复对照图例反而更慢。我的建议是颜色只用三档语义主色表示核心链路节点灰色表示辅助或非核心节点浅色表示外部依赖或规划中。三种足够覆盖绝大多数场景。如果需要强调某条链路用加粗连线而不是换颜色。底色可以用来表达区域但要用非常淡的色调且不超过三个区域。区域太多底色的区分度会下降视觉上变成一团色块。文字和图例始终用深色保证对比度投影时不至于看不清。另外一个细节是字号层级。图标题最大分区名次之节点名再次连线标注最小。四级足够了字号差保持明显比如 20、16、13、10。这个层级定下来之后整张图的阅读顺序会自然形成。6.2 复杂图的拆分策略节点数超过三十单张图就很难看清了。这时的处理方式不是缩小字号硬塞而是拆。拆分方式有三种按场景选。按视角拆是最常用的也就是前面讲的业务、应用、部署、数据四张图。每张图解决一个问题读者按需取用。按链路拆适合核心流程特别长的系统。比如把下单链路、履约链路、售后链路分别画一张每张图只画这条链路经过的节点。缺点是节点会重复出现需要在图上标注完整结构见总图。按层次拆适合分层特别明确的系统。总图只画层与层的关系每层的细节单独出一张图。这种方式的好处是总图非常清爽缺点是读者要来回翻。实际项目中我一般组合使用先出一张总览图控制在 20 个节点以内只画主要层次和核心链路然后针对每条核心链路各出一张详图部署单独一张。这样一个系统大概四到六张图覆盖完整又不冗余。6.3 对外交付时的脱敏处理架构图经常要对外提供比如给合作方、给审计、给新入职同学做培训材料。这时候必须做脱敏而且要在导出前做不要指望事后检查。需要脱敏的内容包括内网网段和具体 IP、真实的域名和端口、第三方服务商的标识、具体的实例数量和规格这个视情况、以及内部的服务代号。处理方式是把具体值替换成占位描述比如内网地址外部接口集群规模 N。有个细节容易漏导出图片的元数据。有些绘图工具会把文件路径、作者信息、甚至图层的隐藏文字写进导出文件。交付前用工具检查一遍或者干脆走截图后重新保存的流程能规避这类问题。另外对外版本和对内版本建议分开维护。对内版本保留完整信息用于运维对外版本只保留结构和逻辑关系。两个版本同源不要各画一遍否则一定会不同步。最后分享一个我自己一直在用的习惯每画完一张图隔一天再看一遍假装自己是个完全不了解这个系统的人从图的左上角开始读看能不能顺畅地读下去、每个框能不能看懂、每条线能不能说清含义。这个隔夜自检能发现大概一半的问题比当场反复检查有效得多。图画出来是给人看的自己先当一次读者是最省成本的验证方式。