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

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

任何任务关键型体系结构的关键设计区域都是应用程序平台。 平台是指必须预配以支持应用程序的基础结构组件和 Azure 服务。 下面是一些重要建议。

• 分层设计。 选择合适的服务集、配置和特定于应用程序的依赖项。 这种分层方法有助于创建逻辑和物理分段。 可用于定义角色和功能以及分配适当权限和部署策略。 此方法最终提高了系统的可靠性。

• 任务关键型应用程序必须高度可靠，并能抵御数据中心和区域性故障。 在主动-主动配置中构建分区和区域冗余是主要策略。 选择适用于你的应用程序平台的 Azure 服务时，请考虑其可用性区域支持以及使用多个 Azure 区域的部署和运营模式。

• 使用基于缩放单元的体系结构来处理增加的负载。 通过缩放单元，可以以逻辑方式对资源进行分组，并且单元可以独立于体系结构中的其他单元或服务进行缩放。 使用容量模型和预期性能来定义每个单元的边界、数量和基线规模。

在此体系结构中，应用程序平台由全局资源、部署标记资源和区域资源组成。 区域资源作为部署标记的一部分进行预配。 每个标记相当于一个缩放单元，如果某个标记不正常，可以整个替换。

每一层中的资源都有不同的特征。 有关详细信息，请参阅典型任务关键型工作负载的体系结构模式。

特征	注意事项
生存期	相对于解决方案中的其他资源，资源的预期生存期是多长？ 资源的生存期是否应比整个系统或区域的生存期长或具有同一生存期？或是否应为临时资源？
状态	此层的持久状态对可靠性或可管理性有何影响？
Reach	资源是否需要进行全局分布？ 资源能否与全局或区域中的其他资源通信？
依赖项	对全局或其他区域中的其他资源有何依赖关系？
规模限制	该资源在该层中的预期吞吐量是多少？ 资源提供多大规模才能满足该需求？
可用性/灾难恢复	对此层的可用性或灾难有何影响？ 它是会导致系统故障还是只会导致局部容量或可用性问题？

全局资源

此体系结构中的某些资源由部署在区域中的资源共享。 在此体系结构中，它们用于跨多个区域分配流量、存储整个应用程序的永久状态以及缓存全局静态数据。

特征	层注意事项
生存期	这些资源预计将长期存在。 其生存期等于或长于系统的生存期。 通常，这些资源是使用就地数据和控制平面更新来管理的，前提是它们支持不停机的更新操作。
状态	由于这些资源至少在系统的生存期内存在，因此此层通常负责存储全局的异地复制状态。
Reach	资源应全局分布。 建议这些资源以低延迟和所需一致性与区域或其他资源进行通信。
依赖项	资源应避免依赖于区域资源，因为如果区域资源不可用，可能会导致全局故障。 例如，如果单个保管库所在的区域发生故障，则保存在该保管库中的证书或机密可能会产生全局影响。
规模限制	通常，这些资源是系统中的单一实例，因此它们应该能够缩放，从而可以处理整个系统的吞吐量。
可用性/灾难恢复	由于区域和标记资源可能使用全局资源或受全局资源影响，因此为全局资源配置高可用性和灾难恢复对于整个系统的健康至关重要。

在此体系结构中，全局层资源包括 Azure Front Door、Azure Cosmos DB、Azure 容器注册表以及用于存储来自其他全局层资源的日志和指标的 Azure Log Analytics。

此设计中还有其他基础资源，例如 Microsoft Entra ID 和 Azure DNS。 为简洁起见，下图中省略了这些资源。

全局负载均衡器

Azure Front Door 用作用户流量的唯一入口点。 Azure 保证 Azure Front Door 将在 99.99% 的时间内无误传送请求的内容。 有关详细信息，请参阅 Front Door 服务限制。 如果 Front Door 不可用，最终用户将看到系统处于关闭状态。

Front Door 实例将流量发送到配置的后端服务，例如托管 API 和前端 SPA 的计算群集。 Front Door 中的后端配置错误可能会导致故障。 为避免因配置错误而导致故障，应全面测试 Front Door 设置。

另一个常见错误可能来自配置错误或缺少 TLS 证书，这可能会阻止用户使用前端或 Front Door 与后端通信。 缓解可能需要手动干预。 例如，可选择回退到以前的配置并重新颁发证书（如果可能）。 不管怎样，当更改生效时，预计不可用。 建议使用 Front door 提供的托管证书来减少运营开销，例如处理过期。

Front Door 除提供全局流量路由外，还提供许多其他功能。 一项重要功能是 Web 应用程序防火墙 (WAF)，因为 Front Door 能够检查正在传递的流量。 当配置为防护模式时，它会阻止可疑流量到达任何后端。

有关 Front Door 功能的信息，请参阅 Azure Front Door 常见问题解答。

有关全局分布流量的其他注意事项，请参阅架构良好的框架的任务关键指南：全局路由。

容器注册表

Azure 容器注册表用于存储开放容器计划 (OCI) 项目，特别是 Helm 图表和容器映像。 它不参与请求流，仅被定期访问。 需要先存在容器注册表，然后才能部署标记资源，并且该资源不应依赖于区域层资源。

启用注册表的区域冗余和异地复制，以便运行时对映像的访问可快速进行且可从故障中复原。 如果不可用，实例随后可以故障转移到副本区域，并且请求会自动重新路由到另一区域。 在故障转移完成之前，拉取映像时可能会出现暂时性错误。

如果无意中删除映像，也可能发生故障，新计算节点将无法拉取映像，但现有节点仍可使用缓存的映像。 灾难恢复的主要策略是重新部署。 容器注册表中的项目可从管道重新生成。 容器注册表必须能够承受许多并发连接才能支持所有部署。

建议使用高级 SKU 启用异地复制。 区域冗余功能可确保特定区域中的复原能力和高可用性。 如果发生区域性故障，其他区域中的副本仍可用于数据平面操作。 使用此 SKU，可通过专用终结点限制对映像的访问。

有关详细信息，请参阅 Azure 容器注册表的最佳做法。

数据库

建议将所有状态全局存储在与区域标记分开的数据库中。 通过跨区域部署数据库来构建冗余。 对于任务关键型工作负载，跨区域同步数据应该是主要关注点。 此外，如果发生故障，对数据库的写入请求应该仍然正常工作。

强烈建议在主动-主动配置中进行数据复制。 应用程序应能够立即连接到另一区域。 所有实例都应能够处理读取和写入请求。

有关详细信息，请参阅任务关键型工作负载的数据平台。

全局监视

Azure Log Analytics 用于存储来自所有全局资源的诊断日志。 建议限制每日存储配额，尤其是在用于负载测试的环境中。 此外，还应设置保留策略。 这些限制将防止因存储超出限制的不需要的数据而导致的任何超支。

基础服务的注意事项

系统可能使用其他可能导致整个系统面临风险的关键平台服务，例如 Azure DNS 和 Microsoft Entra ID。 Azure DNS 保证为有效 DNS 请求实现 100% 可用性 SLA。 Microsoft Entra 保证至少 99.99% 的运行时间。 不过，你应注意发生故障时的影响。

对基础服务的硬依赖是不可避免的，因为许多 Azure 服务都依赖于基础资源。 如果基础资源不可用，预计系统会中断。 例如：

• Azure Front Door 使用 Azure DNS 访问后端和其他全局服务。
• Azure 容器注册表使用 Azure DNS 将请求故障转移到另一区域。

在这两种情况下，如果 Azure DNS 不可用，这两个 Azure 服务都会受到影响。 来自 Front Door 的用户请求的名称解析将失败；不会从注册表拉取 Docker 映像。 使用外部 DNS 服务作为备用服务不会降低风险，因为许多 Azure 服务不允许此类配置并依赖于内部 DNS。 预计会出现完全中断。

同样，Microsoft Entra ID 用于控制平面操作，例如创建新的 AKS 节点、从容器注册表拉取映像或在 Pod 启动时访问密钥保管库。 如果 Microsoft Entra ID 不可用，现有组件应该不会受到影响，但整体性能可能会下降。 新的 Pod 或 AKS 节点将无法正常工作。 因此，如果在此期间需要进行横向扩展操作，预计用户体验会下降。

区域部署标记资源

在此体系结构中，部署标记部署工作负载并预配参与完成业务事务的资源。 标记通常对应于 Azure 区域的部署。 尽管一个区域可以有多个标记。

特征	注意事项
生存期	资源的生存期预计较短（临时的），其目的是可以动态添加和删除这些资源，而标记外部的区域资源将继续保留。 要为用户提供更高的复原能力、缩放性和邻近性，需要临时性。
状态	由于标记是临时的，可以随时销毁，因此标记应尽可能为无状态。
Reach	可与区域和全局资源通信。 但应避免与其他区域或其他标记进行通信。 在此体系结构中，这些资源不需要全局分布。
依赖项	标记资源必须是独立的。 也就是说，它们不应依赖于其他区域中的其他标记或组件。 预计它们将有区域和全局依赖项。 主要共享组件是数据库层和容器注册表。 此组件需要在运行时进行同步。
规模限制	吞吐量是通过测试确定的。 总体标记的吞吐量限制为性能最低的资源。 标记吞吐量需要考虑到估计的高需求，以及由于区域中的另一个标记不可用而导致的任何故障转移。
可用性/灾难恢复	由于标记的临时性，灾难恢复是通过重新部署标记来完成的。 如果资源处于不正常状态，则该标记可整个销毁并重新部署。

在此体系结构中，标记资源包括 Azure Kubernetes 服务、Azure 事件中心、Azure Key Vault 和 Azure Blob 存储。

缩放单元

标记也可视为缩放单元 (SU)。 给定标记内的所有组件和服务都经过配置和测试，可处理给定范围内的请求。 下面是实现中使用的缩放单元示例。

每个缩放单元都部署到一个 Azure 区域，因此缩放单元主要处理来自该给定区域的流量（尽管它可以在需要时接管来自其他区域的流量）。 这种地理分布可能会导致负载模式和工作时间因区域而异，因此每个 SU 都设计为在空闲时进行横向缩减/纵向缩减。

可部署新标记来实现缩放。 在标记内，各个资源也可以是缩放单元。

下面是在单元中选择 Azure 服务时的一些缩放和可用性注意事项：

• 评估缩放单元中所有资源之间的容量关系。 例如，若要处理 100 个传入请求，将需要 5 个入口控制器 Pod、3 个目录服务 Pod 以及 Azure Cosmos DB 中的 1000 个 RU。 因此，当自动缩放入口 Pod 时，预计会根据这些范围缩放目录服务和 Azure Cosmos DB RU。

• 对服务进行负载测试以确定将在其中处理请求的范围。 根据结果配置实例数上限和下限以及目标指标。 达到目标后，可选择自动缩放整个单元。

• 查看 Azure 订阅规模限制和配额，以支持业务要求设置的容量和成本模型。 还要考虑各个服务的限制。 由于单元通常部署在一起，因此应考虑 Canary 部署所需的订阅资源限制。 有关详细信息，请参阅 Azure 服务限制。

• 选择支持可用性区域的服务以构建冗余。 这可能会限制你的技术选择。 有关详细信息，请参阅可用性区域。

有关单元大小和资源组合的其他注意事项，请参阅架构良好的框架的任务关键指南：缩放单元体系结构。

计算群集

要将工作负载容器化，每个标记都需要运行一个计算群集。 在此体系结构中，选择 Azure Kubernetes 服务 (AKS) 是因为 Kubernetes 是新式容器化应用程序的最热门计算平台。

AKS 群集的生存期与标记的临时性质有关。 群集是无状态的，没有永久性卷。 它使用临时 OS 磁盘而不是托管磁盘，因为它们不会接收应用程序或系统级维护。

为提高可靠性，群集配置为在给定区域中使用所有三个可用性区域。 这使得群集可使用 AKS 运行时间 SLA，它保证 AKS 控制平面的 99.95% SLA 可用性。

规模限制、计算容量、订阅配额等其他因素也可能影响可靠性。 如果容量不足或达到限制，横向扩展和纵向扩展操作将失败，但现有计算预计会正常运行。

群集已启用自动缩放功能，使节点池可在需要时自动横向扩展，从而提高可靠性。 使用多个节点池时，所有节点池应自动缩放。

在 Pod 级别，Pod 横向自动缩放程序 (HPA) 根据配置的 CPU、内存或自定义指标缩放 Pod。 对工作负载的组件进行负载测试，以确定自动缩放程序和 HPA 值的基线。

群集还配置为自动节点映像升级，并在这些升级期间进行适当缩放。 通过此缩放，可在执行升级时实现不停机。 如果一个标记中的群集在升级期间出现故障，其他标记中的其他群集应该不会受到影响，但跨标记的升级应在不同时间进行以维护可用性。 此外，群集升级会自动在节点之间滚动，因此它们不会同时不可用。

某些组件（如证书管理器和 ingress-nginx）需要外部容器注册表中的容器映像。 如果这些存储库或映像不可用，则新节点（未缓存映像）上的新实例可能无法启动。 通过将这些映像导入环境的 Azure 容器注册表，可降低此风险。

可观测性在此体系结构中至关重要，因为标记是临时的。 诊断设置配置为将所有日志和指标数据存储在区域 Log Analytics 工作区中。 此外，AKS 容器见解是通过群集内 OMS 代理启用的。 此代理支持群集将监视数据发送到 Log Analytics 工作区。

有关计算群集的其他注意事项，请参阅架构良好的框架的任务关键指南：容器业务流程和 Kubernetes。

密钥保管库

Azure Key Vault 用于存储全局机密（如数据库连接字符串）和标记机密（如事件中心连接字符串）。

此体系结构在计算群集中使用机密存储 CSI 驱动程序从密钥保管库获取机密。 生成新 Pod 时需要机密。 如果密钥保管库不可用，则新 Pod 可能无法启动。 因此，可能会出现中断；横向扩展操作可能会受到影响，更新可能会失败，无法执行新部署。

密钥库对操作次数有限制。 由于机密的自动更新，如果有多个 Pod，则可能会达到限制。 可选择降低更新频率来避免这种情况。

有关机密管理的其他注意事项，请参阅架构良好的框架的任务关键指南：数据完整性保护。

事件中心

标记中唯一有状态服务是消息代理 Azure 事件中心，它会将请求存储一小段时间。 该代理满足了缓冲和可靠消息传送的需求。 处理后的请求保存在全局数据库中。

在此体系结构中，使用标准 SKU 并启用区域冗余以实现高可用性。

事件中心运行状况由计算群集上运行的 HealthService 组件来验证。 它会对各种资源执行定期检查。 这在检测不正常情况时很有用。 例如，如果消息无法发送到事件中心，则该标记将无法用于任何写入操作。 HealthService 应自动检测这种情况并将不正常状态报告给 Front Door，这将使标记停止轮换。

对于可伸缩性，建议启用自动扩充。

有关详细信息，请参阅任务关键型工作负载的消息传送服务。

有关消息传送的其他注意事项，请参阅架构良好的框架的任务关键指南：异步消息传送。

存储帐户

在此体系结构中，预配了两个存储帐户。 这两个帐户都部署为区域冗余模式 (ZRS)。

一个帐户用于事件中心检查点。 如果此帐户没有响应，该标记将无法处理来自事件中心的消息，甚至可能会影响标记中的其他服务。 HealthService 定期检查此情况，它是计算群集中运行的应用程序组件之一。

另一个帐户用于托管 UI 单页应用程序。 如果静态网站服务存在任何问题，Front Door 将检测到问题，并且不会将流量发送到此存储帐户。 在此期间，Front Door 可使用缓存的内容。

有关恢复的详细信息，请参阅灾难恢复和存储帐户故障转移。

区域资源

系统可具有部署在区域中但生存期长于标记资源生存期的资源。 在此体系结构中，标记资源的可观测性数据存储在区域数据存储中。

特征	注意事项
生存期	资源与区域具有同一生存期，并且资源生存期长于标记资源生存期。
状态	存储在区域中的状态的生存期不能长于该区域的生存期。 如果需要跨区域共享状态，请考虑使用全局数据存储。
Reach	资源无需全局分布。 应尽量避免与其他区域进行直接通信。
依赖项	这些资源可以依赖于全局资源，但不能依赖于标记资源，因为标记的生存期较短。
规模限制	通过组合该区域内的所有标记来确定区域资源的规模限制。

监视标记资源的数据

部署监视资源是区域资源的典型示例。 在此体系结构中，每个区域都有一个单独的 Log Analytics 工作区，配置为存储从标记资源发出的所有日志和指标数据。 由于区域资源的生存期长于标记资源生存期，因此即使删除标记，数据也可用。

Azure Log Analytics 和 Azure Application Insights 用于存储来自平台的日志和指标。 建议限制每日存储配额，尤其是在用于负载测试的环境中。 此外，设置保留策略以存储所有数据。 这些限制将防止因存储超出限制的不需要的数据而导致的任何超支。

同样，Application Insights 也部署为区域资源来收集所有应用程序监视数据。

有关监视的设计建议，请参阅架构良好的框架的任务关键指南：运行状况建模。

后续步骤

部署参考实现，以便全面了解此体系结构中使用的资源及其配置。

实现：任务关键型联机