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

Azure 上任务关键型工作负荷的体系结构模式

本文介绍 Azure 上任务关键型体系结构的关键模式。在开始设计过程时应用此模式，然后选择最适合业务需求的组件。本文建议使用北星设计方法，并包括具有常见技术组件的其他示例。

建议评估 关键设计领域，定义使用基础组件的关键用户和系统流，并开发 Azure 资源的矩阵及其配置，同时记住以下特征。

特征	考虑事项
生存期	与解决方案中的其他资源相比，资源的预期生存期是多少？资源的生存期是否应比整个系统或区域的生存期长或具有同一生存期？或是否应为临时资源？
国家	此层的持久状态对可靠性或可管理性有何影响？
Reach	是否需要资源全球分发？资源是否可以与全局或该区域中的其他资源通信？
依赖	其他资源的依赖关系是什么？
规模限制	该资源的预期吞吐量是什么？资源提供多大规模才能满足该需求？
可用性/灾难恢复	此层灾难对可用性有何影响？它是否会导致系统性中断或仅导致本地化容量或可用性问题？

根据上述特征，对任务关键型资源进行分类和标识。该活动有助于跟踪资源利用率和相关成本，同时帮助你在这些最重要的地方集中优化工作。建议 标记被认为对业务至关重要的资源组。请记住，其中一些资源可能在多个工作负荷之间共享。

有关 Microsoft 建议的标记的信息，请参阅标记任务关键型工作负载。

核心体系结构模式

关系图，显示任务关键型应用程序的通用模式。

某些资源由在每个区域中部署的资源全局共享。常见示例是用于跨多个区域分配流量的资源，存储整个应用程序的永久状态，并监视其资源。

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

该标记包含参与完成业务事务的应用程序和资源。标记通常对应于 Azure 区域的部署。尽管一个区域可以有多个标记。

特征	考虑事项
生存期	资源的生存期预计较短（临时的），其目的是可以动态添加和删除这些资源，而标记外部的区域资源将继续保留。要为用户提供更高的复原能力、缩放性和邻近性，需要临时性。
国家	由于标记是临时的，每次部署都会被销毁；因此标记应该尽可能是无状态的。
Reach	可以与区域和全球资源通信。但是，应避免与其他区域或其他邮票的接触。
依赖	标记资源必须是独立的。它们应具有区域和全局依赖关系，但不应依赖于同一区域或其他区域中其他邮票中的组件。
规模限制	吞吐量是通过测试建立的。总体标记的吞吐量限制为性能最低的资源。标记吞吐量需要估计故障转移到另一个标记所引起的需求水平。
可用性/灾难恢复	由于戳记的暂时性，灾难恢复是通过重新部署标记来完成的。如果资源处于不正常状态，则该标记可整个销毁并重新部署。

系统可具有部署在区域中但生存期长于标记资源生存期的资源。例如，监视区域级资源（包括标记）的可观测性资源。

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

这些基线示例用作任务关键型应用程序的推荐北星体系结构。基线强烈建议对应用平台进行容器化，并使用容器编排工具。基线使用 Azure Kubernetes 服务（AKS）。

请参阅精心构建的任务关键型工作负荷：容器化。

基线体系结构

如果你刚刚开始关键任务之旅，请将此体系结构作为参考使用。工作负荷是通过公共终结点访问的，不需要与其他公司资源的专用网络连接。
具有网络控制的基线

此体系结构基于基线体系结构构建。设计被扩展以实现严格的网络控制，以防止未经授权的公众从互联网访问工作负荷资源。
Azure 登陆区域中的基线

在企业环境中，如果需要将工作负载部署在需要与更大组织进行集成的情况下，该体系结构是合适的。工作负荷使用集中式共享服务，需要本地连接，并与企业中的其他工作负荷集成。它部署在从公司管理组继承的 Azure 登陆区域订阅中。
带有应用程序服务的基线

此体系结构通过将应用服务视为主要应用程序托管技术来扩展基线参考，从而为容器部署提供易于使用的环境。