乐悠厨房COSCon‘25 的完整日程安排放出来之后，我第一时间没去研究主论坛，反而盯上了同场的 Pulsar Developer Day。做消息中间件这几年，有个感受越来越强烈：像 Pulsar 这种基础软件，官方文档能告诉你“它是什么”，但真正值钱的永远是“它该怎么用”以及“用的时候踩过哪些坑”。这次把 Pulsar Developer Day 放进开源年会里同场举行，相当于把一线工程师、社区维护者、还在选型阶段的团队负责人聚到同一个房间里，集中聊消息中间件的创新实践。对已经在生产环境跑 Pulsar、或者正在做技术选型的人来说，这份议程的含金量不算低。
很多人可能觉得“开发者日”只是厂商办的活动，听听新特性就结束了。但 Pulsar Developer Day 这次打的旗号是“聚焦消息中间件创新实践”，这就意味着议程内容不是走马观花的产品宣讲，而是偏向真实场景中的方案拆解和经验复盘。借着议程正式发布的节点，我可以把我对这场活动的判断、对消息中间件技术走向的理解，以及给不同角色参会者的一些实操建议整理出来，供大家参考。
1. 先说结论：为什么这场议程值得打开看
1.1 活动定位，以及它与 COSCon 的关系
COSCon 是开源圈子里比较有代表性的年度聚会，每年都会吸引大量开源项目维护者、使用者和技术决策者到场。Pulsar Developer Day 作为它的同场活动，本质上是在大的开源生态语境下，给 Apache Pulsar 建立一个专属交流空间。与单独办一场 Meetup 相比，这种“大会同场”的形式有几个很明显的好处。
第一是流量交叉。参加 COSCon 的人不全是 Pulsar 用户，很多人可能正在对比 Kafka、RocketMQ、RabbitMQ 等不同消息中间件，但未必深入了解过 Pulsar。开发者日放在这里，能让原本不关注 Pulsar 的人有机会走进来。第二是内容往深里走。既然已经有大会主论坛和各类技术专题，Pulsar Developer Day 不必再重复基础概念，可以把时间留给架构深度解析、性能调优、故障处理、迁移实践经验这一类平时很难讲透的话题。第三是社区信号。议程发布本身其实传递了一个信号：Pulsar 在国内的使用规模已经能支撑起一整天的专项活动，而且社区手里已经攒了一批可以公开分享的案例。
所以看这份议程，不应该抱着“去听产品发布会”的心态，而应该带着“去听同行怎么踩坑、怎么解决问题”的心态。前者听完可能就忘了，后者能直接带回去用。
1.2 议程的四个可见板块
从我目前看到的议程整体结构来看，内容大致可以分成四个板块，每个板块对应不同阶段的关注者。
第一个板块是新版本特性与路线图解读。Pulsar 最近几个版本的迭代节奏明显加快，从计算存储分离的进一步强化，到元数据服务的可插拔支持，再到 Pulsar Functions 和连接器生态的完善。这类议题通常由社区核心维护者来讲，他们能说清楚官方为什么要做这个改动、哪些行为发生了变化，以及对现有集群有没有破坏性影响。对运维同学来说这是必听项。
第二个板块是行业落地案例。消息中间件不会单独存在，它一定是嵌在业务系统里的。金融、车联网、电商、物联网这些行业对消息可靠性、延迟、跨地域容灾的要求各不相同，听案例不能只听 PPT 上面的架构图，要关注他们最开始为什么选 Pulsar、中途遇到了什么问题、团队怎么排查性能瓶颈。
第三个板块是原理深挖与调优专场。这类内容通常比较硬核，会涉及 BookKeeper 的存储机制、Broker 的线程模型、消费游标管理、分层存储的触发策略等等。适合已经有 Pulsar 使用经验的人，听完能把自己手上的集群参数对照着检查一遍。
第四个板块是动手实操的 Workshop。我记得以往类似开发者日都会留出一定时间让参会者现场搭环境，跑一个简单的消息收发链路，甚至做一些读写压测。对还没上手 Pulsar 的人来说，这是成本最低的第一次接触。
这四个板块不是完全割裂的。如果你是刚开始接触 Pulsar，建议按“新特性解读 -> 案例分享 -> 动手实操”的顺序来听；如果你已经维护着 Pulsar 集群，重点可以放在调优专场和案例复盘上，前两个板块选听即可。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从议程议题看 Pulsar 的技术演进逻辑
2.1 存储计算分离不是概念，是落地路径
我遇到过不少人，第一次听 Pulsar 架构时觉得“Broker 和存储分离”听起来挺简单，但真正自己部署以后才发现这套架构对运维方式的影响是极其深远的。Pulsar 的 Broker 层不保存数据，所有消息都落到 Apache BookKeeper 上，元数据则由独立的元数据服务来管理。这样做最大的好处是 Broker 变成了无状态节点，你可以像加 Web 服务一样随意扩容，不需要像传统方案那样担心新节点要拷贝一堆历史数据。
用一个接地气的类比来说，传统思路是每个服务员自己背着一大包账单，客人多了不仅要把账单转移给新服务员，还得保证账单顺序不能乱；Pulsar 的做法是把所有账单放进统一的后仓，服务员只负责接待和记录，后仓的人负责保存归档。客人多了，我只需要增加接单的前台，不需要动后仓的物理结构。
这种架构落到实际生产环境里，带来的直接好处是资源可以分别规划。计算能力不够就加 Broker，存储空间不够就扩 BookKeeper，两者互不拖累。对于消息量有明显波动的业务，比如大促、抢购、节假日高峰，这种独立扩缩容的能力非常实用。如果议程里设有专门的架构演进议题，我建议重点听讲解人怎么描述“分区数上限”和“读放大问题”这两个话题，因为这两点恰好是 Pulsar 相对传统实现最具优势、同时最容易被人误解的地方。
2.2 多租户与跨地域复制：企业级能力成为重点
再看议程里反复出现的“企业级能力”相关关键词，我首先想到的是 Pulsar 原生的多租户模型。Pulsar 里有一套三位一体的层次结构：租户、命名空间、主题。一个租户可以对应一个业务部门或者一个产品线，命名空间用来做隔离策略配置，主题就是底层的具体消息通道。在同一个 Pulsar 集群里，不同团队可以被分到不同的租户里，各自有独立的认证、权限、配额和存储策略。
这种隔离能力在大公司内部非常实用。很多公司不愿意让不同团队各自搭一套 Kafka 集群，成本高、利用率低、运维压力也大；但共用一套集群又担心互相影响。Pulsar 的多租户机制正好解决这个问题，管理者可以给某个租户设置消息保留时长、最大存储容量、生产消费速率上限，一个团队突然流量激增时不会把整个集群拖垮。
跨地域复制则是另外一个重要亮点。通过在不同机房部署 Pulsar 集群，再配置命名空间级别的复制策略，可以做到多地多活。对于金融、证券、跨境业务这些对容灾要求极高的场景，单集群永远不够，必须有跨地域的备份能力。听这类议题时，我会比较关注讲解人给出的真实延迟数据，比如“北京到上海这条链路，异步复制大概延迟多少毫秒”“发生机房故障时，切换流程到底是自动的还是半自动的”，这些问题比任何架构图都更能反映真实情况。
2.3 新版本迭代里的信号：元数据层可插拔与生态扩展
如果你关注过 Pulsar 最近几个版本的变化，会发现一个很明确的趋势：它在努力降低部署门槛、让自身更好地融入云原生生态。过去 Pulsar 部署离不开 ZooKeeper 做元数据协调，很多人觉得组件多、维护复杂。新版逐步支持了可插拔的元数据存储实现，引入 etcd 等方案，这让整个系统的部署拓扑变得更灵活。
除此之外，Pulsar Functions 和连接器生态也在快速完善。Pulsar Functions 允许直接在消息流上写轻量处理逻辑，比如做简单的过滤、字段提取、数据转换，不需要额外部署一套流处理框架。连接器生态解决的是“怎么跟周边系统对接”的问题，从数据库到对象存储，再到各种消息队列，都有现成的 Source 和 Sink 可以接。
这些新能力的意义在于，Pulsar 正在从“一个消息中间件”慢慢变成“一个统一的数据接入和事件流处理平台”。议程里如果安排了新版本解读，我建议把它当作一次了解未来版图的机会，而不是仅仅记几个新功能。重点听官方的路线图，想清楚未来一年里的升级路径是否平滑，这直接影响你敢不敢在核心业务上长期投入。
3. 消息中间件创新实践：只有用过才看得出的议题价值
3.1 选型：Pulsar 到底解决谁的什么问题
聊到消息中间件的创新实践，绕不开选型这个话题。每个团队在刚开始接触 Pulsar 时都会问同一个问题：我已经有 Kafka 了，为什么还要换 Pulsar？这个问题不能一概而论，但可以给出一个比较通用的判断框架。
Kafka 的优势在于生态成熟、学习资料多、大部分团队都有运维经验。它的设计假设是你在一个相对稳定的集群里使用分区顺序来保证吞吐，但它的分区数和整个集群的表现会被日志存储的本地化特点限制。当分区数量增长到一定规模，或者需要增加 Broker 节点时，往往需要做数据重平衡，操作不当还会引发长时间复制流量。Pulsar 的存储计算分离恰好规避了这类问题，分区规模可以做得很大，Broker 扩容不用搬数据。
所以如果你面对的是以下几种情况，Pulsar 是值得认真评估的：第一，公司内有多个团队需要共用一套消息集群，希望有清晰的租户隔离和配额管理；第二，业务有跨地域容灾需求，需要多集群复制能力；第三，消息的峰值流量波动大，希望计算和存储分别扩缩容；第四，需要同时处理消息队列和流式数据两种场景，不想维护多套基础设施。
反过来，如果你的业务规模不大，一个 Kafka 集群已经跑得很顺，团队也没精力学新东西，那暂时没有必要为了换而换。选型最忌讳的就是被技术热度驱动，而忽视了运维成本和团队学习曲线。
3.2 落地：集群部署和日常运维的经验
真正开始用 Pulsar 之后，很多人会发现运维侧的重点跟想象中不太一样。我身边踩过比较多坑的，集中在几个部分。
首先是 BookKeeper 集群的容量和磁盘规划。Pulsar 的持久化全靠 BookKeeper，它采用多副本来保证数据可靠，官方推荐至少三个副本，这意味着你写入一条消息，其实是复制了多份。磁盘类型直接决定写入性能，我基于自己的实践建议生产环境优先考虑本地 NVMe 或 SSD，尽量避免用网络存储，否则延迟和稳定性都很难保证。这里说的不是某个具体型号，而是存储选型思路：BookKeeper 的写链路要求足够低的 IO 延迟，任何虚拟化网络存储都可能带来额外抖动。
其次是 JVM 参数调优。Bookie 节点的性能瓶颈经常不在 CPU，而在内存管理和 GC。很多人拿到默认配置就直接上生产，结果遇到消息积压后 GC 时间暴增，吞吐量直线下降。社区推荐的 JVM 参数在官方文档里都有，但更稳妥的做法是在压测环境里先跑一轮积压和恢复测试，观察老年代内存增长曲线，再决定要不要调整堆内和堆外内存的比例。
第三是监控告警体系。Pulsar 的指标非常丰富，但要抓住核心指标才有意义。我一般会优先盯几类：生产速率和消费速率的差值、积压消息数量、Bookie 的 IO 延迟（p99）、Broker 的连接数和负载均衡情况。这些指标能连续跑两周不出问题，基本说明集群是健康状态。反过来，如果等出故障了才打开监控界面，大概率已经晚了。
3.3 迁移：从 Kafka 切换到 Pulsar 的真实体感
议程里如果真的安排了从 Kafka 迁移到 Pulsar 的案例分享，我建议无论你现在用不用 Pulsar 都去听一下。因为这类分享通常包含最多的真实业务细节，比如双写方案怎么设计、切换顺序怎么排、老客户端怎么平滑过渡。
从技术上来说，Pulsar 提供了 Kafka 协议兼容能力，支持直接用 Kafka 客户端连接 Pulsar 集群，这大大降低了迁移初期的成本。你可以把原本指向 Kafka 的客户端连接地址换成 Pulsar，业务代码几乎不用改动。生产环境里稳妥的方案是双写，也就是新旧两条链路同时跑，消费端先从旧链路切到新链路，观察数据完整性和消费延迟，确认稳定后再停止旧链路写入。
不过真正让迁移产生所谓“回不去的感觉”的，往往不是协议兼容，而是日常运维体验的变化。我记得有朋友跟我分享过一个很典型的场景：以前用 Kafka，遇到大流量增长时只能被动加 Broker，加完还得等数据迁移完成。换到 Pulsar 之后，流量增长时可以直接加 Broker，无状态节点扩展起来非常快，存储压力交给 BookKeeper 去扛。这种只要做一次就能感受到差异的第几操作，才让人彻底不想回头。但这不代表迁移是轻松的，监控体系重建、团队知识储备、故障预案都要重新做，这些都是隐形成本。
4. 参会与攒经验值的实操建议
4.1 目标人群和各自的关注重点
我在会场见过特别多不同角色的人，大家关注点差异很大，提前规划听课路线能省不少力气。
如果你是后端开发工程师，重点应该放在客户端使用和消息模型理解上。比如 Pulsar 的四种订阅模式（独占、共享、故障转移、Key 共享）分别适合什么业务场景，生产消费过程中怎么处理大量消费失败的消息，这些问题可以直接带去现场提问。不要纠结太底层的存储机制，那是另一个维度的事情。
如果你是架构师，关注多租户模型、跨地域复制、分层存储和云原生集成。建议带着你们团队现有的架构痛点去听，想清楚 Pulsar 能替代哪些组件、引入后会改变什么。架构师听案例分享时，很重要的一点是看对方的业务规模是否跟你接近，一个日请求量千万级和一个亿级的方案设计往往差异巨大。
如果你是运维或 SRE 角色，重点听集群部署、扩容、监控和故障处理。BookKeeper 的扩缩容流程、Broker 负载均衡策略、副本修复机制，这些才是保命的技能。可以直接问讲解人“当时出故障时你们怎么排查的”，比任何最佳实践总结都值钱。
如果你是技术管理者，听案例时多关注成本和收益。比如团队投入了几个人维护集群、用了多长时间完成迁移、运维复杂度相比原来到底是上升还是下降。不要只看消息中间件的技术指标，还要看团队能不能接得住。
4.2 会场上怎么提问、怎么留联系方式才有价值
很多人参加开发者日，听了一整天回去什么也不记得，很大的原因是提问太少、交流太少。技术分享的公开讲解往往只展示最终方案，真正有价值的上下文都在 Q&A 环节和散场后的交流里。
我自己的经验是提前准备好两个具体问题，而不是泛泛地“你们怎么保证消息不丢”这种大问题。好的问题往往带前置背景，比如“我们集群 Broker 数量不多，但积压一多就会出现消费端延迟陡增，你们在类似场景下是优先调消费端线程数还是调 Bookie 的刷盘策略？”这种问题会让对方意识到你确实在实操中遇到了真实的困难，回答的细致程度完全不同。
关于加联系方式，我一直觉得不要为了加而加。比较自然的方式是在 Q&A 环节或者 Workshop 动手环节里交换意见，再顺势认识一下。加完好友之后，当天晚上可以把你的场景和问题整理成一段简明文字发过去，附上“今天会场聊得不完整，我把背景补充了一下”，这样对方很容易记住你是谁，后续再请教也不会突兀。
4.3 会后进一步学习的资料路径
如果你听完活动想自己动手继续学，我建议按下面的路径走，效率会比较高。
第一优先看官方发布说明和博客。每个大版本的发布说明会列出所有行为变化和新增功能，这是跟上社区节奏最快的途径。第二看 GitHub 上的 Issue 和讨论。很多深度问题在官方文档里看不到，但在 GitHub 上的讨论里能看到社区维护者对某条核心链路为什么这么设计的解释。第三是动手跑一个最小集群，最好是在本地或云上用容器方式拉起一整套环境，然后模拟消息积压、节点故障、扩容缩容这些真实操作。第四是关注本地用户组或社区线下活动，后续还有机会参加更深度的 Workshop。
有一点我想额外说明，也是一直以来的心得体会：学习这类基础软件，永远不要只在文档里打转。把它用起来，用到一个真实的、哪怕很小的业务场景里，才能真正理解文档里那些话为什么要那么写。
5. 新手最容易踩的坑与避坑实操
5.1 三个认知误区
每次聊 Pulsar，我都会遇到一些比较固定的认知误区，趁这个节点集中聊一聊。
第一个误区是把 Pulsar 理解成“Kafka 的协议兼容替代版”。这可以从两个层面看：一方面，Pulsar 确实提供了 Kafka 协议兼容能力，方便快速迁移；但另一方面，Pulsar 本身的存储模型跟 Kafka 有本质区别。如果只把它当 Kafka 用，等于放弃了多租户、跨地域复制、分层存储这些核心能力，同时还背上了新的运维复杂度，得不偿失。
第二个误区是只盯着吞吐量选型。很多团队一上来就问“Pulsar 每秒钟能处理多少条消息”，好像吞吐量越高越厉害。实际生产中，峰值吞吐量只是众多指标里的一个。消息积压后的恢复速度、故障切换时的数据丢失情况、多租户隔离是否可靠，这些维度往往比一个漂亮的吞吐数字重要得多。一个在压测里能跑到百万条每秒的系统，如果积压时恢复过程缓慢并且出现消费延迟，放到真实场景里价值会大打折扣。
第三个误区是拿单机版体验替代完整集群。我见过有人在本地用单机模式跑了一下 Pulsar，然后得出“这个用起来怎么这么乱”的结论。单机模式只是为了快速体验客户端 API，它反映不了真实集群的部署形态。要看 Pulsar 的架构能力，至少得起一个多节点集群，再模拟节点故障和扩容，才能理解存储计算分离带来的效果。
5.2 现场速记的少量基础术语
为了让你在会场听得更顺畅，我把几个高频术语提前解释一下。
Broker 是 Pulsar 的计算层节点，负责处理生产消费请求，不存数据，因此可以无状态水平扩展。Bookie 是存储层节点，隶属于 BookKeeper 集群，数据最终由它落盘保存。Ledger 是 BookKeeper 里的一组日志记录，通过多副本机制提供持久化能力。Cursor 是消费端的游标，用来记录当前消费进度，Pulsar 对游标的管理和保留策略直接决定了你能往前回溯消费多久的数据。订阅模式指的是消费端在共享主题时的分配方式，独占订阅保证一条消息只被一个消费者处理，共享订阅让消息在多个消费者之间分发，Key 共享则保证同一 Key 的消息固定落到同一个消费者，适合严格保序的场景。分层存储是 Pulsar 的一个特色能力，它允许把旧消息从 BookKeeper 自动卸载到对象存储中，用较低的成本保留长时间的历史数据。
这些术语在现场分享里会反复出现，提前在脑子里有个印象，听的时候就不会太费力。如果你真的对某个概念不太懂，又没法在分享中消化，我更建议先把这个词记录下来，会后结合刚才提到的资料路径去查，这比在会场上打断别人更有效率。
回到 Pulsar Developer Day 这件事上，我个人在消息中间件这个领域做了几年一线实施，最期待在议程里看到的，其实是那些把 Pulsar 放进真实业务后的复盘。不是性能数字特别好看的 POC 报告，而是遇到故障后怎么定位、积压时怎么处理、副本数量到底应该怎么取舍，这些内容才是基础软件真正值钱的经验。消息中间件平时不出问题的时候几乎没有存在感，一出问题往往就是全局性的事故，所以任何一线的实操复盘，都值得我们抽出一天时间去听、去问、去记录下来。这次开发者日能和 COSCon 同场出现，本身就是 Pulsar 社区和应用生态走向成熟的一个信号，接下来的重点是怎么把这些经验变成可复制的方法论，带回各自的工作里落地。