你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure 上任务关键工作负载的应用程序平台注意事项
Azure 提供了许多计算服务来托管高度可用的应用程序。 这些服务在功能和复杂性方面有所不同。 建议根据以下条件选择服务：
- 可靠性、可用性、性能和安全性的非功能性要求。
- 可伸缩性、成本、可操作性和复杂性等决策因素。
选择应用程序托管平台是影响所有其他设计领域的关键决策。 例如，旧式或专有开发软件可能不会在 PaaS 服务或容器化应用程序中运行。 此限制会影响你选择的计算平台。
任务关键型应用程序可以使用多个计算服务来支持多个复合工作负载和微服务，每个工作负载和微服务都有不同的要求。
此设计区域提供与计算选择、设计和配置选项相关的建议。 我们还建议熟悉 计算决策树。
重要
本文是 Azure Well-Architected Framework 任务关键型工作负载 系列的一部分。 如果不熟悉本系列，建议从什么是任务关键型工作负载开始。
平台资源的全球分布
任务关键型工作负载的典型模式包括全局资源和区域资源。
不受特定 Azure 区域限制的 Azure 服务部署或配置为全局资源。 一些用例包括跨多个区域分配流量、存储整个应用程序的永久状态以及缓存全局静态数据。 如果需要同时适应缩放单元体系结构和全球分布，请考虑如何在 Azure 区域之间以最佳方式分配或复制资源。
其他资源按区域部署。 这些资源部署为部署标记的一部分，通常对应于缩放单元。 但是，一个区域可以有多个图章，而一个图章可以有多个单元。 区域资源的可靠性至关重要，因为它们负责运行main工作负荷。
下图显示了高级设计。 用户通过中央全局入口点访问应用程序，然后将请求重定向到合适的区域部署标记：
任务关键型设计方法需要多区域部署。 此模型可确保区域容错，以便即使整个区域出现故障，应用程序也仍然可用。 设计多区域应用程序时，请考虑不同的部署策略（如主动/主动和主动/被动）以及应用程序要求，因为每种方法都有明显的权衡。 对于任务关键型工作负载，我们强烈建议使用主动/主动模型。
并非每个工作负载都支持或要求同时运行多个区域。 应权衡特定的应用程序要求与权衡权衡，以确定最佳设计决策。 对于可靠性目标较低的某些应用程序方案，主动/被动或分片可以是合适的替代方法。
可用性区域 可以在一个区域内的不同数据中心之间提供高度可用的区域部署。 几乎所有 Azure 服务都可以在区域配置（其中服务委托给特定区域）或区域冗余配置（其中平台自动确保服务跨区域且能够承受区域中断）中提供。 这些配置提供高达数据中心级别的容错能力。
设计注意事项
区域和区域功能。 并非所有服务和功能都在每个 Azure 区域中都可用。 此注意事项可能会影响所选区域。 此外， 可用性区域 并非在每个区域中都可用。
区域对。 Azure 区域分组为 区域对 ，由单个地理位置中的两个区域组成。 某些 Azure 服务使用配对区域来确保业务连续性并提供一定程度的数据丢失保护。 例如，Azure 异地冗余存储 (GRS) 自动将数据复制到次要配对区域，确保在主要区域不可恢复时数据持久。 如果中断影响多个 Azure 区域，则每对中至少有一个区域优先进行恢复。
数据一致性。 对于一致性挑战，请考虑使用全球分布式数据存储、标记区域体系结构和部分主动/主动部署。 在部分部署中，某些组件在所有区域中处于活动状态，而其他组件则位于主要区域内。
安全部署。 (SDP) 框架的 Azure 安全部署做法可确保对 Azure 平台的计划内维护 (所有代码和配置更改) 分阶段推出。 在发布期间，会分析运行状况以降低。 在 Canary 和试点阶段成功完成后，平台更新将跨区域对进行序列化，因此在给定时间，每个对中只有一个区域进行更新。
平台容量。 与任何云提供商一样，Azure 的资源有限。 不可用可能是由于区域中的容量限制造成的。 如果发生区域性中断，则当工作负荷尝试在配对区域内恢复时，对资源的需求会增加。 中断可能会导致容量问题，即供应暂时无法满足需求。
设计建议
在至少两个 Azure 区域中部署解决方案，以帮助防范区域性中断。 在具有工作负荷所需的功能和特征的区域部署它。 这些功能应满足性能和可用性目标，同时满足数据驻留和保留要求。
例如，某些数据符合性要求可能会限制可用区域的数量，并可能强制设计泄露。 在这种情况下，我们强烈建议在操作包装器上增加额外的投资，以预测、检测和响应故障。 假设你受限于具有两个区域的地理位置，并且其中只有一个区域支持可用性区域 (3 + 1 数据中心模型) 。 使用容错域隔离创建辅助部署模式，以允许在活动配置中部署这两个区域，并确保主要区域包含多个部署标记。
如果合适的 Azure 区域未全部提供所需的功能，请准备好在区域部署标记的一致性上妥协，以便确定地理分布的优先级并最大程度地提高可靠性。 如果只有一个 Azure 区域适用，请在所选区域中) (区域缩放单元部署多个部署标记以缓解某些风险，并使用可用性区域提供数据中心级容错。 但是，地理分布方面的这种重大妥协极大地限制了可实现的复合 SLA 和整体可靠性。
重要
对于面向大于或等于 99.99% 的 SLO 的方案，建议至少使用三个部署区域，以最大程度地提高复合 SLA 和整体可靠性。 计算所有用户流的 复合 SLA 。 确保复合 SLA 与业务目标保持一致。
对于具有大量流量的大规模应用程序方案，请将解决方案设计为跨多个区域缩放，以在单个区域内导航潜在的容量约束。 其他区域部署标记将实现更高的复合 SLA。 使用全局资源会限制通过添加更多区域来实现的复合 SLA 的增加。
(RTO) 定义并验证 RPO) 和恢复时间目标 (恢复点目标。
在单个地理位置中，优先使用区域对，以便从 SDP 序列化的推出中获益，以便进行计划外维护，并按区域优先级进行计划外维护。
在地理上将 Azure 资源与用户并置在一起，以最大程度地减少网络延迟并最大程度地提高端到端性能。
选择部署区域时，使当前服务可用性与产品路线图保持一致。 某些服务可能不会在每个区域中立即可用。
容器化
容器包括应用程序代码以及应用程序需要运行的相关配置文件、库和依赖项。 容器化为应用程序代码及其依赖项提供抽象层，并创建与基础托管平台的分离。 单个软件包具有高度可移植性，可以跨各种基础结构平台和云提供商一致运行。 开发人员无需重写代码，可以更快、更可靠地部署应用程序。
重要
建议对任务关键型应用程序包使用容器。 它们可以提高基础结构利用率，因为可以在同一虚拟化基础结构上托管多个容器。 此外，由于容器中包含所有软件，因此无论运行时或库版本如何，都可以跨各种操作系统移动应用程序。 与传统的虚拟化托管相比，容器的管理也更容易。
任务关键型应用程序需要快速缩放以避免性能瓶颈。 由于容器映像是预生成的，因此可以将启动限制为仅在启动应用程序期间发生，从而提供快速的可伸缩性。
设计注意事项
监视。 监视服务可能很难访问容器中的应用程序。 通常需要第三方软件来收集和存储容器状态指示器，例如 CPU 或 RAM 使用情况。
安全性。 托管平台 OS 内核在多个容器之间共享，从而产生单一攻击点。 但是，主机 VM 访问的风险是有限的，因为容器与基础操作系统隔离。
状态。 尽管可以将数据存储在正在运行的容器的文件系统中，但在重新创建容器时，数据不会保留。 而是通过装载外部存储或使用外部数据库来保留数据。
设计建议
将所有应用程序组件容器化。 使用容器映像作为应用程序部署包的主模型。
尽可能确定基于 Linux 的容器运行时的优先级。 映像更轻量级，并且经常发布适用于 Linux 节点/容器的新功能。
使容器不可变且可替换，生命周期较短。
请务必从容器、容器主机和基础群集收集所有相关日志和指标。 将收集的日志和指标发送到统一的数据接收器进行进一步处理和分析。
将容器映像存储在 Azure 容器注册表 中。 使用 异地复制 跨所有区域复制容器映像。 为容器注册表启用Microsoft Defender，为容器映像提供漏洞扫描。 确保通过Microsoft Entra ID 管理对注册表的访问。
容器托管和业务流程
多个 Azure 应用程序平台可以有效地托管容器。 其中每个平台都有各自的优点和缺点。 比较业务需求上下文中的选项。 但是，始终优化可靠性、可伸缩性和性能。 有关详细信息，请参阅以下文章：
重要
Azure Kubernetes 服务 (AKS) 和 Azure 容器应用应是容器管理的首要选择之一，具体取决于你的要求。 尽管 Azure 应用服务 不是业务流程协调程序，但作为低摩擦容器平台，它仍然是 AKS 的可行替代方案。
Azure Kubernetes 服务的设计注意事项和建议
AKS 是一种托管 Kubernetes 服务，无需复杂的群集管理活动即可实现快速群集预配，并提供包含高级网络和标识功能的功能集。 有关完整的一组建议，请参阅 Azure Well-Architected Framework 评审 - AKS。
重要
有一些基础配置决策，如果不重新部署 AKS 群集，则无法更改这些决策。 示例包括选择公共和专用 AKS 群集、启用 Azure 网络策略、Microsoft Entra集成，以及使用 AKS 托管标识而不是服务主体。
可靠性
AKS 管理本机 Kubernetes 控制平面。 如果控制平面不可用，则工作负荷会出现停机。 利用 AKS 提供的可靠性功能：
跨 不同 Azure 区域部署 AKS 群集 作为缩放单元，以最大程度地提高可靠性和可用性。 使用 可用性区域 在物理上独立的数据中心之间分布 AKS 控制平面和代理节点，以最大限度地提高 Azure 区域中的复原能力。 但是，如果归置延迟是一个问题，可以在单个区域中执行 AKS 部署，或使用 邻近放置组 来最大程度地减少节点间延迟。
使用生产群集的 AKS 运行时间 SLA 来最大化 Kubernetes API 终结点可用性保证。
可伸缩性
考虑 AKS 规模限制，例如节点数、每个群集的节点池以及每个订阅的群集数。
如果规模限制是一种约束，请利用 缩放单元策略，并使用群集部署更多单元。
启用群集自动缩放程序以自动调整代理节点数以响应资源约束。
使用 水平 Pod 自动缩放程序 根据 CPU 利用率或其他指标调整部署中的 Pod 数。
对于大规模和突发方案，请考虑使用 虚拟节点 进行广泛和快速缩放。
在应用程序部署清单中定义 Pod 资源请求和限制 。 否则，可能会遇到性能问题。
隔离
维护工作负载和系统工具使用的基础结构之间的边界。 共享基础结构可能会导致资源利用率过高和邻近干扰情况。
对系统和工作负载服务使用单独的节点池。 工作负荷组件的专用节点池应基于专用基础结构资源（如高内存 GPU VM）的要求。 通常，为了减少不必要的管理开销，请避免部署大量节点池。
使用 排斥和容许 来提供专用节点并限制资源密集型应用程序。
评估应用程序相关性和反关联要求，并在节点上配置适当的容器并置。
安全性
默认的 vanilla Kubernetes 需要大量配置，以确保任务关键型方案具有适当的安全态势。 AKS 现成地解决了各种安全风险。 功能包括专用群集、审核和登录到 Log Analytics、强化节点映像和托管标识。
应用 AKS 安全基线中提供的配置指南。
使用 AKS 功能来处理群集标识和访问管理，以减少操作开销并应用一致的访问管理。
使用托管标识而不是服务主体，以避免管理和轮换凭据。 可以在群集级别添加 托管标识 。 在 Pod 级别，可以通过Microsoft Entra Workload 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 应用服务的设计注意事项和建议
对于基于 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 提供的推送和拉取操作格式和标准的容器注册表。 这些解决方案是兼容的，并且大部分是可互换的。
部署模型。 可以将容器注册表部署为组织中多个应用程序使用的集中式服务。 也可以将其部署为特定应用程序工作负载的专用组件。
公共注册表。 容器映像存储在 Azure 和给定虚拟网络外部的Docker Hub或其他公共注册表中。 这不一定是个问题，但它可能会导致与服务可用性、限制和数据外泄相关的各种问题。 对于某些应用程序方案，需要在专用容器注册表中复制公共容器映像，以限制出口流量、提高可用性或避免潜在的限制。
设计建议
使用专用于应用程序工作负载的容器注册表实例。 除非组织的可用性和可靠性要求与应用程序完全一致，否则避免在集中式服务上创建依赖项。
在建议 的核心体系结构模式中，容器注册表是长期生存的全局资源。 请考虑为每个环境使用单个全局容器注册表。 例如，使用全局生产注册表。
确保公共注册表的 SLA 与可靠性和安全目标保持一致。 请特别注意依赖于Docker Hub的用例的限制。
确定托管容器映像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 虚拟机：
- 可用的 PaaS 服务不提供所需的性能或控制级别。
- 工作负荷需要操作系统访问权限、特定驱动程序或网络和系统配置。
- 工作负荷不支持在容器中运行。
- 没有供应商对第三方工作负载的支持。
本部分重点介绍使用 Azure 虚拟机和相关服务以最大程度地提高应用程序平台可靠性的最佳方法。 它重点介绍了转置云原生和 IaaS 迁移方案的任务关键型设计方法的关键方面。
设计注意事项
由于虚拟机和操作系统的管理要求，使用 IaaS 虚拟机的运营成本明显高于使用 PaaS 服务的成本。 管理虚拟机需要频繁推出软件包和更新。
Azure 提供了提高虚拟机可用性的功能：
设计建议
重要
尽可能使用 PaaS 服务和容器来降低操作复杂性和成本。 仅在需要时才使用 IaaS 虚拟机。
适当调整 VM SKU 大小 ，以确保有效利用资源。
跨 可用性区域 部署三个或更多虚拟机，以实现数据中心级容错。
- 如果要部署现成的商业软件，请在将软件部署到生产环境之前咨询软件供应商并对其进行充分测试。
对于无法跨可用性区域部署的工作负载，请使用包含三个或多个 VM 的可用性集 。
- 仅当可用性区域不符合工作负载要求时，才考虑可用性集，例如对于低延迟要求的聊天工作负载。
优先使用虚拟机规模集实现可伸缩性和区域冗余。 这一点对于具有不同负载的工作负荷尤其重要。 例如，如果每秒活动用户或请求数是不同的负载，
不要直接访问单个虚拟机。 如果可能，请使用它们前面的负载均衡器。
若要防范区域性中断，请跨多个 Azure 区域部署应用程序虚拟机。
- 有关如何在活动部署区域之间以最佳方式路由流量的详细信息，请参阅 网络和连接设计区域 。
对于不支持多区域主动/主动部署的工作负载，请考虑使用热/暖备用虚拟机进行区域故障转移来实现主动/被动部署。
使用来自Azure 市场的标准映像，而不是需要维护的自定义映像。
实施自动化流程以部署和推出对虚拟机的更改，避免任何手动干预。 有关详细信息，请参阅操作过程设计区域中的 IaaS 注意事项。
实现混沌试验，将应用程序故障注入虚拟机组件，并观察故障缓解措施。 有关详细信息，请参阅 持续验证和测试。
监视虚拟机，并确保将诊断日志和指标引入 到统一的数据接收器中。
为任务关键型应用程序方案（如果适用）实施安全做法，并为 Azure 中的 IaaS 工作负载实施安全最佳做法。
后续步骤
查看数据平台的注意事项。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈