如果刚刚开始任务关键型旅程,请使用此体系结构作为参考。 工作负荷通过公共终结点进行访问,不需要与其他公司资源的专用网络连接。
你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
Azure 上任务关键型工作负载的体系结构模式
本文介绍 Azure 上任务关键型体系结构的关键模式。 在开始设计过程时应用此模式,然后选择最适合业务要求的组件。 本文建议采用北star设计方法,并包含具有常见技术组件的其他示例。
建议评估 关键设计领域,定义使用基础组件的关键用户和系统流,并开发 Azure 资源及其配置的矩阵,同时记住以下特征。
特征 | 注意事项 |
---|---|
生存期 | 相对于解决方案中的其他资源,资源的预期生存期是多少? 资源的生存期是否应比整个系统或区域的生存期长或具有同一生存期?或是否应为临时资源? |
状态 | 此层的持久状态对可靠性或可管理性有何影响? |
Reach | 资源是否需要进行全局分布? 资源是否可以与位于全球或该区域中的其他资源通信? |
依赖项 | 其他资源的依赖项是什么? |
规模限制 | 该资源的预期吞吐量是多少? 资源提供多大规模才能满足该需求? |
可用性/灾难恢复 | 此层灾难对可用性有何影响? 它是否会导致系统中断或仅导致本地化容量或可用性问题? |
重要
本文是 Azure Well-Architected 任务关键型工作负载 系列的一部分。 如果不熟悉本系列,建议从 什么是任务关键型工作负载开始?
核心体系结构模式
全局资源
某些资源由每个区域中部署的资源全局共享。 常见示例是用于跨多个区域分配流量、存储整个应用程序的永久状态以及监视这些资源的资源。
特征 | 注意事项 |
---|---|
生存期 | 这些资源预计将在非临时) (长期存在。 其生存期等于或长于系统的生存期。 通常,这些资源是使用就地数据和控制平面更新来管理的,前提是它们支持不停机的更新操作。 |
状态 | 由于这些资源至少在系统的生存期内存在,因此此层通常负责存储全局的异地复制状态。 |
Reach | 资源应全局分布并复制到托管这些资源的区域。 建议这些资源以低延迟和所需一致性与区域或其他资源进行通信。 |
依赖项 | 资源应避免依赖区域资源,因为它们不可用可能会导致全局故障。 例如,如果单个保管库所在的区域发生故障,则保存在该保管库中的证书或机密可能会产生全局影响。 |
规模限制 | 通常,这些资源是系统中的单一实例,它们应该能够缩放,以便可以处理整个系统的吞吐量。 |
可用性/灾难恢复 | 区域和标记资源可以使用全局资源。 为整个系统的运行状况配置高可用性和灾难恢复全局资源至关重要。 |
区域标记资源
标记包含参与完成业务事务的应用程序和资源。 标记通常对应于 Azure 区域的部署。 尽管一个区域可以有多个标记。
特征 | 注意事项 |
---|---|
生存期 | 资源的生存期预计较短(临时的),其目的是可以动态添加和删除这些资源,而标记外部的区域资源将继续保留。 要为用户提供更高的复原能力、缩放性和邻近性,需要临时性。 |
状态 | 由于标记是临时的,并且将随每个部署一起销毁,因此标记应尽可能无状态。 |
Reach | 可与区域和全局资源通信。 但应避免与其他区域或其他标记进行通信。 |
依赖项 | 标记资源必须是独立的。 它们应具有区域和全局依赖项,但不应依赖于同一区域或其他区域中其他标记中的组件。 |
规模限制 | 吞吐量是通过测试确定的。 总体标记的吞吐量限制为性能最低的资源。 标记吞吐量需要估计故障转移到另一个标记所导致的高级别需求。 |
可用性/灾难恢复 | 由于标记的临时性,灾难恢复是通过重新部署标记来完成的。 如果资源处于不正常状态,则该标记可整个销毁并重新部署。 |
区域资源
系统可具有部署在区域中但生存期长于标记资源生存期的资源。 例如,监视区域级别的资源的可观测性资源,包括标记。
特征 | 注意事项 |
---|---|
生存期 | 资源与区域具有同一生存期,并且资源生存期长于标记资源生存期。 |
状态 | 存储在区域中的状态不能超过该区域的生存期。 如果需要跨区域共享状态,请考虑使用全局数据存储。 |
Reach | 资源无需全局分布。 应尽量避免与其他区域进行直接通信。 |
依赖项 | 这些资源可以依赖于全局资源,但不能依赖于标记资源,因为标记的生存期较短。 |
规模限制 | 通过组合该区域内的所有标记来确定区域资源的规模限制。 |
任务关键型工作负载的基线体系结构
这些基线示例用作任务关键型应用程序的建议北star体系结构。 基线强烈建议容器化并为应用程序平台使用容器业务流程协调程序。 基线使用 Azure Kubernetes 服务 (AKS) 。
请参阅 架构良好的任务关键型工作负载:容器化。
-
基线体系结构
-
使用网络控件的基线
此体系结构基于基线体系结构构建。 该设计进行了扩展,以提供严格的网络控制,以防止未经授权的公共访问从 Internet 访问工作负荷资源。
-
Azure 登陆区域中的基线
如果要在企业设置中部署工作负载,需要在更广泛的组织内集成,则此体系结构是合适的。 该工作负载使用集中式共享服务,需要本地连接,并与企业中的其他工作负载集成。 它部署在继承自公司管理组的 Azure 登陆区域订阅中。
-
应用服务的基线
此体系结构将应用服务视为主要应用程序托管技术,为容器部署提供易于使用的环境,从而扩展了基线参考。
设计领域
建议使用提供的设计指南来导航关键设计决策,以获得最佳解决方案。 有关信息,请参阅 什么是关键设计领域?
后续步骤
查看有关设计任务关键型应用程序方案的最佳做法。