Azure 通知中心 的可靠性

Azure 通知中心可帮助你跨多个平台通知系统（例如 Apple 推送通知服务（APNs）、Firebase Cloud Messaging（FCM）和Windows推送通知服务（WNS）管理推送通知。

使用 Azure 时，可靠性是共同的责任。 Azure 提供了一系列支持复原和恢复的功能。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍如何使通知中心能够灵活应对各种潜在的中断和问题，包括暂时性故障、可用性区域故障、区域范围的故障和服务维护。 它还介绍了有关通知中心服务级别协议（SLA）的备份和还原选项和密钥信息。

生产部署建议

对于生产工作负荷，请遵循以下建议：

  • 使用基本层或标准层，以使您的命名空间符合 SLA 适用条件。

  • 如果可能，请使用安装，而不是在设备应用程序中注册。

  • 使用Microsoft提供的 SDK 与通知中心交互。

  • 启用区域冗余。

  • 若要为区域范围的中断做好准备，请启用元数据灾难恢复到另一个Azure区域。 规划如何备份和还原设备注册和安装。

可靠性体系结构概述

Azure 通知中心围绕命名空间和通知中心进行组织。 命名空间是包含一个或多个中心的管理边界。 中心表示应用程序的终结点。 设备使用 注册 或 安装向这些终结点注册，使服务能够向设备发送推送通知。 有关详细信息，请参阅 注册管理。

通知中心将推送通知发送到平台通知系统（PNS），例如 Apple 推送通知服务（APNs）和 Firebase Cloud Messaging（FCM）。 端到端通知传递取决于通知中心的可用性以及下游 PNS 提供程序的行为。

对于可靠性规划，请务必区分通知中心管理的以下数据类型：

  • 元数据： 命名空间和中心配置，包括连接信息和灾难恢复配置。
  • 注册数据：将用户和设备映射到标记和模板的设备注册和安装信息。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。

通知中心会自动处理连接到 PNS 时发生的暂时性故障。 但是，当服务或用户的设备与通知中心交互时，你负责处理暂时性故障。 在注册操作、通知发送操作和管理操作期间可能会发生暂时性故障。 遵循以下指南：

  • 注册和安装： 设备上的应用程序应重试由于暂时性故障而失败的注册和安装操作。 Microsoft提供的 SDK 自动处理重试。 如果无法使用提供的 SDK，请实现带有指数退避和抖动的重试逻辑，并尽可能使注册操作具有幂等性。

    创建或更新安装这一操作是幂等的，因此可以安全地重试该操作。 如果可能，请使用安装而不是注册。

  • 通知发送和管理操作：使用Microsoft提供的 SDK 发送推送通知并执行管理操作。 发生暂时性故障时，这些 SDK 会自动重试。

    如果无法使用提供的 SDK，请实现带有指数退避和抖动的重试逻辑，并在可能的情况下使通知发送操作具备幂等性。

应对可用区故障的弹性

可用性区域 是 Azure 区域内物理上独立的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。

在支持可用性区域的区域中，通知中心命名空间支持 区域冗余 配置。 通知中心会自动为某些区域中的所有命名空间启用区域冗余。 启用区域冗余后，Microsoft跨区域中所有可用性区域复制元数据和注册数据。

显示区域冗余通知中心命名空间的示意图，该命名空间使用区域中的三个可用性区域。

Requirements

  • 区域支持：

    Notification Hubs 会自动为以下区域中的所有命名空间启用区域冗余。 不能在这些区域中禁用区域冗余：

    亚太
    中国北部 3

    在其他 支持通知中心 且具有 可用性区域的区域中，区域冗余是可选的。 只能在创建命名空间时启用它。

  • 层支持： 可以将可用性区域与通知中心的所有层配合使用。

Cost

区域冗余会产生超出层价格的额外费用。 有关详细信息，请参阅 通知中心定价。

配置可用性区域支持

  • 创建新的区域冗余命名空间： 创建新区域冗余命名空间的过程取决于你使用的区域：

    • 在通知中心自动启用区域冗余的区域中，无需对其进行配置。

      Important

      在这些区域中，通知中心始终创建启用了区域冗余的命名空间，即使基于代码的部署（如Bicep文件或Azure 资源管理器模板）也指定禁用区域冗余。

      如果不需要区域冗余命名空间，请在支持可选区域冗余的区域中创建它。

    • 在区域冗余是可选的区域中，只能在创建命名空间时启用它。 若要了解如何设置具有区域冗余的新命名空间，请参阅在Azure门户中创建Azure通知中心。

  • 使现有命名空间区域冗余： 通知中心不支持就地将现有命名空间迁移到可用性区域支持。 需要部署新命名空间并将注册移动到该命名空间。 按照Azure区域之间移动资源的指南进行操作，如果在同一区域中部署新命名空间，也会适用该指南。

所有区域正常时的行为

本节介绍当将通知中心命名空间配置为区域冗余且所有区域均正常运行时的预期情况。

  • 跨区域操作： 通知中心通过使用区域中任何区域中的基础结构自动分发和处理请求。

  • 跨区域数据复制： 注册数据和元数据在指定区域的所有区域中同步复制。

区域故障期间的行为

本部分介绍在为通知中心命名空间配置区域冗余后，如果其中一个区域发生中断，可能会出现的情况。

  • 检测和响应： Microsoft 检测区域故障并在区域内管理故障转移。 无需启动故障转移。

  • 进行中的请求： 在故障转移期间，正在进行中的管理操作、设备注册以及发送通知的新请求可能会失败。 应用程序应按照 暂时性故障处理指南重试失败的操作。

  • 预期数据丢失： 由于通知中心跨可用性区域同步复制命名空间和中心配置和注册数据，因此在单区域中断期间不会发生数据丢失。

    此复制不是备份。 在共同责任模型中，你负责备份注册和安装数据。 有关详细信息，请参阅 备份和还原。

  • 预期的停机时间：Microsoft重新路由流量时，可能会发生短暂的服务中断。 按照 暂时性故障处理指南 为这些中断准备应用程序。

  • 重新分发： 该服务会自动将请求重定向到正常区域。

区域恢复

当受影响的区域恢复时，无需执行任何操作。 Microsoft还原并重新平衡通知中心基础结构以使用恢复的区域。

测试区域故障

无法直接触发 Notification Hubs 区域故障转移。 若要测试工作负荷的行为，请在非生产环境中针对重试、幂等性和依赖项故障进行弹性测试。 还可以使用Azure Chaos Studio测试周围的应用程序组件。

对区域范围的故障的复原能力

通知中心通过 跨区域复制命名空间元数据来提供元数据灾难恢复，但不会复制设备注册数据。 此功能需要在区域发生中断期间进行手动干预，并且会导致您的通知中心出现一定的停机时间。

如果需要减少故障转移期间的停机时间和手动干预，请考虑使用 自定义多区域解决方案。

用于复原的自定义多区域解决方案

Microsoft 管理的元数据异地灾难恢复仅复制元数据。 此功能可以将该元数据恢复到辅助命名空间，但你负责将设备注册导入该命名空间，以便应用程序可以继续操作。 此方法需要在灾难期间进行手动干预，并且需要停机。

如果恢复目标需要更少的停机时间或手动干预，则可以实现自定义主动-主动多区域解决方案。 提前将第二个通知中心命名空间部署到另一个Azure区域。

Note

本部分提供有关设计此类解决方案的基本指南。 你负责设计、实现、测试、部署、故障转移和管理解决方案。

  • 故障转移： 由于第二个命名空间是一个可用资源，因此您可以实现相应逻辑来检测区域发生故障，并切换到该命名空间。

  • 同步： 若要使第二个通知中心与主通知中心保持同步，请使用以下选项之一：

    • 对于安装： 使用同时在两个通知中心创建和更新安装的应用后端。 通过安装，可以指定自己的唯一设备标识符，该标识符支持此复制方案。 有关详细信息，请参阅 RedundantHub 示例。

    • 注册： 使用应用后端，该后端定期将注册从主通知中心导出为备份，并将其批量导入辅助通知中心。 有关详细信息，请参阅批量导出和导入Azure 通知中心注册。

    或者，如果没有后端，请将应用配置为在目标设备上启动时在两个中心中创建安装。 设备会在这两个通知中心中创建新的注册信息。 最终，辅助通知中心已注册所有活动设备。

  • 注册和安装过期： 辅助通知中心可能已过期注册和安装。 当向已过期的句柄发送推送时，Notification Hubs 会根据从 PNS 服务器收到的响应，自动清理通知中心中关联的注册或安装记录。 可以通过添加自定义逻辑来清理所选备份解决方案中的过期记录，以便处理来自每个发送的反馈并删除过期的注册和安装。

  • 未打开的应用： 有一段时间后，具有未打开的应用的设备不会收到通知。

  • 成本： 如果使用自己的辅助中心来保护注册数据，则中心会产生正常的服务费用。 同样，如果将任何其他Azure资源部署到次要区域以支持恢复，则按正常服务费率为这些资源付费。

备份和还原

通知中心不会为命名空间中存储的所有数据提供单一内置备份和还原功能。 你负责组合以下方法：

  • 使用基础结构即代码（如 Bicep）来定义命名空间、中心和策略配置。 将这些定义存储在源代码管理中，以便在必要时重新部署资源。
  • 通过批量导出 Azure 通知中心 注册信息来备份设备注册数据。

导出的注册集可在发生意外删除或非预期更改后提供一个恢复点。 IaC 会保留资源配置，但它不会保留设备注册数据。 有关冗余和备份的不同角色的详细信息，请参阅 冗余、复制和备份。

服务维护期间的系统弹性能力

Microsoft定期应用服务更新并执行其他维护。 Azure平台会自动处理这些活动，确保维护是无缝且透明的。 除非通过 Azure 服务运行状况 计划内维护 通知，否则在维护事件期间不会有停机。

服务级别协议

Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 联机服务的 SLA。

对于通知中心，可用性 SLA 适用于使用基本层和标准层的命名空间。

相关内容

  • Última atualização em