你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上任务关键工作负载的应用程序平台注意事项
Azure 提供了许多用于托管高可用性应用程序的计算服务。 服务在功能和复杂性方面有所不同。 建议根据以下条件选择服务：
- 可靠性、可用性、性能和安全性的非功能要求。
- 可伸缩性、成本、可操作性和复杂性等决策因素。
选择应用程序托管平台是影响所有其他设计领域的关键决策。 例如，旧版或专有开发软件可能无法在 PaaS 服务或容器化应用程序中运行。 此限制会影响你选择的计算平台。
任务关键型应用程序可以使用多个计算服务来支持多个复合工作负载和微服务，每个工作负荷和微服务都有不同的要求。
此设计区域提供与计算选择、设计和配置选项相关的建议。 我们还建议熟悉 计算决策树。
平台资源的全局分布
任务关键型工作负荷的典型模式包括全局资源和区域资源。
不受特定 Azure 区域约束的 Azure 服务部署或配置为全局资源。 一些用例包括跨多个区域分布流量、存储整个应用程序的永久状态以及缓存全局静态数据。 如果需要同时 适应缩放单元体系结构 和全球 分布，请考虑如何在 Azure 区域中以最佳方式分配或复制资源。
其他资源是区域性部署的。 这些资源部署为部署标记的一部分，通常对应于缩放单元。 但是，一个区域可以有多个图章，一个标记可以有多个单位。 区域资源的可靠性至关重要，因为它们负责运行主工作负荷。
下图显示了高级设计。 用户通过中心全局入口点访问应用程序，然后将请求重定向到合适的区域部署标记：
任务关键型设计方法需要多区域部署。 此模型可确保区域容错，以便即使整个区域出现故障，应用程序也仍然可用。 设计多区域应用程序时，请考虑不同的部署策略，例如主动/主动和主动/被动，以及应用程序要求，因为每种方法都有重大权衡。 对于任务关键型工作负荷，强烈建议使用主动/主动模型。
并非每个工作负荷都支持或要求同时运行多个区域。 应权衡特定的应用程序要求，以权衡利弊，以确定最佳设计决策。 对于可靠性较低的某些应用程序方案，主动/被动或分片可以是合适的替代方法。
可用性区域 可以在区域内的不同数据中心提供高度可用的区域部署。 几乎所有的 Azure 服务都可用于区域配置，其中服务委托给特定区域，或区域冗余配置，其中平台会自动确保服务跨区域且能够承受区域中断。 这些配置提供高达数据中心级别的容错能力。
设计注意事项
区域和区域功能。 并非所有服务和功能都可在每个 Azure 区域中使用。 此注意事项可能会影响所选区域。 此外， 可用性区域 在每个区域中都不可用。
区域对。 Azure 区域分组为 区域对 ，由单个地理位置中的两个区域组成。 某些 Azure 服务使用配对区域来确保业务连续性，并提供防止数据丢失的级别。 例如，Azure 异地冗余存储（GRS）会自动将数据复制到次要配对区域，确保在主要区域不可恢复时数据持久。 如果中断影响多个 Azure 区域，则每个对中至少有一个区域优先进行恢复。
数据一致性。 对于一致性挑战，请考虑使用全局分布式数据存储、标记的区域体系结构和部分活动/主动部署。 在部分部署中，某些组件在所有区域中处于活动状态，而其他组件则位于主要区域中。
安全部署。 Azure 安全部署实践（SDP）框架可确保 Azure 平台的所有代码和配置更改（计划内维护）都经过分阶段推出。 分析运行状况，以便在发布期间降级。 在 Canary 和试点阶段成功完成后，平台更新跨区域对进行序列化，因此每个对中的一个区域在给定时间只更新一个区域。
平台容量。 与任何云提供商一样，Azure 具有有限的资源。 不可用可能是区域容量限制的结果。 如果发生区域性服务中断，则随着工作负荷尝试在配对区域中恢复，资源需求增加。 中断可能会导致容量问题，其中供应暂时无法满足需求。
设计建议
在至少两个 Azure 区域中部署解决方案，以帮助防止区域性中断。 在具有工作负荷所需的功能和特征的区域部署它。 这些功能应满足性能和可用性目标，同时满足数据驻留和保留要求。
例如，某些数据符合性要求可能会限制可用区域的数量，并可能强制设计泄露。 在这种情况下，强烈建议在操作包装器中添加额外的投资来预测、检测和响应故障。 假设你受限于具有两个区域的地理位置，并且其中只有一个区域支持可用性区域（3 + 1 数据中心模型）。 使用容错域隔离创建辅助部署模式，以允许这两个区域部署在活动配置中，并确保主要区域包含多个部署标记。
如果合适的 Azure 区域并非所有区域都提供所需的功能，请准备好在区域部署标记的一致性上妥协，以确定地理分布的优先级并最大程度地提高可靠性。 如果只有一个 Azure 区域适用，请在所选区域中部署多个部署标记（区域缩放单元），以缓解某些风险，并使用可用性区域提供数据中心级容错。 但是，地理分布中的这种重大妥协极大地制约了可实现的复合 SLO 和整体可靠性。
重要
对于面向大于或等于 99.99 的 SLO 的方案，建议至少三个部署区域。 计算所有用户流的复合 SLO。 确保这些目标与业务目标保持一致。
对于具有大量流量的大规模应用程序方案，请设计解决方案以跨多个区域进行缩放，以在单个区域中导航潜在的容量约束。 其他区域部署标记可以实现更高的复合 SLO。 有关详细信息，请参阅如何 实现多区域目标。
定义并验证恢复点目标（RPO）和恢复时间目标（RTO）。
在单个地理位置中，优先使用区域对，以便从 SDP 序列化的推出中受益，以便计划内维护和区域优先顺序进行计划外维护。
地理上将 Azure 资源与用户并置，以最大程度地降低网络延迟并最大化端到端性能。
选择部署区域时，将当前服务可用性与产品路线图保持一致。 某些服务可能不会在每个区域中立即可用。
容器化
容器包括应用程序代码以及应用程序需要运行的相关配置文件、库和依赖项。 容器化为应用程序代码及其依赖项提供抽象层，并创建与基础托管平台的分离。 单个软件包高度可移植，可跨各种基础结构平台和云提供商一致运行。 开发人员不需要重写代码，并且可以更快、更可靠地部署应用程序。
重要
建议对任务关键型应用程序包使用容器。 它们提高了基础结构利用率，因为可以在同一虚拟化基础结构上托管多个容器。 此外，由于所有软件都包含在容器中，因此无论运行时或库版本如何，都可以跨各种操作系统移动应用程序。 使用容器管理也比传统虚拟化托管更轻松。
任务关键型应用程序需要快速缩放，以避免性能瓶颈。 由于容器映像是预构建的，因此只能在启动应用程序期间进行，从而提供快速的可伸缩性。
设计注意事项
监视。 监视服务访问容器中的应用程序可能很困难。 通常需要第三方软件来收集和存储容器状态指示器，例如 CPU 或 RAM 使用情况。
安全性。 托管平台 OS 内核跨多个容器共享，从而创建一个攻击点。 但是，主机虚拟机（VM）访问的风险有限，因为容器与基础操作系统隔离。
状态。 尽管可以将数据存储在正在运行的容器的文件系统中，但在重新创建容器时，数据不会保留。 而是通过装载外部存储或使用外部数据库来保留数据。
设计建议
容器化所有应用程序组件。 使用容器映像作为应用程序部署包的主模型。
尽可能确定基于 Linux 的容器运行时的优先级。 映像更轻量，Linux 节点/容器的新功能经常发布。
使容器不可变且可替换，生命周期较短。
请务必从容器、容器主机和基础群集收集所有相关日志和指标。 将收集的日志和指标发送到统一的数据接收器，以便进一步处理和分析。
将容器映像存储在Azure 容器注册表中。 使用 异地复制 跨所有区域复制容器映像。 为容器注册表启用 Microsoft Defender，为容器映像提供漏洞扫描。 请确保对注册表的访问由 Microsoft Entra ID 管理。
容器托管和业务流程
多个 Azure 应用程序平台可以有效地托管容器。 每个平台都有优点和缺点。 比较业务需求上下文中的选项。 但是，始终优化可靠性、可伸缩性和性能。 有关详细信息，请参阅以下文章：
重要
Azure Kubernetes 服务（AKS）和 Azure 容器应用应是容器管理的第一个选择之一，具体取决于你的要求。 尽管Azure App 服务不是协调程序，但作为低摩擦容器平台，它仍然是 AKS 的可行替代方法。
Azure Kubernetes 服务的设计注意事项和建议
AKS（托管 Kubernetes 服务）支持快速群集预配，而无需复杂的群集管理活动，并提供一个功能集，其中包括高级网络和标识功能。 有关一组完整的建议，请参阅 Azure 架构良好的框架评审 - AKS。
重要
在重新部署 AKS 群集的情况下，无法更改一些基本配置决策。 示例包括选择公共和专用 AKS 群集、启用 Azure 网络策略、Microsoft Entra 集成以及对 AKS 而不是服务主体使用托管标识。
可靠性
AKS 管理本机 Kubernetes 控制平面。 如果控制平面不可用，则工作负荷将经历停机。 利用 AKS 提供的可靠性功能：
将 AKS 群集作为缩放单元部署到不同的 Azure 区域 ，以最大限度地提高可靠性和可用性。 使用 可用性区域 通过跨物理独立数据中心分配 AKS 控制平面和代理节点，以最大程度地提高 Azure 区域中的复原能力。 但是，如果共置延迟是个问题，则可以在单个区域中执行 AKS 部署，或使用 邻近放置组 将节点间延迟降到最低。
使用生产群集的 AKS 运行时间 SLA 来最大化 Kubernetes API 终结点可用性保证。
伸缩性
考虑 AKS 缩放限制，例如每个群集的节点数、每个群集的节点池数和每个订阅的群集数。
如果规模限制是约束，请利用 缩放单元策略，并使用群集部署更多单元。
启用群集自动缩放程序以自动调整代理节点数以响应资源约束。
使用水平 Pod 自动缩放程序根据 CPU 利用率或其他指标调整部署中的 Pod 数。
对于大规模和突发方案，请考虑使用 虚拟节点 进行广泛和快速缩放。
在应用程序部署清单中定义 Pod 资源请求和限制 。 如果没有，可能会遇到性能问题。
隔离
维护工作负载和系统工具使用的基础结构之间的边界。 共享基础结构可能会导致高资源利用率和干扰性邻居方案。
对系统和工作负荷服务使用单独的节点池。 工作负荷组件的专用节点池应基于专用基础结构资源（如高内存 GPU VM）的要求。 一般情况下，若要减少不必要的管理开销，请避免部署大量节点池。
使用 排斥和容忍 提供专用节点并限制资源密集型应用程序。
评估应用程序相关性和反关联要求，并在节点上配置容器的相应并置。
安全性
默认 vanilla Kubernetes 需要大量配置，以确保为任务关键型方案提供合适的安全态势。 AKS 可以解决各种现装的安全风险。 功能包括专用群集、审核和登录到 Log Analytics、强化节点映像和托管标识。
应用 AKS 安全基线中提供的配置指南。
使用 AKS 功能来处理群集标识和访问管理，以减少操作开销并应用一致的访问管理。
使用托管标识而不是服务主体来避免凭据的管理和轮换。 可以在群集级别添加 托管标识 。 在 Pod 级别，可以通过 Microsoft Entra 工作负荷 ID 使用托管标识。
使用 Microsoft Entra 集成 进行集中式帐户管理和密码、应用程序访问管理和增强标识保护。 将 Kubernetes RBAC 与 Microsoft Entra ID 用于 最低特权，并最大程度地减少授予管理员权限以帮助保护配置和机密访问。 此外，使用 Azure 基于角色的 访问控制来限制对 Kubernetes 群集配置文件 的访问。 限制对容器可以执行的操作的访问权限，提供最少的权限，并避免使用根权限升级。
升级
需要定期升级群集和节点。 AKS 支持 Kubernetes 版本 与本机 Kubernetes 的发布周期一致。
订阅 GitHub 上的公共 AKS 路线图 和 发行说明 ，以随时了解即将进行的更改、改进，最重要的是 Kubernetes 版本发布和弃用。
应用 AKS 清单中提供的指南，以确保与最佳做法保持一致。
请注意 AKS 支持 用于更新节点和/或群集的各种方法。 这些方法可以手动或自动化。 可以使用 计划内维护 来定义这些操作的维护时段。 每周发布新映像。 AKS 还支持 自动升级通道 ，以便在 AKS 群集可用时自动将 AKS 群集升级到较新版本的 Kubernetes 和/或更新节点映像。
网络
评估最适合你的用例的网络插件。 确定是否需要对 Pod 之间的流量进行精细控制。 Azure 支持 kubenet、 Azure CNI，并为特定用例自带 CNI。
评估网络要求和群集大小后，确定 Azure CNI 的使用优先级。 Azure CNI 允许使用 Azure 或 Calico 网络策略来控制群集内的流量。
监视
监视工具应能够捕获正在运行的 Pod 中的日志和指标。 还应从 Kubernetes 指标 API 收集信息，以监视正在运行的资源和工作负荷的运行状况。
使用 Azure Monitor 和 Application Insights 从 AKS 资源收集指标、日志和诊断，以便进行故障排除。
启用和查看 Kubernetes 资源日志。
在 Azure Monitor 中配置 Prometheus 指标 。 Monitor 中的容器见解提供载入功能，支持现成的监视功能，并通过内置 Prometheus 支持启用更高级的功能。
治理
使用策略以一致的方式将集中式安全措施应用于 AKS 群集。 在订阅范围或更高范围内应用策略分配，以推动开发团队之间的一致性。
使用 Azure Policy 控制向 Pod 授予哪些函数以及是否运行与策略相矛盾。 此访问权限是通过 AKS 的 Azure Policy 加载项提供的内置策略定义的。
使用 Azure Policy 为 AKS 群集和 Pod 配置建立一致的可靠性和安全基线。
使用 AKS 的 Azure Policy 加载项控制 Pod 函数（如根特权）以及禁止不符合策略的 Pod。
Azure App 服务的设计注意事项和建议
对于基于 Web 和 API 的工作负荷方案，App 服务可能是 AKS 的可行替代方法。 它提供低摩擦容器平台，无需 Kubernetes 的复杂性。 有关一组完整的建议，请参阅App 服务App 服务和卓越运营的可靠性注意事项。
可靠性
评估 TCP 和 SNAT 端口的使用情况。 TCP 连接用于所有出站连接。 SNAT 端口用于到公共 IP 地址的出站连接。 SNAT 端口耗尽是常见的故障方案。 在使用Azure 诊断监视端口时，应通过负载测试来预测地检测此问题。 如果发生 SNAT 错误，则需要跨更多或更大的辅助角色进行缩放，或者实现编码做法，以帮助保留和重复使用 SNAT 端口。 可以使用的编码做法示例包括连接池和资源的延迟加载。
TCP 端口耗尽是另一种故障方案。 当给定辅助角色的出站连接之和超过容量时，会发生此情况。 可用的 TCP 端口数取决于工作器的大小。 有关建议，请参阅 TCP 和 SNAT 端口。
伸缩性
规划未来的可伸缩性要求和应用程序增长，以便从一开始就应用适当的建议。 这样做可以避免随着解决方案的增长而发生技术迁移债务。
启用自动缩放以确保有足够的资源可用于服务请求。 评估App 服务上的高密度托管的按应用缩放。
请注意，App 服务每个App 服务计划的实例的默认软限制。
应用自动缩放规则。 如果满足配置文件中的任何规则，则App 服务计划横向扩展，但仅当满足配置文件中的所有规则时才会缩小。 使用横向扩展和横向缩减规则组合来确保自动缩放可以同时执行横向扩展和缩减操作。 了解单个配置文件中多个缩放规则的行为。
请注意，可以在App 服务计划级别启用按应用缩放，以允许应用程序独立于托管它的App 服务计划进行缩放。 应用通过针对偶数分发的最佳方法分配给可用节点。 尽管不保证偶数分布，但平台可确保同一应用的两个实例不在同一实例上托管。
监视
监视应用程序行为并获取对相关日志和指标的访问权限，以确保应用程序按预期工作。
可以使用诊断日志记录通过 Azure 事件中心 将应用程序级日志和平台级日志引入 Log Analytics、Azure 存储 或第三方工具。
使用 Application Insights 对应用程序性能进行应用程序性能监视提供了深入的见解。
如果发生故障，任务关键型应用程序必须能够自我治愈。 启用 自动愈合 以自动回收不正常的辅助角色。
需要使用适当的运行状况检查来评估所有关键的下游依赖项，这有助于确保整体运行状况。 强烈建议启用 运行状况检查 来识别响应不响应的辅助角色。
部署
若要解决每个App 服务计划实例的默认限制，请在单个区域中以多个缩放单元部署App 服务计划。 在可用性区域配置中部署App 服务计划，以确保工作器节点分布在区域中的区域。 请考虑打开支持票证，将最大辅助角色数增加到需要正常峰值负载的实例计数的两倍。
容器注册表
容器注册表托管部署到容器运行时环境（如 AKS）的映像。 需要仔细为任务关键型工作负荷配置容器注册表。 中断不应导致拉取映像的延迟，尤其是在缩放操作期间。 以下注意事项和建议侧重于Azure 容器注册表，并探讨与集中式和联合部署模型关联的权衡。
设计注意事项
格式。 请考虑使用依赖于 Docker 提供的用于推送和拉取操作的格式和标准的容器注册表。 这些解决方案是兼容的，大部分是可互换的。
部署模型。 可以将容器注册表部署为组织中多个应用程序使用的集中式服务。 也可以将其部署为特定应用程序工作负荷的专用组件。
公共注册表。 容器映像存储在 Docker 中心或其他公共注册表中，这些注册表存在于 Azure 和给定虚拟网络之外。 这不一定是个问题，但它可能会导致与服务可用性、限制和数据外泄相关的各种问题。 对于某些应用程序方案，需要在专用容器注册表中复制公共容器映像，以限制出口流量、提高可用性或避免潜在的限制。
设计建议
使用专用于应用程序工作负荷的容器注册表实例。 除非组织可用性和可靠性要求与应用程序完全一致，否则避免对集中式服务创建依赖项。
在建议 的核心体系结构模式中，容器注册表是长期生存的全球资源。 请考虑在每个环境中使用单个全局容器注册表。 例如，使用全局生产注册表。
确保公共注册表的 SLA 与可靠性和安全目标保持一致。 请特别注意依赖于 Docker 中心的用例的限制。
为托管容器映像设置Azure 容器注册表优先级。
有关Azure 容器注册表的设计注意事项和建议
此本机服务提供一系列功能，包括异地复制、Microsoft Entra 身份验证、自动化容器生成和通过容器注册表任务修补。
可靠性
配置到所有部署区域的异地复制，以删除区域依赖项并优化延迟。 容器注册表支持通过 异地复制到 多个配置的区域实现高可用性，从而提供针对区域中断的复原能力。 如果某个区域变得不可用，其他区域将继续为映像请求提供服务。 当区域重新联机时，容器注册表会恢复并复制其更改。 此功能还在每个配置的区域中提供注册表并置，从而减少网络延迟和跨区域数据传输成本。
在提供可用性区域支持的 Azure 区域中， 高级容器注册表层支持区域冗余 ，以提供针对区域性故障的保护。 高级层还支持 专用终结点 ，以帮助防止对注册表进行未经授权的访问，这可能导致可靠性问题。
主机映像靠近消耗的计算资源，位于同一 Azure 区域中。
图像锁定
图像可能会被删除，例如手动错误。 容器注册表支持 锁定映像版本或存储库 ，以防止更改或删除。 更改以前部署的映像 版本 后，同一版本部署可能会在更改前后提供不同的结果。
如果要保护容器注册表实例免遭删除，请使用 资源锁。
标记的图像
默认情况下，标记的容器注册表映像是可变的，这意味着同一标记可用于推送到注册表的多个映像。 在生产方案中，这可能导致可能影响应用程序运行时间的不可预知行为。
标识和访问管理
使用 Microsoft Entra 集成身份验证来推送和拉取映像，而不是依赖于访问密钥。 为了增强安全性，请完全禁用使用管理员访问密钥。
无服务器计算
无服务器计算按需提供资源，无需管理基础结构。 云提供商会自动预配、缩放和管理运行已部署的应用程序代码所需的资源。 Azure 提供了多个无服务器计算平台：
Azure Functions。 使用 Azure Functions 时，应用程序逻辑作为不同的代码块或 函数实现，这些块以响应事件（如 HTTP 请求或队列消息）运行。 每个函数根据需要缩放以满足需求。
Azure 逻辑应用。 逻辑应用最适合用于创建和运行集成各种应用、数据源、服务和系统的自动化工作流。 与 Azure Functions 一样，逻辑应用使用内置触发器进行事件驱动的处理。 但是，可以使用支持条件和循环等代码块的图形用户界面来创建逻辑应用，而不是部署应用程序代码。
Azure API 管理。 可以使用API 管理通过消耗层发布、转换、维护和监视增强的安全 API。
Power Apps 和 Power Automate。 这些工具提供低代码或无代码开发体验，提供简单的工作流逻辑和集成，可通过用户界面中的连接进行配置。
对于任务关键型应用程序，无服务器技术提供简化的开发和操作，这对于简单的业务用例非常有用。 但是，这种简单性代价在于可伸缩性、可靠性和性能方面的灵活性，对于大多数任务关键型应用程序方案来说，这不可行。
以下部分提供了有关将 Azure Functions 和逻辑应用用作非关键工作流方案的替代平台的设计注意事项和建议。
Azure Functions 的设计注意事项和建议
任务关键型工作负荷具有关键和非关键系统流。 对于没有与关键系统流相同的严格业务需求的流，Azure Functions 是可行的选择。 它非常适合具有短生存期进程的事件驱动流，因为函数执行了尽可能快运行的不同操作。
选择适用于应用程序可靠性层的 Azure Functions 托管选项。 建议使用高级计划，因为它允许你配置计算实例大小。 专用计划是无服务器选项。 它提供自动缩放，但这些缩放操作比其他计划慢。 建议使用高级计划来最大程度地提高可靠性和性能。
有一些安全注意事项。 使用 HTTP 触发器公开外部终结点时，请使用 Web 应用程序防火墙（WAF）为 HTTP 终结点提供一级保护，防止常见的外部攻击途径。
建议使用专用终结点来限制对专用虚拟网络的访问。 它们还可以缓解数据外泄风险，例如恶意管理员方案。
需要在 Azure Functions 代码上使用代码扫描工具，并将这些工具与 CI/CD 管道集成。
Azure 逻辑应用的设计注意事项和建议
与 Azure Functions 一样，逻辑应用使用内置触发器进行事件驱动的处理。 但是，可以使用支持条件、循环和其他构造等块的图形用户界面来创建逻辑应用，而不是部署应用程序代码。
提供了多个 部署模式 。 建议使用标准模式来确保单租户部署并缓解干扰性邻居方案。 此模式使用基于 Azure Functions 的容器化单租户逻辑应用运行时。 在此模式下，逻辑应用可以具有多个有状态和无状态工作流。 应注意配置限制。
通过 IaaS 进行约束的迁移
许多具有现有本地部署的应用程序使用虚拟化技术和冗余硬件来提供任务关键级别的可靠性。 现代化通常受到业务限制的阻碍，这些约束阻止与建议用于任务关键型工作负荷的云原生基线（North Star）体系结构模式完全一致。 这就是为什么许多应用程序采用分阶段方法，初始云部署使用虚拟化和 Azure 虚拟机作为主要应用程序托管模型。 在某些情况下，可能需要使用基础结构即服务（IaaS）VM：
- 可用的 PaaS 服务不提供所需的性能或控制级别。
- 工作负荷需要操作系统访问、特定驱动程序或网络和系统配置。
- 工作负荷不支持在容器中运行。
- 没有对第三方工作负荷的供应商支持。
本部分重点介绍使用虚拟机和相关服务的最佳方法，以最大程度地提高应用程序平台的可靠性。 它重点介绍了转置云原生和 IaaS 迁移方案的任务关键设计方法的关键方面。
设计注意事项
由于 VM 和操作系统的管理要求，使用 IaaS VM 的运营成本明显高于使用 PaaS 服务的成本。 管理 VM 需要频繁推出软件包和更新。
Azure 提供提高 VM 可用性的功能：
- 可用性区域 可以通过将 VM 分布到区域中的物理隔离数据中心，从而帮助你实现更高的可靠性级别。
- Azure 虚拟机规模集 提供自动缩放组中 VM 数的功能。 它们还提供监视实例运行状况和自动修复 不正常实例的功能。
- 具有灵活业务流程 的规模集可以通过自动跨容错域分配 VM 来帮助防范网络、磁盘和电源故障。
设计建议
重要
尽可能使用 PaaS 服务和容器来降低操作复杂性和成本。 仅当需要时才使用 IaaS VM。
适当调整 VM SKU 大小 ，以确保有效的资源利用率。
跨 可用性区域 部署三个或多个 VM 以实现数据中心级容错。
- 如果要部署现成的商业软件，请在将软件部署到生产环境之前咨询软件供应商并对其进行充分测试。
对于无法跨可用性区域部署的工作负荷，请使用 包含三个或多个 VM 的灵活虚拟机规模集 。 有关如何配置正确数量的容错域的详细信息，请参阅 管理规模集中的容错域。
优先使用虚拟机规模集来实现可伸缩性和区域冗余。 对于具有不同负载的工作负荷，这一点尤其重要。 例如，如果活动用户数或每秒请求数是不同的负载。
不要直接访问单个 VM。 尽可能在负载均衡器前面使用负载均衡器。
若要防止区域性中断，请在多个 Azure 区域部署应用程序 VM。
对于不支持多区域主动/主动部署的工作负荷，请考虑使用热/暖备用 VM 实现主动/被动部署进行区域故障转移。
使用来自Azure 市场的标准映像，而不是需要维护的自定义映像。
实现自动化过程，以部署和推出对 VM 的更改，避免任何手动干预。 有关详细信息，请参阅操作过程设计区域中的 IaaS 注意事项。
实现混沌试验，将应用程序故障注入 VM 组件，并观察故障缓解措施。 有关详细信息，请参阅 持续验证和测试。
监视 VM 并确保将诊断日志和指标引入到统一 的数据接收器中。
针对任务关键型应用程序方案实施安全做法（如果适用）以及 Azure 中 IaaS 工作负荷的安全最佳做法。
下一步
查看数据平台的注意事项。