系统架构图怎么画？从需求分层到组件关系的绘制步骤

很多系统架构图的问题不是“画得不好看”，而是没有说明这张图要帮助谁做什么决定。业务负责人关心系统边界和能力，开发关心组件与接口，运维关心部署和故障，安全人员关心信任边界。把这些内容强行放在一张图里，往往得到一张信息很多却无法评审的图。

一、系统架构图是什么？先区分结构、行为和部署

系统架构图用图形表达系统边界、主要组件、职责、依赖和关键约束。它通常回答三类问题：

• 结构：系统由哪些应用、服务、数据存储和外部依赖组成。
• 行为：请求、事件或数据怎样在组件之间流动。
• 部署：组件运行在哪里，如何隔离、扩缩容和恢复。

这三类问题可以共享术语，但最好用不同视角表达。结构图回答“有什么”，行为图回答“怎样运行”，部署图回答“运行在哪里”。

二、画图前先写清楚读者、决策和范围

开始拖拽图形之前，先用三句话定义任务：

1. 这张图的主要读者是谁？
2. 读者看完要做什么决定？
3. 图中明确包含和排除哪些系统？

例如：“给研发和安全评审新支付链路；决定服务边界、数据流向与信任边界；只包含订单、支付和风控，不展开财务结算内部实现。”这段说明比“画一张电商架构图”更能约束图的内容。

三、选择合适的架构视角和缩放层级

C4 Model使用系统上下文、容器、组件和代码等缩放层级讲述不同故事，并指出并非所有团队都需要画齐四层。实务中可以采用“最少充分图集”：

• 系统上下文图：定义系统、用户和外部系统的关系。
• 应用/容器图：展示可独立运行的应用、服务与数据存储。
• 部署图：展示环境、节点、网络区域和运行关系。

只有当组件边界本身是重要决策时，才继续深入组件图。图的层级越深，维护成本越高；没有评审用途的细节不应进入图中。

四、系统架构图的7步绘制方法

步骤1：画出系统边界和外部参与者

先画一个清晰的系统边界，再放入用户、角色和外部系统。此时不要急着展开内部组件。

步骤2：列出组件并写一句职责

每个组件都用“负责什么”描述，而不是只写技术名。无法写清职责的组件通常边界也不清楚。

步骤3：按业务或技术层次分组

可以按接入、应用、领域、数据和基础设施分层，也可以按业务域分区。分组方式必须服务于当前决策。

步骤4：连接关键关系

从最重要的三到五条链路开始，不要一次画出所有调用。连接线上写明动作、数据或事件。

步骤5：补充数据和信任边界

标出数据存储、所有者、敏感数据流向，以及公网、内网、第三方等信任边界。

步骤6：增加非功能约束

在相关组件旁标记容量、可用性、延迟、恢复目标、成本或合规约束，不把这些关键条件藏在另一份文档里。

步骤7：用场景走查并删减

走查正常与失败场景，修正遗漏后删除无关细节。好的架构图不是元素最多，而是决策信息密度最高。

五、组件、边界和连接线应该怎样标注？

图形语义应尽量稳定。组件名称采用“业务能力 + 组件类型”，例如“订单服务”“用户数据库”；连接线使用动词或事件，例如“创建订单”“发布库存预留事件”，必要时补充协议。

• 边界用来表达所有权、部署区域或信任关系，不只是装饰分组。
• 颜色用于少量稳定语义，例如内部/外部或正常/异常，不用颜色代替文字。
• 箭头方向必须与真实调用或数据流一致，双向关系最好拆成两条有含义的线。
• 每张图提供图例，但图例不能复杂到需要另一张图解释。

六、把非功能需求直接变成可评审问题

AWS Well-Architected等框架使用运营、安全、可靠性、性能、成本和可持续性维度评审系统。架构图不需要把所有答案写满，但应让关键问题有落点：

七、用“正常、异常、变化”三类场景验证架构图

只走查正常请求会让许多架构缺陷被隐藏。建议至少选择三类场景：

1. 正常：一个关键业务请求如何从入口到数据存储并返回。
2. 异常：依赖超时、消息重复、数据库不可用时如何降级或恢复。
3. 变化：流量增长十倍、增加新渠道、替换外部服务时哪里需要改变。

如果团队无法沿着图完整讲清某个场景，说明连接、职责或边界仍然缺失。架构图应接受场景测试，而不只是接受视觉评审。

八、系统架构图常见的6个错误

• 没有说明读者和用途，导致所有细节混在一起。
• 只有产品Logo，没有组件职责和关系语义。
• 所有线都写“调用”，看不出动作、数据或事件。
• 把业务系统、微服务和服务器实例放在同一抽象层级。
• 只画正常路径，忽略安全边界、超时、重试和恢复。
• 上线后无人维护，图与实际系统逐步漂移。

解决这些问题的共同方法是减少“看起来完整”的追求，增加读者、视角、场景和更新时间等可验证信息。

九、怎样用模板和AI提高效率而不牺牲准确性？

模板适合提供基本分区和视觉规则，AI适合把需求变成候选组件与初稿。两者都不能代替团队对真实系统的确认。建议先选择与视角匹配的系统架构图模板，再根据输入合同使用AI生成系统架构图，最后回到场景走查。

在Boardmix画布中，可以将系统边界、组件、便签、评审问题和架构决策放在同一空间，通过评论与历史版本保留讨论上下文。

十、系统架构图常见问题

系统架构图一定要使用标准符号吗？

不一定，但必须保持图内一致，并提供图例。若使用云服务图标，应遵守对应厂商的图标规范，并在图标附近写明服务名称。

一张系统架构图应该包含多少组件？

没有固定数量。以读者能快速理解并完成目标决策为准；当组件过多时，应拆成不同视角或不同缩放层级。

业务架构图和技术架构图可以合在一起吗？

小型系统可适度结合，但应清晰分层。复杂系统更适合共享术语的两张图，避免业务能力和技术实现互相干扰。

多久更新一次架构图？

重大设计、接口、部署或边界变化后更新，并设置负责人和最后核验日期。固定周期复核可以防止长期漂移。