通过

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

Azure 上任务关键工作负载的应用程序平台注意事项

  • 项目

Azure 提供了许多用于托管高可用性应用程序的计算服务。 服务在功能和复杂性方面有所不同。 建议根据以下条件选择服务：

  • 可靠性、可用性、性能和安全性的非功能要求。
  • 可伸缩性、成本、可操作性和复杂性等决策因素。

选择应用程序托管平台是影响所有其他设计领域的关键决策。 例如，旧版或专有开发软件可能无法在 PaaS 服务或容器化应用程序中运行。 此限制会影响你选择的计算平台。

任务关键型应用程序可以使用多个计算服务来支持多个复合工作负载和微服务，每个工作负荷和微服务都有不同的要求。

此设计区域提供与计算选择、设计和配置选项相关的建议。 我们还建议自己熟悉计算决策树。

重要

本文是 Azure Well-Architected Framework 任务关键型工作负载系列的一部分。 如果你不熟悉此系列，我们建议从什么是任务关键型工作负荷？开始。

平台资源的全局分布

任务关键型工作负荷的典型模式包括全局资源和区域资源。

不受特定 Azure 区域约束的 Azure 服务部署或配置为全局资源。 一些用例包括跨多个区域分布流量、存储整个应用程序的永久状态以及缓存全局静态数据。 如果需要同时兼顾缩放单元架构和全球分布，请考虑如何在 Azure 区域中以最佳方式分配或复制资源。

其他资源是区域性部署的。 这些资源作为部署标记的一部分进行部署，通常与一个缩放单元对应。 但是，一个区域可以有多个图章，一个标记可以有多个单位。 区域资源的可靠性至关重要，因为它们负责运行主工作负荷。

下图显示了高级设计。 用户通过中心全局入口点访问应用程序，然后将请求重定向到合适的区域部署标记：

Diagram that shows a mission-critical architecture.显示任务关键型架构的图表。

任务关键型设计方法需要多区域部署。 此模型可确保区域容错，以便即使整个区域出现故障，应用程序也仍然可用。 设计多区域应用程序时，请考虑不同的部署策略，例如主动/主动和主动/被动，以及应用程序要求，因为每种方法都有重大权衡。 对于任务关键型工作负荷，强烈建议使用主动/主动模型。

并非每个工作负荷都支持或要求同时运行多个区域。 应权衡特定的应用程序要求与利弊，以确定最佳的设计决策。 对于可靠性较低的某些应用程序方案，主动/被动或分片可以是合适的替代方法。

可用性区域可以在区域内的不同数据中心之间实现高可用的区域部署。 几乎所有的 Azure 服务都可用于区域配置，其中服务委托给特定区域，或区域冗余配置，其中平台会自动确保服务跨区域且能够承受区域中断。 这些配置提供高达数据中心级别的容错能力。

设计注意事项

  • 区域和可用区功能。 并非所有服务和功能都可在每个 Azure 区域中使用。 此注意事项可能会影响所选区域。 此外，并非每个区域中都提供可用性区域。

  • 区域对。 Azure 区域将分组为区域对，而区域对由单个地域中的两个区域组成。 某些 Azure 服务使用配对区域来确保业务连续性，并提供防止数据丢失的级别。 例如，Azure 异地冗余存储（GRS）会自动将数据复制到次要配对区域，确保在主要区域不可恢复时数据持久。 如果中断影响多个 Azure 区域，则每个对中至少有一个区域优先进行恢复。

  • 数据一致性。 对于一致性挑战，考虑使用全局分布式数据存储区、标准区域体系结构和部分主动/主动部署。 在部分部署中，某些组件在所有区域中处于活动状态，而其他组件则位于主要区域中。

  • 安全部署。 Azure 安全部署实践（SDP）框架确保 Azure 平台的所有代码和配置更改（计划内维护）都经过分阶段的推广。 在发布过程中分析健康状况是否降级。 在金丝雀和试点阶段成功完成后，平台更新会在区域对内依次进行，因此每对中只有一个区域会在同一时间内得到更新。

  • 平台容量。 与任何云提供商一样，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 应用程序服务不是业务流程协调程序，但作为低摩擦的容器平台，它仍是 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 虚拟机）的需求进行设置。 一般情况下，若要减少不必要的管理开销，请避免部署大量节点池。

  • 使用排斥和容许来提供专用节点，并限制资源密集型应用程序。

  • 评估应用程序相关性和反关联要求，并在节点上配置容器的相应并置。

安全性

默认的基础版 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 群集可用时，自动将其升级到 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 指标。 监视器中的容器见解提供载入，支持开箱即用的监视功能，并通过内置 Prometheus 支持启用更高级的功能。

治理

使用策略以一致的方式将集中式安全措施应用于 AKS 群集。 在订阅范围或更高范围内应用策略分配，以推动开发团队之间的一致性。

  • 使用 Azure Policy 控制向 Pod 授予哪些功能，以及运行时是否与策略相矛盾。 此访问权限是通过 Azure Policy 插件 for AKS 提供的内置策略所定义的。

  • 使用 Azure Policy 为 AKS 群集和 Pod 配置建立可靠性和安全性的一致基准。

  • 使用 Azure Policy Add-on for AKS 来控制 Pod 功能（如根特权），并禁止那些不符合策略的 Pod。

注意

将部署到 Azure 登陆区域时，Azure 策略应由登陆区域的实现方案提供，以帮助确保一致的可靠性和安全性。

关键任务参考实现提供了一套基线策略，以驱动推荐的可靠性和安全性配置。

Azure App 服务的设计注意事项和建议

对于基于 Web 和 API 的工作负载场景，App Service 可能是 AKS 的可行替代方案。 它提供低摩擦容器平台，无需 Kubernetes 的复杂性。 有关完整建议集，请参阅应用程序服务的可靠性注意事项和应用程序服务的卓越运营。

可靠性

评估 TCP 和 SNAT 端口的使用情况。 TCP 连接用于所有出站连接。 SNAT 端口用于与公共 IP 地址建立出站连接。 SNAT 端口耗尽是常见的故障方案。 在使用Azure 诊断监视端口时，应通过负载测试来预测地检测此问题。 如果发生 SNAT 错误，则需要跨更多或更大的辅助角色进行缩放，或者实现编码做法，以帮助保留和重用 SNAT 端口。 可以使用的编码做法示例包括资源的连接池和延迟加载。

TCP 端口耗尽是另一种故障方案。 当给定辅助角色的出站连接总数超过容量时，会发生这种情况。 可用的 TCP 端口数取决于工作器的大小。 有关建议，请参阅 TCP 和 SNAT 端口。

伸缩性

规划未来的可伸缩性要求和应用程序增长，以便从一开始就应用适当的建议。 这样做，可以避免随着解决方案的增长而产生技术迁移债务。

  • 启用自动缩放以确保有足够的资源可用于服务请求。 为应用程序服务上的高密度托管苹果按应用缩放。

  • 请注意，应用程序服务在每个应用服务计划的实例数方面存在默认软限制。

  • 应用自动缩放规则。 如果满足配置文件中的任何规则，应用服务计划会横向扩展；但是，仅当满足配置文件中的所有规则时才会横向缩减。 使用横向扩展和横向缩减规则组合，确保自动缩放可以同时执行横向扩展和横向缩减操作。 了解单个配置文件中多个缩放规则的行为。

  • 请注意，您可以在应用服务计划级别启用按应用程序进行的缩放，以允许应用程序能够独立于托管它的应用服务计划进行扩展。 应用程序通过尽量的方法分配给可用节点，以实现均匀分布。 尽管不保证偶数分布，但平台可确保同一应用的两个实例不在同一实例上托管。

监控

监视应用程序行为并获取对相关日志和指标的访问权限，以确保应用程序按预期工作。

  • 可以使用诊断日志记录，通过 Azure 事件中心将应用级日志和平台级日志引入 Log Analytics、Azure 存储或第三方工具。

  • 使用 Application Insights 监视应用程序性能可以提供深入的见解。

  • 如果发生故障，任务关键型应用程序必须能够自我治愈。 启用自动修复以自动回收运行不正常的辅助角色。

  • 需要使用适当的运行状况检查来评估所有关键的下游依赖项，这将有助于确保整体运行状况。 强烈建议启用运行状况检查，以识别无响应的辅助角色。

部署

若要解决每个App 服务计划实例的默认限制，请在单个区域中以多个缩放单元部署App 服务计划。 在可用区配置中部署App 服务计划，以确保工作节点分布在某一区域的不同可用区中。 考虑提交一个支持 Ticket，将最大辅助角色数增加到正常峰值负载所需实例数的两倍。

容器注册表

容器注册表托管部署到容器运行时环境（如 AKS）的映像。 需要仔细为任务关键型工作负荷配置容器注册表。 中断不应导致延迟拉取映像，尤其是在缩放操作期间。 以下注意事项和建议侧重于Azure 容器注册表，并探讨与集中式和联合部署模型关联的权衡。

设计注意事项

  • 格式。 请考虑使用依赖于 Docker 提供的用于推送和拉取操作的格式和标准的容器注册表。 这些解决方案是兼容的，大部分是可互换的。

  • 部署模型。 可以将容器注册表部署为组织中多个应用程序使用的集中式服务。 也可以将其部署为特定应用程序工作负荷的专用组件。

  • 公共注册表。 容器映像存储在 Docker 中心或其他公共注册表中，这些注册表存在于 Azure 和给定虚拟网络之外。 这不一定是个问题，但它可能会导致与服务可用性、限制和数据外泄相关的各种问题。 对于某些应用场景，需要在私有容器注册表中复制公共容器镜像，以限制出口流量、提高可用性或避免潜在的限制。

设计建议

  • 使用专用于应用程序工作负荷的容器注册表实例。 除非组织可用性和可靠性要求与应用程序完全一致，否则避免对集中式服务创建依赖项。

    在建议的核心架构模式中，容器注册表是持久存在的全球资源。 请考虑在每个环境中使用单个全局容器注册表。 例如，使用全局生产注册表。

  • 确保公共注册表的 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）VM：

  • 可用的 PaaS 服务不提供所需的性能或控制级别。
  • 工作负荷需要操作系统访问、特定驱动程序或网络和系统配置。
  • 工作负荷不支持在容器中运行。
  • 没有供应商对第三方负载的支持。

本部分重点介绍使用虚拟机和相关服务的最佳方法，以最大程度地提高应用程序平台的可靠性。 它重点介绍了转置云原生和 IaaS 迁移方案的任务关键设计方法的关键方面。

设计注意事项

  • 由于 VM 和操作系统的管理要求，使用 IaaS VM 的运营成本明显高于使用 PaaS 服务的成本。 管理 VM 需要频繁推出软件包和更新。

  • Azure 提供提高 VM 可用性的功能：

    • 可用性区域可以通过将虚拟机分布到区域内物理隔离的数据中心，帮助您实现更高的可靠性。
    • Azure 虚拟机规模集提供在组内自动缩放虚拟机数量的功能。 它们还提供监视实例运行状况和自动修复故障实例的功能。
    • 具有灵活编排的规模集能够通过自动在容错域中分配虚拟机 (VM) 来帮助防范网络、磁盘和电源故障。

设计建议

重要

尽可能使用 PaaS 服务和容器来降低操作复杂性和成本。 仅当需要时才使用 IaaS VM。

  • 优化 VM SKU 大小，以确保资源的有效利用。

  • 跨可用性区域部署三个或更多虚拟机，以实现数据中心级容错。

    • 如果要部署现成的商业软件，请在将软件部署到生产环境之前咨询软件供应商并对其进行充分测试。

  • 对于无法跨可用性区域部署的工作负载，请使用包含三个或更多虚拟机的灵活虚拟机规模集。 有关如何配置正确数量的容错域的详细信息，请参阅管理规模集中的容错域。

  • 优先使用虚拟机规模集来实现可伸缩性和区域冗余。 对于具有不同负载的工作负荷，这一点尤其重要。 例如，如果活动用户数或每秒请求数是不同的负载。

  • 不要直接访问单个 VM。 尽可能在它们前面使用负载均衡器。

  • 若要防止区域性中断，请在多个 Azure 区域部署应用程序 VM。

    • 有关如何在活动部署区域之间优化路由流量的详细信息，请参阅网络和连接设计领域。

  • 对于不支持多区域主动/主动部署的工作负荷，考虑将热/温备用虚拟机用于区域故障转移，实现主动/被动部署。

  • 使用来自Azure 市场的标准映像，而不是需要维护的自定义映像。

  • 实现自动化过程，以部署和推出对 VM 的更改，避免任何手动干预。 有关详细信息，请参阅 操作过程设计区域中的 IaaS 注意事项。

  • 实现混沌试验，将应用程序故障注入 VM 组件，并观察故障缓解措施。 有关详细信息，请参阅 持续验证和测试。

  • 监视 VM，并确保诊断日志和指标被引入到统一的数据汇聚点中。

  • 在适用情况下针对任务关键型应用程序应用场景实现安全做法，并实现 Azure 中 IaaS 工作负荷的安全性最佳做法。

下一步

查看数据平台的注意事项。

数据平台