1. 活动背景为什么说MQ需要“再度伟大”1.1 “Make MQ Great Again”的真正含义先说个有意思的事。我那天到会场门口看到横幅上印着“Make MQ Great Again”身边好几个同行都在笑。这个句式大家一眼就认得出来但它放在技术圈其实是很典型的“技术梗”——说白了就是一群做消息队列的人想给这个有点“过气”的技术方向打打气。为什么这么讲过去十年消息队列这个领域其实挺尴尬的。一提到MQ很多年轻工程师脑子里蹦出来的还是“老、重、难”三个字老牌商业中间件配置复杂日志要翻几层目录才能找到开源生态里Kafka风头最盛但真正在生产环境摸爬滚打过的人都知道Kafka的Broker和存储绑定在一起扩规模的时候要动分区跨机房同步要自己搭MirrorMaker运维起来并没有那么省心。时间一长MQ在很多人心里就成了“能用但不好玩”的基础设施讨论度远低于微服务网关、容器编排这些新玩具。所以这次COSCon’25上挂出“Make MQ Great Again”这个口号本质不是在喊什么宏大口号而是想表达消息队列这门基础技术值得被重新审视一遍。尤其是以Apache Pulsar为代表的新一代消息平台已经在存储架构、多租户、跨地域复制这些维度上交出了不一样的答卷只是很多人还没真正用过、没真正体会过它带来的改变。活动名字玩了个梗但主题却是实打实的技术回归。1.2 COSCon与Pulsar Developer Day合并办会意味着什么这次活动的特别之处在于它是COSCon’25和Pulsar Developer Day 2025合在一起办的。COSCon是中国开源年会偏重社区、治理、生态协作Pulsar Developer Day则聚焦Apache Pulsar这一个具体项目的开发者生态。两个活动放一起信息量其实很大。我在现场听了几场分享之后最大的感受是开源社区和具体项目之间的连接正在变紧密。以前很多大会是“各讲各的”社区讲许可证、讲治理项目讲架构、讲版本。但这次合办你能明显感觉到一个趋势Apache Pulsar已经不只是“某个大厂开源出来的项目”它已经有了自己的开发者群体、自己的用户案例、自己的周边工具链。这不是一个项目能走多远的全部条件却是它能否真正成为基础设施级软件的关键。再说一句比较个人的体会现在大家谈开源经常谈“捐赠给基金会之后怎么办”也就是所谓的“毕业之后”阶段。Pulsar从捐给Apache基金会到现在经历了版本迭代、社区治理、生产环境大规模检验这次能在中国开源年会上占据一整天的议程本身就说明它已经过了“只见Demo不见生产”的阶段。这种从“项目”到“生态”的转变比单纯看看架构图要重要得多。2. 技术拆解Pulsar凭什么扛起MQ的大旗2.1 传统MQ与Kafka的经典困局要理解Pulsar为什么值得关注得先回顾一下现有方案的痛点。传统消息队列比如RabbitMQ、ActiveMQ解决的是应用解耦和削峰填谷的基本问题它们好用好学但天花板也很明显消息堆积能力有限存储和计算耦合在一个进程里一旦积压数据超过内存和磁盘缓冲的设计范围性能就会急剧下降扩容往往要停业务或者接受一段不可用时间。Kafka解决了“堆积”这个问题它用追加写日志的方式把消息持久化到磁盘理论上可以保留海量数据。但它也有自己的麻烦分区是扩容的基本单位一个分区只能被一个消费者组里的一个消费者读取如果你想通过增加消费者来提高处理速度分区数不够就得先扩分区而扩分区往往要重启或做数据重分布另外Broker和存储还是绑在一起的每个节点既要负责处理请求又要管理本地磁盘上的日志文件遇到磁盘故障、节点迁移运维操作非常吃经验。还有一个常被忽略的问题是跨地域复制。全球化业务现在很普遍但Kafka的跨机房方案要么用MirrorMaker做异步镜像要么靠外部工具同步拓扑复杂延迟和一致性都很难兼顾。传统MQ就更不用说了很多连基本的跨地域能力都没有。这些痛点叠加起来导致一个尴尬局面消息队列在架构里无处不在但架构师选型的时候往往是在“简单的不好用”和“复杂但难运维”之间二选一。大家嘴上不说心里都在等一个“既有MQ的简单性又有Kafka的吞吐量还能轻松运维”的方案。Pulsar就是冲着这个诉求去的。2.2 Pulsar存算分离架构解读Pulsar最核心的设计是“存储和计算分离”。这里面有个值得展开的技术细节我用自己的话讲一下。传统消息队列里Broker既是大脑也是仓库。消息来了Broker要决定路由还要把数据写到本机磁盘消费者拉数据Broker还得从本机磁盘把数据读出来。这种架构简单直接但扩展能力被锁死了。Pulsar把这两件事拆开了Broker只负责计算——接收请求、管理游标、执行路由策略而消息数据全部交给Apache BookKeeper这个分布式存储系统来管。BookKeeper负责把数据切成Segment多副本落盘Broker本身不持有消息数据。这样做的好处非常直接扩容Broker不需要搬数据因为数据不在Broker上扩容存储只需要加BookKeeper节点Broker完全无感。系统架构图在Pulsar文档里看起来多了一层但实际运维起来反而少了“搬家”的噩梦。而且它天然支持分层存储老数据可以自动沉降到S3、Azure Blob这类廉价对象存储里消息保留时间从“几天”变成“几个月甚至几年”成本还能控住。这里我想插一句存算分离这四个字在过去几年被很多系统提过但真正落到消息队列上Pulsar是做得比较彻底的那个。它不只是在部署形态上拆开而是在数据模型上就把存储和计算解耦了。这点很关键因为只有数据模型上解耦才能在运行时不产生“存储跟着节点走”的隐式依赖。2.3 现场最让我印象深刻的Pulsar架构细节活动上有个分享专门讲了Pulsar的Segment存储机制我听完觉得特别有收获这里用自己的话复述一下。Pulsar里的Topic数据不是连续的一大块而是由很多Segment组成。每个Segment是一段独立的日志存储在BookKeeper里Segment可以分布在不同的存储节点上。写入的时候一个Segment写满了就“滚动”到下一个Segment老Segment可以选择继续留在热存储也可以按照策略转移到冷存储。这个设计带来了一个很有意思的能力你可以对Segment做“只读归档”。打个比方传统消息队列像一本厚厚的笔记本写到后面想翻前面的内容得整本翻Pulsar像活页夹每页可以拆下来哪页不常用了就单独收进档案柜想用的时候再按编号取出来。这种按段管理的方式让“消息保留”的成本结构彻底变了——不再是一股脑地堆在昂贵磁盘上而是按数据的“冷热”分层定价。另外BookKeeper底层用的是以Entry为单位的追加写配合Ledger的概念写入链路很短没有复杂的二级索引。读过Pulsar源码的人应该知道它的读写路径设计得非常直接Producer发消息到BrokerBroker批量写入BookKeeperConsumer消费时Broker从BookKeeper批量读取并把游标状态记下来。相比Kafka要处理“分区副本之间的Leader选举、ISR同步”Pulsar的存储副本机制由BookKeeper的Quorum写入来保证逻辑上更单纯。当然我不是说Pulsar没有短板但单纯从架构优雅度上讲它确实解决了我在2.1里提到的那些经典困局。现场有位工程师提问“Pulsar这么设计是不是为了卖云服务”大家笑了但其实他的问题背后是很多人的疑虑存算分离是不是意味着更贵的机器、更高的网络开销这个问题的答案后面我在实操建议部分会细说。3. 现场实况议题、Demo和社区生态3.1 活动上的议题分布这次Pulsar Developer Day的议题设置看得出来是花过心思的。上午的议程偏架构和技术原理从Pulsar的存储引擎讲到Broker的流量控制再到消息生命周期的管理。下午的议程偏落地实战内容包括基于Pulsar构建事件流平台、用Pulsar做数据集成CDC、还有和Flink配合搭建实时数仓的案例。我在现场简单扫了一眼议程表发现一个明显趋势讲“如何调优单个参数”的议题少了讲“如何围绕Pulsar搭建一整套系统”的议题多了。这说明Pulsar社区的重心正在从“怎么把Pulsar跑起来”过渡到“怎么把Pulsar用好”。对技术从业者来说这是一种信号这个项目已经过了“能用”的阶段进入“好用”的阶段了。还有一个细节议题里出现了不少“MQ与流”结合的讨论。以前大家喜欢把消息队列和流处理分得特别清仿佛MQ就是低延迟小消息流就是高吞吐大数据。但这次很多分享都在讲边界正在模糊。Pulsar本身既有队列模型独占消费又有流模型共享消费一个系统能把“实时接口调用”和“离线批处理”之间的连接打通这正好呼应了大会主题里的“Make MQ Great Again”——不是重新发明MQ而是让MQ重新回到架构的中心承担更多的职责。3.2 两个印象深刻的Demo场景现场有几个Demo让我印象很深。先说第一个用Pulsar做跨地域数据同步模拟的是两个数据中心之间的实时订单同步。演示者在两个Region各部署了一套Pulsar集群通过Pulsar的跨地域复制功能把一个Region的订单Topic同步到另一个Region。最直观的效果是你在A中心写入一条消息五六百毫秒内就能在B中心读到而且整个过程不需要额外部署同步工具。以前我用Kafka做类似场景要用MirrorMaker还得自己设计“防止回环复制”的命名规则一个不小心两个机房的数据就无限镜像了。Pulsar的跨地域复制是内建的复制是双向可配的使用上像给Topic加一个配置项不用起专门进程。这个体验上的差别只有真正搭过一遍的人才知道有多舒服。第二个Demo是关于“死信队列”的改进。传统MQ的死信队列基本上就是一个“消息垃圾场”消息进了死信队列之后要么人工捞出来重放要么直接丢掉。Pulsar开发者现场演示的是一种更精细的重试机制消息处理失败后不直接进死信而是进入延迟重试Topic通过延迟消息的特性让消息在几秒或几分钟之后再投递给消费者重试几次之后才真正进入死信。配合Pulsar的Topic多订阅模式同一个Topic可以有不同消费者组一个组做即时处理一个组做延迟重试互不干扰。这个设计思路很轻巧但对业务容错能力的提升非常明显。做支付的、做订单的、做IoT指令下发的都应该看一下这个模式。3.3 社区氛围与技术交流参加完一整天的活动我一直有一个感受就是Pulsar社区的讨论氛围比较务实。下午有一个开放讨论环节观众席上的问题都很具体比如“BookKeeper的Journal和Ledger各自在什么条件下会拖慢写入”、“做分层存储的时候冷数据回读的延迟阈值大概是多少”、“Pulsar Functions在生产环境用得多不多”。当时台上的几位嘉宾没有打太极能答的都直接答了不能当场给结论的也直接说“这个要看具体负载和版本建议你们在测试环境压一下”。这种气氛在国内技术活动里其实是稀缺的很多会议分享者倾向于谈上限、谈理念而这里大家更愿意聊下限、聊边界。我还在现场认识了一位做IoT平台的工程师他们团队用Pulsar的MQTT协议接入设备数据用共享消费模式做设备指令下发。他说他们之前用自研的长连接网关随着设备量从十万级涨到百万级连接管理和消息投递的复杂度迅速飙升后来换到Pulsar的MQTT接入光“连接断线重连”这一个问题就从业务代码里彻底删掉了。这种一线案例比任何架构图都更有说服力。4. MQ演进方向云原生、多协议与可观测性4.1 云原生时代的弹性MQ这次大会上有好几个议题都在讲同一个方向消息队列正在跟云原生深度绑定。具体到Pulsar的语境里“弹性”不是一个虚词它有一整套可落地的组合拳。首当其冲的是容器化部署。Pulsar从早期就提供了比较完整的Kubernetes支持Broker、BookKeeper、ZooKeeper或etcd这些组件都可以通过Helm Chart部署到K8s集群里。再加上它天然存算分离Broker是纯无状态的这意味着你可以根据Topic的流量动态扩缩Broker的数量——流量高峰来了多起几个Broker Pod分摊写压力流量降了把多余的Pod收回即可不用担心Broker本地丢数据因为数据根本不在本地。BookKeeper的存储节点理论上是有状态的但它可以通过“自动恢复”机制来应对节点故障当一个BookKeeper节点挂了Pulsar会自动把它的Segment副本重新复制到其他可用节点上整个过程不需要人工介入。我现在还清楚地记得现场有位运维工程师问“BookKeeper扩节点要提前做数据迁移规划吗”台上嘉宾的回答是“不用新节点加进来之后老节点上可以选做一次I/O重平衡但即使不做新的写入也会自动倾向新节点。”这个操作体验和传统MQ加磁盘、改分区完全是两个时代的东西。4.2 多协议兼容一个Broker吃遍所有客户端Pulsar还有一个让我觉得特别实用的特性多协议。很多人不知道Pulsar原生支持多种协议接入除了自有的Pulsar协议它还能兼容Kafka协议、MQTT、AMQP、WebSocket等。这意味着什么意味着你可以在“系统级”只部署一套Pulsar然后把不同业务线的接入协议统一到一个消息平台上。我见过不少团队内部同时跑着两套甚至三套消息系统微服务之间用RabbitMQ的AMQP协议大数据链路用Kafka协议IoT设备用MQTT协议三套系统分别运维、分别监控、分别买机器。光想想这个重复建设就知道钱和人力浪费得有多厉害。Pulsar的“一个平台多协议接入”思路做的正是资源的集约化整合。而且它的Kafka协议兼容做得比较彻底很多Java的Kafka客户端升级到9.0以上版本以后连接地址一改就能直接连Pulsar业务代码几乎不用动。不过这里要提醒一句协议兼容不等于“完全同义”。比如Kafka协议下事务语义和消费组管理与原生Pulsar客户端不完全一样如果你用了Kafka的高级特性上线之前一定要做一轮完整的兼容性测试。我在现场跟一个做金融系统的朋友聊他说他们就是看中了Kafka协议兼容才决定把消息中台从Kafka迁移到Pulsar的但迁移过程中花费最多时间的就是“语义对齐”测试而不是性能压测。这个经验很实在。4.3 运维可观测性从黑盒到白盒讲运维绕不开可观测性。这是我在这次大会上收获最大的一个部分。过去不管是维护RabbitMQ还是Kafka运维团队最头疼的问题就是“消息丢没丢”、“有没有积压”、“消费者是不是卡住了”。这些问题不是不能查而是查起来特别费劲要看一堆指标还要问开发“你们的Topic是哪个”翻日志翻得昏天黑地。Pulsar在这方面提供了非常完整的可观测性接口。Broker上有丰富的Prometheus指标比如收发消息速率、消费积压量、后台写BookKeeper的延迟分布BookKeeper也有自己的指标包括Journal写入延迟、Ensemble切换次数、磁盘利用率等。把这些指标接入Grafana之后基本上可以做到“实时知道每个Topic的动态”。更让我觉得有用的是Pulsar的“消息追踪”能力。通过启用Broker的追踪功能每一条消息从Producer进入写到BookKeeper再到Consumer消费出去的完整链路都可以通过日志或追踪系统查看。有了这套东西“消息是不是丢了”这个问题几乎可以变成“消息在任意一个环节分别花了多长时间”比从前的黑盒排查体验强了不止一个量级。在这个部分我确实从大会的分享里获得了一个认知MQ的“现代化建设”不只是把老技术换个容器跑一遍。真正的现代化是把弹性扩缩容、多协议统一、全链路可观测这些基础能力真正补齐让人能把精力放到业务逻辑上而不是天天救火。5. 参会后的实操建议与避坑清单5.1 哪些场景适合用Pulsar这个问题我在活动现场问过不少人也和自己的经验做了对照。我个人现在的判断是以下四类场景优先考虑Pulsar。第一全球化业务的跨地域消息同步。Pulsar内置跨地域复制不需要额外搭同步服务运维成本低延迟也能接受。第二多租户或多团队共享消息平台。Pulsar的多租户模型做得很细——租户、命名空间、Topic三个层级可以精细地做配额、隔离和权限控制比较适合中大型企业统一建设消息中台。第三需要超长消息保留的场景比如事件溯源、审计日志、回放分析。Pulsar的分层存储可以把几个月甚至几年的消息沉淀到对象存储查阅历史数据时还能用函数做一次过滤再发给消费者成本优势很明显。第四IoT设备接入。Pulsar原生支持MQTT协议设备消息接入和指令下发可以用一套平台搞定。但也不是所有场景都要上Pulsar。如果业务就是单机房、单集群消息量不大只需要应用解耦和基本的削峰填谷那RabbitMQ依然是更轻的选择。用一个更直白的话说别为了追新而引入复杂度你的团队有没有精力承担一个新的分布式系统的运维这个变量往往比架构先进性更关键。5.2 部署与运维的避坑经验说到部署运维我结合自己和朋友的踩坑经历整理几条现场聊出来的实战经验。BookKeeper配置一定要分开Journal盘和Ledger盘。Journal盘是关键路径磨损和IO延迟直接决定写入性能Ledger盘是数据盘单独放可以避免互相干扰。千万别图省事把所有数据放一块盘上。这是很多初用者都会犯的错误也是压测结果不理想的主要原因之一。Broker的配置需要关注的参数很多但我觉得最重要的一个是内存统计和JVM堆的关系。Pulsar Broker有堆内和堆外内存的精细管理如果你给Broker容器设了过大的内存Limit却没给JVM设对应的Heap和DirectMemory上限很容易被操作系统杀掉。这里的原则是容器内存Limit要真正能给Broker用多少就写多少别留太多“看似有余”的冗余。Consumer的消费模式要提前规划好。Pulsar支持独占、共享、故障转移、Key_Shared这几种订阅模式它们之间的行为差异很大。共享模式可以提高消费并行度但消息顺序则不保证如果业务严格要求顺序就要用Key_Shared或独占模式再配合适当的Key。很多刚开始用Pulsar的业务方上来就默认共享消费结果发现消息顺序乱了又回过来改。这个坑趁早排掉。Topic数量不要设计得太随意。Pulsar官方建议每分钟不要创建超过100个Topic否则会对ZooKeeper和Broker造成不必要的压力。合理规划Topic的维度比如按业务类型而不是按具体设备建TopicIoT设备数据走MQTT的时候更是如此。5.3 一些值得关注的周边项目最后分享几个这次活动上被反复提到的周边项目它们不是Pulsar本体但和Pulsar配合起来能解决很具体的问题。第一个是Pulsar Functions。它是一个轻量级的计算框架可以直接在Broker上运行简单的消息处理函数比如做格式转换、过滤、字段补全。不是所有项目都需要引入一套完整的流处理引擎简单逻辑丢给Functions就够了。第二个是Pulsar IO它提供了一个连接器框架可以把Pulsar数据接出去到HDFS、S3、JDBC、Elasticsearch等系统。CDC场景里它也可以从数据库拉取变更日志再写入Pulsar。第三个是Flink的Pulsar连接器这次大会上有好几个Demo都用了它做实时数仓、实时指标计算的团队值得优先关注。如果你已经在生产环境用了Kafka但不是特别满意可以先不急着全量迁移。很多团队的做法是搭一套Pulsar用Kafka协议兼容先接入一小部分新业务跑一段时间观察运维体验、性能表现再逐步扩大范围。这种渐进式迁移的路径比“周日凌晨割接”要稳得多。我个人在实际操作中的体会是Pulsar最打动人的地方不是某个性能数字比别人高多少而是“运维体验”发生了质的变化。存算分离让你可以不慌不忙地扩容多租户让你可以把消息平台当作公司内部的一种公共资源来运营内置跨地域复制让你不用再造轮子。它没有让消息队列这件事变复杂反而把很多原本要自己扛的事情接了过去。如果你正在为消息中间件发愁不妨照着这篇文章里的场景清单搭一个小规模集群用自己的真实流量压一压。做技术选型这件事看十篇评测不如亲手踩一轮坑。