【读书笔记】如何画好架构图：架构思维的三大底层逻辑
架构图并非技术人的“画功比拼”，而是一个团队、一个系统、一次项目从混沌走向清晰的关键抓手。它是系统的视觉语言，是让技术人员、产品经理、运营甚至老板都能站在统一上下文下讨论的“认知中枢”。
结合来自 CSDN 的观点（参考链接），我们将“画图”这件事拆解为三大底层逻辑，并补充四个“进阶技巧”，帮助你构建出既能表达系统，又能支撑决策的架构图。
一、目标逻辑：图是“沟通工具”而不是“汇报材料”
正如文章中提到的，“画图不等于交作业”，一张好图不是为了上交，而是为了协同。所以，任何架构图都要回答三个问题：
| 核心问题 | 典型回答示例 |
|---|---|
| 画图目的是什么？ | 表达系统接口关系 / 汇报某次架构重构 / 定位某类问题 |
| 受众是谁？ | 项目经理 / 后端研发 / 运维 / 测试 / 业务方 |
| 图要解决什么问题？ | 描述依赖关系？展示流量路径？评估扩容影响？ |
文章指出：“一个系统不同阶段、不同角色对信息的需求是不同的”，因此不能用一张图应对所有人，应该为特定视角单独设计。
二、结构逻辑：可读性来自“语义统一 + 空间有序”
原文强调：“图形不是装饰，颜色不是点缀”，图形和颜色本身就代表语义。
结合这一理念，你的架构图应该具备以下结构特征：
| 元素 | 表达含义 |
|---|---|
| 形状差异 | 区分服务、存储、接口等 |
| 颜色分区 | 表示职责边界/生命周期 |
| 箭头方向 | 表达调用方向或依赖流 |
| 分组/层次 | 表示逻辑结构和上下游关系 |
建议做法包括：
- 使用标准图例模板（如服务=圆角方块，数据=数据库形状）
- 逻辑相关元素靠近，避免跨层连线
- 一张图表达一个“面”，不要上下混排流程与拓扑
三、演化逻辑：让图“活”起来，而不是只做一次性的演示
架构图不是“一次性 PPT 图”，它应当随着系统成长而演化。文章指出，“架构图要承载未来演进的想象空间”，因此建议：
- 明确哪些模块可以替换（如：API 可切换为 gRPC）
- 哪些部分存在扩展点（如：预留插件位）
- 哪些链路是瓶颈（可配红色警示）
- 哪些模块是外部系统，未来可能脱离或合并
你甚至可以添加 时间线或多版本层叠视图，展示不同阶段架构如何变迁，让团队理解设计演化的“意图”。
四个进阶技巧
-
一图一意图
每张图明确一个意图，不贪图全面。复杂系统用分图串联。 -
保持图-口-文一致
图例、文字、讲述口径保持一致，形成统一语义体系，避免“图说一套，人讲一套”。 -
图中嵌套指标或状态
引入 SLA、TPS、QPS、Error Rate 等核心指标展示系统状态，增强图的“运营能力”。 -
结构与视角解耦
架构图结构不变，但通过图层切换、颜色变化表达不同视角（如安全视角、成本视角）。
总结：从“图”到“沟通语言”
画架构图不是为了炫技，而是为了成为团队内部通用的沟通语言。只有明确目标逻辑、结构逻辑、演化逻辑，并结合语义统一、可视状态、分视角组织的技巧，你的架构图才能真正落地在设计、开发、运营、复盘等各类场景中，变成系统建设的一部分。
“一张图，就是一份系统的自省，一次思维的外化，一种团队的对齐。”
画图，不只是画，更是一种架构能力的体现。
