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

多租户和 Azure 事件中心

事件中心是一个大数据流式处理平台和事件引入服务,每秒能够接收和处理数百万个事件。 你可以使用实时分析提供程序和批处理/存储适配器来转换和存储事件中心数据。 有关事件中心和其他 Azure 消息传送服务的比较,请参阅在 Azure 消息传送服务之间进行选择 - 事件网格、事件中心和服务总线

本文介绍可在多租户解决方案中使用的事件中心功能和隔离模型。

隔离模型

在多租户系统中使用事件中心时,需要确定所需的隔离级别。 事件中心支持不同的多租户模型。

  • 受信任的多租户:所有租户共享一个事件中心命名空间。 当所有租户都位于组织中时,此选项可能适用。
  • 恶意多租户:每个租户都有不共享的私有命名空间。 当你希望确保租户没有近邻干扰问题时,此选项可能适用。

一个系统可以实现这两个模型:一些租户共享命名空间,另一些租户有一个专用的命名空间。 此外,租户可以与其他租户共享命名空间,但具有专用的事件中心。

下表汇总了事件中心的主要租户隔离模型之间的差异。 以下各节将更详细地介绍这些模型。

注意事项 专用命名空间 共享命名空间、专用事件中心 共享命名空间和事件中心
数据隔离 中等
性能隔离 最高。 根据每个租户的要求管理性能需求。 中等。 可能有近邻干扰问题。 低。 可能有近邻干扰问题。
部署复杂性 中。 请注意订阅级别的事件中心配额和限制 中等。 必须为每个租户部署单独的消息实体。 请注意事件中心配额和限制。 在某些情况下,需要多个命名空间,具体取决于租户数。
操作复杂性 高。 需要按租户管理命名空间。 中等。 某些租户需要对消息实体进行精细管理。
示例方案 每个租户的单独应用程序实例。 每个租户的专用事件中心。 具有共享应用层和一个或多个共享事件中心的大型多租户解决方案。

注意

适用于 Apache Kafka 的事件中心是一项功能,在事件中心之上提供协议头,以便事件中心可供 Apache Kafka 应用程序使用。 应用程序将事件流式传输到事件中心,这些事件中心等效于 Kafka 主题。 有关详细信息,请参阅什么是适用于 Apache Kafka 的事件中心

专用命名空间

在此模型中,为每个租户预配事件中心命名空间。 此方法提供最大隔离级别,并能够为所有租户提供可接受的性能。

可以使用以下技术微调事件功能,以满足租户要求:

如果达到 Azure 订阅中事件中心命名空间的最大数量,则可以使用部署标记模式跨不同订阅部署命名空间。

此隔离模型的缺点是,随着租户数量的增长,命名空间的管理变得更加复杂。 另一个缺点是模型会增加成本,因为要为每个命名空间付费。

共享命名空间、专用事件中心

即使命名空间由多个租户共享,也可以将租户隔离到专用事件中心。 可以使用共享访问签名或 Microsoft Entra 标识来控制访问。

随着系统中租户数的增长,事件中心的数量也会增加,以适应每个租户。 这种增长会导致更高的运营成本和更低的组织敏捷性。 每个命名空间的事件中心数都有限制。 因此,系统所需的命名空间数取决于租户所需的事件中心数。

共享命名空间时,更可能出现近邻干扰问题。 例如,租户的事件实体可能会消耗不成比例的命名空间资源,并妨碍其他租户。 事件中心命名空间对其处理单元(高级层)或容量单位(专用层)以及到名称空间的中转连接数都有限制。 考虑单个租户是否可能消耗过多的资源。

共享命名空间和事件中心

可以拥有由所有租户共享的命名空间和事件实体。 此模型可降低操作复杂性并降低资源成本。

然而,使用共享命名空间可能会导致近邻干扰问题,并导致某些租户的延迟更高。 还必须实现应用程序,以便为多个租户提供服务。 共享事件中心和 Kafka 主题不会在租户之间提供数据隔离,因此必须满足应用程序逻辑中的数据隔离要求。

注意

请勿使用事件中心分区来尝试隔离租户。 在事件中心进行分区可以处理事件和可伸缩性,但它不是隔离模型。 可以直接将事件发送到分区,但不建议这样做,因为这会将事件中心的可用性降级到分区级别。 有关详细信息,请参阅事件中心内的可用性和一致性

支持多租户的事件中心的功能

事件中心的以下功能支持多租户:

以下各节讨论了这些功能。

应用程序组

应用程序组是一个或多个与事件中心数据平面交互的客户端应用程序的集合。 通过将配额和访问管理策略应用于组本身,可以将配额和访问管理策略应用于组中的所有应用程序。

每个应用程序组的范围都可以限定为单个事件中心命名空间或单个事件中心。 它应使用客户端应用程序的唯一标识条件标识符,例如安全上下文,它是共享访问签名 (SAS) 或 Microsoft Entra 应用程序 ID。

有关详细信息,请参阅使用应用程序组进行资源治理

Microsoft Entra 身份验证

事件中心与 Microsoft Entra ID 集成。 客户端可以通过将托管标识与 Microsoft Entra ID 配合使用来对事件中心资源进行身份验证。 事件中心定义一组内置角色,可授予租户以访问事件中心实体。 例如,通过使用 Microsoft Entra 身份验证,可以授权租户访问包含该租户消息的事件中心。 可以使用此方法将租户与其他租户隔离开来。

Kafka 应用程序可以使用托管标识 OAuth 访问事件中心资源。

有关详细信息,请参阅以下文章:

共享访问签名

使用共享访问签名 (SAS),你可以授予租户对具有特定权限的事件中心资源的访问权限。 如果在事件实体级别隔离租户,则可以在仅适用于特定租户的事件中心或 Kafka 主题上授予 SAS 密钥。

有关详细信心,请参阅使用共享访问签名 (SAS) 对事件中心资源访问进行身份验证

客户管理的密钥

如果租户需要自己的密钥来加密和解密事件,则可以在某些事件中心版本中配置客户管理的密钥。

此功能要求使用专用命名空间隔离模型。 只能为新的或空的命名空间启用加密。

有关详细信息,请参阅配置客户管理的密钥以加密静态 Azure 事件中心数据

事件中心捕获

可以使用事件中心捕获功能从事件中心自动捕获流数据,并将其存储到 Azure Blob 存储或 Data Lake Storage 帐户。

此功能可用于存档事件。 例如,如果出于合规性原因需要存档租户的事件,可以部署特定于租户的命名空间,并启用事件中心捕获以将事件存档到特定于租户的 Azure 存储帐户。 还可以在共享命名空间中特定于租户的事件中心启用事件中心捕获。

有关详细信息,请参阅通过 Azure Blob 存储或 Azure Data Lake Storage 中的 Azure 事件中心来捕获事件

异地灾难恢复

异地灾难恢复持续将事件中心命名空间的整个配置从主命名空间复制到与主命名空间配对的辅助命名空间。 此功能有助于从灾难(例如区域性故障)中恢复。

例如,如果在命名空间级别隔离租户,则可以将租户命名空间的配置复制到次要区域,以防止主区域发生中断和故障。

有关详细信息,请参阅 Azure 事件中心 - 异地灾难恢复

注意

为了帮助保护运营的连续性,异地灾难恢复将主要命名空间的配置复制到辅助命名空间。 它不会复制事件数据,也不会复制用于主命名空间的任何 Microsoft Entra RBAC 分配。 有关详细信息,请参阅多站点和多区域联合

IP 防火墙规则

可以使用 IP 防火墙规则来控制对命名空间的访问。 在命名空间级别隔离租户时,可以将命名空间配置为仅接受来自允许的 IP 地址或地址范围的客户端的连接。

有关详细信息,请参阅:

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

首席作者:

其他参与者:

若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

后续步骤