企业官网建设流程全解析

先说结论，这场COSCon‘25期间的Pulsar Developer Day 2025专场，是我今年参加过最“解渴”的消息队列技术活动。从早到晚的内容排得非常满，不是那种念PPT式的分享，而是真刀真枪地讲架构演进、生产落地方案和踩坑细节。作为一个长期跟MQ打交道、也维护过好几套生产消息中间件的人，这一天下来，很多东西都值得记录下来。这篇回顾文章，就是想把当天的技术干货、社区动态和我个人的一些思考整理出来，给关注消息队列选型、以及想深入了解Pulsar的读者一个参考。

标题里那句“Make MQ Great Again”其实挺有意思，它不是营销口号，而是技术圈里的一种情绪表达。消息队列这些年一直被叫做“系统的血管”，但说实话，真正把消息队列当成核心基础设施来打磨的团队并不多。而Apache Pulsar这几年在存储计算分离、多租户和分层存储这些方向上的进展，确实让这个领域重新变得性感起来。

1. 先聊聊这一天的整体印象：议程与技术主线

1.1 从早到晚的节奏：演讲、动手实验与自由交流

那天我大概是早上八点半到的会场，签到处已经排起了队。和很多技术会议一样，大家胸前挂着胸牌，背着双肩包，但明显能感觉到这个场子里的“精准度”很高——来的人基本都是后端开发、架构师或者中间件负责人，讨论的话题也始终围绕主题在转。

上午场的安排以主题演讲为主。开场是项目动态和社区进展的介绍，接着是几个核心议题的深度分享，节奏大概在30到40分钟一个主题，中间有短暂的茶歇。我最关注的是其中关于存储架构和生产环境实践的Session，这些内容不是那种泛泛的产品介绍，而是带着真实业务压力去讲的。

下午场是动手实验（Workshop）的环节，参与者可以跟着讲师一步步操作，现场搭起一套单机版Pulsar环境，跑通生产消费、了解分层存储的配置方式。这种一边讲一边跑的环节，参与度明显比纯听高很多。我记得当时我旁边坐着一个做电商业务的工程师，他一边敲命令一边跟同伴小声讨论：“这个offload策略如果接到我们S3的桶里，是不是就能把一年前的订单数据直接丢对象存储了？”那种感觉，就是技术分享真正产生了共鸣的时刻。

除了正式的议程之外，会场角落里还有一些自由交流的讨论角，几个人围着一张桌子，聊开源协议的兼容性、聊跨地域复制的同步延迟，甚至还有人在现场给Pulsar提了一个关于客户端连接池问题的改进建议。这种交流的信息密度，有时候比台上的演讲还高。

1.2 “Make MQ Great Again”这句话背后的技术圈情绪

这句口号挂在主会场背景板上，乍一看有点戏谑，但仔细想想，它确实点出了消息队列圈子当下的状态。过去十几年，Kafka几乎成了消息中间件的代名词，稳定、吞吐高、生态好，但它的存储模型和运维模型也带来了一堆让人头疼的问题：分区数上去了之后均衡成本高，冷数据占磁盘导致查询变慢，多租户支持基本要靠多集群来堆。

“Great Again”并不是说过去很好现在不行了，而是说这个领域需要一点新的想象力。Pulsar的存算分离架构、原生多租户、分层存储和跨地域复制，正好指向了Kafka时代那些不太好绕开的问题。它的兴起不只是一款产品的崛起，更是整个MQ技术栈在向“云原生基础设施”方向演进的一种表现。

我在现场听到有位分享者说了一句话，大意是“我们把消息队列从通信组件变成了数据基础设施”。这句话其实很关键。当你把MQ当作通信管道时，关心的就是吞吐、延迟；当你把它当作数据基础设施时，关心的就是持久性、可追溯性、隔离性和跨地域的容灾能力。Pulsar的很多设计，正是在为后者铺路。

2. 核心分享复盘：Pulsar真正打动人的技术点

2.1 存算分离不是噱头，是架构长期主义的落点

很多人在聊Pulsar时都会提到存算分离，但说实话，如果不是仔细读过它的架构设计，很容易把这个概念和普通的“服务拆分开”混为一谈。Pulsar的存算分离，指的是Broker（承担计算和读写）与BookKeeper（承担存储）是完全独立的两层，各自可以单独扩缩容。

给你打个比方。传统消息队列像一个小杂货铺，老板既要站在柜台前招呼客人，又要去仓库理货，客人一多、货一多，老板就会手忙脚乱。Kafka其实就是这个模式，Broker既要处理读写请求，又要管磁盘上的日志文件，流量高峰期和存储压力混在一起，互相拖累。而Pulsar更像一个大超市，前台收银和后台仓储是两拨人，哪边忙就给哪边加人。Broker层无状态，扩容时不用搬数据，BookKeeper层专注把数据安全可靠地写进持久化存储，挂了一个节点也能通过副本机制快速恢复。

现场有位嘉宾讲到了这个架构在生产环境中的实际价值，他提到一个细节：他们曾经在业务高峰期给Pulsar集群的Broker层扩容，整个过程几乎没影响在线读写，因为新Broker加入后只需要做一些负载接管，不需要像Kafka那样做分区重分配和长时间的数据迁移。这个“弹性”带来的运维体感，是用过Kafka再转向Pulsar之后体会最深的一点。

另外，存算分离还有一个不那么显性但很重要的好处：支持更大的Topic规模。Kafka的Topic数量一旦涨上去，分区文件和小文件碎片会成为运维噩梦，而Pulsar因为底层用BookKeeper的分段存储（Segment）机制，单个集群能承纳的Topic数量高出不少。对于有大量业务线、每个业务线都有自己Topic的团队来说，这个差异是实打实的成本差异。

2.2 多租户模型：一个集群服务几十条业务线的底气

Pulsar的多租户模型是我觉得它在架构上做得最优雅的部分。它把资源逻辑拆成了三层：租户（Tenant）、命名空间（Namespace）和主题（Topic）。你可以把租户理解为一栋写字楼，命名空间是某一层，Topic就是这一层里的一个个办公室。每个层级都可以独立地设置权限、配额、隔离策略和消息保留策略。

这意味着什么？意味着一个Pulsar集群可以服务多个业务部门或团队，每个团队放在自己的租户或命名空间里，互不干扰。比如A团队的消息设置了3天保留，B团队的消息设置了30天回溯，C团队设置了无限保留用于审计，这些策略可以共存在同一个集群里，而不是为每个团队单开一套集群。

现场有个分享嘉宾介绍了一个典型案例：他们公司用一套Pulsar集群同时支撑订单事件、用户行为日志、搜索索引构建、数据分析等多个业务场景，每个业务线一个命名空间，各自的存储策略、消费模式、权限互相独立。如果放在Kafka里，要达到类似效果，要么给每个团队搭一套集群，要么就只能共用一个大集群然后自己维护非常复杂的ACL规则。前者浪费资源，后者管理成本和风险都很高。

多租户还带来一个很重要的能力：资源隔离与配额保护。在Pulsar里，你可以设置每个命名空间的存储配额、Backlog配额和消息速率限制。这样即使某个业务线出现了消费故障导致消息大量积压，也不会影响其他业务线的正常读写。这一点对于中大型团队来说非常实用，等于从平台层面给业务排障留出了缓冲带。

2.3 分层存储与跨地域复制：从“删日志”到“无限回溯”

在我接触过的很多消息队列团队里，围绕“消息能保留多久”这件事，都有过痛苦的决定。Kafka的存储和计算耦合在一起，数据只能存在本地磁盘上，磁盘空间有限，所以一般只能保留几天或几周的数据，超过窗口的消息只能被删除。这在很多场景下是很可惜的，因为那些老数据不只是日志，它们还是审计证据、是数据重放的基础、是出问题之后排查的线索。

Pulsar的分层存储机制，正是解决这个问题的一把钥匙。它的基本思路是：热数据先存在BookKeeper里，当数据段达到一定条件（比如时间或大小阈值），可以自动把老的数据段卸载（Offload）到廉价的存储介质上，最常见的是对象存储。数据卸载之后不会被删除，消费者需要回溯消费时，Broker能透明地从对象存储把数据重新读出来。

这个机制转换，意味着“无限保留”成为了一个实际可选的策略，而不是一个奢望。我在现场看到演示时还是有点激动的：操作员对着一个已经积累了几个月的Topic执行了一条命令，BookKeeper上的磁盘占用立刻下降，而用消费者去消费一个月前的消息，依然能正常读到数据。整个过程对客户端完全是透明的，和读热数据没有区别。

跨地域复制则是另一个让我觉得“终于等到了”的功能。它允许你在多个机房或区域之间配置异步复制，每个副本都保持消息的顺序和元数据一致性，用于构建多活或者灾备架构。Kafka也有MirrorMaker这样的跨集群复制方案，但使用起来相对粗糙，更多是“同步数据”，而Pulsar的复制是内建的、搭配多级安全和Topic策略来使用的。在现场问答环节，有人问“跨地域复制会不会丢数据”，嘉宾的回应也很实在：异步复制天然存在一个极小的同步窗口，但对大多数灾备场景来说，它提供的保障已经远胜于没有复制；如果你的业务要求强一致，那还需要搭配其他方案来兜底。

2.4 订阅模型和协议兼容：让新老用户都有的选

Pulsar的订阅模型也是这次大会里被反复讨论的话题。它支持独占（Exclusive）、共享（Shared）、故障转移（Failover）和按键共享（Key_Shared）四种模式。如果你用过其他消息队列，这几种模式拆开来看都不陌生，但Pulsar把它们在同一个Topic下统一支持了，这就有意思了。

独占模式保证严格的消息顺序，适合事件排序敏感的场景；共享模式把消息分发给多个消费者，提升消费吞吐，但顺序性被弱化；故障转移模式则是在一个消费者挂掉之后，由备用消费者无缝接管，适合有状态但需要高可用的场景；按键共享模式是很多人最喜欢用的一个，它把相同Key的消息固定发给同一个消费者，这样既保证了某个维度（比如用户ID、订单ID）的消息有序，又能通过增加消费者来扩展消费能力。

我记得现场有人问了一个特别实战的问题：“我们订单系统想提高消费并行的能力，但又不敢丢顺序，到底该用共享还是按键共享？”讲师的回答很干脆：订单维度对同一个订单号必须严格有序，那就用按键共享，按订单号作为Key；而如果只是系统通知、日志处理这类不需要顺序约束的消息，直接用共享模式拉满消费线程就行。这种“按场景匹配订阅模式”的思维，也正是Pulsar能同时吸引流计算和队列场景用户的原因。

协议兼容方面，Pulsar提供了Kafka兼容API。这个能力我一开始也有点怀疑，毕竟客户端生态的兼容性不是一蹴而就的。但现场演示中，他们用标准Kafka客户端直连Pulsar集群，发消息、消费消息、查看消费组积压，整个过程几乎是无感知的。对已经在用Kafka、但被运维问题困扰的团队来说，这意味着可以分阶段地迁移：先切一部分流量验证，再逐步改成原生Pulsar客户端。这个过渡路径设计得相当务实。

3. 实战视角：从分享和Workshop看消息队列落地细节

3.1 一个真实的迁移故事：从旧MQ走到Pulsar的路径

下午的某个环节，分享嘉宾讲了一个他们团队从旧MQ迁移到Pulsar的过程。因为现场不允许提具体公司名，我这里就拿“某团队”来代称。他们的背景很有代表性：公司已经有一套成熟的Kafka集群，跑了好几年，但随着业务线增加，分区数和Topic数增长很快，运维团队开始疲于应付迁移、扩分区、重平衡这些事；而且多个团队共用大集群，权限和资源隔离做得不够精细，偶尔还会因为某个业务疯狂写数据拖垮全集群。

他们做的第一件事不是立刻换技术栈，而是花了一个月时间做了压测和对比。他们在同样的硬件上分别部署了Kafka和Pulsar，测试了高吞吐写入、消费积压恢复、网络抖动下的表现。最终Pulsar的打分最高，尤其是在故障恢复这个维度上：模拟Broker宕机后，Pulsar集群很快就能恢复读写，而Kafka那套在分区重平衡时耗时比较长。

迁移策略上，他们非常稳健：第一阶段只迁非核心链路的日志和异步通知，让团队熟悉运维和监控；第二阶段把订单事件等核心消息切到Pulsar，但在切换前保持了双写和双读并行了一个月，用两边的数据对比来验证可靠性。他们提到一个很重要的经验：不要做“大爆炸式”的迁移，一定要给团队留出学习和适应的时间。

他们也踩了一些坑。客户端版本不一致导致连接闪断，是一个很典型的教训。Pulsar客户端和服务端之间的协议兼容性没有想象中那么“无限向后兼容”，团队在开发环境用了新版本的客户端，而生产环境还是老版本，结果升级过程中出现了短暂的消息延迟。另外一个是消息大小上限的配置。他们在迁移初期没有调整消息最大尺寸，结果某些业务发超过默认大小限制的消息时直接被拒绝，排查了半天才找到原因。这些细节，都是文档里不常见、但实战中一定会遇到的。

3.2 性能调优到底要动哪些参数：现场分享的调参清单

在另一个技术分享里，嘉宾列出了一组Pulsar性能调优的关键参数，并把它们分成“一开始就要设对”和“运行后按需调整”两类。这个分类方式很实用，我也把它整理成了一个清单，方便大家对照。

先说一开始就要设对的。存储层有一组关于副本和确认的参数，包括分段大小、写法定和确认法定。默认的分段大小通常在几十到上百MB之间，这个值会影响存储文件的读取效率和分层存储的卸载频率，一般建议按消息体大小来粗略估算，不要让一个分段里只有几条大消息，也不要让分段太大导致读取热点过于集中。副本数和确认数的配置更多是可靠性与性能的权衡，默认配置下能保证至少两个副本确认写入成功，如果需要更高的容错性可以调整，但也会带来额外的写入开销。

然后是一些运行时需要关注的参数。内存缓存的大小很关键，它决定了读热数据时的缓存命中率；如果缓存太小，Broker会频繁回源读取存储层，延迟会明显上升。还有订阅的Backlog配额策略，这个是要在业务上线前就定好的，否则某个消费组挂了没人处理，消息积压起来会拖垮存储。最后是生产端的批处理参数，比如批处理大小、批处理时间窗口和最大排队消息数，这三个参数直接影响吞吐和延迟的平衡点。如果你追求低延迟，就要把批处理窗口调小；如果你追求高吞吐，就要适当牺牲一点延迟。

这里我给一个我自己的经验：调优不是一个“照着参数改一遍”就完事的过程，而是必须先明确业务的目标，到底是延迟敏感还是吞吐优先，再去动对应的参数。很多团队上来就抄推荐配置，结果发现完全不适合自己的场景，最后又花了几周改回去。这个弯路，我也是踩过的。

3.3 从零跑通Pulsar单机版：Workshop现场实操笔记

下午的Workshop环节，讲师带着我们从零搭了一个Pulsar单机版环境。虽然步骤不算复杂，但我觉得对没有接触过Pulsar的人来说，能亲手跑一遍“启动、发消息、消费消息、看策略配置”的完整流程，比看多少页文档都管用。

我先记一下核心步骤，方便想自己动手尝试的读者参考。首先需要下载Pulsar的二进制发布包并解压，然后直接启动单机模式：

wget https://archive.apache.org/dist/pulsar/pulsar-3.3.1/apache-pulsar-3.3.1-bin.tar.gz tar -xzf apache-pulsar-3.3.1-bin.tar.gz cd apache-pulsar-3.3.1 bin/pulsar standalone

启动过程会拉起单机版的ZooKeeper、BookKeeper和Broker。等日志输出稳定后，新开一个终端，用CLI先创建一个租户和命名空间：

bin/pulsar-admin tenants create my-tenant bin/pulsar-admin namespaces create my-tenant/my-namespace

然后生产一条消息，再消费出来：

bin/pulsar-client produce my-tenant/my-namespace/my-topic --messages "hello-pulsar" bin/pulsar-client consume my-tenant/my-namespace/my-topic --subscription-name my-sub --num-messages 1

如果你也想体验分层存储的配置过程，可以执行：

bin/pulsar-admin namespaces set-offload-policies my-tenant/my-namespace \ --driver S3 --bucket pulsar-offload --region us-east-1 bin/pulsar-admin namespaces get-offload-policies my-tenant/my-namespace

最后一条命令会把命名空间下的数据段卸载到对象存储中。在单机环境里，这个操作不会真的产生巨大的数据迁移，但能让你直观理解“分层存储策略是配置在命名空间这一层”这个事实。这种亲手操作带来的体感，和单纯听PPT是完全不同的。

4. 场外互动里的信息量：社区正在变成一个“资源池”

4.1 现场人群画像：看看谁在关注Pulsar

我很喜欢在技术大会上观察来参加的人，因为这能反映出这个项目真实的用户基础。当天到场的人里面，有相当一部分是已经在生产环境使用Pulsar的工程师，他们来的目的是交流踩坑经验、看看新版本有没有解决自己的问题；还有一部分是正在做选型调研的技术负责人，手里可能握着几套消息中间件的对比表格，想通过现场提问来验证一些疑虑；另外还有一些学生和刚开始接触中间件的新人，他们在Workshop环节问了很多基础但重要的问题。

人群成分多样，说明Pulsar已经不只是“大厂玩具”了。特别是那几位正在选型阶段的工程师给我印象很深，他们的问题非常具体，比如“我们团队对Kafka特别熟，换Pulsar之后学习成本怎么控制”“Pulsar的监控面板有哪些关键指标要注意”，这类问题是真正准备推动技术落地的团队才会关心的。

4.2 现场高频提问速查：选型、运维和兼容性的答案

我把现场问答环节和私下交流中出现频率最高的几个问题整理了一下，做成一个速查表，每个问题的答案都来自当天多位分享者和社区老兵的回答。

这张表只是给一个大概的方向，真正决策时还是要结合自己业务的流量模型、容灾目标和团队运维能力来综合判断。大会上没有任何一个嘉宾给出“无脑选Pulsar”这种结论，反而都强调要理性对比。

4.3 一个值得关注的细节：项目健康度与社区贡献者

除了内容本身，我还特别关注了一个细节：Pulsar项目的活跃度和治理模式。会场上有一些项目的维护者和核心贡献者，他们会在展台旁边回答与会者的问题，也会认真记录社区里反馈的需求和Bug。有人在现场提交了一个关于客户端线程模型的问题，维护者当场就打开Issue看上下文，然后约了会后细聊。这种“用户和核心贡献者之间几乎零距离”的互动状态，对于一个开源项目长期健康发展来说，价值远超一次大会本身。

我也观察到，Pulsar社区在文档和工具链上花了很大的功夫。官方文档的示例代码、运维脚本以及各个连接器的完善度，比早期版本好了非常多。对一个开源中间件来说，代码再强、文档跟不上，用户上手就是灾难。而Pulsar社区明显意识到了这一点，这从现场很多新人能快速完成Workshop这一点就能看出来。

5. MQ选型观察：从大会分享反推三款消息中间件的取舍

5.1 三款主流MQ的定位差异与选择逻辑

每次参加这类与中间件有关的活动，我都会下意识地做一次横向对比。Kafka、RocketMQ和Pulsar是目前国内技术圈里被讨论最多的三款消息队列，它们各有各的“舒适区”，不是看几张性能对比图就能拍板的。

Kafka的优势在于高吞吐和庞大的生态，它天然适配大数据管道、日志收集、流计算这些场景。但如果你的业务追求多租户隔离、存储无限回溯和跨地域容灾，Kafka就会显得比较费力，因为这些能力要靠外部方案或自己搭建来补齐。RocketMQ在国内电商、金融场景落地非常广，事务消息和延迟消息这些功能做得早，Java生态也友好，但它的架构设计和Pulsar的思路不太一样，多租户和存储弹性没有Pulsar那么原生。

Pulsar的差异化竞争力在于云原生的架构理念和统一的消息与流模型。它既能当消息队列用，也能当流平台用；既支持Kafka协议兼容，又有自己原生客户端；既能做多租户隔离，又能做到分层无限存储。它的代价是组件更多，学习曲线相对陡峭，如果你的团队对Kafka体系已经很熟，又没有强烈的架构变革需求，那么迁移的成本可能大于收益。

我用一个简单类比来理解这三款产品的定位：Kafka像一个效率极高的装配流水线，专门为大规模吞吐优化，但它的灵活性一般；RocketMQ像一个功能齐全的国产车间，很多常用功能都内置好了，用起来顺手；Pulsar则像一个可以灵活分割、可以无限扩建的现代智慧园区，前期规划复杂一点，但后面扩展空间大。选哪个，本质上是在“近期工程效率”和“长期架构弹性”之间做取舍。

5.2 消息队列正在变成“数据基础设施”，这对选型意味着什么

这次大会给了我一个很明显的信号：消息中间件正在从一个“通信管道”逐渐演变成“数据基础设施”。过去，我们用MQ主要是为了削峰填谷、解耦系统；现在，越来越多的团队把消息流当作一种数据资产，用来做审计、做数据重放、做事件溯源，甚至直接作为实时数仓的一部分。

这个趋势对选型的影响很大。如果你只是把MQ当成一个临时排队工具，那吞吐、延迟这些指标就够了；但如果你打算把消息数据长期留存、跨地域容灾、让多个团队安全地共享一套集群，那就必须考虑存储架构、多租户能力和生态连接器这些“后置需求”。

Pulsar的存算分离和多租户模型，天然更适合这种“基础设施化”的方向。它可以把一个集群做成一个“消息中台”，不同业务线以租户和命名空间的方式接入，消息默认无限保留，按需配置分层存储策略。这种模式下，消息不再是被用完就丢的瞬时数据，而是能回溯、能审计、能重放的数据底座。这次大会上，不少分享者都在这个框架下介绍自己的实践。

当然，这不是说每个团队都要立刻拥抱Pulsar。基础设施的替换成本很高，必须结合团队现状和业务未来规划来决策。但至少在未来三到五年的技术演进方向上，我可以确定“存储计算分离”和“多租户云原生”会是消息队列领域的主流叙事。

6. 给下次参加开源大会的你：几条务实的参会建议

6.1 会前准备：不预习等于白来

技术大会的议程通常非常密集，如果你不带着目标和问题去，一天下来很容易被灌输一堆零散的信息，回来之后什么都记不住。我参加过不少大会，踩过这个坑，所以现在养成了习惯：拿到议程表之后，先圈出“必听”和“备选”，并且提前把必听Session里可能涉及的关键词扫一遍。

比如这次，我提前在本地把Pulsar单机版跑通了，所以听分享的时候能更快跟上嘉宾的思路，也能在Workshop环节直接对标自己的操作。如果你正在做消息队列选型，建议去之前先在本地用Pulsar发几条消息，再看看Kafka和Pulsar的对比文档，这样现场提问的时候就能问出“我们目前Kafka有200个分区，换到Pulsar后分区模型要不要重新设计”这种具体问题，而不是“Pulsar能不能替代Kafka”这种太宽泛的问题。

6.2 会中互动：提问和交流的正确姿势

在开源技术大会上，你是在一个信息密度极高的场子里。怎么从里面挖到最多的干货，一定程度上取决于你怎么提问、怎么聊天。

提问一定要具体。不要问“你们怎么看消息队列的未来”这种可以聊一晚但聊不出结论的开放问题。更好的问法是“我们的场景有跨地域容灾需求，Pulsar的异步复制在极端网络故障下有哪些已知边界”。这种问题，分享者一听就知道你是有备而来，回答也会更有针对性。

找维护者和核心贡献者聊天时，也建议先展示自己的实践。比如你可以说“我最近在跑Pulsar单机版，遇到一个连接池释放的问题”，这样对方能快速进入你的上下文，而不是要从零开始问你是什么人、遇到了什么。这种交流方式，本质上是在节省双方的时间。

6.3 会后沉淀：把一天的热闹变成长期生产力

大会结束之后的前两天，是信息记忆的黄金期。我的习惯是当天晚上就把笔记整理成一份结构化的文档，把每个Session的核心观点、自己当时的心得和后续要查的资料分开列好。隔一周再回头看，往往会发现很多当时觉得“震撼”的内容已经过时，而真正留下来的，是几个自己最关心的技术点。

如果Workshop里有动过手的内容，一定要在本地重新跑一遍，不要“看完就算”。很多时候，现场有讲师引导、有同伴帮助，你觉得一切简单，但回到自己电脑前往往会有各种意想不到的环境问题。把Demo跑熟了，知识才是你的。最后，可以把这次大会的内容带回团队做一次十五分钟的mini分享，这样不仅强化自己的理解，也为团队后续技术选型做了一点铺垫。

开源技术大会的入口是那一天的会议，但出口其实是一个长期的社区和项目。真正有收获的人，不会在散场之后就停下，他们会把会上听到的问题带回工作中验证，会在社区里继续讨论，甚至可能从用户变成贡献者。

说实话，这一天参加下来，我最深的体会是：消息队列这个领域正在被重新定义。过去的MQ更像是一个“传输管道”，用完即走；现在的Pulsar这种新一代消息平台，已经在试图成为整个系统架构中的数据底座——你可以在上面跑核心业务消息、做流式计算、做审计回溯、做跨地域容灾，甚至把它当一个小型数据库来用它的事件存储能力。最打动我的，不是某个单独的功能点，而是这种“统一”的架构哲学：一套系统能解决的问题越多，团队需要维护的中间件工具链就越短。

如果你也在做消息队列选型，或者正在被Kafka的Topic膨胀、存储压力和多团队共享问题困扰，我建议你先找一台机器把Pulsar单机版跑起来，亲手体验一下“一条命令建租户、无限保留消息、分层存储”的感受，再回来看这些分享内容，可能你会得出和我类似的判断。那一天高潮迭起的分享，也许可以成为你技术架构上做出一次重要决策的起点。