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

Azure Spring Apps 中的可靠性

本文详细介绍了可用性区域的区域复原能力,以及跨区域灾难恢复和业务连续性对 Azure Spring Apps 的支持。

可用性区域支持

可用性区域是每个 Azure 区域内在物理上独立的数据中心组。 当一个区域发生故障时,服务可以故障转移到其余区域中的一个。

有关 Azure 中可用性区域的详细信息,请参阅什么是可用性区域?

Azure Spring Apps 支持区域冗余。 创建 Azure Spring Apps 服务实例并启用区域冗余时,Azure Spring Apps 会自动跨底层 Azure 基础结构的逻辑部分分配基本资源。 底层计算资源会跨所有可用性区域分配 VM,以确保能够进行计算。 即使数据中心发生故障,底层存储资源也会跨可用性区域复制数据,使其保持可用状态。 此分配提供更高级别的可用性,防止出现硬件故障或计划内维护事件。

先决条件

  • 区域冗余在基本计划中不可用。

  • Azure Spring Apps 支持以下区域中的可用性区域:

    • 澳大利亚东部
    • 巴西南部
    • 加拿大中部
    • 美国中部
    • 东亚
    • 美国东部
    • 美国东部 2
    • 法国中部
    • 德国中西部
    • 北欧
    • 日本东部
    • 韩国中部
    • 南非北部
    • 美国中南部
    • 东南亚
    • 英国南部
    • 西欧
    • 美国西部 2
    • 美国西部 3

创建已启用可用性区域的 Azure Spring Apps 实例

注意

仅当创建 Azure Spring Apps 服务实例时,才能启用区域冗余。 创建后,就无法更改区域冗余属性。

可以使用 Azure CLIAzure 门户在 Azure Spring Apps 中启用区域冗余。

若要使用 Azure CLI 在 Azure Spring Apps 中创建服务并启用区域冗余,请在创建服务时包含 --zone-redundant 参数,如以下示例所示:

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

启用自己的资源并启用可用性区域

可以在 Azure Spring Apps 中启用自己的资源,例如你自己的持久性存储。 但是,必须确保为资源启用区域冗余。 有关详细信息,请参阅如何在 Azure Spring Apps 中启用自己的持久性存储

区域故障体验

当应用实例由于位于故障区域中的 VM 节点上而失败时,Azure Spring Apps 将在另一个可用性区域中的另一个 VM 节点上为失败应用创建新的应用实例。 在此期间,用户可能会遇到短暂的中断。 无需用户操作,服务将恢复受影响的 Azure Spring Apps 实例。

定价

启用区域冗余不会产生额外费用。 只需为需要启用区域冗余的标准计划或企业计划付费。

跨区域灾难恢复和业务连续性

灾难恢复 (DR) 是指从会导致故障时间和数据丢失的高影响事件(例如自然灾害或部署失败)中恢复。 不管灾难的原因是什么,最好的补救措施就是一个定义全面且经过测试的 DR 计划,以及一个主动支持 DR 的应用程序设计。 在开始考虑创建灾难恢复计划之前,请参阅设计灾难恢复策略的建议

在 DR 方面,Microsoft 使用责任共担模型。 在共担责任模型中,Microsoft 会确保基线基础结构和平台服务可用。 同时,许多 Azure 服务不会自动复制数据,也不会从失败区域回退以交叉复制到另一个启用的区域。 对于这些服务,你负责设置适用于工作负载的灾难恢复计划。 大多数在 Azure 平台即服务 (PaaS) 产品/服务上运行的服务都提供支持 DR 的功能和指导,你可以使用特定于服务的功能来支持快速恢复,从而帮助制定 DR 计划。

Azure Spring Apps 服务不提供异地灾难恢复,但仔细规划有助于防止停机。

若要确保高可用性并预防灾难,请将 Azure Spring Apps 中托管的应用程序部署到多个区域。 Azure 提供了一系列配对区域,使你可以相应地规划应用部署。

设计体系结构时,请考虑以下关键因素:

  • 区域可用性。 若要最大程度地减少网络延迟和传输时间,请选择支持 Azure Spring Apps 区域冗余的区域,或靠近用户的地理区域。
  • Azure 配对区域。 为了确保以协调的方式进行平台更新,并根据需要确定恢复工作的优先级,请选择所选地理区域中的配对区域。
  • 服务可用性。 确定配对区域应当采用热/热、热/暖还是热/冷模式运行。

使用 Azure 流量管理器路由流量

Azure 流量管理器提供基于 DNS 的流量负载均衡,并可以在多个区域之间分配网络流量。 使用 Azure 流量管理器将客户定向到最近的 Azure Spring Apps 服务实例。 为了实现最佳性能和冗余,请先通过 Azure 流量管理器定向所有应用程序流量,然后再将其发送到你的 Azure Spring Apps 服务实例。 有关详细信息,请参阅什么是流量管理器?

如果 Azure Spring Apps 中的应用程序在多个区域中运行,Azure 流量管理器可以控制在每个区域中流向你的应用程序的流量流。 使用实例 IP 为每个服务实例定义 Azure 流量管理器终结点。 应连接到指向 Azure Spring Apps 服务实例的 Azure 流量管理器 DNS 名称。 Azure 流量管理器将在所定义的终结点之间对流量进行负载均衡。 如果数据中心遭受灾难,Azure 流量管理器会将来自该区域的流量定向到其配对区域,以确保服务连续性。

使用以下步骤为 Azure Spring Apps 实例创建 Azure 流量管理器实例:

  1. 在两个不同的区域中创建 Azure Spring Apps 实例。 例如,在美国东部和欧洲西部创建服务实例,如下表所示。 每个实例充当流量的主要终结点和故障转移终结点。

    服务名称 位置 应用程序
    service-sample-a 美国东部 gateway / auth-service / account-service
    service-sample-b 西欧 gateway / auth-service / account-service
  2. 为服务实例设置自定义域。 有关详细信息,请参阅教程:将现有的自定义域映射到 Azure Spring Apps。 成功设置后,这两个服务实例将绑定到同一自定义域,例如 bcdr-test.contoso.com

  3. 创建流量管理器和两个终结点。 有关说明,请参阅快速入门:使用 Azure 门户创建流量管理器配置文件,其中介绍了如何生成以下流量管理器配置文件:

    • 流量管理器 DNS 名称:http://asa-bcdr.trafficmanager.net
    • 终结点配置文件:
    配置文件 类型 目标 优先度 自定义标头设置
    终结点 A 配置文件 外部终结点 service-sample-a.azuremicroservices.io 1 host: bcdr-test.contoso.com
    终结点 B 配置文件 外部终结点 service-sample-b.azuremicroservices.io 2 host: bcdr-test.contoso.com
  4. 在类似于以下示例的 DNS 区域中创建 CNAME 记录:bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net

环境现已设置完毕。 如果使用了链接文章中的示例值,则应能够使用 https://bcdr-test.contoso.com

使用 Azure Front Door 和 Azure 应用程序网关路由流量

Azure Front Door 是可缩放的全局入口点,它使用 Microsoft 全局边缘网络来创建快速、安全且可大规模缩放的 Web 应用程序。 Azure Front Door 提供与 Azure 流量管理器相同的多地理位置冗余和路由到最近区域功能。 Azure Front Door 还提供高级功能,如 TLS 协议终止、应用层处理和 Web 应用程序防火墙 (WAF)。 有关详细信息,请参阅什么是 Azure Front Door?

下图显示了多区域冗余、集成虚拟网络的 Azure Spring Apps 服务实例的体系结构。 该图显示了具有自定义域的应用程序网关和 Front Door 的正确反向代理配置。 此体系结构基于在虚拟网络中使用端到端 TLS 公开应用程序中所述的方案。 这种方法将两个集成了应用程序网关的 Azure Spring 应用程序虚拟网络注入实例组合到一个地理冗余实例中。

显示多区域 Azure Spring Apps 服务实例体系结构的示意图。

后续步骤