咪爷前两天看到社区放出的 Apache Pulsar 2025 年度开发报告，我深夜一口气读完，忍不住想聊点自己的看法。作为一个从 2.x 时代就把 Pulsar 当生产消息队列用的人，这份报告里不少内容其实在我日常运维中已经有了预感，但读完之后还是有几个点让我觉得“哦，原来官方是这么想的”。这篇内容就是基于这份年度报告做的拆解，不光是帮你看懂 2025 年 Pulsar 干了什么，更重要的是结合我自己的实操经验，说说这些变化对正在用或者准备用 Pulsar 的团队到底意味着什么。无论是刚接触 Pulsar 的架构师，还是已经在生产环境里摸爬滚打的运维同学，都可以从里面找到自己关心的东西。
1. 2025 年度开发报告的整体观感：Pulsar 在解决什么问题
报告开篇其实没有太多花哨的路线图，反而花了不少篇幅去讲稳定性和运维体验，这个信号值得注意。前几年大家提到 Pulsar，第一反应是“架构先进”“多租户”“分层存储”“云原生”，但真实生产环境里跑起来以后，大家吐槽最多的往往是“为什么 bookie 莫名其妙抖动”“broker GC 一长监控就报警”“ topic 一多，元数据服务就成了瓶颈”。2025 年的开发报告，明显是把火力集中在了这几个“实战痛点”上。
我个人的理解是，Pulsar 社区正在完成一次从“技术领先”到“生产可用且好用”的重心转移。技术上已经有 compute-storage separation、segment-centric storage 这些底子，但如果不把稳定性、可观测性和大规模运维效率补上，就很难进入更多企业的核心链路。所以今年报告里出现的几个核心关键词，基本都是围绕这三件事展开的：稳定性（broker 与 bookie 的抖动治理）、可观测性（topic 级指标、prometheus 指标治理）、大规模部署效率（元数据分片、自动负载均衡增强）。
这份报告适合谁看？我的答案是三类人。第一类是正在做消息中间件选型的架构师，你需要从报告的演进方向判断 Pulsar 是否适合未来三到五年的业务场景；第二类是已经在生产环境维护 Pulsar 的运维和 SRE，报告里不少优化细节能解释你在实际中遇到的怪问题；第三类是写业务代码的工程师，新版客户端参数变化和协议兼容能力会直接影响到你的接入方式。接下来我会按报告的几个重点方向，结合我自己的实践做详细拆解。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心特性演进与设计逻辑：协议兼容、分层存储和流原生化
2.1 协议兼容层：Kafka 兼容从“能用”到“好用”
今年报告里关于 Kafka protocol handler 的进展着墨不少。这个功能的定位一直很明确：让 Kafka 客户端不用改代码就能连上 Pulsar，从而降低迁移成本。早期版本只能说“能用”，但 topic 创建时机、offset 提交语义、消费者 group 的行为都跟原生 Kafka 有细节差异，一旦遇到复杂用法就露馅。2025 年的改进方向是两个：一是补齐协议细节，提高兼容度；二是优化性能，减少因为协议转换带来的开销。
我自己的经验是，Kafka 兼容功能最适合的场景是“存量系统渐进式迁移”，而不是“双跑长期共存”。团队可以先让部分非核心业务通过 Kafka 协议接入 Pulsar，跑一段时间观察稳定性，再逐步把核心链路切过来。但要注意，兼容层不等于 100% 等价，比如 Kafka 的事务语义在 Pulsar 侧依然是近似实现，如果业务强依赖跨分区事务，我建议还是不要硬迁，优先评估 Pulsar 原生客户端。
提示：启用 Kafka protocol handler 前，务必检