如何画好一张架构图/业务图/流程图——生产排障的第一步
本文是体系化知识专题的第 3 篇 叙事框架：
场景引入 → 逐层拆解 → 原理深潜 → 优化实践 → 全景总结
场景引入：排障的第一步不是看代码，是画图
你有没有想过，为什么同一个线上问题，7 个人排查会有 7 种不同的结论？
不是因为技术能力差距，而是因为每个人脑子里对"系统长什么样"的认知不一样。A 认为时序上先经过网关再进服务，B 认为业务逻辑里还有回源调用，C 以为某个缓存一定命中了——认知偏差让排查变成猜谜。
我第一次带队排一个"支付回调丢失"的故障时，花了整整 4 个小时。前 3 小时五个人各查各的，后 1 小时画了一张图，10 分钟定位根因。
那张图长这样：
画完图才发现：我们争议的本质不是"回调去哪了"，而是"谁在哪个环节消费了回调消息"——这根本不是一个代码问题，而是一个架构认知对齐的问题。
这就是本文的核心观点：生产排障的第一步，不是看日志，不是看代码，而是画图。 画图解决的不是技术问题，是信息对齐问题。
那问题来了——排障时到底应该画什么图？三种最常见的类型：
| 图类型 | 回答什么问题 | 典型场景 |
|---|---|---|
| 架构图 | 系统分几层？组件间怎么调用的？ | 服务整体认知、调用链梳理 |
| 业务图 | 数据怎么流转？各角色做了什么？ | 业务流程对齐、数据血缘分析 |
| 流程图 | 决策路径是什么？异常分支怎么处理？ | 排障决策、代码逻辑追踪 |
下面逐一说清楚每种图怎么画。
第一站：架构图 — 层级分区、组件关系、部署拓扑
架构图的核心作用
架构图回答一个排障中的根本问题：这个请求经过了哪些组件？
排障时最常犯的错误是"只见树木不见森林"——盯着一个服务的日志看了半小时，但问题可能出在调用链的上游或下游。架构图让你先看清全貌，再做定位。
好的架构图应该画出什么？
支付系统是一个经典案例，涉及接入层、核心服务、消息、数据、外部依赖五层：
这张图的层次结构很清晰：
第一层：接入层 — Nginx 做反向代理 + SSL 终结，API Gateway 做鉴权和限流。排障时如果怀疑"请求根本没到达服务"，先看这一层。
第二层：核心服务层 — pay-svc、order-svc、user-svc、wallet-svc。注意这里用的是虚线箭头表示服务间 Feign 调用，实线表示 Gateway 到服务的路由。
第三层：消息层 — RocketMQ 做支付结果通知。排障经典误区：很多人以为支付回调是 HTTP 直接调回来的，实际上是通过 MQ 异步通知的——有这张图就不会错。
第四层：数据层 — MySQL + Redis。这里是大多数问题的埋藏点：缓存没命中、数据不一致、慢查询。
第五层：外部依赖 — 微信支付、支付宝。典型的"黑盒"组件——你无法控制它们，但你的核心业务流程依赖它们。
架构图的层级分区原则
画架构图有一个黄金原则：一个子图一个层次，颜色即语义。
错误画法（左）：所有节点平铺在同一层面，颜色随手选。这种图约等于没画——你只是把组件名写出来了，没有传达任何架构信息。
正确画法（右）：
1. 按层次用 subgraph 分区（接入层/应用层/缓存层/持久层）
2. 每层统一配色（接入层绿色、应用层蓝色、缓存层红色、数据层青色）
3. 层与层之间有明确的调用方向
排障中架构图的应用
架构图在排障中的真实用法：
| 场景 | 画什么 | 帮助 |
|---|---|---|
| 接口超时 | 请求路径架构图 | 看哪一段耗时异常 |
| 数据不一致 | 数据流架构图 | 看数据经过哪些服务 |
| 级联故障 | 依赖关系架构图 | 看调用链和依赖层级 |
| 部署异常 | 部署拓扑图 | 看节点分布和流量分配 |
第二站：业务图 — 数据流转、参与角色、状态变更
业务图的核心作用
如果说架构图回答"有哪些组件"，业务图回答"业务数据怎么走"。
排障中一个常见困境：技术栈都查过了，但业务逻辑错了。 比如订单状态不对、数据被错误覆盖、某个业务条件没触发。这时候画一张业务图，把数据流向和参与角色画清楚，盲点就浮出来了。
业务流转图：订单全生命周期
这是最常见的业务图形式。关键设计原则：
- 按阶段分区：创建/支付/履约/售后，每个阶段一个子图
- 每个阶段的动作和状态变化合在一起：节点 = 动作 + 结果
- 阶段间的箭头发送"消息"，不是"调用"
排障时的典型用法：检查异常订单处在哪个阶段、卡在哪个步骤。
数据流图：谁产生谁消费
业务图的另一种重要形式是数据流图。它回答"数据从哪里来、到哪里去"：
数据流图在排障中的价值在于追踪数据的生产—传输—存储—消费链路。
业务图在排障中的应用
| 场景 | 画什么 | 帮助 |
|---|---|---|
| 数据丢失 | 数据流图 | 看哪一段链路断了 |
| 状态不一致 | 状态转换图 | 看哪些路径跳过了校验 |
| 业务逻辑错误 | 业务流转图 | 看各角色执行了不同逻辑 |
第三站：流程图 — 决策节点、异常分支、时序逻辑
流程图的核心作用
架构图和业务图是"静态的"——它们告诉你系统长什么样、数据怎么走。但排障过程本身是动态的，你需要决策：先查什么、后查什么、什么条件下走哪条路。
流程图回答的是排障中最关键的问题："如果 A 成立则走 B，否则走 C——B 和 C 分别是什么？"
排障决策树：流程图的最佳实践
这张图用一个排障典型场景展示了流程图的画法：接口超时了，按什么顺序排查？
流程图的三个设计要点：
- 决策节点（菱形）：每个决策问一个 boolean 问题（"CPU 是否高？"）
- 分支标注：标注"是/否"路径，不能少任何一条
- 终点明确：每条路径最终指向一个确定的排查动作
异常分支是流程图的灵魂
很多人画流程图只画正常路径——这是最大的错误。真正的排障价值在异常分支：
这张图是支付回调处理的真实流程。注意看三个异常分支：
| 分支 | 处理 | 排障启示 |
|---|---|---|
| 验签失败 | 记录异常，返回错误 | 排查方向：签名算法/密钥配置 |
| 金额不一致 | 发起人工审核 | 排查方向：业务逻辑/数据篡改 |
| 订单已支付 | 幂等处理，返回成功 | 排查方向：重复回调/重试机制 |
流程图在排障中的应用
| 场景 | 画什么 | 帮助 |
|---|---|---|
| 重复告警 | 排障决策树 | 标准化排查路径 |
| 代码逻辑复杂 | 控制流图 | 看清条件分支和循环 |
| 时序跨系统 | 时序图 | 看清异步/并行交互 |
| 状态不明确 | 状态机图 | 看清合法状态转换 |
工具与原则：DOT vs Mermaid
画图工具怎么选？回答这个问题之前，先理解一个前提：排障画图要能进 Git。
白板拍照不行——拍完就找不到了。Visio/Draw.io 可以但不够好——因为无法 diff、无法 code review。排障画图的最佳实践是用文本格式作图文件，像管理代码一样管理图。
目前两种最主流的文本格式：DOT（Graphviz）和 Mermaid。
选型参考
DOT 适合：
| 场景 | 原因 |
|---|---|
| 架构图（含子图集群） | subgraph cluster 天然支持层级边框 |
| 复杂路由 | splines=ortho 精确控制连线 |
| 排障决策树 | 菱形节点 + 分支标注 |
| 任意复杂度的有向图 | 布局引擎成熟，不限制节点数 |
Mermaid 适合：
| 场景 | 原因 |
|---|---|
| 时序图 | sequenceDiagram 语法简洁 |
| 饼图 / Gantt 图 | DOT 原生不支持 |
| 简单流程图 | 学习成本低，Markdown 原生支持 |
总体原则：排障场景的架构图和流程图用 DOT，时序图用 Mermaid。
核心绘制原则
原则一：一个节点一件事
每个节点只表达一个概念。不要在一个节点里同时写"用户→Nginx→App→DB"，那应该分成四个节点。
原则二：不超过 20 个节点
一张图超过 20 个节点，说明边界不对。拆成子图或多张图。20 个节点是人在一张图上同时处理信息的极限。
原则三：颜色即语义
同层同色，不同层不同色。红色表示异常/高危，绿色表示正常/通过，蓝色表示处理中。彩虹图（每个节点颜色都不一样）是噪音。
避坑清单
画图不是越多越好，也不是越详细越好。以下是 5 个最常见的作图误区：
误区 1：画成代码级
❌ 错误：在架构图中画出类名、方法名、if-else 分支
架构图回答"谁在哪儿"的问题，不是"代码怎么执行"的问题。把代码逻辑画进架构图，结果就是没人看得懂。流程图可以画代码逻辑，但一张图只画一个关注层级。
误区 2：没有层次，全平铺
❌ 错误：所有节点摆成一行，看不出层次关系
排障的核心能力是分层排查——先排除接入层，再查应用层，最后查数据层。图没有层次，排查就没有优先级。用 subgraph 分区是最简单有效的层次化手段。
误区 3：颜色无效（彩虹图）
❌ 错误：每个节点不同颜色，颜色没有语义信息
人体对颜色的短期记忆极限是 3-5 种。超过 5 种颜色就和黑白图没区别了。遵循"同层同色"原则：接入层用一组色、应用层另一组色。颜色要能表达"这些是同一个层次的东西"。
误区 4：不画异常分支
❌ 错误：流程图只画正常路径
排障的 90% 价值在异常分支。正常路径人人看得懂，谁不都犯错。真正的问题是"在什么条件下会走到这条错误的路径"。每次画流程图都必须自问：我把异常分支画全了吗？
误区 5：一次画太大
❌ 错误：一张图想覆盖所有信息
系统复杂时，拆成多张图。推荐的分拆方式：架构总览图 1 张 + 各组件详细图若干张。总览图不超过 20 个节点。
好图与坏图对比
同一系统，左图是典型的坏图：平铺、彩虹色、无层次、圆形节点命名混乱。右图是好图：分层清晰、颜色语义一致、子图边界明确、节点命名规范。
全景总结：排障画图 Checklist
每次排障前，先问自己 6 个问题
- 这张图给谁看？ 自己排障画的图和团队分享画的图不一样。自己用可以粗糙快，给别人看需要规范清晰。
- 画什么类型的图？ 架构图、业务图和流程图，选对类型比画得好看重要一万倍。
- 核心节点 ≤ 20？ 超过 20 个说明边界不对，拆。
- 颜色有语义吗？ 同层同色 vs 彩虹图。好图的颜色你不看图例也能猜出层次。
- 异常分支画了吗？ 只画正常路径等于没画。
- 文件可版本管理吗？ .dot / .mmd 文本文件进 Git，白板拍照是浪费。
排障画图的完整流程
这个时序图展示了排障画图的完整过程：告警来了 → 先画架构图标出告警位置 → 再画流程图理清排查路径 → 标注异常分支 → 发现被忽略的分支 → 缩小范围 → 定位根因。
工具推荐
| 工具 | 适用场景 | 版本管理 |
|---|---|---|
| DOT (Graphviz) | 架构图、流程图、决策树 | ✅ git diff 天然支持 |
| Mermaid | 时序图、饼图、简单流程图 | ✅ Markdown 或 .mmd 均可 |
| draw.io | 协作画图、导出 SVG | ⚠️ 仅导出版本号，无法 diff |
| PlantUML | 时序图、UML 类图 | ✅ 纯文本，可 diff |
原则速记
一个节点一件事，不超过二十个； 同层同色语义明，异常分支不能省； DOT 为主 Mermaid 辅，文本进 Git 最靠谱。
延申阅读：
- 微服务架构下"一个请求的一生"：从 DNS 到 DB 的全路径拆解 — 本文所有架构图画法的实际案例
- Graphviz DOT 官方文档：节点形状、颜色、布局完整的配置参考
- 从单机到分布式：一个接口的事务一致性演进 — 业务流转图的深度应用
