架构图

架构图

架构图展示分层、组件与依赖，适合方案评审与系统说明。构图AI「架构图」技能支持一句话生成手绘分层图。

登录可免费体验 1 次；VIP 期内不限制日常画图；导出 PNG / SVG / .excalidraw。

什么时候用

• 方案评审：说明为什么这样分层、关键依赖如何走、风险点在哪一层。
• 系统演进：从单体到拆分、加网关、加缓存时画「现状 vs 目标」。
• 跨团队对齐：前端、后端、数据、运维对同一套边界达成共识。
• 对外讲解：面试、路演、客户技术方案中的「系统长什么样」。

不适合替代接口时序细节（用时序图），也不适合替代表结构建模（用 ER 图）。网络设备连线与集群节点互联更适合拓扑图。一张架构图最好只服务一类读者，避免「既要给 CEO 又要给 SRE」导致信息过载。

核心元素

好的架构图让读者快速回答：边界在哪、主链路怎么走、数据落在哪一层。同层组件避免排成无限长一行，宜用 2～3 列网格，并用底色区分层级。

排版规则（架构专用）

1. 层自上而下、依赖箭头少交叉：接入在上、数据在下是默认阅读习惯。
2. 同层 2～3 列网格：组件超过四个就换行，不要拉成超宽单行。
3. 外部系统靠边：第三方支付、开放平台放左右外沿，避免混进业务层。
4. 同步与异步分线型：同步实线、消息虚线，必要时图例说明。

反例：把 JWT 鉴权、线程池参数、每个 REST 路径、Redis 键格式全塞进一张「概览架构」——受众瞬间失焦。概览版只保留网关、鉴权、业务服务、缓存、数据库；细节另开 JWT 专题图或时序图。

Prompt 好坏对比

写 prompt 时按「层名 + 层内组件 + 关键依赖」组织句子，比罗列一堆技术名词更易生成清晰分层。同一系统可维护「概览版」与「细节版」两张图。

常见错误

1. 层名与组件混杂：把「Redis」和「业务层」平级堆放，层次感消失。
2. 箭头无方向或双向乱飞：依赖应可读；必要时拆「同步调用」与「异步事件」两套线。
3. 为炫技塞满 logo：信息过载，评审抓不住重点。
4. 受众错位：给业务同学看的图却写满端口与线程模型，沟通效率反而下降。
5. 用架构代替拓扑：集群节点、网段、可用区应另开拓扑图，不要在分层框里硬画机柜。

与相邻图类型的区别

用构图AI怎么画

选择「架构图」，按层描述，例如：「画 Web 三层架构：前端、后端 API、数据库，含 Redis 缓存」。或描述微服务：网关、业务服务、消息队列、基础设施。生成后微调分组与箭头标注，再导出。可先看微服务、JWT 示例页的分层方式，再套到自己的系统。

构图AI 提供 12 种技能，可与时序图、拓扑图互补：架构定全景，拓扑定落地，时序定关键链路。

相关：微服务指南 · 微服务示例 · JWT 架构示例 · 前端架构指南 · 使用此技能画图

最后提醒：架构图评审结束时，固定留下「已通过版本」截图或导出文件，避免口头同意、图却还是旧的。

此外，建议把本页与站内示例对照着练两次：第一次照抄结构，第二次换成你的业务词。两轮之后，你对该图类型的边界会比只读文档清晰得多。

分层命名建议

常见可用：接入层、应用层、领域服务层、数据层、基础设施层。不要同时使用「中台」「平台」「公共服务」三个近义层名，除非团队词典已定义差异。层名是给人类对齐用的语言，不是装点门面的标签。

当出现「公共服务层」膨胀时，问三个问题：它是否有独立发布节奏？是否有独立故障域？是否被超过三个域依赖？三个「是」才配成为一层，否则宁肯画回所属域内的模块。

与部署图的衔接

架构图通过评审后，再画一张缩小范围的部署/拓扑图说明实例数与机房，避免在架构图上堆 Pod 名。两张图互相链接，比一张超载图更容易维护。