咪爷前两天看到社区放出的 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 前，务必检查客户端版本。老版本 Kafka 客户端的协议实现差别很大，实测中 0.x 和 2.x 的兼容表现差距明显，最好直接上较新的 3.x 客户端。
2.2 分层存储：真正把“无限流”做出来
Pulsar 的分层存储一直是它区别于 Kafka 的核心卖点：数据先写 BookKeeper，满足实时读，然后按策略把老数据 offload 到 S3、GCS 或者 HDFS，达到“topic 无限保留”的效果。2025 年度报告里，这一块的重点从功能可用转向了性能和成本优化，包括 offload 调度逻辑改进、读冷数据路径的缓存优化、以及更多存储后端的适配。
实际运维中分层存储最容易被忽视的点，是 offload 之后的数据读取延迟。很多团队把 offload 当成“只写不读”的冷数据存储，结果真到要回溯数据的时候，发现一条消息拉取要等好几秒，于是开始怀疑 Pulsar。其实这是正常的——从对象存储拉数据本来就有网络开销，关键是业务要做好预期管理。我的做法是，把分层存储当成“冷备 + 合规留存”而不是“热读”，真正高频查询的数据还是保留在 BookKeeper 里。
另外，报告里提到的 offload 调度改进解决了一个真实痛点：以前当积压 topic 持续写入时，offload 操作常常会抢占资源，影响实时流量。新版本在调度上更保守，会给实时读写让路。我自己在生产环境里的经验是，把 offload 触发阈值调高一点，比如等 Topic 积压超过 50GB 再触发，避免频繁的小批次 offload 造成无谓的读放大。
2.3 流原生化与消息模型统一
“流原生化”这个词听起来比较虚，但落到具体功能上其实就是一件事：让 Pulsar 既能当消息队列用，也能当流处理的数据源用，而且两种模式之间不需要模型转换。2025 年的报告在消费模型和 topic 间顺序保证上做了一些增强，配合 Pulsar 延迟队列、消息 TTL、死信策略这些能力，让开发者可以在同一个系统里同时处理异步任务和实时流计算。
从工程角度讲，这个趋势对我最大的吸引力是“一套基础设施，多种数据语义”。以前团队经常要同时维护 Kafka（流）和 RabbitMQ（队列），中间还要做数据同步，链路长、故障点多。Pulsar 的模型统一之后，可以省掉一层同步逻辑，直接用 Pulsar 的 topic 作为流处理数据源，用 subscription 实现队列消费。当然，这也要求开发团队改变一些使用习惯，比如不再用“这是一个 Kafka topic”的思维，而是从“存储模型 + 消费模型”两个维度去设计。
3. 性能调优与稳定性建设：我实测下来最该关注的三个点
3.1 broker 连接数与流控：别让一次滚动重启打崩集群
年度报告里花了很大篇幅讲 broker 稳定性，其中一个重点方向是连接与流控机制。Pulsar 跟 Kafka 一个很大的区别是，Pulsar 客户端与 broker 之间是长连接，并且每个 broker 都持有大量 subscription 状态，当 broker 滚动发布或者网络抖动时，所有客户端会同时重连，非常容易造成“重连风暴”，严重的时候直接把 broker 的 CPU 打满，甚至引起雪崩。
我自己在集群升级时就踩过这个坑：一次正常的滚动重启，因为客户端重连没有加随机退避，导致后面几个 broker 重启时负载异常高，最后不得不紧急回滚。后来我做了三件事：一是客户端侧设置合理的重连间隔和随机抖动；二是把 broker 侧的最大连接数和每连接最大 pending 请求数调到一个保守值；三是升级时采用“先摘流量、再重启、逐步回放”的方式，避免所有 broker 同时处于重启窗口。
报告里提到的新版本在流控指标上做了细化，比如区分了“生产积压”和“消费积压”，这两个指标混在一起时很难定位问题。我的建议是监控上一定要把这两个维度分开建告警：生产积压高说明写链路有问题，消费积压高说明消费者或者是读路径有问题，处理方式完全不同。
3.2 BookKeeper 写入路径与磁盘均衡：性能问题多半在这里
Pulsar 的读写性能几乎都绕不开 BookKeeper，而 BookKeeper 的调优核心又集中在磁盘 IO 上。2025 年度报告里专门提到了写入路径优化和 IO 隔离，这也符合我长期的生产观察：Pulsar 集群绝大多数性能瓶颈都出在 bookie 的 journal 盘跟不上，而不是 CPU 或内存不够。
如果你还没把 journal 和 ledger 放到不同的磁盘上，我建议马上改。journal 盘承担顺序写入，延迟极其敏感，SSD 和机械盘混用会直接拖垮写入吞吐；ledger 盘可以相对慢一点，但不能和 journal 抢 IO。真实场景里，两台配置完全相同的 bookie，一台因为跟别的应用共享磁盘导致 IO 抖动，写入延迟直接翻倍，所以磁盘隔离不只是技术问题，也是运维规范问题。
版本里另一个重点是 write quorum 与磁盘均衡的关系。很多团队为了数据安全把 write quorum 设置成 3，但没想过在 3 副本之下，如果 bookie 数量很多，写入成功取决于最慢的那个节点，局部慢节点会被放大成全局问题。我的经验是，优先保证所有 bookie 磁盘性能一致，然后通过 bookkeeper 的 placement policy 做区域感知，而不是简单地调大副本数。
注意：升级 BookKeeper 后，建议观察一段时间 journal sync 耗时。如果发现 p999 延迟升高，先检查磁盘固件、内核 IO 调度器，不要急着调客户端的 timeout，否则会把问题掩盖掉。
3.3 客户端参数默认值的演进与兼容性
2025 年度报告里专门有一节介绍客户端行为的变化，其中最容易被忽略的是某些参数默认值的调整。比如一些版本的客户端会把 acknowledgements 的批量策略调得更积极、超时时间更保守，这些变化在大多数场景下是好的，但如果你刚好有超长耗时消费任务，升级之后可能突然开始大量超时重发，造成消息重复。
这个问题很难在测试环境提前发现，因为测试环境的消费耗时和生产环境完全不是一回事。我的建议是：每次升级客户端驱动库，都先看官方的 changelog，特别是带“default value changed”字样的条目，然后对照自己的生产消费耗时做评估。如果业务链路里有跨服务调用、慢 SQL 这类耗时不确定的场景，宁可手动把 ack timeout 调大，也不要信默认值。
另外，新版本客户端普遍对负反馈更加敏感，即服务端返回限流信号时，客户端会更快地降低发送速率。这个机制是好事，但也意味着如果你的 topic 经常出现短时突发限流，客户端指标会出现明显抖动，这是正常现象，不要一看到限流就以为自己集群容量不够，先看持续时间和频次再决定要不要扩容。
4. 生态集成与上手指南：Kafka、Flink、Spark 该怎么选
4.1 通过协议兼容实现“零改造迁移”的落地步骤
Pulsar 生态这几年一直在做“连接一切”的事情，最典型的成果就是协议兼容层。我去年帮一个团队把 Kafka 链路迁到 Pulsar 上，整个过程几乎没改应用代码，大致分四步走：
- 第一步：在 Pulsar 集群启用 Kafka protocol handler，确认 9092 端口能正常监听；
- 第二步：准备好对应的 topic，并通过租户、命名空间划分好资源，避免所有业务混在一起；
- 第三步：修改客户端的 bootstrap.servers 指向 Pulsar 集群，并保留原有的 group.id 和 topic 名；
- 第四步：灰度观察消费位点提交、消息延迟、重平衡行为，确认无误后逐步切流量。
这套方案适合那些“不想大改造但想换底层基础设施”的团队。但有几个细节需要特别留意：第一，Pulsar 的 topic 最好提前创建好，否则开发者首次访问时自动建 topic，容易在命名空间里生成一堆不规则的名字；第二，协议兼容层对事务类 API 的支持还比较有限，如果业务里有生产者和消费者跨事务的强一致需求，建议转用原生客户端实现。
4.2 Flink/Spark 流批一体实践与常见入坑点
报表里跟 Flink、Spark 相关的更新也比较多。Pulsar 作为流处理的数据源有天然优势，因为它的 topic 既支持消息队列式的逐条消费，也支持从指定位置批量读取，这让流批一体变得非常自然。我在项目里经常用 Flink 消费 Pulsar，再把结果写回到另外一个 Pulsar topic 或者下游 OLAP 存储，整个过程不用维护额外的消息中间件。
这里有一个特别想提醒的点：Flink checkpoint 和 Pulsar 消费位点的提交机制要协调好。Pulsar 的 consumer 支持 cumulative ack，Flink 的 Pulsar connector 一般会把位点提交绑定到 checkpoint 上，但如果你手动调用了 negative ack 或者 seek，很容易导致位点来回跳。一个保险的做法是，Flink 作业里只依赖 checkpoint 做位点管理，不要同时开启 Pulsar 侧的自动提交，避免两套机制打架。
Spark Structured Streaming 的接入逻辑类似，但它的微批模型对延迟更敏感。如果你需要秒级延迟，建议直接上 Flink；如果批处理为主、实时为辅，Spark 就够用。报告里也提到 Pulsar 在持续优化与 Spark 交互时的 offset 管理，不过我的经验是不要在这类集成上追求极限性能，稳定的位点提交和易排查的监控指标比那几毫秒延迟重要得多。
4.3 Pulsar IO 连接器与轻量 ETL
Pulsar IO 是很多人忽略的一块宝地。它提供了一堆开箱即用的 source/sink 连接器，可以直接把数据从数据库、日志、对象存储接入 Pulsar，或者从 Pulsar 写到下游系统。年度报告里也花了不少篇幅讲连接器的维护和更新，这其实是在释放一个信号：官方希望 Pulsar 成为数据流的中转站。
我的实际感受是，Pulsar IO 最适合做轻量 ETL 和事件路由，而不是重数据计算。比如数据库 binlog 捕获、日志采集、Cloud Events 路由，这些场景用连接器几分钟就能搭起来。但如果要做复杂的聚合、多流 join，还是应该交给 Flink 这类计算引擎，Pulsar 负责稳定地“搬数据”，计算引擎负责“算数据”，各司其职是最稳的组合。
5. 社区治理与版本节奏：从年度报告里读出背后的项目风向
5.1 版本迭代节奏加快，PIP 驱动设计的好处
年度报告里列了不少 PIP（Pulsar Improvement Proposal），这其实是 Pulsar 社区最值得学习的地方。每一个比较大的改动，都会先有一个设计文档，说明背景、方案、兼容性影响，再进入社区讨论和投票。这带来一个好处：你在生产环境升级一个大版本之前，可以通过 PIP 了解它到底改了什么、为什么要这么改、会影响哪些旧行为，而不像某些开源项目，发版说明写得像黑盒。
2025 年的版本节奏明显加快了，一年内发布了多个功能版本。对于生产用户来说，我的建议是不要盲目追新，小版本可以直接上，大版本先在测试环境跑两周，重点观察元数据后台任务（比如负载均衡、offload、compaction）有没有异常，再逐步推广。PIP 文档是很好的“预习材料”，值得纳入升级前 checklist。
5.2 报告里的“彩蛋”：那些没被重点宣传但很有价值的小功能
每份年度报告都会有一些“彩蛋”功能，它们的出现不是很显眼，但对特定场景价值极大。比如我在报告里注意到几个方向：元数据服务的进一步分片、broker 在线降级能力、更精细的 topic 迁移策略。这些功能对于超大规模集群的运维者来说，某种程度上比新增一个客户端特性更“救命”。
拿 broker 在线降级来说，以前遇到一个大版本有问题，想回滚几乎等于重新发布一次集群，风险极高。如果能做到在线降级，意味着团队可以更大胆地尝试新版本，遇到问题快速回退，这会显著降低升级的心理门槛。另外一个点是对元数据存储的持续优化，Pulsar 的 topic 元数据全部集中在 ZooKeeper 或 etcd，当 topic 数量达到百万级时，元数据服务确实可能变成瓶颈。2025 年在元数据分片和访问模式上的优化，就是在为“超大规模 topic 数量”场景做准备。
5.3 如何追踪 Pulsar 的后续发展
如果你看完年度报告，想知道下一次更新会有什么，我的经验是盯住两个地方：一是 GitHub 上的 PIP 列表，那里能看到还在讨论中的方案；二是邮件列表和社区周报，里面经常有维护者对近期问题的分析。年度报告本身是“回顾”，但回看它的各个章节，可以反推出未来半年到一年的技术重点。
我自己还会周期性做“版本对比”——把当前生产环境用的版本和最新版本进行功能差异分析，重点看那些“bug fix”和“behavior change”的条目。很多时候，线上疑难杂症其实在新版本里已经修复了，只是你还不知道。
6. 概览总结：我对 Pulsar 2025 年度开发报告的实战评价
看完整份报告，我最深的体会是：Pulsar 不再只是一个“架构很酷”的项目，而是一个“越来越适合跑关键业务”的成熟系统。2025 年的很多改动，都是回应生产环境里最真实的痛点：连接风暴、bookie 抖动、可观测性不足、升级回滚困难。作为长期使用者，这是我最想看到的方向。
如果让我给正在评估 Pulsar 的团队一个建议，那就是不要只盯着功能列表，要真正跑到生产环境里去压测、去试错。Pulsar 的优势（分层存储、多租户、模型统一）需要一定规模的数据和 topic 数量才能体现；反过来，它的调优门槛也确实比 Kafka 高一些，需要团队对 BookKeeper、broker、客户端交互有一定理解。但一旦跨过这个门槛，它带来的灵活性和扩展性是非常值得的。
把这份年度报告和我们自己集群的运维数据对照之后，我给自己列了一个 2025 下半年的重点优化清单：第一，把 broker 的连接和流控参数按照新版建议重新梳理一轮；第二，在测试环境验证分层存储的新调度逻辑，尝试加大 offload 阈值；第三，选一个非核心业务试点 Kafka 兼容接入，积累更多迁移经验。希望这篇内容能给你提供一些参考，也欢迎你们在实践后回来交流各自的踩坑经历。