你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于此 Azure Well-Architected 框架可靠性清单建议：
| RE：05 | 在不同级别（尤其是关键流）添加冗余，以帮助实现可靠性目标。 考虑冗余基础结构组件，例如计算和网络，以及解决方案的多个实例。 |
|---|
本指南介绍了在不同工作负荷层（优化复原能力）上在整个关键流中添加冗余的建议。 通过将适当的冗余级别应用于计算、数据、网络和其他基础结构层，满足定义的可靠性目标的要求。 应用此冗余，为工作负荷提供强大的可靠基础来构建基础。 在没有基础结构冗余的情况下生成工作负荷时，由于 潜在的故障，导致长时间停机的风险很高。
定义
| 术语 | Definition |
|---|---|
| 冗余 | 工作负荷组件的多个相同实例的实现。 |
| 区域 | Azure 数据中心位置。 |
| Polyglot 持久性 | 通过同一应用程序或解决方案使用不同的存储技术来利用每个组件的最佳功能的概念。 |
| 数据一致性 | 同步或不同步给定数据集的度量值跨多个存储区。 |
| Partitioning | 以物理方式将数据划分为单独的数据存储的过程。 |
| 碎片 | 支持具有常见架构的多个存储实例的水平数据库分区策略。 数据不会在所有实例中复制。 |
在可靠性上下文中，使用冗余来包含影响单个资源的问题，并确保这些问题不会影响整个系统的可靠性。 使用你确定的关键流和可靠性目标的信息，做出每个流的冗余所需的明智决策。
例如，你可能有多个一次性运行的 Web 服务器节点。 如果它们支持的流至关重要，则所有节点可能需要副本，如果问题影响整个池，例如整个数据中心中断，则可能需要立即接受流量的副本。 或者，由于大规模问题很少见，因此部署整个副本集的成本很高，因此可以部署有限数量的副本，以便流在解决问题之前以降级状态运行。
在性能效率上下文中设计冗余时，将负载分布到多个冗余节点，以确保每个节点的性能最佳。 在可靠性上下文中，构建备用容量以吸收影响一个或多个节点的故障或故障。 确保备用容量可以吸收恢复受影响节点所需的整个时间的故障。 考虑到这一区别，这两种策略都需要共同努力。 如果将流量分散到两个节点的性能，并且它们都以 60% 利用率运行，并且一个节点发生故障，则剩余节点面临不堪重负的风险，因为它无法在 120%运行。 将负载分散到另一个节点，以确保保持性能和可靠性目标。
权衡：
更多的工作负荷冗余相当于更多的成本。 请仔细考虑添加冗余并定期查看体系结构，以确保管理成本，尤其是在使用过度预配时。 使用过度预配作为复原策略时，请将其与定义完善的 缩放策略 进行平衡，以最大程度地降低成本效率低下。
在高度冗余的情况下生成时，可能会进行性能权衡。 例如，跨可用性区域或位置分布的资源可能会影响性能，因为必须在冗余资源（如 Web 服务器或数据库实例）之间通过高延迟连接发送流量。
同一工作负荷中的不同流可能具有不同的可靠性要求。 特定于流的冗余设计可能会给整体设计带来复杂性。
低延迟冗余设计意味着在发生大规模事件（如地理灾难）时，你接受丢失这些组件的风险，使所有实例都脱机。 异地远程灾难恢复（DR）环境有助于缓解此风险，但会增加成本。
首选无服务器和完全托管服务，以减少运营负担
利用 无服务器、软件即服务（SaaS）和平台即服务（PaaS）解决方案，轻松将冗余添加到工作负荷，而无需管理数据复制或故障转移作。 这些服务以透明方式实现冗余，从而消除了设计和维护自己的冗余机制的作负担。 评估服务选项时，优先使用需要手动冗余配置的基于基础结构的方法自动处理冗余的托管服务。
Azure 托管服务通过不同的模型提供冗余。 每个模型提供不同级别的抽象和作简单性。
具有内置冗余的全局服务： Microsoft Entra ID、Azure DNS 和 Azure Key Vault 等服务充当跨多个区域的自动冗余的全局服务。 这些服务提供固有的复原能力，无需你进行任何冗余配置。 它们以透明方式自动处理故障转移和恢复方案。
抽象容量模型： Azure Cosmos DB、Azure Databricks 和 Azure OpenAI 托管终结点等产品/服务抽象化容量单位、DTU 或其他逻辑指标背后的底层基础结构复杂性。 这些服务会在多个实例、区域和区域之间自动分配工作负荷，同时提供简化的计费和管理模型。 指定容量要求，而不是管理单个冗余实例。
构建解决方案时，请在实现基于基础结构的冗余之前评估每个组件的托管服务选项是否存在。 托管服务可减少运营开销，并且通常提供比自定义解决方案更可靠的冗余实现，尽管它们可能涉及控制方面的权衡，并且每个容量单元的成本可能更高。
使用多个组件实例在工作负荷中生成冗余
部署基础结构组件和服务的多个实例，以实现工作负荷所需的复原能力。 此基本冗余策略可确保如果一个实例发生故障，其他实例可以继续处理工作负荷。 可以通过不同的方法实现多个实例。 某些方案要求通过单独部署多个资源（例如多个 Azure ExpressRoute 线路或在多个区域中配置 Azure 流量管理器）来手动配置冗余。 其他服务旨在直接支持多个实例，例如将 Azure 虚拟机规模集设置为 5 个实例，或将 Azure 应用服务配置为运行 10 个实例。 如果可能，首选为多个实例和自动缩放功能提供内置支持的服务，因为它们简化了冗余管理，并且可以响应可靠性和性能需求。
部署冗余基础结构组件时，确定每个组件实例满足可靠性目标的数量。 考虑是需要所有组件的多个实例还是只需要特定关键组件的多个实例，并确定这些实例的地理分布以满足复原能力要求。 部署冗余基础结构时，请考虑以下建议。
计算资源：
首选支持内置冗余的服务。 这些服务允许你指定所需的实例数，并可能为你处理这些实例的分发和管理。
使计算层 保持任何状态的干净 ，因为可能随时删除、出错或替换处理请求的各个节点。
设计和测试缩放策略以匹配冗余方法。
数据资源：
跨地理区域复制数据，以提供区域中断和灾难性故障的复原能力。
了解所使用的 有状态平台服务的内置复制和冗余功能 。
确定工作负荷功能是否需要同步或异步数据复制。 有关详细信息，请参阅 有关使用可用性区域和区域的建议。
根据服务支持，按地理位置分配数据，以最大程度地减少地理本地化故障的影响。
在数据库实例失败后自动执行故障转移。 可以在多个 Azure PaaS 数据服务中配置自动故障转移。 支持多区域写入（如 Azure Cosmos DB）的数据存储不需要自动故障转移。 有关详细信息，请参阅 有关设计 DR 策略的建议。
为数据使用最佳 数据存储 。 采用使用数据存储技术组合的多面体持久性或解决方案。 数据不仅包括持久化的应用程序数据。 它还包括应用程序日志、事件、消息和缓存。
考虑数据一致性要求，并在要求允许时使用 最终一致性 。 分发数据时，请使用适当的协调来强制实施强一致性保证。 协调可以降低吞吐量，使系统紧密耦合，从而使它们更弱。 例如，如果某个作更新了两个数据库，而不是将其放入单个事务范围，则如果系统能够适应最终一致性，则情况会更好。
为可用性分区数据。 数据库分区 可提高可伸缩性，还可以提高可用性。 如果一个分片出现故障，其他分片仍可访问。 一个分片中的失败只会中断总事务的子集。
如果分片不是选项，则可以使用 命令查询责任分离（CQRS）模式 来分隔读写和只读数据模型。 添加更多冗余只读数据库实例以提供更多的复原能力。
网络资源：
确定可靠且可缩放的网络拓扑。 使用中心辐射型模型或 Azure 虚拟 WAN 模型来帮助将云基础结构组织成逻辑模式，使冗余设计更易于生成和缩放。
选择适当的 网络服务 ，以平衡和重定向区域内或跨区域的请求。 尽可能使用全局或区域冗余负载均衡服务来满足可靠性目标。
确保已在虚拟网络和子网中分配足够的 IP 地址空间来考虑计划的使用情况，包括横向扩展要求。
确保应用程序可以在所选应用程序托管平台的端口限制内进行缩放。 如果应用程序启动多个出站传输控制协议（TCP）或用户数据报协议（UDP）连接，则可能耗尽所有可用端口并导致应用程序性能不佳。
选择 SKU 并配置可满足带宽和可用性要求的网络服务。 VPN 网关的吞吐量因 SKU 而异。 对区域冗余的支持仅适用于某些负载均衡器 SKU。
确保用于处理域名系统（DNS）的设计以复原能力为重点构建，并支持冗余基础结构。
使用部署标记模式简化冗余方法
除了单个基础结构组件和服务冗余之外，通过部署整个工作负荷或资源逻辑组的多个实例，将冗余策略扩展到工作负荷级别。 按照 部署戳记设计模式 创建可重复的自包含单元，其中包括将工作负荷传送到特定用户或要求子集所需的所有资源。
部署标记表示从组件级别到工作负荷级冗余的转变。 每个标记都作为一个包含所有必要资源（计算、存储、网络和依赖项）的完整规模单元，可以独立运行。 此方法提供关键优势，包括包含爆炸半径的隔离故障域、通过附加模具部署进行水平缩放，而不是单个组件缩放、按地理位置或要求灵活分段，以及通过相同的可重复单位简化作。
无论是在主动-主动模型中部署图章（其中所有邮票同时主动为流量提供服务）还是主动-被动模型（其中一个图章为流量提供服务，而其他标记处于备用状态），都将每个模具设计为可以独立处理其指定工作负荷的完整自足部署。
通过主动-主动冗余实现零停机时间
主动-主动部署通过同时运行工作负荷的多个实例来最大化服务可用性，每个实例都主动处理流量。 此设置可确保即时故障转移、消除停机时间，并通过保持所有实例的工作效率来优化资源使用。 如果一个实例失败，流量会自动重新路由到正常运行的实例，而不会中断服务。
例如，在旺季，电子商务平台可以保持无缝运营，即使一个部署遇到问题。 主动-主动配置非常适合需要不间断可用性的任务关键型工作负荷，但它们具有更高的基础结构成本和复杂性。 需要高级作策略来管理多个实时环境，确保数据一致性，并跨所有实例协调更新。
以下部分介绍主动-主动部署的配置选项。
容量主动-主动： 两个或更多位置中的镜像部署标记，每个标记都配置为处理它们服务的位置或位置的生产工作负荷，并且可以缩放，以便在发生区域性中断时处理来自其他位置的负载。
主动-主动过度预配： 两个或更多位置中的镜像部署标记，每个标记都过度预配，用于处理其服务的位置或位置的生产工作负荷，并在发生区域性中断时处理来自其他位置的负载。
这两种设计的常见优势： 完全工作负荷中断的高复原能力和低风险。
这两种设计的常见缺点： 由于各种因素，运营成本和管理负担较高，包括管理应用程序状态和数据同步的必要性。
使用主动-被动体系结构设计提供 DR 复原能力
主动-被动部署配置提供经济高效的方法，通过运行主实例来确保 DR，该主实例处理所有流量，同时使辅助实例保持空闲但已就绪。 仅当主实例发生故障或正在进行维护时，才会激活这些备用实例。 此方法可最大程度地减少资源使用情况，同时提供可靠的故障转移功能。
例如，金融交易平台可以使用此设置来保持服务连续性。 主系统管理所有事务，而辅助系统在后台保持同步。 如果主系统出现故障，辅助系统会快速接管和还原作，且中断最少。 此方法平衡可靠性和成本，这使得它非常适合可以容忍短暂的恢复时间的工作负荷，而无需主动-主动部署的复杂性或费用。
请考虑以下主动-被动部署的配置选项。
暖备用： 一个主要位置和一个或多个辅助位置。 辅助位置部署时，可以最少的计算和数据大小调整，且无需加载即可运行。 此位置称为 暖备用 位置。 故障转移后，将缩放计算和数据资源，以处理主要位置的负载。
联网： 使用 优先级 全局路由。
数据复制和一致性： 将数据库复制到被动位置，并使用 PaaS 解决方案（如 Azure Cosmos DB 和 Azure SQL 数据库）的自动故障转移功能。
此设计的优点： 主动-被动设计中的最短恢复时间。
此设计的缺点： 主动-被动设计中的运营成本最高。
冷备用： 一个主要位置和一个或多个辅助位置。 辅助位置进行缩放以处理完整负载，但所有计算资源都会停止。 此位置称为 冷备用 位置。 需要在故障转移之前启动资源。
联网： 使用 优先级 全局路由。
数据复制和一致性： 将数据库复制到被动位置，并使用 PaaS 解决方案（例如 Azure Cosmos DB 和 SQL 数据库）的自动故障转移功能。
此设计的优点： 比暖备用设计更低的运营成本。
此设计的缺点： 恢复时间比暖备用设计更长。
跨代理独立基础结构分配工作负荷
在附近的独立数据中心或数据中心扇区部署工作负荷可提供冗余，而不会影响性能。 通过使用地理上接近但物理上独立的设施，此设置可确保故障隔离，且延迟影响最小。 它提供分布式基础结构的复原能力，同时保持单站点部署的响应能力。 在 Azure 中，可用性区域提供此功能。 可用性区域是物理上独立的数据中心或数据中心扇区，旨在让你轻松部署容错、低延迟的工作负荷。
对于延迟敏感的应用程序（如实时游戏），此方法可实现无缝故障转移和不间断的用户体验。 跨本地数据中心分发的游戏服务器可以在中断期间立即重新路由流量，实现透明负载均衡和准实时数据复制，从而保持游戏连续性。 但是，此策略确实存在一些风险，因为大规模区域事件仍可同时影响所有站点。
通过异地远程部署加强容错
跨地理分布的数据中心进行部署，通过跨区域分布数百或数千英里的工作负荷，可以最强地保护大规模灾难。 此方法可确保在自然灾害、基础结构故障或可能影响整个大都市地区的地缘政治中断等事件期间保持业务连续性。 在 Azure 中，可以将工作负荷部署到分布在全球的区域。 使用此设计方法时，请选择靠近用户但地理上很遥远的区域，例如美国西部和美国东部。
例如，如果一个区域遇到重大中断，则全球金融平台可以通过将流量路由到不受影响的区域来维护不间断的服务。 此方法可最大程度地提高复原能力，并支持跨司法管辖区的法规遵从性，但它引入了更高的延迟、复杂的数据一致性要求和更高的作开销。 必须根据全球冗余的好处仔细权衡这些因素。
Azure 便利化
Azure 平台通过执行以下作来帮助优化工作负荷的复原能力并添加冗余：
使用 “选择 Azure 区域”指南，帮助你为多区域体系结构选择最佳 Azure 区域。
提供具有许多 PaaS 和 SaaS 解决方案的内置冗余，其中一些解决方案是可配置的。
提供全局托管服务，例如Microsoft Entra ID、Azure DNS 和 Key Vault，以透明方式实现冗余，而无需配置。
允许使用 可用性区域 和区域间冗余来设计和实现区域内部冗余。
提供区域冗余计算解决方案，例如 虚拟机规模集，在部署虚拟机（VM）时，这些解决方案可以跨可用性区域自动分散计算。
提供副本感知负载均衡服务，例如 Azure 应用程序网关、 Azure Front Door 和 Azure 负载均衡器。
提供轻松实现的异地复制解决方案，例如 SQL 数据库的 活动异地复制 。 使用 Azure Cosmos DB 实现 全局分发 和透明复制。 Azure Cosmos DB 提供两个选项来处理 冲突写入。 为工作负荷选择最佳选项。
为许多 PaaS 数据服务提供时间点还原（PITR）功能。
通过 Azure NAT 网关 或 Azure 防火墙缓解端口耗尽。
特定于 DNS 的 Azure 便利化
对于内部名称解析方案，请使用具有内置区域冗余和异地冗余的 Azure DNS 专用区域。 有关详细信息，请参阅 Azure DNS 专用区域复原能力。
对于外部名称解析方案，请使用具有内置区域冗余和异地冗余的 Azure DNS 公共区域。
公共和专用 Azure DNS 服务是可复原区域中断的全局服务，因为区域数据在全球可用。
对于本地和云环境之间的混合名称解析方案，请使用 Azure DNS 专用解析程序。 如果工作负荷位于支持可用性区域的区域中，则此服务支持区域冗余。 区域范围的服务中断在区域恢复期间无需执行任何作。 该服务会自动自我愈合和重新平衡，以利用健康区域。 有关详细信息，请参阅 Azure DNS 专用解析程序中的复原能力。
若要消除单一故障点并跨区域实现更具弹性的混合名称解析，请跨不同区域部署两个或多个 Azure DNS 专用解析程序。 在条件转发方案中，DNS 故障转移是通过将解析程序分配为主 DNS 服务器来实现的。 将其他区域中的其他解析程序分配为辅助 DNS 服务器。 有关详细信息，请参阅 使用专用解析程序设置 DNS 故障转移。
Example
有关多区域冗余部署的示例，请参阅 基线高度可用的区域冗余 Web 应用程序。
下图显示了另一个示例。
相关链接
若要了解有关冗余的详细信息，请参阅以下资源：
可靠性清单
请参阅完整的建议集。