通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

体系结构设计图

架构师经常通过关系图进行通信。 设计良好的视觉对象是一种功能强大的工具，可帮助实现者、安全审阅者和业务利益干系人融合在一起的共享心理模型，提前暴露风险，并减少返工。 若要与意向通信，架构师必须选择并经常选择与消息、受众和生命周期阶段匹配的层关系图类型。

最终，体系结构关系图的选择取决于你试图传达的内容和受众的问题。 架构师在整个设计活动、要求优化和利益干系人沟通中使用多种类型的关系图。 期望在设想、设计细化、威胁建模、实施、运营和治理之间维护多个关系图。

关系图做法

有效的关系图传达了大量信息，而无需广泛的文本解释。 若要避免歧义并确保明确的通信，请遵循以下建议：

使用标准表示法。 使用广为人知的符号、图标和演示约定，确保不同受众的可读性和一致性。

避免不明确行。 关系图通常显示使用线条的实体之间的关系。 在整个关系图中表示这些关系的方式保持一致。

使用方向箭头。 没有箭头的线条使关系不清楚。 始终使用箭头，如果存在双向通信，则显示两个单独的流（首选）或批注单个箭头（请求/响应注释）。

避免双向箭头。 双箭头表示双向依赖项，这可能导致混淆。 使用单端箭头表示从发起组件（客户端）到依赖项（服务器）的流。

明确标记所有内容。 为每个图标、分组容器和关系提供清晰、准确且有意义的标签。 当关系在上下文中不立即明显时标记线条。

保持一致性。 对类似元素使用标准化颜色、大小写、图标大小、线条粗细、线条类型、箭头头和边框样式。 在解决方案集中的每个关系图中应用相同的分类。 借鉴现有的组织标准或分类。

准确无误。 虽然关系图是抽象，但不要为不必要的简单性牺牲准确性。 例如，如果通过专用终结点实际访问了子网中的 PaaS 服务，则不要描述该服务。 关系图中的不准确可能导致严重的错误沟通和实现延迟或错误。 停用不再准确回答积极利益干系人问题的图表。

包括元数据。 确保每个关系图都包含提供有关其用途、范围和重要性的基本上下文的元数据。 包括标题、说明、上次更新时间、作者、版本和外部引用等元素。 此信息可帮助查看者了解图表的意图和新鲜度。 首次共享关系图后，维护链接的更改日志有助于返回查看者了解更改的内容。

使用官方图标和服务名称。 表示特定技术时，请始终使用最新的官方图标和命名约定。 不要任意拉伸或重新着色品牌形状。 不要将营销徽标替换为概念元素，例如，使用通用 API 网关 块的供应商徽标。

例如，下面是Microsoft服务的图标：

提供图例。 例如，如果引入边框或线条语义，则实心是异步短划线时的同步调用，请包含一个紧凑图例。

辅助功能设计。 确保有足够的颜色对比度。 避免只依赖颜色来区分类型，而是将颜色与图案一致配对。

层，不重载。 抵制在单个关系图中对每个子系统、数据分类和运行时路径进行编码的冲动。 提供渐进式披露：上下文关系图导致容器关系图，这会导致关键用例的焦点组件或序列图。

版本控制。 将图表源文件存储在与工作负荷的其他版本控制资产相同的存储库或文档存储中。

设计图的类型

工作负荷体系结构非常复杂，且具有多维性。 不同的关系图类型侧重于系统的特定方面，为每个维度提供有针对性的详细信息级别。 例如，流程图演示进程流，而实体关系图显示系统组件之间的关系。

使用不同的关系图类型可以全面了解所有体系结构维度。 此方法有助于在具有不同技术背景和关注的不同利益干系人之间进行有效的沟通、解决问题和决策。 体系结构决策记录引用这些关系图来可视化决策。

以下类型包括常见的云体系结构通信项目以及多个高价值添加项。 图表类型的列表并不详尽。 在实践中，许多项目是混合的或不断发展的。 若要可视化工作负荷，请在创建每种可能的类型时选择最少的有目的关系图。 开始广泛，逐渐缩小，然后应用方案和交叉视图。

上下文关系图

上下文图在其外部环境中将工作负荷显示为单个黑盒。 它命名系统，简要说明其用途，并显示外部角色、上游和下游系统以及与之交互的数据源或接收器。 仅显示高级通信或集成路径;内部结构是故意省略的，因此受众侧重于范围边界和依赖项，而不是实现。 依赖外部系统的通用形状而不是产品徽标，并且始终包含显式边界，以便读者不必推断范围。

高级系统或容器关系图

高级系统关系图大致概述了整个工作负荷或工作负荷中的主要子部分。 它将工作负荷分解为其主要组件、其关系，以及通过系统传递的一般数据流。 箭头指示交互和依赖项的方向。

在上下文对齐后使用此关系图公开宏结构、托管模型（如 PaaS 或自我管理）和外部依赖项。 在深入技术讨论之前，这些关系图非常适合在利益干系人之间建立共识。 它们对于高管和利益干系人沟通也很有价值，在这些沟通中，高级理解比技术细节更重要。

块或功能图

块图使用与技术无关的块将工作负荷分解为主要功能，侧重于所执行的功能，而不是特定组件。

例如，块图可以引用 订单队列 或 消息总线 ，而不是指定特定的消息总线技术，如 Azure 服务总线或 Apache Kafka。 此抽象级别有助于解释系统的结构、数据流和处理流，而不会让受众难以承受实现细节，因此非常适合早期域建模讨论和要求收集。

组件图

组件图通过用特定技术和集成点替换通用功能块来构建块图。 它提供了一个详细视图，用于传达系统的具体技术及其关系，例如客户端-服务器交互。 这些关系图充当体系结构的可视材料清单，准确显示将实施哪些技术。

部署关系图

部署关系图侧重于如何将基础结构、商用现成软件和自定义代码部署到托管环境中。 它显示软件组件与托管它们的物理或虚拟基础结构之间的映射。

这些关系图适用于 DevOps 规划、环境设置以及了解体系结构的作方面。 它们可帮助团队可视化缩放边界、部署单元、基础结构依赖项和环境。

数据流图 （DFD）

数据流图（DFD）说明了数据如何移动、转换、存储和退出系统。 强调源、接收器、转换阶段、分类（公共、机密、管控），以及移动是批处理、流式处理还是准实时移动。 它有助于数据世系分析、治理控件和性能瓶颈识别。

安全威胁建模（如 STRIDE 模型）使用专用 DFD。 该图显示了进程、数据存储、外部实体、信任边界和数据流跨越这些边界。 它侧重于使用协议和加密对流进行批注，并重点介绍需要保护的资产。 此图驱动缓解标识和安全控制验证。

序列图

序列图描述了单个用例或方案的交互的临时顺序。 例如， 用户下订单。 它说明了客户端-服务器关系，并清楚地显示交互是同步的还是异步的。 这些关系图还突出显示了通信模式中的依赖关系，并帮助评估组件交互中的潜在故障方案。 序列图对于 API 设计特别有价值。

用户流或旅程关系图

用户流图显示用户或角色跨接口和服务执行的端到端步骤。 它直观显示用户浏览系统的过程，显示用户及其数据如何与各种组件和进程交互。 这些关系图有助于阐明功能要求、验证用户体验设计并确保在体系结构中正确解决所有用户方案。 对关键流的性能或服务级别预期进行批注。

实体关系图 （ERD）

实体关系图（ERD）表示逻辑或物理数据模型结构：实体（表和集合）、属性、键和基数。 使用逻辑 ERD 进行域对齐和物理 ERD 实现详细信息（索引、分区）。 有时，可以在此关系图中传达诸如分片范围等详细信息。 这些关系图可帮助开发人员在实现开始之前了解数据关系和约束。

网络连接关系图

网络图从网络基础结构的角度说明了工作负荷，其中显示了组件在网络边界之间通信的位置。 这些关系图直观显示网络分段、潜在的网络故障点和关键网络转换，例如 Internet 入口点和出口点。 工作负荷可以受益于具有一个网络关系图，该关系图侧重于东西方流量，另一个网络关系图适用于南北流量。

网络关系图通常扩展了超出初始实现阶段的实用工具。 它们经常在安全审核、合规性评审和事件响应活动中被引用，使它们具有宝贵的长期文档资产。

状态图

状态图是一种专用可视化效果，显示域对象、工作流或子系统的可能状态。 它包括触发状态之间转换的条件或事件。 例如，描述 订单 如何从草稿、提交、审阅、完成到关闭。

状态图有助于突出显示潜在的并发问题、转换处理和补偿事务需求。 这有助于减少生产中意外的状态更改行为的可能性。

流程图和活动图

流程图和活动图使工作负荷中复杂的工作流、决策逻辑和业务流程更加清晰。 它们可用于表示审批流程和条件分支方案，这有助于记录作 Runbook、业务流程自动化和事件响应流。

其他专用关系图

类型 当它添加非重复值时 焦点
可用性和复原能力映射 灾难恢复（DR）规划和服务级别目标（SLO）评审期间 显示冗余、故障转移路径、RPO/RTO 注释。
合规性数据驻留映射 受监管的工作负荷 显示数据位置、复制、分类、保留。
标识和访问流图 安全性和符合性评审 显示身份验证和授权流。 确定令牌颁发的位置、信任边界发生更改的位置，以及发生代理流的位置。

基于规范的关系图

存在多个开放规范，可以基于这些规范。 采用一个是工作负荷团队决策;仅当它添加所需的共享词汇以减少歧义时，才这样做。 如果当前的视觉通信方法已经有效，请避免仅仅为形式添加进程权重。 即使你不采用规范，选择性地借用经过验证的约定（分层、基数表示法、事件标记、图例模式）也会在整个关系图集中提高清晰度和一致性。

关系图和建模规范的示例：

后续步骤

架构师的清单