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

什么是适用于 Apache Kafka 的 Azure 事件中心

本文介绍如何使用 Azure 事件中心从 Apache Kafka 应用程序流式传输数据,而无需自己设置 Kafka 群集。

注意

此功能仅在标准、高级和专用层中受支持

概述

Azure 事件中心在一个事件中心提供 Apache Kafka 终结点,使用户能够使用 Kafka 协议连接到事件中心。 通常,可以从应用程序使用事件中心的 Kafka 终结点,而无需更改任何代码。 你只修改配置,即更新配置中的连接字符串以指向事件中心公开的 Kafka 终结点,而不是指向 Kafka 群集。 然后,可以从使用 Kafka 协议的应用程序开始将事件流式传输到事件中心,这等效于 Kafka 主题。

注意

用于 Kafka 生态系统的事件中心支持 Apache Kafka 版本 1.0 及更高版本。

Apache Kafka 和 Azure 事件中心概念映射

从概念上讲,Kafka 和事件中心非常相似。 它们都是为流式处理数据生成的已分区日志,因此,客户端可以控制它要读取保留的日志的哪一部分。 下表映射 Kafka 和事件中心之间的概念。

Kafka 概念 事件中心概念
群集 命名空间
主题 事件中心
分区 分区
使用者组 使用者组
Offset Offset

Apache Kafka 和 Azure 事件中心之间的主要区别

尽管 Apache Kafka 是你通常需要安装和操作的软件,但事件中心是一种完全托管的云原生服务。 没有需要管理和监视的服务器、磁盘或网络,也没有需要考虑或配置的中转站。 你需要创建一个命名空间(即具有完全限定的域名的终结点),然后在该命名空间中创建事件中心(主题)。

有关事件中心和命名空间的详细信息,请参阅事件中心功能。 作为云服务,事件中心使用单一稳定的虚拟 IP 地址作为终结点,因此客户端无需了解群集中代理或计算机的情况。 尽管事件中心实现了同一协议,但此差异意味着所有分区的所有 Kafka 流量都可通过这一个终结点以可预测方式进行路由,而无需对群集的所有中转站进行防火墙访问。

事件中心的规模由你购买的吞吐量单位 (TU)处理单位的数量控制。 如果为标准层命名空间启用自动扩充功能,则当你达到吞吐量限制时,事件中心会自动纵向扩展 TU。 此功能也适用于 Apache Kafka 协议支持。 对于高级层命名空间,可以增加分配给命名空间的处理单位的数量。

Apache Kafka 是适合你的工作负载的解决方案吗?

Apache Kafka 源自于使用 Apache Kafka 构建应用程序,也有助于理解 Azure 事件中心是一系列服务的一部分,这些服务还包括 Azure 服务总线Azure 事件网格

虽然某些 Apache Kafka 的商业分发提供商可能会指出 Apache Kafka 是所有消息平台需求的一站式商店,但事实是 Apache Kafka 还没有实现,例如,竞争使用者队列模式在某个级别不支持发布-订阅,而“发布-订阅”允许订阅者根据服务器评估的规则(而不是纯偏移量)访问传入消息,并且没有任何工具可以跟踪消息启动的作业的生命周期,或将错误消息 sideline(暂存)到死信队列中,这些都是许多企业消息传递方案的基础功能。

要了解模式之间的差异以及哪种模式最适合哪种服务,请查看 Azure 中的异步消息传递选项指南。 作为 Apache Kafka 的用户,你可能会发现,利用事件网格或服务总线,不仅可以实现目前通过 Kafka 能够实现通信路径,而且基本复杂性降低,功能更强大。

如果需要 Apache Kafka 的特定功能,而 Apache Kafka 接口的事件中心未提供这些功能,或者如果你的实施模式超过了事件中心配额,则还可以运行 Azure HDInsight 中的本机 Apache Kafka 群集

安全性和身份验证

每次你发布或使用来自用于 Kafka 的事件中心的事件时,客户端都会尝试访问事件中心资源。 你希望确保使用已授权的实体来访问资源。 在客户端上使用 Apache Kafka 协议时,可以使用 SASL 机制设置用于身份验证和加密的配置。 如果使用用于 Kafka 的事件中心需要 TLS 加密(因为事件中心传输的所有数据都是经过 TLS 加密的),可以在配置文件中指定 SASL_SSL 选项来完成此操作。

Azure 事件中心提供了多个选项来授予对安全资源的访问权限。

  • OAuth 2.0
  • 共享访问签名 (SAS)

OAuth 2.0

事件中心与 Microsoft Entra ID 集成,后者提供与 OAuth 2.0 兼容的集中式授权服务器。 使用 Microsoft Entra ID,可通过 Azure 基于角色的访问控制 (Azure RBAC) 向客户端标识授予精细权限。 可以指定“SASL_SSL”作为协议,并指定“OAUTHBEARER”作为机制,通过这种方式将此功能用于 Kafka 客户端。 有关 Azure 角色和范围访问级别的详细信息,请参阅使用 Microsoft Entra ID 授予访问权限

bootstrap.servers=NAMESPACENAME.servicebus.windows.net:9093
security.protocol=SASL_SSL
sasl.mechanism=OAUTHBEARER
sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required;
sasl.login.callback.handler.class=CustomAuthenticateCallbackHandler

注意

上述配置属性适用于 Java 编程语言。 有关展示如何通过不同编程语言将 OAuth 与适用于 Kafka 的事件中心配合使用的示例,请参阅 GitHub 上的示例

共享访问签名 (SAS)

事件中心还提供了共享访问签名 (SAS),方便你对用于 Kafka 的事件中心资源进行委派访问。 与 SAS 相比,使用 OAuth 2.0 基于令牌的机制授予访问权限具有更好的安全性和易用性。 内置角色还可以消除基于 ACL 的授权(用户必须对其进行维护和管理)的需要。 可以指定“SASL_SSL”作为协议,并指定“PLAIN”作为机制,通过这种方式将此功能用于 Kafka 客户端。

bootstrap.servers=NAMESPACENAME.servicebus.windows.net:9093
security.protocol=SASL_SSL
sasl.mechanism=PLAIN
sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="{YOUR.EVENTHUBS.CONNECTION.STRING}";

重要

{YOUR.EVENTHUBS.CONNECTION.STRING} 替换为事件中心命名空间的连接字符串。 有关获取连接字符串的说明,请参阅获取事件中心连接字符串。 下面是一个配置示例:sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="$ConnectionString" password="Endpoint=sb://mynamespace.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=XXXXXXXXXXXXXXXX";

注意

对 Kafka 客户端使用 SAS 身份验证时,在重新生成 SAS 密钥时,已建立的连接不会断开。

注意

使用 Apache Kafka 终结点的事件中心时,不支持生成的共享访问签名令牌

示例

有关创建事件中心并使用 SAS 或 OAuth 对其进行访问的分步说明教程,请参阅快速入门:使用 Kafka 协议通过事件中心进行数据流式传输

其他 Azure 事件中心功能

适用于 Apache Kafka 的事件中心功能是在 Azure 事件中心并发提供的三个协议之一,用于补充 HTTP 和 AMQP。 你可以使用这些协议中的任何一种进行写入,也可以使用任何一种进行读取,以便你当前的 Apache Kafka 生成者可以继续通过 Apache Kafka 进行发布,但是你的读取者可以受益于与事件中心的 AMQP 接口的原生集成,例如 Azure 流分析或 Azure Functions。 反之,你可以轻松地将 Azure 事件中心作为目标终结点集成到 AMQP 路由网络中,但仍通过 Apache Kafka 集成读取数据。

此外,事件中心功能(例如捕获)可通过 Azure Blob 存储和 Azure Data Lake Storage 实现极具成本效益的长期存档,并且异地灾难恢复也与适用于 Kafka 的事件中心功能一起使用。

幂等性

适用于 Apache Kafka 的 Azure 事件中心同时支持幂等生成者和幂等使用者。

Azure 事件中心的核心原则之一是“至少传递一次”的概念。 此方法可确保事件始终会被传递。 这也意味着使用者(如函数)可以多次接收事件,甚至重复接收。 因此,使用者支持幂等使用者模式至关重要。

Apache Kafka 的功能差异

适用于 Apache Kafka 的事件中心的目标是为锁定到 Apache Kafka API 的应用程序提供对 Azure 事件中心功能的访问权限,否则必须由 Apache Kafka 群集提供支持。

前面所述,Azure 消息传递队列为众多消息传递方案提供了丰富且可靠的覆盖范围,尽管事件中心对 Apache Kafka API 的支持目前不支持以下功能,但我们指出了所需功能的位置和使用方式。

事务

Azure 服务总线具有强大的事务支持,该事务支持允许在事务的一致性保护下接收并处理消息和会话,同时将消息处理过程中产生的出站消息发送到多个目标实体。 此功能集不仅允许对序列中的每条消息进行恰好一次处理,而且还避免了其他使用者无意中重新处理相同消息的风险,就像 Apache Kafka 的情况一样。 对于事务性消息工作负荷,建议使用服务总线服务。

压缩

Apache Kafka 的客户端压缩功能可将一批(多条)消息在生成者端压缩为单条消息,然后在使用者端解压该批。 Apache Kafka 中转站将批视为一条特殊消息。

Kafka 生成者应用程序开发人员可以通过设置 compression.type 属性来启用消息压缩。 在公共预览版中,唯一支持的压缩算法是 gzip。

Compression.type = none | gzip

此功能目前仅支持 Apache Kafka 流量生成者和使用者流量。 AMQP 使用者可以将压缩的 Kafka 流量作为解压缩的消息来使用。 任何事件中心事件的有效负载都是字节流,内容可以通过所选算法进行压缩,但在公共预览版中,唯一选项是 gzip。 使用 Kafka 压缩的好处是消息大小较小、可传输的有效负载大小增加以及消息代理资源消耗降低。

Kafka Stream

Kafka Streams 是用于流分析的一个客户端库,它是 Apache Kafka 开源项目的一部分,但独立于 Apache Kafka 事件流中转站。

Azure 事件中心客户要求提供 Kafka Streams 支持的最常见原因是,他们对 Confluent 的“ksqlDB”产品感兴趣。 “ksqlDB”是经过许可的专有共享源项目,因此不允许任何“提供服务型软件、平台即服务、基础结构即服务或其他与 Confluent 产品或服务有竞争关系的类似联机服务”的供应商使用或提供“ksqlDB”支持。 实际上,如果你使用 ksqlDB,你必须亲自运营 Kafka,或者必须使用 Confluent 的云产品/服务。 许可条款还可能会影响为许可证排除的用途提供服务的 Azure 客户。

Kafka Streams 独立且没有 ksqlDB,其功能与许多替代框架和服务相比较少,它们的大多数都具有内置的流式处理 SQL 接口,目前全部与 Azure 事件中心集成:

列出的服务和框架通常可以通过适配器直接从不同的源集中获取事件流和参考数据。 Kafka Streams 只能从 Apache Kafka 获取数据,因此你的分析项目会被锁定到 Apache Kafka 中。 若要使用来自其他源的数据,需要先使用 Kafka Connect 框架将数据导入到 Apache Kafka 中。

如果你必须使用 Azure 上的 Kafka Streams 框架,Apache Kafka on HDInsight 会提供该选项。 Apache Kafka on HDInsight 提供对 Apache Kafka 的所有配置方面的完全控制,同时与 Azure 平台的各个方面(从故障/更新域放置到网络隔离再到监视集成)完全集成。

后续步骤

本文介绍了适用于 Kafka 的事件中心。 若要了解详细信息,请参阅针对 Azure 事件中心的 Apache Kafka 开发人员指南

有关创建事件中心并使用 SAS 或 OAuth 对其进行访问的分步说明教程,请参阅快速入门:使用 Kafka 协议通过事件中心进行数据流式传输

此外,请参阅 GitHub 上的 OAuth 示例