Share via

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

Azure 上任务关键型工作负载的设计方法

  • 项目

在任何云平台上构建任务关键型应用程序都需要大量的技术专业知识和工程投资，特别是因为存在与以下项相关的重大复杂性：

  • 了解云平台，
  • 选择合适的服务和组合，
  • 应用正确的服务配置，
  • 操作已利用的服务，以及
  • 不断与最新的最佳做法和服务路线图保持一致。

此设计方法致力于提供易于遵循的设计路径，以帮助应对这种复杂性，并为生成最佳目标体系结构所需的设计决策提供信息。

1 - 针对业务需求进行设计

并非所有任务关键型工作负载都有相同的要求。 预计此设计方法提供的评审注意事项和设计建议将针对不同的应用程序方案产生不同的设计决策和权衡。

选择可靠性层

可靠性是一个相对概念，对于任何工作负荷来说，要适当可靠，它应反映围绕它的业务要求。 例如，具有 99.999% 可用性服务级别目标的任务关键型工作负载 (SLO) 需要比 SLO 为 99.9% 的另一个不太重要的工作负载更高的可靠性级别。

此设计方法应用以可用性 SLO 表示的可靠性层的概念，以告知所需的可靠性特征。 下表捕获了与常见可靠性层关联的允许错误预算。

可靠性层 (可用性 SLO) 允许的停机时间 (周) 允许的停机时间 (月) 允许的停机时间 (年)
99.9% 10 分 4 秒 43 分 49 秒 8 小时 45 分 56 秒
99.95% 5 分 2 秒 21 分 54 秒 4 小时 22 分 58 秒
99.99% 1 分钟 4 分 22 秒 52 分 35 秒
99.999% 6 秒 26 秒 5 分 15 秒
99.9999% <1 秒 2 秒 31 秒

重要

这种设计方法认为，可用性 SLO 不仅仅是简单的运行时间，而是相对于已知正常应用程序状态的一致应用程序服务级别。

作为初始练习，建议读者通过确定可接受的停机时间来选择目标可靠性层？ 追求特定的可靠性层最终将对设计路径和包含的设计决策产生重大影响，这将导致不同的目标体系结构。

此图显示了不同的可靠性层和基础业务要求如何影响概念参考实现的目标体系结构，特别是关于区域部署的数量和利用的全球技术。

任务关键可靠性拨号

恢复时间目标 (RTO) 和恢复点目标 (RPO) 是确定所需可靠性的进一步关键方面。 例如，如果努力实现不到一分钟的应用程序 RTO，则基于备份的恢复策略或主动-被动部署策略可能是不够的。

2 - 使用设计原则评估设计领域

此方法的核心在于关键设计路径，其中包括：

  • 基础 设计原则
  • 具有高度相互关联和依赖设计决策的基本设计 领域 。

在每个设计领域内做出的决策的影响将在其他设计领域和设计决策中产生回响。 查看提供的注意事项和建议，以更好地了解包含的决策的后果，这些决策可能会在相关设计领域产生利弊。

例如，若要定义目标体系结构，必须确定如何最好地跨关键组件监视应用程序运行状况。 强烈建议查看运行状况建模设计领域，使用概述的建议来帮助制定决策。

3 - 部署第一个任务关键型应用程序

请参阅这些参考体系结构，这些体系结构描述了基于此方法的设计决策。

提示

GitHub 徽标 该体系结构由演示设计建议 的任务关键联机 实现提供支持。

生产级项目 每个技术项目都已准备好在生产环境中使用，并考虑了所有端到端操作方面。

植根于实际体验 所有技术决策都以 Azure 客户的经验和从部署这些解决方案中吸取的经验教训为指导。

Azure 路线图一致性 任务关键型参考体系结构有自己的路线图，与 Azure 产品路线图保持一致。

4 - 在 Azure 登陆区域中集成工作负载

Azure 登陆区域订阅 为需要集中治理的企业部署提供共享基础结构。

评估任务关键型应用程序所需的连接用例至关重要。 Azure 登陆区域支持两个main原型，分为不同的管理组范围：联机或公司，如下图所示。

联机和公司管理组以及与任务关键型工作负载的集成示意图。

联机订阅

任务关键型工作负载作为独立解决方案运行，无需与 Azure 登陆区域体系结构的其余部分建立任何直接的企业网络连接。 应用程序将通过 策略驱动的治理 得到进一步保护，并通过策略自动与集中式平台日志记录集成。

基线体系结构和任务关键联机实现与联机方法一致。

公司订阅

部署在公司订阅中时，任务关键型工作负载依赖于 Azure 登陆区域来提供连接资源。 此方法允许与其他应用程序和共享服务集成。 需要围绕一些基础资源进行设计，这些资源将作为共享服务平台的一部分预先存在。 例如，区域部署标记不应再包含临时虚拟网络或 Azure 专用 DNS区域，因为这些标记将存在于 Corp. 订阅中。

若要开始使用此用例，建议使用 Azure 登陆区域参考体系结构中的基线 体系结构。

提示

GitHub 徽标 上述体系结构由 任务关键型连接 实现提供支持。

5 - 部署沙盒应用程序环境

在设计活动的同时，强烈建议使用Mission-Critical参考实现建立沙盒应用程序环境。

这提供了通过复制目标体系结构来验证设计决策的实践机会，从而可以快速评估设计不确定性。 如果正确应用具有代表性的要求范围，则可以发现并随后解决可能阻碍进度的大多数问题。

6 - 通过 Azure 路线图不断发展

使用此设计方法建立的应用程序体系结构必须根据 Azure 平台路线图 不断发展，以支持优化的可持续性。

后续步骤

查看任务关键型应用程序方案的设计原则。

设计原则