通过


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

Azure 事件网格中的可靠性

Azure 事件网格 是一种完全托管的消息传送服务,用于在服务和应用程序之间实现基于事件的通信。 它通常用于生成事件驱动的体系结构,并将 Azure 服务与自定义应用程序集成。

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

本文介绍如何提高 Azure 事件网格的复原能力,以应对各种潜在的中断和问题,包括暂时性故障、可用性区域故障和区域范围的故障。 它还突出显示了有关 Azure 事件网格服务级别协议(SLA)的关键信息。

生产部署建议

Azure Well-Architected 框架提供有关可靠性、安全性、成本、作和性能的建议。 若要了解这些领域如何相互影响并有助于可靠的 Azure 事件网格解决方案,请参阅 Azure 事件网格的 Azure Well-Architected 框架指南

可靠性体系结构概述

本部分介绍从可靠性的角度来看,服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构,其中包括部署和使用的某些资源和功能。 它还讨论了物理架构,该架构提供了服务内部运作方式的详细信息。

逻辑体系结构

Azure 事件网格将事件从事件 发布者 路由到事件 使用者。 客户应用程序和 Azure 服务都使用它来发布和消费事件,例如在资源创建、更新或删除时发布和消费通知。

事件网格支持多种资源类型和部署模型:

  • 主题 是接收和存储事件的主要实体。

    系统主题 由 Azure 服务自动创建,以针对特定 Azure 资源类型发出事件。 自定义主题 由你创建和管理。

    主题可以支持 推送和拉取传递

  • 事件域 在单个终结点下对多个自定义主题进行分组,从而简化事件的发布。 有关详细信息,请参阅了解用于管理事件网格主题的事件域

  • 命名空间 与标准层一起使用,并为多个事件网格资源提供容器。 有关详细信息,请参阅 Azure 事件网格命名空间概念

事件网格支持多个层,包括基本层和标准层。 这些层提供不同的功能,它们在部署和管理资源的方式上有所不同。 有关详细信息,请参阅 为解决方案选择正确的事件网格层

物理体系结构

Azure 事件网格是一项完全托管的服务。 Microsoft管理底层基础结构,包括计算和存储资源。 在受支持的区域中,事件网格 会自动跨可用性区域分配资源 ,以提供内置区域冗余。

暂时性故障的复原能力

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

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

使用事件网格时,请考虑以下做法以确保您的解决方案能够应对暂时性故障:

  • 事件发布者: 当客户端应用程序将事件发布到事件网格时,它负责处理暂时性故障。 应用程序应在发布事件时实现重试逻辑。 有关详细信息,请参阅 排查暂时性连接问题

    建议使用 事件网格数据平面 SDK,这些 SDK 会自动提供暂时性故障处理。

  • 事件使用者: 事件网格将事件传送到配置的目标。 对于这些出站连接,可以在事件订阅上配置重试策略。 这些策略定义发生故障时事件网格重试传递的频率和时长,包括暂时性故障。 有关详细信息,请参阅 消息推送传递和使用命名空间主题重试

  • 幂等性:幂等性设计事件体系结构是一种很好的做法,这意味着可以多次安全地接收和处理事件。 例如,如果应用程序正在处理事件时发生暂时性故障或其他问题,则幂等方法意味着应用程序可以重新处理消息并恢复。

    你负责设计事件体系结构和应用程序以支持幂等性。 有关更多信息,请参阅 幂等性

  • 死信队列:事件网格支持对无法交付的事件使用死信队列,这有助于在事件消费者出现长期故障期间持久化数据。 有关详细信息,请参阅 Azure 事件网格中命名空间主题的事件订阅的死信

应对可用区故障的弹性

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

支持可用性区域的区域中的 Azure 事件网格资源是区域冗余的。 区域冗余意味着即使可用性区域出现问题,事件网格资源也会继续使用其他区域中的基础结构。 事件数据在三个可用性区域中自动复制,以实现区域内部复原,并在区域范围的服务中断期间进行事件网格自我愈合。 无需启用或配置此功能。

要求

区域支持: 区域冗余适用于所有 支持可用性区域的 Azure 区域

Cost

区域冗余无需额外付费。 不能启用或禁用此功能;默认情况下,它包含在受支持的区域中。

配置可用性区域支持

无需配置。 支持区域内的所有事件网格资源均具有自动化的区域级冗余功能。

所有区域正常时的行为

本部分介绍当事件网格资源为区域冗余且所有区域都正常运行时会发生什么情况。

  • 跨区域操作: 事件网格在跨可用性区域的主动-主动模型中运行。 客户端连接会跨区域自动负载均衡,服务无论区域如何,都会将操作路由到可用的消息传送基础设施。

  • 跨区域数据复制: 事件网格自动跨可用性区域复制元数据和事件数据,以保持复原能力。

区域故障期间的行为

本部分介绍当事件网格资源具备区域冗余功能时,以及其中一个区域发生中断时可能出现的情况。

  • 检测和响应: 事件网格会自动检测区域故障,并启动故障转移到正常区域。 无需执行任何操作即可启动区域故障转移。
  • 活动请求: 在区域故障期间,事件网格可能会删除活动请求。 如果客户端适当地处理 暂时性故障 ,例如在短时间内重试,它们通常会避免产生重大影响。

  • 预期数据丢失: 事件网格区域冗余模型旨在实现对区域故障的复原能力,影响最小。 但是,在发生区域故障期间,可能会丢失数据。

    如果需要确保应用程序即使在区域故障期间也不会丢失数据,则应:

    • 设计事件生成者和使用者以遵循 暂时性故障处理建议,包括重试和幂等性。
    • 在源或持久事件存储中规划事件持续性。
  • 预期的停机时间: 区域故障可能会导致几秒钟的停机时间。 如果客户端适当地处理 暂时性故障 ,例如在短时间内重试,它们通常会避免产生重大影响。

  • 流量重新路由: 事件网格检测到区域丢失,并自动将新请求重定向到一个正常的可用性区域中的基础结构。

区域恢复

当受影响的区域恢复时,事件网格会自动将其重新集成到服务中,而无需客户操作。 然后,恢复的区域将接受新的连接,并与其他区域一起处理消息。 在中断期间复制到幸存区域的数据保持不变,所有区域中的正常复制都会恢复。 无需采取措施进行区域恢复或重新集成。

测试区域故障

事件网格管理区域故障的流量路由、故障转移和区域恢复,因此无需验证可用性区域故障过程或提供进一步的输入。

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

事件网格资源部署到单个区域。 如果发生区域范围的故障,则事件网格资源不可用。

配对的 Azure 区域中,Event Grid 为您的 Event Grid 资源的元数据提供有限的异地灾难恢复。 还可以设计和构建自己的多区域解决方案,从而支持灾难恢复规划。 下表显示了不同的事件网格资源类型如何支持每个模型:

事件网格资源 支持地理灾难恢复 支持自定义解决方案
自定义主题 已支持 已支持
系统主题 自动启用 不支持
域名 已支持 已支持
命名空间 不支持 已支持
合作命名空间 不支持 已支持

地质灾害恢复

异地灾难恢复将事件网格元数据复制到主要区域的配对区域,以获取支持的资源。 不会复制事件数据。

zh-CN: 异地灾难恢复设计为在严重区域性中断时尽力而为,由Microsoft管理的回退方案,并非旨在提供快速或可预测的恢复时间。 在少数情况下,Microsoft 会执行其启动的故障转移,将事件网格资源从受影响的区域转移到对应的异地配对区域。 Microsoft 有权决定何时执行此选项。 在流量故障转移之前,此机制不涉及客户同意。

重要

Microsoft 触发 Microsoft 托管的故障转移。 很可能在出现重大延迟后发生,并尽最大努力完成。 事件网格资源的故障转移可能会在不同于其他 Azure 服务的时间发生。

如果需要应对区域故障,请考虑使用自定义多区域弹性解决方案之一。

可以选择禁用异地灾难恢复,并使用自己的 自定义多区域解决方案 来满足区域选择、故障转移时间等要求。 禁用跨区域灾难恢复时,不会将Microsoft的事件数据复制到另一个区域。

此功能在没有配对区域的区域中不可用。

要求

  • 区域支持: 异地灾难恢复仅在具有配对区域的 Azure 区域中可用。

  • 资源类型: 自定义主题和域支持异地灾难恢复。 系统主题会自动启用跨地域灾难恢复。 不支持其他资源类型,例如命名空间和合作伙伴命名空间。

Cost

异地灾难恢复无需额外付费。

配置多区域支持

在受支持的区域中,系统主题会自动配置为进行异地灾难恢复。 对于其他事件网格资源类型:

  • 若要启用异地灾难恢复,请: 更新主题或域的配置,然后选择 “跨地理位置 ”(默认值)。

  • 若要禁用异地诊断恢复,请: 更新主题或域的配置,然后选择“ 区域”。

当所有区域都正常时的行为

本部分描述了在为事件网格资源配置地理灾难恢复时的预期情况,以及当所有区域正常运行时的状态。

  • 跨区域操作: 所有流量都路由到主要区域。

  • 跨区域数据复制: 元数据同步复制到配对区域。 不会复制事件数据。

区域故障期间的行为

本部分介绍为地理灾难恢复配置事件网格资源时应期待的情况,以及如果主要区域发生中断,该如何应对。

  • 检测和响应: Microsoft检测区域故障,并确定是否以及何时启动故障转移。
  • 活动请求: 对主要区域的活动请求将终止。 故障转移完成后,客户端应用程序必须重试这些请求。

  • 预期数据丢失:

    • 元数据:事件网格在故障转移期间保留元数据。 由于所有元数据更改都是同步复制的,因此不会丢失元数据。

    • 事件数据: 主要区域中的事件数据不可用,如果区域不可恢复,可能会丢失。

      发生故障转移后,将从配对区域处理新数据。 在缓解服务中断后,将从主要区域调度未处理的事件。 如果主要区域的恢复需要的时间长于 针对事件设置的生存时间值,则可能会删除主要区域中的数据。 若要缓解此数据丢失,建议 为事件订阅配置死信目标

      如果受影响的区域丢失且不可恢复,则会出现一些数据丢失。 在最佳情况下,使用者会跟上发布速率,并且仅丢失几秒钟的数据。 最糟糕的情况是,当消费者未主动处理事件时,且最长生存时间为 24 小时,数据丢失最多可以达到 24 小时。

      注释

      事件网格无法保证区域中断期间的数据保留。 如果需要有保证的保留期,则需要将应用程序设计为将事件持久存储在另一个数据存储中。

  • 预期的停机时间: 停机时间量取决于中断的严重性以及Microsoft评估和启动故障转移所需的时间。 应预计停机时间至少为一小时,可能更长。

    启动故障转移后,在五分钟内,事件网格开始接受主题和订阅的流量,包括创建、更新和删除操作。

  • 重分配: 故障转移完成后,流量会自动路由到备用区域。

区域恢复

Microsoft负责管理区域恢复,而恢复过程取决于具体的故障情景。 一般情况下,故障转移通常被视为单向操作。

针对区域故障进行测试

Azure 事件网格管理流量路由、故障转移和恢复,以便进行异地灾难恢复。 你不需要开始任何事情。 由于此功能完全托管,因此无需验证区域故障进程。

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

可能考虑不依赖或禁用微软发起的故障转移机制,具体原因如下:

  • 需要跨区域复制事件数据,而不仅仅是元数据。
  • 需要保证特定的故障转移时间或方法。 Microsoft 发起的故障转移是尽最大努力完成的。
  • 你的区域未与其他 Azure 区域配对。
  • 你的区域配对不符合你组织的数据驻留要求。

为了提高控制和可预测性,可以实现自定义多区域体系结构。 此方法涉及在多个区域中部署单独的事件网格资源,并在应用程序级别管理故障转移。 使用此模型时,你负责跨区域部署、配置和保持资源同步。

设计多区域解决方案时,请考虑以下因素:

  • 复制: 应实现自定义过程,以在主要区域和次要区域之间复制事件网格资源及其配置。 请记住复制客户端标识、CA 证书、客户端组、主题空间和权限绑定(如果适用)。 可以决定是实现手动复制还是自动复制。

  • 故障转移策略: 可以选择是创建主动-主动还是主动-被动解决方案:

    • 可以通过复制元数据并在命名空间之间实现负载均衡来实现双活解决方案
    • 主从解决方案可以通过复制元数据来使辅助命名空间保持就绪,以便在主命名空间不可用时,将流量定向到辅助命名空间。
  • 运行状况监视: 可以使用事件网格提供的内置运行状况 API 来监视主题的运行状况。

    客户端应用程序必须检测某个区域的故障,并将事件路由到另一个适当的区域。

    或者,您可以实施入口服务,在这些终结点执行运行状况检查,以便将客户端定向到其主题或命名空间的主要或次要终结点。 接待服务可以是一个 Web 应用程序,可通过 DNS 重定向技术或服务(如 Azure 流量管理器)进行异地复制和保持可访问性。

有关一种方法(包括示例代码)的详细信息,请参阅 Azure 事件网格中的客户端故障转移实现

备份和还原

事件网格主要是事件路由服务,没有本机备份或还原功能。

如果需要实现备份功能,或者需要长期保留,我们建议在应用程序中执行存档。 为此,您应建立逻辑,将事件路由或复制到持久存储(例如 Azure Blob 存储),同时与主要传送路径并行进行。 如果下游系统不可用,应用程序可以使用存档来重播事件。

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

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

服务级别协议

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

事件网格可用性 SLA 涵盖事件发布。