微软云Kafka怎么用？从Event Hubs到HDInsight的完整实战指南
一、微软云上的Kafka，到底有几条路可以走？
如果你在Azure上搜索Kafka，搜索结果不会只给你一个答案。微软在这件事上做了一个颇为聪明的安排——他们并没有强迫所有人走同一条路，而是提供了三种气质完全不同的选择。
第一种是Azure Event Hubs的Kafka兼容端点。Event Hubs本身是一个云原生的事件流平台，底层跑的是AMQP协议，但它特意在9093端口上开了一个Kafka协议入口，让那些已经用Kafka客户端写好的应用可以几乎不做任何代码改动就迁移过来。这就像一家餐厅同时准备了中餐和西餐两个厨房，你拿着西餐的菜单走进去，厨师照样能给你端出熟悉的味道。
第二种是HDInsight上的Apache Kafka集群。这是微软提供的托管型开源Kafka集群方案，你在Azure门户上点几下，就能得到一个由多个工作节点组成的Kafka集群，每个工作节点扮演一个broker的角色。这是真正意义上的Kafka集群，你可以访问broker端配置，也可以用Kafka自带的命令行工具去管理topic和分区。
第三种是Confluent Cloud on Azure Marketplace。Confluent是Kafka的原始开发团队创建的公司，他们在Azure Marketplace上提供了完全托管的Kafka与Flink服务，你可以在Azure门户里直接订阅，也可以把Confluent组织和Azure App Service、Azure Kubernetes Service等计算服务连接起来。对于那些需要Schema Registry、ksqlDB、完整Kafka Connect生态的团队来说，这条路提供的能力最完整。
三条路，三种性格。接下来我们逐一拆解它们的用法。
二、Event Hubs Kafka端点：改配置不改代码的连接方式
先说说Event Hubs这条路，因为它是大多数Kafka开发者进入微软云时最先碰到的入口。
Event Hubs在创建命名空间的时候会自动启用Kafka端点，你不需要额外做什么操作。需要注意的是，基本层不支持Kafka功能，你必须选择标准层或更高层级才能使用。如果你追求完整的Kafka协议兼容性，高级层或专用层是更稳妥的选择，标准层在某些Kafka工作负载上会有功能限制。
连接配置本身非常简单。所有Kafka客户端需要的认证参数只有四项：
bootstrap.servers指向你的命名空间地址加上9093端口，security.protocol设为SASL_SSL，sasl.mechanism使用PLAIN，然后在sasl.jaas.config里填入连接字符串作为密码。对于中国区的Azure，bootstrap.servers的域名后缀会变成chinacloudapi.cn。
这里有一个容易被忽略但很重要的细节：Event Hubs会在空闲240秒后主动关闭Kafka连接。如果你的客户端配置里metadata.max.age.ms和connections.max.idle.ms用的是Kafka的默认值（分别是300秒和540秒），客户端会尝试在一个已经被服务端关闭的连接上发送数据，表现出来的症状是批量消息莫名其妙地过期。解决办法是把这两个值都调到240秒以下，官方推荐180秒。
另一个坑在生产者端。Kafka默认的max.request.size是1048576字节，但Event Hubs对这个值的容忍上限是1046528。如果你用的是默认值，超出的部分会导致连接直接被关闭。建议把生产者的max.request.size降到1000000字节，留出安全余量。
压缩类型也需要留意。Event Hubs只支持gzip压缩，snappy、lz4、zstd这些在标准Kafka上常用的压缩算法在这里都用不了。如果你的应用依赖snappy的低CPU开销特性，迁移前需要重新评估压缩策略。
三、Spring Boot项目怎么接上去？
如果你的项目是Spring Boot技术栈，接入Event Hubs的过程会比裸Kafka客户端更顺畅一些。
核心依赖是Spring Cloud Stream加上Kafka binder。Event Hubs的Kafka端点和Spring Cloud Stream的Kafka binder是兼容的，你不需要为Event Hubs写任何特殊的binder实现。
配置层面，Spring Boot的application.properties里需要填写和裸客户端相同的认证参数。如果你使用连接字符串方式，把bootstrap-servers指向命名空间的9093端口，然后配置security.protocol和sasl相关的属性即可。如果你在Azure计算服务（比如VM或AKS）上运行应用，更推荐使用Microsoft Entra身份验证——给计算资源分配一个托管身份，然后在Event Hubs的访问控制里把"Azure Event Hubs Data Sender"和"Azure Event Hubs Data Receiver"角色授予这个身份，代码里完全不需要出现任何凭据。
在实际项目中，我见过最常见的错误是忘记给消费者配置group.id，或者生产者用了默认的acks策略导致吞吐量上不去。在Event Hubs上，acks设为-1（所有副本确认）会显著增加延迟，如果你的场景更看重吞吐量而不是严格的零丢失保证，acks=1是一个合理的折中。
四、搭建一条流处理管道：Kafka输入Stream Analytics
Event Hubs解决了消息的收发问题，但消息进来之后要做什么？这时候就需要把流处理层接上去。
Azure Stream Analytics可以直接把Kafka集群当作输入源来使用。它支持的Kafka最低版本是0.10，安全协议上支持mTLS、SASL_SSL、SASL_PLAINTEXT和None四种模式。需要注意的是，Stream Analytics不支持用OAuth或SAML SSO去连接Confluent Cloud。
配置Kafka输入时，有一个技术约束容易被忽略：输入topic的时间戳类型必须是LogAppendTime，这是Stream Analytics唯一支持的时间戳类型。如果你的Kafka集群配置的是CreateTime，需要提前调整。
整条管道的典型形态是这样的：Kafka生产者把数据写入Event Hubs的Kafka端点，Stream Analytics从Event Hubs拉取数据做窗口聚合或异常检测，然后把结果输出到Azure Blob Storage、Power BI或者另一个Event Hub里。如果Kafka集群跑在虚拟网络内部或防火墙后面，Stream Analytics需要通过私有链接或专用网络配置来访问。
对于更复杂的流处理需求，比如需要事件时间语义、有状态计算、或者Kafka Streams的拓扑操作，Event Hubs高级层和专用层是支持Kafka Streams客户端的，但需要调整一些默认配置参数来适配Event Hubs的broker行为。
五、从自建Kafka迁移过来，哪些地方要改？
把现有的Kafka应用迁移到Event Hubs，核心原则是"改配置，不改代码"。但在实际迁移之前，有几个功能维度的兼容性需要提前确认。
分区数量的规划是迁移中最需要谨慎对待的部分。在标准层和高级层上，分区数一旦创建就不能减少。如果你现有的Kafka topic有24个分区，Event Hub也需要创建24个分区。专用层支持动态增加分区，但减少分区在任何层级上都不支持。如果你的应用依赖分区键的哈希来保证消息顺序，动态增加分区会破坏这个顺序保证，所以迁移前要把分区规划做扎实。
消息大小上限也是一个需要关注的维度。标准层和高级层的单条消息最大1MB，专用层可以到20MB。如果你的现有应用有超过1MB的大消息，要么压缩，要么升级到专用层。
Kafka Connect在Event Hubs上是支持的，但Event Hubs本身不提供原生的Connect框架，你需要把Connector跑在独立进程里，让它以Kafka端点的身份连接到Event Hubs。Schema Registry方面，Event Hubs可以和Azure Schema Registry配合使用。
Kafka事务功能目前处于预览阶段，如果你的应用重度依赖事务性消息，迁移前需要做充分的验证。
至于那些需要broker端配置的场景——比如自定义的日志保留策略、broker级别的限流、或者基于Kafka AdminClient的topic管理操作——在Event Hubs上都不适用，因为它是完全托管的PaaS服务，你不拥有broker的控制权。如果你的架构强依赖这些能力，HDInsight上的托管Kafka集群或者Confluent Cloud会是更合适的选择。
六、选型建议：三条路各适合什么样的团队
如果你是一个已经在用Kafka、但团队规模不大、不想花精力维护Kafka集群运维的团队，Event Hubs的Kafka端点是最省心的选择。改几个配置就能跑起来，微软帮你扛住了broker的运维压力。代价是你在功能上要做一些妥协——不能用snappy压缩，不能自定义broker参数，Kafka事务还在预览阶段。
如果你需要broker级别的控制权，或者你的应用重度依赖Kafka Connect、Kafka Streams、Schema Registry这一整套生态，HDInsight上的托管Kafka集群值得认真考虑。它给你一个真正的Kafka集群，代价是你要承担比Event Hubs更多的运维责任。
如果你的团队在多个云上都有业务，或者你希望用一个统一的流处理平台覆盖Azure、AWS和GCP，Confluent Cloud提供的是最完整的Kafka体验。它比Event Hubs贵，但换来的是没有功能折损的Kafka——包括完整的Connect生态、ksqlDB、以及跨云的一致性体验。
说到底，选哪条路不取决于哪个技术"更好"，而取决于你的团队当下最缺的是什么。缺运维人力的团队选Event Hubs，缺功能完整性的团队选Confluent Cloud或HDInsight，缺预算的团队从Event Hubs标准层起步，验证业务之后再往上走。技术选型的本质不是找最优解，而是找最合适的那个平衡点。
在微软云Kafka的落地过程中，上饶追云逐智信息科技有限公司作为覆盖八大主流公有云的综合型服务商，在Azure Event Hubs、HDInsight Kafka以及Confluent Cloud的部署与调优方面积累了丰富的实战经验。公司拥有十年以上行业深耕、五百人全职技术团队，八大云平台全年综合销量突破二十亿人民币，累计服务超过一百万合作客户。对于正在评估微软云Kafka方案的团队来说，追云逐智可以提供从选型咨询到部署落地的全程支持，并且作为微软云头部一级代理商，能够为客户争取到微软云九折或者返百分之十的优惠，ChatGPT等AI大模型服务可以给到八折。
七、几个高频疑问的简短回应
问：Event Hubs的Kafka端点和自建Kafka能混用吗？
消费者可以从Event Hubs读，生产者往自建Kafka写，反过来也行，前提是两边都能解析对方的消息格式。但跨集群的一致性保证（比如精确一次语义）在这种混合架构里很难实现，需要应用层自己做补偿。
问：标准层到底能不能跑Kafka？
能跑，但有约束。标准层不支持Kafka压缩（除了gzip），不支持Kafka事务，某些Kafka AdminClient的操作也不可用。如果只是简单的消息收发，标准层够用；如果用到Kafka的高级特性，直接上高级层。
问：从自建Kafka迁移到Event Hubs，消费者偏移量怎么办？
Event Hubs管理自己的消费者组偏移量，和自建Kafka的__consumer_offsets不共享。迁移时需要决定是重置偏移量从头消费，还是从某个时间点开始消费。如果业务对消息的"不重不漏"有严格要求，需要设计一套偏移量映射和过渡方案。
问：HDInsight上的Kafka集群和自己在虚拟机上搭Kafka有什么区别？
HDInsight帮你管理了集群的生命周期、补丁、监控和与Azure存储的集成，但底层还是标准的Apache Kafka。你可以通过SSH登录到工作节点，也可以用Kafka自带的脚本操作topic。区别在于HDInsight把运维的部分标准化了，你不需要自己写Ansible playbook去部署和扩缩容。
问：Confluent Cloud和Event Hubs的Kafka端点，价格差多少？
粗略来说，Confluent Cloud在同等吞吐量下比Event Hubs贵百分之二十五到三十五。但Confluent的定价包含了Schema Registry、ksqlDB和完整的Connector生态，如果你本来就需要这些能力，总拥有成本的差距会缩小。
问：微软云Kafka的消息保留时间最长可以设多久？
Event Hubs标准层是1到7天，高级层和专用层可以到1到90天。如果你需要无限期的消息保留，Confluent Cloud的长期存储方案更合适，它支持把Kafka数据分层存储到Azure Blob Storage里。
