COSCon25和Pulsar Developer Day 2025放在同一场地的那天早上我站在签到处翻着日程表心里第一反应是消息队列MQ这个被喊了十几年老技术的领域到底还有多少人愿意专门为它跑一趟开发者日结果开场半小时我就发现自己想岔了。主会场走廊过道全是人白板上的讨论稿写了又擦、擦了又写从上午到散场围着Pulsar存算分离Broker无状态扩容多租户隔离这些问题聊的人就没断过。Make MQ Great Again这个标语挂在会场最显眼的位置。我第一眼看到的时候觉得好笑但认真逛了一圈之后理解了——在技术语境里这四个字说的不是口号而是一个真实存在的行业状态消息中间件正在经历一轮实打实的架构重构。这篇文章就把这届活动上我听到、看到、并且自己验证过的东西整理出来包括Pulsar为什么能在这轮讨论里站到C位、它的核心机制到底解决了什么问题以及我顺手在现场走读的一个物联网端侧场景——STM32环境监测链路怎么跟消息中间件接起来。适合做后端架构选型、搞物联网接入、或者纯粹对MQ技术演进好奇的读者参考。1. 为什么重振MQ成为这届COSCon25绕不开的话题先说一个很多人不愿承认的事实消息中间件这个领域过去十年里其实没有发生过真正意义上的架构级创新。大家提到MQ脑子里浮现的无非是几个固定答案——Kafka吞日志很强RabbitMQ做业务解耦顺手RocketMQ在金融场景里有口碑。这些结论本身没错但它们的底层模型都是围绕分区队列消费组这三个概念转转来转去运维上的老问题一个都没少。1.1 消息队列的老问题清单我在会场上随手记下了几个高频吐槽点基本就是当前主流选型的真实痛点分区扩容要迁移数据。Kafka的分区一旦定了想加分区、换Broker、挪副本都要触发数据重平衡集群越大重平衡越痛苦。Broker和存储绑死。传统模型里每个Broker节点自己扛磁盘想扩容量得加节点加了节点又得做数据再分布存储和计算没法各自伸缩。租户隔离靠拆集群。很多团队为了隔离不同业务直接物理拆出好几套集群运维成本直接翻倍。消费模型单一。队列模型和流模型的边界很模糊一个Topic想既给流处理用、又给业务队列用配置起来经常别扭。这些问题单独拎出来任何一个大家都能忍。但攒在一起就变成了一个很尴尬的局面中间件成了分布式系统里最不好伺候的那一块。而这正是Pulsar这类云原生架构的中间件能在这届活动现场被反复讨论的根本原因。1.2 从现场观众构成看MQ需求的三个方向我在现场观察到一个很有意思的现象来听Pulsar议题的人明显分成了三个群体需求完全不一样。第一个群体是互联网公司的后端架构师他们关心的是我能不能把Kafka迁到Pulsar省掉分区重平衡的运维噩梦第二个群体是做SaaS和B端系统的团队他们关心的是一个集群能不能同时服务几十个客户并且互相不干扰第三个群体最让我意外——不少做物联网和硬件接入的人。他们的问题集中在设备上报的数据量不大但连接数很多消息中间件能不能扛得住。这三个群体对应的是MQ选型的三个真实驱动力运维复杂度、多租户隔离、海量连接。而这三点恰恰是Pulsar在架构设计上优先解决的问题。所以与其说Pulsar是来取代谁的不如说它是来回答一个更根本的问题消息中间件能不能真正做到按需伸缩、自带隔离、原生支持多种接入协议。这届活动上所有的技术分享基本都围绕这个核心在场内外展开。2. Pulsar在开发者日上被反复论证的四个硬核点接下来这部分是我认为整场活动信息密度最高的地方。Pulsar的技术分享不少见但开发者日的优势在于讲师会直接放生产环境的实测数据而不是只讲PPT。我挑四个讨论最热烈的机制来说每一个都在现场被追问到了底层。2.1 存算分离把仓库和调度中心分开Pulsar架构里最核心、也最容易被误解的就是存算分离。用大白话解释传统Kafka是运输队和仓库绑在一起——每个Broker既管接收数据又管把数据写在本地磁盘车队要扩大必须先盖仓库而Pulsar把这两件事拆开了Broker只负责接收请求、维护元数据、分发消息数据本身交给另一层叫BookKeeper的存储节点去持久化。这意味着什么呢第一Broker可以做到真正的无状态想加就加想减就减不需要迁移任何数据。第二存储层扩容极其简单——往BookKeeper里加Bookie节点就行新数据会自然分布到新节点上旧数据不需要大规模重分布。第三资源可以独立调配计算压力大就加Broker存储不够就加Bookie互不拖累。当时有个参会者问了一个很尖锐的问题存算分离之后一条消息从发给Broker到真正落盘路径变长了延迟是不是会变差讲师直接放了一组数据Pulsar的端到端延迟P99在生产环境可以稳定维持在几十毫秒级别对于大部分业务消息场景完全是可接受的而且由于BookKeeper是追加写的日志模型顺序写盘效率反而很高。也就是说你用架构上的多一跳换来了巨大的运维灵活性这笔账是划算的。2.2 多租户隔离与统一配额管理第二个被反复讨论的是Pulsar的多租户模型。它把资源分成了三级租户Tenant、命名空间Namespace、主题Topic。租户对应一个业务线或一个客户命名空间对应一个项目或环境主题就是具体的数据通道。这套模型的实际价值在于一个集群可以同时服务多个业务线互不干扰还能做到真正意义上的配额隔离。比如你给A租户配了100GB存储配额和每秒10万条的消息速率限制给B租户配了10GB和每秒1万条这两个租户的Topic可以物理上落在同一批Bookie上但谁也别想抢谁的资源。现场有做SaaS的工程师分享了一个很典型的例子他们一个集群收了三十多个客户的流量每个客户一个租户通过命名空间区分生产环境和测试环境。遇到某个客户突发流量直接给对应租户调配额就行其他客户完全无感。这个能力在传统MQ里几乎是不可想象的——以前要么拆集群要么被噪音邻居问题折磨。多租户这个特性对任何需要面向多业务方提供消息能力的团队来说都是实打实的降本手段。2.3 四种订阅模型与消费模式的组合Pulsar在消费模型上的设计也是现场讨论的热点。它把订阅和消费分开理解四种订阅类型覆盖了几乎所有消息场景独占订阅Exclusive一个Topic同一时刻只允许一个消费者适合严格有序处理的场景。共享订阅Shared多个消费者轮询拉取消息适合吞吐优先、不需要严格顺序的任务队列。键共享订阅Key_Shared按消息Key把消息路由到固定的消费者同一Key的消息有序不同Key的可并行这是非常实用的折中方案。故障转移订阅Failover多个消费者绑定一个Topic主消费者挂了自动切到备用的适合需要高可用但不想牺牲顺序的场合。我当时就想要是早几年有这个模型很多团队就不用为了既要顺序又要并行这种需求去自研一层路由了。这四种订阅类型和Pulsar的多租户能力结合起来基本可以覆盖从流处理到业务解耦的绝大多数场景。2.4 跨地域复制与容灾的实操意义活动上还有一个话题让我印象很深跨地域复制。Pulsar原生支持多个集群之间的异步复制消息在本地集群写入后会异步同步到远端集群。这跟我们常见的主备切换不同它是双向的、多活的结构每个集群都是独立的生产和消费入口数据在多个地域之间互相复制。对一个有容灾要求的系统来说这个能力意味着你的消息中间件不需要再单独搭一套复杂的数据同步工具配置几行就能建立跨地域的数据通道。现场有个做金融支付场景的工程师分享他们用Pulsar的双集群复制做机房级容灾数据损失窗口控制在秒级切换时几乎无感知。当然跨地域复制有个前提是网络质量要好这个我们在国内的云环境下基本都是满足的。3. 当MQ真正下沉到硬件一个STM32环境监测链路的现场走读说实话我的关注点本来只在服务端架构上但这次活动有个环节很特别——现场摆了一个用STM32做环境监测的端到端demo从传感器采集到消息中间件再到云端展示全链路打通。当时围了一圈人我挤进去看完之后发现这其实就是把消息队列用在物联网场景最好的教学案例。3.1 从MQ-2到MQ一个有趣的名字插曲先说个现场的乌龙。有人看到demo板上的气体传感器写着MQ-2第一反应是这怎么还跟消息队列同名了还专门回头去确认自己没走错会场。其实这里的MQ是英文气体敏感材料相关命名的历史遗留叫法跟消息队列Message Queue的缩写完全就是一个巧合。但这正好成了一个很生动的隐喻硬件端的传感器在采集数据软件端的消息队列在搬运数据两个MQ在一条链路上碰了面。这届活动的标题叫Make MQ Great Again某种程度上也像是给这两个MQ一起喊的话。3.2 端侧采集的完整链路我把那个demo的硬件链路拆开整理了一下完全复刻成本不高物料都很便宜适合拿来练手。主要模块包括STM32F103C8T6主控板或者带WiFi的ESP32也可以看你想不想让设备直接联网。DHT11温湿度传感器用的单总线协议读取时序要卡准数据脚接普通GPIO。BH1750光照传感器走I2C总线分辨率可以到1勒克斯量程覆盖1到65535。MQ-2气体传感器输出是模拟量用ADC采样上电后需要预热一会儿再读数值。OLED屏通常是SSD1306驱动I2C接口用来本地显示读数。采集逻辑不复杂我整理成大概这样的流程while (1) { 定时1秒 读DHT11 - 温度 湿度 读BH1750 - 光照强度 读MQ-2(ADC多次采样取均值) - 气体浓度标定值 OLED刷新显示 MQTT发布{temp:26.5,humidity:48.0,light:320,gas:0.21} delay(1000); }实际做的时候有几个小坑DHT11的读到一半总线就被拉低会卡死最好加超时退出BH1750有几种测量模式连续高分辨率模式适合做监测MQ-2的模拟值受供电电压影响建议用稳定3.3V或5V供电并且记录基线值做相对比较而不是直接拿绝对值当标准浓度。3.3 为什么IoT数据值得走消息中间件而非HTTP直连这个demo真正有意思的地方不是采集本身而是数据传输环节的设计逻辑。很多做硬件原型的人第一反应是设备直接HTTP POST到服务器但当设备量上来以后HTTP直连的坑会越来越明显。设备端到服务器之间加一层消息中间件解决的是三个很实际的痛第一连接不是短命的一次性请求而是长连接设备状态可以被服务端实时感知第二数据先落到Topic里消费端按自己的节奏拉取服务器临时抖动也不会丢数据第三多个来源的数据可以在同一个集群里统一处理比如环境监测数据、设备心跳、告警事件全部进入Pulsar再按租户和命名空间分类后期无论是写库还是触发告警都有清晰的通道。现场这个demo用的是MQTT协议从传感器接入然后通过Pulsar的MQTT协议适配能力直接进入Topic后续有订阅者负责把数据写入时序数据库做展示。这套链路的优雅之处在于你完全不需要为物联网场景单独建一套后端消息中间件天然就把设备接入和业务处理解耦了。4. 围观之后要想清楚的三件事避坑经验与选型复盘参加完活动最值钱的其实不是Pulsar好棒这种结论而是搞清楚它到底好在哪以及哪些场景不应该用。我在现场和一些已经落地Pulsar的工程师聊完加上回去后自己做了几天压测和部署测试整理出三条最容易犯的认知偏差。4.1 误区一Pulsar只能跑在K8s上活动上有人一听到云原生就默认必须上K8s这个想法其实是把云原生和容器编排绑定死了。Pulsar确实在K8s里有官方Operator部署很丝滑但对于中小团队来说用Docker Compose在几台裸机上跑一个最小集群也完全可行甚至搭配二进制包直接部署都能跑得很稳。我实测下来单机部署Pulsar做功能验证非常快跑起来只需要一个ZooKeeper或自带的元数据服务、一个Broker、一个Bookie。真正要注意的是生产环境的存储规划BookKeeper的Journal盘和Ledger盘要分开Journal盘用SSDLedger盘可以用机械盘做低成本的大容量存储。这种配置细节比纠结用不用K8s重要得多。提示最小可用集群跑通之后再考虑到底要不要K8s。很多团队的生产流量其实还没大到需要弹性扩容先把JVM内存参数、磁盘规划、监控告警这些基础做好收益更大。4.2 误区二存算分离只是Kafka加外部存储这是在会上被讲师正面纠正过的理解。存算分离不是把Kafka的消息搬到对象存储里就叫分离关键是两个方向的独立弹性Broker不持有任何数据扩容时不需要数据迁移BookKeeper以追加日志的方式提供高吞吐持久化数据保留策略、副本策略都由存储层统一管理。所以你会发现一个很实际的效果当你需要增加Topic或调整保留时间时Pulsar的操作是秒级的你不需要关心数据被存到了哪台机器、磁盘够不够、要不要重平衡。这在Kafka里是好几件事在Pulsar里是一件事。真正的价值不是架构上很酷而是日常运维里省下的那无数个小时。4.3 误区三多租户是大型团队才会用到的东西我一开始也觉得自己团队就一个业务线要啥租户隔离。但仔细想一下开发环境、测试环境、生产环境是不是就是三个天然隔离的空间在Pulsar里把它们放进三个命名空间甚至分属不同租户你就能对每个环境设置独立的保留策略、存储配额和权限控制。开发环境产生的垃圾Topic不会污染生产测试环境的流量再大也卡不到生产数据——这就是多租户的最小落地场景。4.4 一张选型表与一个冷静的边界综合这届活动上的讨论我把几个主流的消息中间件做成一张对照表方便做选型时直接参考维度RabbitMQApache KafkaApache RocketMQApache Pulsar核心定位企业级消息路由高吞吐流数据管道金融级可靠消息云原生流与队列一体化吞吐量级万级百万级十万级百万级消息模型队列为主分区消费组Topic队列Topic订阅多租户隔离弱靠拆实例弱靠Topic约定中原生三级隔离数据保留短消费即删按磁盘大小保留按时间保留按策略精细化控制扩容体验加节点加节点重平衡加节点迁移计算/存储独立加适合场景异步解耦、任务分发日志、实时数仓事务消息、订单混合负载、IoT多租户接入选型时最关键的一条边界是流量很小、业务简单、团队运维时间有限的场景别盲目上Pulsar。它再能打也需要你理解BookKeeper、懂存储规划、能配置租户策略。如果你的需求就是几十个微服务之间发个异步消息RabbitMQ的那点运维成本反而更低。技术选型从来不是选最先进的而是选最匹配你当前复杂度的。活动散场时我在门口站了一会儿几个参会者还在聊Pulsar与Kafka的迁移对比。回想这届COSCon25和Pulsar Developer Day给我留下最深印象的不是具体某个功能点而是大家终于开始认真讨论消息中间件应该长成什么样子这个问题本身。从现场那个把STM32传感器接入消息队列的demo到多租户隔离在生产环境的真实分享其实都在说明一件事MQ这个老家伙并没有过时它只是在换一种更符合云时代和物联网时代需求的方式存在。如果你正在纠结消息中间件选型我的建议很简单——先把流量模型算清楚再把团队能付出的运维精力算清楚然后带着这两个数字重新回去看一遍这些对比答案会比你想的明显很多。