企业官网建设流程全解析

1. 活动背景与现场直击：MQ的文艺复兴

1.1 为什么"Make MQ Great Again"成为了口号

看到这个标题的时候，我愣了一下——Make MQ Great Again，乍一看有点戏谑，但仔细想想，这恰恰是这几年消息队列圈子最真实的状态。MQ（消息队列）这个诞生了几十年的老家伙，在云原生和AI浪潮里不但没被淘汰，反而被Pulsar、Kafka、RocketMQ这些项目一次次重新激活。这次COSCon'25和Pulsar Developer Day 2025放在一起办，现场最大的感受就是：MQ不是老了，是正在经历一场文艺复兴。

现场签到的时候瞄了一眼数据，报名人数远超预期，很多是冲着Pulsar的专场去的。这也不奇怪——Apache Pulsar这几年在技术圈的热度直线上升，尤其是它那套"存储计算分离"的架构，动摇了Kafka多年来的统治地位。会场内外的技术讨论、圆桌交流、甚至走廊上的小型争论，几乎都绕不开一个话题：MQ到底应该怎么演进，才能跟上这个数据爆炸、AI遍地走的时代。

1.2 大会日程结构与参会人群画像

这一天的日程排得相当扎实。上午是COSCon主会场的几个主题演讲，下午则是Pulsar Developer Day的专场，安排了十几个分享。参会人群里，我看到的至少有这几拨人：一拨是不满足于Kafka、想看看新方案的架构师；一拨是已经在生产环境跑Pulsar、来取经或者来吐槽的一线工程师；还有一拨是做实时数据、AI基础设施的开发者。

这让我挺感慨。上一次见到这么混合的人群，还是在几年前的容器圈子里。MQ这个领域正在经历和Kubernetes当年类似的阶段——技术架构在变、使用方式在变、社区的版图也在变。而Pulsar恰好站在了这个变化的中心位置。

注意：本文内容基于大会现场的分享、圆桌讨论和个人实操经验整理。涉及具体的数据和性能参数，会注明出处或标注为个人测试结果，方便大家自己判断。

2. MQ技术生态现状：Kafka、RocketMQ与Pulsar的暗战

2.1 Kafka的"统治"与裂缝

要说消息队列生态，Kafka绝对是一个绕不开的名字。它靠着高吞吐、分布式日志的设计，几乎成为了"消息队列"的代名词。过去十年，凡是搞大数据、搞实时流处理的，默认选项基本就是Kafka。我在不少公司见过这样的场景：业务团队根本不管什么消息顺序、重试策略，直接"先上Kafka再说"。

但Kafka并不是没有短板。最典型的问题有两个：一是分区扩容（Partition Scaling）极其痛苦，分区数定了之后想调整，要么运维层面做数据迁移，要么直接忍受rebalance带来的长时间不可用；二是broker和存储强耦合，每个broker屁股后面挂着一堆本地磁盘，节点挂了之后分区leader的恢复速度、数据均衡的周期都很让人头疼。Kafka的架构是典型的"Share-Nothing"设计，看起来简单，但scale-out和scale-in都像是在做手术。

这次大会的圆桌环节，有人直接问了一个现场很多人心里都有的问题：Kafka的KRaft模式都搞了这么久了，为什么在生产环境还是很少有人敢把ZooKeeper去掉？这其实说明了一件事——Kafka的架构变更牵一发动全身，哪怕是官方在推的大改动，社区和用户的迁移节奏也是非常缓慢的。这给Pulsar留下了巨大的空间。

2.2 Pulsar的差异化打法：存储计算分离

Pulsar这套架构，核心思路是和Kafka反着来的。Kafka是把数据放在broker的本地磁盘，Pulsar则是把消息数据放进一个独立的存储层——Apache BookKeeper。Broker变成了一个真正的"无状态"接入层，只管收发消息、维护订阅状态、执行策略。

这个设计带来的直接好处就是：想扩broker，随时加，加了之后立即分担流量，本地不用做数据搬移；想缩容，直接撤掉，也不用担心数据丢失——因为数据根本不在broker上。存储层扩容同理，BookKeeper节点是独立的一组，加节点就能提升存储容量和IO能力，业务无感知。

现场有个分享用了非常接地气的比喻：Kafka像是"一个人既要接客又要记账"，Pulsar则是"前台只管接待，财务和仓库是独立部门"。这个类比做得很到位，也让不少第一次接触Pulsar的人一下子get到了架构差异的本质。

2.3 Pulsar的消息模型与订阅模式到底强在哪

比架构差异更重要的是消息模型的差别。Kafka提供的消费模型本质上只有两种：消费者组（相当于独占或灾备订阅）和广播（相当于订阅中的一些模式）。在复杂的业务场景里，你会发现有些Kafka的"玩法"是硬凑出来的，比如共享消费，Kafka社区是长期不支持的，因为offset管理在共享场景下非常复杂。

Pulsar原生支持四种订阅模式：独占（Exclusive）、共享（Shared）、灾备（Failover）和按键共享（Key_Shared）。这看起来只是API层面的差异，实际上影响深远。举个例子：如果你有一个任务队列的场景，每条消息的处理时间不确定，用Kafka你只能祈祷partition的key散列足够均匀，否则就会出现某几个消费者空闲、某几个已经堆积到天荒地老的情况。而Pulsar的共享订阅，让每条消息可以被消费者池里的任何一个实例拉取，天然解决了负载不均的问题。

我在生产环境里就用过Key_Shared模式处理过订单事件。同一个订单ID的消息必须被同一个消费者处理，但不同订单之间要并行。这在Kafka里只能通过自定义分区策略去做，而Pulsar直接在订阅模式层面就给你了。这类原生的能力差异，是会直接影响业务代码复杂度的。

3. Pulsar技术深潜：架构原理与核心机制拆解

3.1 分层架构的完整链路：Broker、BookKeeper与ZooKeeper的协作

要理解Pulsar，脑子里必须有一张清晰的架构图。消息的路由和处理在Broker层完成，消息的持久化落在BookKeeper的Bookie节点上，元数据（哪些topic在哪个broker、每个topic的游标等）则由ZooKeeper（后续版本用etcd）管理。

这一条链路里，Broker是无状态的，状态被拆到了另外两个组件上。无状态带来的是什么？是"水平伸缩的粒度变得极细"。你的系统遇到流量洪峰，理论上可以直接加broker节点，十几分钟内就能完成扩容。这在Kafka的架构下是不可想象的。

但是也要泼一盆冷水：Broker无状态不等于整个系统简单。BookKeeper本身的IO模型、数据同步机制、故障恢复逻辑，复杂度并不低。大会上有位分享嘉宾直言：Pulsar把Kafka在broker层的很多复杂度，转移到了存储层。这句话我深表认同。使用时你会感觉Broker侧逻辑清晰，但一旦Bookie出了问题，排查的思路就要切换成存储专家的思维，这对团队的能力结构是有要求的。

3.2 游标（Cursor）管理：Pulsar最容易被低估的设计

Kafka的offset管理是通过内部topic（__consumer_offsets）实现的，消费者提交的offset本质上是发给一个特殊的topic。这种设计的优点是不用额外引入组件，但缺点也不少——重平衡（Rebalance）的时候offset恢复有延迟，且消费者和分区之间的关系变化会导致offset语义的混乱。

Pulsar的做法完全不同。游标（Cursor）是Pulsar自己管理的一等公民，每个订阅都对应一组游标，游标的持久化依赖BookKeeper的Ledger。这意味着什么？意味着消费者的消费进度和消息数据一样，有了真正的"持久化"和"高可用"。

我在生产环境实际遇到过一个场景：某个消费者处理消息的速率突然下降，积压了几千万条。在Kafka里想跳过这些积压消息，你要么写脚本去改offset，要么干脆丢弃重建topic。而在Pulsar里，我直接重置了订阅的游标位置，把这个订阅的回退时间设置到一个小时前，一条命令就完成了。这种运维体验上的差距，只有真正操作过的人才会懂。

3.3 消息生命周期与保留策略：不只是堆数据

Pulsar另一个让我觉得设计得相当优雅的地方，是消息保留策略。Kafka的日志保留逻辑是Segment级别的，删除也是"删整个Segment"，粒度相对粗糙。Pulsar则可以从几个维度精细控制：按时间保留（TTL）、按消息数保留、按存储大小保留，还可以设置“持久化但不可消费”的策略。

举个具体的场景：合规审计需要所有原始消息保存三年，但业务消费者只需要处理一周之内的消息。如果你用的是Kafka，要么让消费者一直挂在topic上做“假消费”（通常会有问题），要么就再复制一份存到对象存储里。而在Pulsar里，你可以设定消费端的留存无关策略——消息不会被自动删除，但游标可以往后跳，消费者不会再拉到过期消息。这些都是真实的业务需求，不是技术上的炫技。

3.4 分层存储与无状态Broker的实际收益

Pulsar的分层存储（Tiered Storage）是我个人非常喜欢的一个功能。它允许把很久以前的消息从BookKeeper自动转移到廉价的存储介质上，比如AWS S3或者阿里云OSS，同时对外还保持完全一致的消息访问语义。

这意味着什么？意味着你可以在同一个topic里，既能读到几毫秒前刚产生的消息，也能读到一个星期甚至一年前的历史消息——不需要额外走一遍大数据导出流程。有个金融行业的分享嘉宾讲了他们的案例：合规需求要保留半年的所有交易流水，但是热数据其实只需要存三天。用Pulsar的分层存储，BookKeeper只需要支撑三天的事务型IO，半年的冷数据挂在对象存储上，存储成本估算下来比原来用Kafka加离线备份的方案节省了至少40%到50%。

无状态Broker在生产环境最直接的价值是——机器的故障处置变得很轻松。我的团队曾经在高峰期遇到一台broker物理机硬件告警，按传统思路这是要申请变更窗口的重活儿，但在Pulsar里，我们直接把这台机器的broker进程停掉，流量自动转移到其它broker，整个过程业务无感，消费者集群没有任何重平衡风暴。这个体验用过就回不去了。

4. 大会演讲精华回顾：Pulsar在AI与大规模生产环境的实战

4.1 AI时代MQ的新角色：从"管道"到"数据底座"

这次大会有一个明显的风向：MQ正在从一个“传输管道”，变成一个完整的"数据底座"。多个演讲嘉宾都提到了一个趋势——AI应用（尤其是Agent类应用）需要的不仅仅是消息路由，还需要消息的历史回溯、事件驱动、多租户隔离，甚至需要消息数据直接参与模型特征计算。

有个做AI Infra的嘉宾提到，他们用Pulsar的Key_Shared模式来给不同用户的AI Agent请求做隔离，确保同一个用户的上下文不会被不同消费者并发处理。这在我听下来是一个相当巧妙的用法——AI对话的上下文连续性和消息队列的消费模式，本质上是同一个需求。过去你可能要自己写一堆状态管理代码，现在MQ原生能力就能解决。

另一个做数据平台的同学分享了他们在Pulsar上跑批流一体任务的实践：通过Pulsar Functions做轻量级的流式计算，过滤、清洗、格式转换在消息进了topic之后就能完成，不用再把数据投到一套独立的流处理系统。这让我觉得，MQ在未来AI基础设施里的位置，恐怕比很多人预想的要重要得多。

4.2 大规模生产环境案例拆解：千万级Topic的运维哲学

下午场有几个分享是针对超大规模集群的，其中一个案例让我印象很深：他们管理着接近2000个broker、超千万个topic（包括分区），每天的Topic活跃度差异极大，大量Topic可能一天只有几百条消息，但又要保障秒级延迟。

在这种规模下，Kafka经常遇到的痛点是无辜的Rebalance。而Pulsar的无状态Broker在这个场景下优势彻底显露了：broker挂了，影响范围基本只有在该broker上建立的连接，服务端没有复杂的分区迁移过程，客户端会自动重连到其它broker。这个规模级的运维分享不是纸上谈兵，他们的监控大屏上清晰地展示出了单台broker宕机后的客户端重连曲线——平滑、快速、无毛刺。

同时他们也分享了踩坑经验：聊聊BookKeeper的Journal和Disk的分离配置。如果所有数据都写在同一块磁盘上，写延迟会急剧升高。通过把Journal（写前日志）放在高性能NVMe上，把Ledger数据放在普通SSD上，集群性能得到了数倍的提升。这个细节在官方文档里只是一句话，但在真实运维场景里能直接影响集群的稳定性。

4.3 多租户隔离在Pulsar中的落地实践

多租户是Pulsar在架构层面就内置的能力，和很多MQ通过"起多个集群"来隔离租户的笨办法完全不同。Pulsar有Namespace级别的隔离体系：存储配额、消息速率、订阅数量，都可以针对不同Namespace做精细化的策略配置。

一个SaaS服务商的嘉宾分享了他们的做法：他们的每个大客户独占一个Namespace，设置独立的存储配额和流量限制；小客户则共享一个大Namespace，单独用Topic做逻辑隔离。通过这种方式，他们不费吹灰之力就解决了吵闹邻居（Noisy Neighbour）的问题——某个客户流量突然暴增，不会影响到同集群的其他客户。底层能力原生支持，而不是靠上层业务逻辑去弥补，这种优势在长期维护中感受最明显。

4.4 Pulsar生态工具链：从Kafka协议兼容到插件机制

对于已经深度使用Kafka协议的业务，Pulsar提供了一个几乎零成本的迁移路径——Kafka协议兼容层。这意味着你的Kafka客户端（Java、Go、Python等）可以不用改代码，把bootstrap地址换成Pulsar集群的地址，就能直接对接Pulsar。我们去掉了Kafka这个名字的束缚。

大会现场有个真实的迁移案例让我印象深刻，他们的Kafka业务平均迁移时间在一天以内，剩下来的时间主要花在测试和回归上，代码改动量微乎其微。另外一个作分享的嘉宾还提到了Pulsar在北向生态上的努力，像Pulsar Functions、Pulsar IO以及和Flink、Spark等主流计算引擎的深度整合。

5. 实操干货：从零到一上手Pulsar的完整路径与踩坑记录

5.1 单机部署与第一个消息的发送

这里给还没接触过Pulsar的同学一个最快速的上手路径。生产环境肯定不推荐单机模式，但本地开发、跑通概念验证是够了。官方提供的二进制包直接解压就能跑。

# 下载最新的二进制发行包（以当前稳定版本为例） wget https://archive.apache.org/dist/pulsar/pulsar-3.3.0/apache-pulsar-3.3.0-bin.tar.gz tar -xzf apache-pulsar-3.3.0-bin.tar.gz cd apache-pulsar-3.3.0/ # 启动单机模式（会同时启动broker和依赖的BookKeeper、ZooKeeper） bin/pulsar standalone # 再开一个终端，用命令行生产一条消息 bin/pulsar-client produce my-topic --messages "hello-pulsar" # 消费消息 bin/pulsar-client consume my-topic --subscription-name my-sub --num-messages 1

这里有一个很多人第一次用会困惑的点：Pulsar standalone模式启动一个进程就把ZooKeeper、BookKeeper和Broker全都拉起来了，看进程列表会看到一大串Java进程。实际上这是三个独立组件各自有启动脚本，standalone帮你拼成了一个One-Box环境。你可以在本地调试这个丑但实用的方式快速验证逻辑。

5.2 生产环境的正确部署姿势：独立组件的划分

本地跑通了之后，生产环境部署需要认真对待组件拆分。我个人的建议是：生产环境不要用standalone模式，用systemd或者容器编排来分别部署ZooKeeper集群（至少3节点）、BookKeeper集群（至少4节点，保证宕机一台不影响写可用性）、Broker集群（按流量预估节点数，建议起步三台）。

# 以二进制方式启动Bookie（存储节点） bin/pulsar bookie # 以二进制方式启动Broker（接入层） bin/pulsar broker

这段配置里需要重点关心两个参数的设定：

# conf/bookkeeper.conf 中重点关注 journalDirectories=/data/pulsar/bookkeeper/journal ledgerDirectories=/data/pulsar/bookkeeper/ledgers # conf/broker.conf 中重点关注 managedLedgerDefaultMarkDeleteRateLimit=1000 allowAutoTopicCreation=true defaultNumberOfTopicPartitions=1

说几个生产环境的实测经验：

• 磁盘规划上，Journal目录用NVMe，Ledger目录用普通SATA SSD，这两种磁盘的IO特性完全不同，不要混用。如果Jounral和Ledger混在同一块盘上，会导致频繁的写放大和IO争抢，写延迟会呈指数级恶化。
• managedLedgerDefaultMarkDeleteRateLimit这个参数是在控制游标删除速率。如果设置得太高，在消费速度快的时候会导致Bookie上的Ledger被快速删除，反而造成频繁的元数据操作，影响集群性能。默认值可能不合你的场景，需要根据实际消息吞吐量做压测调节。
• 建议创建namespace之后立即设置存储配额和消息保留策略。这是很多人会忘记做的一步。默认策略是无限保留，这在生产环境是灾难性的——线上事故后恢复的消息会把磁盘瞬间打满，而且你根本没有一个自动清理机制去兜底。

5.3 客户端使用中容易踩的坑：Consumer与Producer配置

客户端是踩坑重灾区，社区里被问得最多的几个问题，几乎都集中在Consumer配置上。

首先是负确认（Negative Acknowledgment）和Re-delivery延迟。很多Pulsar新手会把RabbitMQ"处理失败就nack，立刻重新投递"的习惯带进来。但Pulsar并不推荐这么做，因为默认的Re-delivery延迟是0，如果你在Consumer里对一条无法处理的消息不停地负确认，就会形成死循环。正确的做法是negativeAckRedeliveryDelayMicros这个参数，把它设置成秒级别或者更高，例如：

Consumer<byte[]> consumer = client.newConsumer() .topic("my-topic") .subscriptionName("my-subscription") .subscriptionType(SubscriptionType.Shared) .negativeAckRedeliveryDelay(5, TimeUnit.SECONDS) .subscribe();

其次是Receiver Queue Size。这个参数代表消费者本地预取的消息条数，默认值在1000条上下。如果在共享订阅里，一个Consumer挂着巨大的Queue，会一次性拉走大量消息，导致同一订阅下的其它消费者长期处于饥饿状态。我在压测环境里就遇到过这个问题——4个消费者，负载完全不均衡，就因为第一个Consumer启动时会把Queue填满，另外三个完全拉不到消息。

5.4 消息积压问题的定位思路：不止是消费者慢

当Pulsar的消息开始积压，定位问题的思路和Kafka有本质区别。Kafka积压了，大概率是消费者消费能力不足或分区分配不合理。而Pulsar积压了，要先去确认消费者是在"还没拉取"还是"拉取了但没确认"。

我在实践中积累了一套速查思路：

如果确认了是消费者处理能力的问题，Pulsar的处理手段就比Kafka灵活很多——直接在共享订阅下加消费者实例就行，不需要动topic的分区数，无状态Broker会无缝的把消息分发给新加入的消费者。这个过程我在生产环境做过很多次，真的做到了服务无重启、消息无丢失。

5.5 死信Topic与重试策略的最佳实践

Pulsar的死信机制比很多MQ要灵活，它可以同时设置死信Topic以及重试Topic。所谓重试Topic，其实就是专门存"处理失败但还有机会成功"消息的Topic，消费者在下次启动时，会自动先消费重试Topic里的消息，再处理主Topic。

Consumer<byte[]> consumer = client.newConsumer() .topic("my-topic") .subscriptionName("my-subscription") .subscriptionType(SubscriptionType.Shared) .deadLetterPolicy(DeadLetterPolicy.builder() .maxRedeliverCount(10) .deadLetterTopic("my-dlq-topic") .build()) .subscribe();

这里有个很大要注意的点：死信Topic必须开启allowAutoTopicCreation才能自动创建。如果关了自动创建，又没有提前手工建好死信Topic，那积压到一个程度，消息就会一直重投，直到达到确认超时的时间，消息进入一种"反复重投但最终无处安放"的状态。

我在一个金融项目里吃过这个亏，当时团队按文档配了死信策略，也配置了自动创建Topic的开关，但因为生产环境部分Namespace做了更严格的权限控制，默认禁止了自动创建。上线后两天才发现有大量消息卡在重投循环里，排查了很久才定位到是死信Topic没建出来。后来的经验是：任何时候配了死信策略，提前把死信Topic手工建好，线上环境不能依赖自动创建这种"方便"。

5.6 Pulsar与Kafka选型：别再争谁取代谁

现场几乎每个圆桌都在讨论Pulsar和Kafka的未来关系。在我看来，二者不是简单的"替代"关系，而是有各自更好的适用场景。

我的个人结论是：如果你的场景主要是"离线分析、日志管道、高吞吐顺序写入"，Kafka那些根深蒂固的优势仍然存在，迁移成本不值得。但如果是微服务解耦、多团队共享、SaaS多租户、混合负载、以及需要大量灵活的消费模型，Pulsar的架构优势会更加明显。

6. 社区动态与未来趋势：Pulsar的下一个里程碑

6.1 Pulsar周边生态的活力与挑战

Pulsar社区目前的活跃度，从这次活动的热度能明显感觉到。几个热门项目的作者都来到了现场，包括Pulsar Manager、Pulsar Protocol以及各种客户端库的维护者。这让我重新确信MDC级别的项目正在向更高成熟度迈进。

不过也要承认，Pulsar生态相比Kafka还是有不小差距。在大数据生态的整合上，虽然Flink、Spark都已经支持Pulsar，但Kafka的整合力度和成熟度依然更强一些。社区的职位缺口也很现实：招聘一个熟练的Kafka运维比找一个经验丰富的Pulsar运维容易得多。这不是技术问题，是生态积累的问题，需要时间。

6.2 从大会氛围看MQ领域的未来方向

这次大会让我看到一个很清晰的趋势：MQ正在和AI基础设施深度融合。现场聊到的一个典型需求是——如何让大模型在生成过程中实时的消费、分析数据流，同时保证模型状态的多租户隔离。

从架构上看，事件驱动和消息流式处理天然是AI系统中"数据进、数据出"的高速通道。Pulsar在架构层的弹性伸缩能力、持久化游标能力和多租户能力，让它在这一波AI浪潮里具备相当强的叙事潜力。

同时，Pulsar社区也在明显加大在这些方向的投入：批量消息的高效处理、更完善的事务机制，以及与数据湖、流湖一体架构的打通。这些都是实打实的Roadmap，不是画饼。

提醒：不管用哪个MQ，都有替代方案。但如果你正在为微服务、AI、实时计算等场景选型，我建议把Pulsar纳入概念验证清单里，尤其是需要多租户隔离、消费模式灵活性和无状态Broker的场景。这个结论放在三年前我会犹豫，但现在，它的答案越来越清晰。

7. 参会后的个人思考与建议

7.1 值得立刻尝试的四个方向

大会结束后，我回想了这次活动带给我的信息量，如果只能挑选出最值得立刻上手尝试的几件事，我的清单是这样的：

第一，搭建一个哪怕只有单机模式的Pulsar环境，把四种订阅模式全部用代码跑一遍。很多东西光看文档是理解不了的，比如Key_Shared和Shared在面对相同消息序列时的行为差异，你一定要实际动手才能有体感。

第二，如果你的团队还在用Kafka做微服务间的事件传递，试试Pulsar的Kafka协议兼容层。配一套测试环境，把相同代码的Kafka客户端切到Pulsar上，体验一下消息查重、死信策略和一些Kafka做得比较痛苦的事情。

第三，认真评估多租户隔离策略。只要你公司有多个业务团队共享MQ集群的需求，Pulsar在Namespace级别的配额和流量管理能力，就能帮你解决过去最常见的“某个团队把集群干爆”的运维事故。

第四，把"分层存储"记到脑子里。如果你长期有保存数月甚至数年消息的合规要求，又苦于成本太高，Pulsar的Tiered Storage很值得做一轮深度的技术验证。

7.2 给技术团队的落地建议

如果你想在团队里推动Pulsar从评估走向落地，我的建议是不要急着把全部业务迁过来。选择一个非核心、但对消息可靠性有要求的业务先做试点。期间重点观察三件事：架构集群的稳定性、消费模型是否有明显改进、以及运维工具链是否顺手。试点没问题，再逐步扩大范围，这个节奏是最稳的。

大会现场我详细问了几个已经在生产环境大规模使用Pulsar的团队，得到的一个共通的反馈是：刚迁移过去的第一周最痛苦，因为Kafka的很多使用习惯要改，尤其是消费模型的思维模式。但一旦适应之后，真的不太愿意回到Kafka的运维模式中去了。

7.3 我的个人感受：MQ的"再次伟大"正在发生

作为一个和消息队列打了多年交道的人，我经历过RabbitMQ的灵活，体验过Kafka的强壮，也见证过RocketMQ在电商场景里的独到之处。这次参会最大的感受是，消息队列这个领域，远没有到成熟定型的那一天。当AI技术、云原生架构和数据基础设施继续往前推进，MQ依然是被反复需要的刚需底座。

"Make MQ Great Again"这句口号，看起来像是一句调侃，但实际上它正在发生。Pulsar就是这个进程里最有代表性的技术之一。如果你也在思考自己团队的消息架构应该怎么演进，我非常推荐你把Pulsar纳入视野，动手测一测，亲自体验一下技术演进带来的实际改变。这次的参会经历让我更加确认了这个方向，也推荐所有关注MQ生态的人持续关注Pulsar社区接下来的动作。