你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关设计冗余的建议
适用于此 Azure 架构良好的框架可靠性清单建议：
| RE：05 | 在不同级别添加冗余，尤其是对于关键流。 根据确定的可靠性目标，将冗余应用到计算、数据、网络和其他基础结构层。 |
|---|
相关指南：使用可用性区域和区域进行高可用性多区域设计 |
本指南介绍了在不同工作负荷层（优化复原能力）上在整个关键流中添加冗余的建议。 通过将适当的冗余级别应用于计算、数据、网络和其他基础结构层，满足定义的可靠性目标的要求。 应用此冗余，为工作负荷提供强大的可靠基础来构建基础。 在没有基础结构冗余的情况下生成工作负荷时，由于潜在的故障，出现长时间停机 的风险很高。
定义
| 术语 | 定义 |
|---|---|
| 冗余 | 工作负荷组件的多个相同实例的实现。 |
| 多语言持久化 | 通过同一应用程序或解决方案使用不同的存储技术来利用每个组件的最佳功能的概念。 |
| 数据一致性 | 同步或不同步给定数据集的度量值跨多个存储区。 |
| 分区 | 以物理方式将数据划分为单独的数据存储的过程。 |
| 分片 | 支持具有常见架构的多个存储实例的水平数据库分区策略。 数据不会在所有实例中复制。 |
关键设计策略
在可靠性上下文中，使用冗余来包含影响单个资源的问题，并确保这些问题不会影响整个系统的可靠性。 使用你确定的关键流和可靠性目标的信息，做出每个流的冗余所需的明智决策。
例如，可能同时运行多个 Web 服务器节点。 如果存在影响整个池的问题（例如区域性中断）的问题，则他们支持流的严重性可能要求所有流都具有可接受流量的副本。 或者，由于大规模问题很少见，因此部署整个副本集的成本很高，因此，可以部署有限数量的副本，以便在解决问题之前，流以降级状态运行。
在性能效率上下文中设计冗余时，将负载分布到多个冗余节点，以确保每个节点的性能最佳。 在可靠性上下文中，构建备用容量以吸收影响一个或多个节点的故障或故障。 确保备用容量可以吸收恢复受影响节点所需的整个时间的故障。 考虑到这一区别，这两种策略都需要共同努力。 如果流量分散到两个节点的性能，并且它们都以 60% 的利用率运行，并且一个节点发生故障，则剩余节点面临不堪重负的风险，因为它无法以 120% 的速度运行。 将负载分散到另一个节点，以确保保持性能和可靠性目标。
权衡：
- 更多的工作负荷冗余相当于更多的成本。 请仔细考虑添加冗余并定期查看体系结构，以确保管理成本，尤其是在使用过度预配时。 使用过度预配作为复原策略时，请将其与定义完善的 缩放策略 进行平衡，以最大程度地降低成本效率低下。
- 在高度冗余的情况下生成时，可能会有性能权衡。 例如，跨可用性区域或区域分布的资源可能会影响性能，因为必须在冗余资源（如 Web 服务器或数据库实例）之间通过高延迟连接发送流量。
- 同一工作负荷中的不同流可能具有不同的可靠性要求。 特定于流的冗余设计可能会给整体设计带来复杂性。
冗余体系结构设计
设计冗余体系结构时，请考虑两种方法：主动-主动或主动-被动。 根据基础结构组件支持的用户流和系统流的关键性，选择你的方法。 在可靠性方面，多区域主动-主动设计有助于实现可能的最高可靠性级别，但比主动-被动设计要高得多。 决定适当的地理区域将成为下一个关键选择。 还可以使用可用性区域将这些设计方法用于单个区域。 有关详细信息，请参阅 针对高度可用的多区域设计的建议。
部署标记和规模单位
无论是在主动-主动模型还是主动-被动模型中部署，都遵循 部署标记设计模式 ，以确保以可重复、可缩放的方式部署工作负荷。 部署戳是将工作负载传递到给定客户子集所需的资源的分组。 例如，该子集可能是区域子集，也可能是一个与工作负载具有相同数据隐私要求的子集。 将每个标记视为一个 缩放 单元，可以复制该单元来横向缩放工作负荷或执行蓝绿部署。 使用部署标记设计工作负荷，以优化主动-主动或主动-被动实现，实现复原和管理负担。 规划多区域横向扩展对于克服区域中潜在的临时资源容量限制也很重要。
Azure 区域中的可用性区域
无论是部署主动-主动还是主动-被动设计，都利用 活动区域中的可用性区域 来完全优化复原能力。 许多 Azure 区域提供多个可用性区域，这些区域是区域内数据中心的分隔组。 根据 Azure 服务，可以通过跨区域冗余部署工作负荷的元素或将元素固定到特定区域来利用可用性区域。 有关详细信息，请参阅有关使用可用性区域和区域的建议。
为计算资源实现区域冗余
为工作负荷选择适当的 计算服务 。 根据你设计的工作负荷类型，可能有多个可用选项。 研究可用的服务并了解哪些类型的工作负荷最适合给定的计算服务。 例如，SAP 工作负载通常最适合基础结构即服务（IaaS）计算服务。 对于容器化应用程序，请确定需要控制的特定功能，以确定是使用Azure Kubernetes 服务（AKS）还是平台即服务（PaaS）解决方案。 云平台完全管理 PaaS 服务。
如果要求允许，请使用 PaaS 计算选项。 Azure 完全管理 PaaS 服务，从而减轻管理负担，并内置了记录的冗余程度。
如果需要部署虚拟机（VM），请使用 Azure 虚拟机规模集。 使用虚拟机规模集，可以跨可用性区域自动均匀地分散计算。
使计算层 保持任何状态 的干净，因为可能随时删除、出错或替换处理请求的各个节点。
尽可能使用区域冗余服务来提供更高的复原能力，而不会增加运营负担。
过度预配关键资源，以缓解冗余实例的故障，甚至在自动缩放操作开始之前，系统仍可在组件故障后继续运行。 在将过度预配合并到冗余设计中时，计算故障的可接受效果。 与冗余决策过程一样，可靠性目标和财务权衡决策决定了通过过度预配添加备用容量的程度。 过度预配具体是指 横向扩展，这意味着添加给定计算资源类型的额外实例，而不是增加任何单个实例的计算功能。 例如，如果将 VM 从较低层 SKU 更改为较高层 SKU。
在要在其中实现解决方案的每个可用性区域或区域中手动或通过自动化部署 IaaS 服务。 某些 PaaS 服务具有跨可用性区域和区域自动复制的内置功能。
为数据资源实现区域冗余
确定工作负荷功能是否需要同步或异步数据复制。 若要帮助你做出此决定，请参阅 有关使用可用性区域和区域的建议。
考虑数据的增长率。 对于容量规划，请规划数据增长、数据保留和存档，以确保在解决方案中的数据量增加时满足可靠性要求。
根据服务支持，按地理位置分配数据，以最大程度地减少地理本地化故障的影响。
跨地理区域复制数据，以提供区域中断和灾难性故障的复原能力。
在数据库实例失败后自动执行故障转移。 可以在多个 Azure PaaS 数据服务中配置自动故障转移。 支持多区域写入（如 Azure Cosmos DB）的数据存储不需要自动故障转移。 有关详细信息，请参阅有关设计灾难恢复策略的建议。
为数据使用最佳 数据存储 。 采用混合数据存储技术的 polyglot 持久性或解决方案。 数据不仅包括持久化的应用程序数据。 还包括应用程序日志、事件、消息和缓存。
考虑数据一致性要求，并在要求允许时使用 最终一致性 。 分发数据时，请使用适当的协调来强制实施强一致性保证。 协调可以降低吞吐量，使系统紧密耦合，从而使它们更加脆弱。 例如，如果某个操作更新了两个数据库，而不是将其放入单个事务范围，则如果系统能够适应最终一致性，则情况会更好。
为可用性分区数据。 数据库分区 可提高可伸缩性，还可以提高可用性。 如果一个分片出现故障，其他分片仍可访问。 一个分片中的失败只会中断总事务的子集。
如果分片不是选项，则可以使用 命令和查询责任分离（CQRS）模式 来分隔读写和只读数据模型。 添加更多冗余只读数据库实例以提供更多的复原能力。
了解所使用的有状态平台服务的内置复制和冗余功能。 有关有状态数据服务的特定冗余功能，请参阅 相关链接。
为网络资源实现区域冗余
确定可靠且可缩放的网络拓扑。 使用中心辐射型模型或 Azure 虚拟 WAN 模型帮助你以逻辑模式组织云基础结构，使冗余设计更易于生成和缩放。
选择适当的 网络服务 ，以平衡和重定向区域内或跨区域的请求。 尽可能使用全局或区域冗余负载均衡服务来满足可靠性目标。
确保已在虚拟网络和子网中分配足够的 IP 地址空间来考虑计划的使用情况，包括横向扩展要求。
确保应用程序可以在所选应用程序托管平台的端口限制内进行缩放。 如果应用程序启动多个出站 TCP 或 UDP 连接，则可能会耗尽所有可用端口并导致应用程序性能不佳。
选择 SKU 并配置可满足带宽和可用性要求的网络服务。 VPN 网关的吞吐量因 SKU 而异。 对区域冗余的支持仅适用于某些负载均衡器 SKU。
确保用于处理 DNS 的设计以复原能力为重点，并支持冗余基础结构。
Azure 便利化
Azure 平台可帮助你优化工作负荷的复原能力，并通过以下方式添加冗余：
通过许多 PaaS 和软件即服务（SaaS）解决方案提供内置冗余，其中一些解决方案是可配置的。
允许使用 可用性区域 和区域间冗余来设计和实现区域内部冗余。
提供副本感知负载均衡服务，例如 Azure 应用程序网关、Azure Front Door 和 Azure 负载均衡器。
提供轻松实现的异地复制解决方案，例如用于Azure SQL 数据库的活动异地复制。 使用 Azure Cosmos DB 实现 全局分发 和透明复制。 Azure Cosmos DB 提供两个选项来处理 冲突写入。 为工作负荷选择最佳选项。
为许多 PaaS 数据服务提供时间点还原功能。
通过 Azure NAT 网关或Azure 防火墙缓解端口耗尽。
特定于 DNS 的 Azure 便利化
对于内部名称解析方案，请使用具有内置区域冗余和异地冗余的 Azure DNS 专用区域。 有关详细信息，请参阅 Azure DNS 专用区域复原能力。
对于外部名称解析方案，请使用具有内置区域冗余和异地冗余的 Azure DNS 公共区域。
公共和专用 Azure DNS 服务是可复原区域中断的全局服务，因为区域数据在全球可用。
对于本地和云环境之间的混合名称解析方案，请使用 Azure DNS 专用解析程序。 如果工作负荷位于支持可用性区域的区域中，则此服务支持区域冗余。 区域范围的服务中断在区域恢复期间无需执行任何操作。 该服务会自动自我愈合和重新平衡，以利用健康区域。 有关详细信息，请参阅 Azure DNS 专用解析程序中的复原能力。
若要消除单一故障点并跨区域实现更具弹性的混合名称解析，请跨不同区域部署两个或多个 Azure DNS 专用解析程序。 在条件转发方案中，DNS 故障转移是通过将解析程序分配为主 DNS 服务器来实现的。 将其他区域中的其他解析程序分配为辅助 DNS 服务器。 有关详细信息，请参阅 使用专用解析程序设置 DNS 故障转移。
示例
有关多区域冗余部署的示例，请参阅 基线高度可用的区域冗余 Web 应用程序。
下图显示了另一个示例：
相关链接
若要了解有关冗余的详细信息，请参阅以下资源：
可靠性清单
请参阅完整的建议集。