企业官网建设流程全解析

1. 先弄清楚这是一场什么活动

1.1 COSCon 同场活动是什么来头

先说结论：COSCon 是开源社组织的一年一度开源技术年会，每年都会聚集一大批开源项目的维护者、深度用户和社区新人。而这次 COSCon‘25 同场的 Pulsar Developer Day，就是专门为 Apache Pulsar 这个项目单独开出一条线的开发者日活动，标题已经很直白——聚焦消息中间件创新实践。

很多人刚看到这个消息会有一个疑问：年会里面项目很多，为什么 Pulsar 值得单独占用一天？这背后其实是消息中间件这个赛道正在发生的真实变化。过去十年，Kafka 几乎成了“消息系统”的代名词，大家在选型时会不自觉地拿它当默认选项。但 Pulsar 走的技术路线不一样，它从底层就做了存算分离，以 Apache BookKeeper 作为日志存储层，这种架构在灵活性和运维体验上跟 Kafka 拉开了一个级别的差异。所以这个活动主要面向的人群就很清晰：已经在生产上跑 Pulsar 的、正在做消息中间件选型的、负责维护公司消息平台的技术团队，还有想往开源社区贡献代码的开发者。

同类活动通常由 Apache Pulsar 社区的核心贡献者、企业维护团队和一线大规模用户共同组织，内容往往覆盖几个块面：架构设计、大规模生产实践、性能调优、生态集成，以及开源贡献方法论。注意，这只是这类开发者日的常见构成，最终以现场实际日程表为准，我这边写的是通用规律，提前给没有参加过的人做一个心理预期。

1.2 这个活动适合谁去，以及每个人的“目标感”差异

去一个技术活动，最忌讳的就是抱着“去听听看”的心态。一天下来听七八个分享，看十几个 PPT，回公司以后什么都落不了地。我自己的经验是，参加这种开发者日之前，先要分清楚自己属于哪一类人，因为每一类人的获取重点完全不同。

第一类是已经在生产环境用 Pulsar 的。你们最应该做的事是找同量级的实践分享者，尤其是遇到过和你一样痛点的人。别人踩过的坑，比 PPT 上的架构图画得再漂亮都有价值。第二类是正在选型、还没有定下来的。你们的关注点应该放在技术边界上，比如 Pulsar 在超高吞吐、大规模分区、跨地域容灾上的表现，而不是被一堆功能列表带偏。第三类是做平台和基础设施的。你们的思路应该更细，去看多租户隔离怎么做、监控指标体系怎么搭、滚动升级平滑度怎么样。第四类是纯粹想参与开源贡献的。那就不要挤在主会场抢座位，去找 committer 聊天，问社区现在的活跃模块、贡献入门任务，这些信息你在公开 Session 里是拿不到的。

所以，从准备阶段开始，就要给这次活动贴一个自己的标签。三天时间，用来调整参展路线完全够用。这也是这篇文章接下来所有建议的出发点——你先明确想得到什么，再去套后面这些方法。

2. 为什么 Pulsar 值得拿出来单独开一天

2.1 消息中间件的三条路线，Pulsar 卡在哪一条

要理解为什么一个项目能撑起一整天的开发者活动，先把消息中间件这个领域的地图铺开。市面上的产品五花八门，但本质上走的是三条路线。

第一条路线是传统消息队列，代表是 RabbitMQ、ActiveMQ。它们解决的问题是“消息可靠地送达到消费者”，强调路由、确认、优先级这些特性，适合企业内部的异步任务解耦。它们的强项是灵活，但吞吐量有天花板，横向扩展也比较费劲。

第二条路线是日志管道，代表是 Kafka。它把消息看成不可变的日志，顺序追加、批量消费，天生适合高吞吐的数据管道场景。但它有一个很有意思的设计——存储和计算在节点上没有完全分开，或者说，存储紧紧地绑在 broker 上。分区数量和节点数量需要配套考虑，扩展本质上是一场搬迁。

第三条路线就是云原生流平台，目前最典型的代表就是 Pulsar。它底层引入 Apache BookKeeper 做存储，面向 broker 和存储两组集群独立设计。传到上面的 broker 不持有数据，消息进到 BookKeeper 的 bookie 节点，这样计算层可以随意伸缩，存储层也可以按容量单独扩容。我常常打个比方：Kafka 像每个快递站点自带一个大仓库，站点扩容的时候仓库也要跟着搬；Pulsar 的 broker 是站点，BookKeeper 是独立运转的仓储网络，站点不够就加站点，仓库不够就扩仓储，两边互不拖累。

Pulsar 之所以有底气拿一整天的议程来聊“创新实践”，核心就在这个差异上。它不只是在吞吐量、延迟这些数字上跟 Kafka 较劲，而是把消息中间件的运维模型改变了，让一套集群可以更从容地服务多个业务团队，也让跨地域复制、分层存储这些能力变成了基础配置而不是毛坯房装修。

2.2 一张表格看懂 Pulsar、Kafka、RabbitMQ 的关键取舍

这里我给一份很朴素的对比表格，不谈那些花哨的基准测试数字，就从架构和运维视角看差异，每一行都是生产环境里真实会遇到的问题。

这张表不是要得出“Pulsar 全面胜出”的结论。它想表达的是另一件事——选型不是比参数，是比你的团队能接受的运维模型。Kafka 的单套组件设计让它在中小规模下非常省心，但一旦分区数上去了、跨机房容灾来了、多业务团队共用需要互相不干扰，Pulsar 的内置能力确实能省掉大量自研工作量。

2.3 那些“创新实践”里值得先搞懂的几个点

既然活动名是“聚焦消息中间件创新实践”，参会前至少有四个概念值得你花两小时搞清楚，不然现场分享里的很多细节你只能听懂一半。

第一是存算分离。前面已经展开过，这里补充一个技术细节：Pulsar 的 topic 数据是分段存储的，写入时先落 BookKeeper 的 ledger，再根据时间或容量策略将老旧分段卸载到对象存储。这个机制有个很实的效果——topic 可以几乎无限积压，不会因为消费者跟不上就把磁盘打爆。传统消息系统遇到积压是灾难，Pulsar 可以直接让积压数据落到低成本存储上，等消费者恢复再接上。

第二是多租户模型。Pulsar 里 tenant 是最高隔离单位，namespace 是次一级隔离单位，每个 namespace 可以独立配置消息保留策略、存储配额、权限。这意味着一个平台团队可以跑一套集群服务几十个业务团队，每个团队只能看见自己的 namespace，这正好是大型公司做消息平台的时候最头疼的问题。

第三是四种订阅模式。独占（Exclusive）适合严格有序的消息流；共享（Shared）适合吞吐优先的并发消费；故障转移（Failover）是在多个消费者里选一个活跃节点接收消息；按键共享（Key_Shared）则保证同一个 key 的消息只被同一个消费者处理。这个模型比 Kafka 的消费者组模式丰富，现场分享中一多半的架构演进故事，底层都离不开订阅模式的切换。

第四是协议兼容。Pulsar 原生提供 Pulsar 协议，同时又可以做 Kafka 协议适配。这句话翻译过来就是：你可以保留已有的 Kafka 客户端代码，后端却换上 Pulsar，逐步迁移而不是推倒重来。很多团队选型时担心的“搬迁成本”，在这个能力面前会小很多。这类细节，去活动现场听一线维护者讲，比看官方文档吸收得快。

3. 去参加这种开发者日活动，该怎么准备

3.1 拿一张“问题清单”出门，别空手去

参加技术大会最亏的姿势，就是坐到下午才想起自己好像有疑问要问，但要问什么又说不清楚。我建议出发前花半小时，拿张纸写下五到八个问题，越具体越好。

不要写这种：“Pulsar 能不能支撑我们这种量级？”这种问题没法回答，因为提问者自己都没定义好量级。要写就写：“我们每天 2 亿条消息，峰值 8 万 QPS，单 topic 分区 64 个，现在碰到分区分裂后 consumer 重平衡时间长的问题，Pulsar 在分区均衡上是怎么处理的？”你给出上下文，分享者才能给出有信息量的回答。如果团队现在没在用 Pulsar，问题清单就要围绕选型风险写：“我们想从 Kafka 平滑迁移到 Pulsar，客户端协议兼容的坑主要在哪，有没有踩过 production 迁移的实际案例？”这种问题在会议现场的 Q&A 环节特别受欢迎，因为台上的嘉宾也愿意聊这类真实的业务细节。

问题清单还有一个附加价值——它会倒逼你把自己系统的现状梳理一遍。你在写问题的过程中，会自然回忆起监控指标、连接方式、消息堆积的时间点，这些信息在会后验证 Pulsar 方案的时候全部用得上。

3.2 提前做一点“预习”，30 分钟足够

如果之前完全没用过 Pulsar，不要慌，一场开发者日的分享大多从基础概念讲起。但为了现场吸收效果更好，我强烈建议会前花 30 分钟把单机版跑起来，亲手收发几条消息，感受一下名词和实物之间的对应关系。这是基于我自己多次参会经验的建议，会前接触过工具和零基础直接听，吸收率差距非常大。

最简单的方式是用 Docker 跑单机版：

docker run -it -p 8080:8080 -p 6650:6650 apachepulsar/pulsar:latest standalone

跑起来之后，打开一个新的终端，创建一个 tenant 和一个 namespace：

docker exec -it <容器ID> bin/pulsar-admin tenants create demo docker exec -it <容器ID> bin/pulsar-admin namespaces create demo/ns1

然后可以顺手生产一条消息试试：

docker exec -it <容器ID> bin/pulsar-client produce demo/ns1/test-topic --messages "hello pulsar"

执行完你就亲眼看到了 topic 是怎么被创建出来的，消息是怎么进去的。再花十分钟把消费者跑起来：

docker exec -it <容器ID> bin/pulsar-client consume demo/ns1/test-topic -s sub1

看到消息被消费掉的那一秒，你就已经跨过了“纸上谈兵”的阶段。后面听分享时，别人讲到分区、订阅、持久化，你脑子里有画面，自然就理解了。

3.3 值得重点关注的议题方向，依目标取舍

一场开发者日通常有主会场和分会场，议题既有大范围的趋势分享，也有垂直领域的深度案例。通用规律是，这类活动基本会覆盖几个板块：架构设计与内核解析、大规模生产实践、性能调优、生态集成与多语言客户端、开源社区治理与贡献。具体议程以官方公布为准，但你可以按目标划分优先级。

我的个人取舍策略是这样：如果我是平台维护团队，性能调优和生产实践排第一优先级，因为这类议题通常附带真实的压测数据、参数基线、故障复盘；如果我是业务开发团队，生态集成和客户端使用层面的分享优先级更高；如果我是想参与开源的，普通 Session 可以不追，直接去开源贡献工作坊或者找 committer 深聊。一天的时间是有限的，与其每个 session 都听个开头，不如挑三个最贴合自己目标的 Session 从头听到尾，把 Q&A 也听完。

4. 活动当天的高效参与方式

4.1 日程取舍：不要试图追完所有场次

到了现场，最大的诱惑就是什么分享都想听，结果每个场次都只坐了 15 分钟就走了，什么都没沉淀下来。这不是参会，这是走马观花。我建议到现场第一件事就是找日程墙或打开活动 App，把你想听的三个 Session 标记出来，其他时间全部留给交流。

三个 Session 怎么挑？就看哪几个议题跟你的问题清单重合度最高。听 Session 的技巧也有讲究：前五分钟未必坐得住，但最后五分钟的 Q&A 一定要留。很多有含金量的信息都在答疑环节冒出来，主讲人讲到一半时不会说的资源限制、性能瓶颈、版本坑，往往在有人追问的时候才会松口。如果你坐在前排，可以准备一支录音笔或者手机上的录音应用，征得主讲人同意后录下来，方便会后复盘。注意，现场网络环境往往很差，指望现场打开链接下载资料是不现实的，所有关键页面和示例代码，看到了就立刻本地保存、拍屏或复制到备忘录。

4.2 怎么在 Q&A 和圆桌环节问出有效问题

会场的 Q&A 时间很宝贵，但每次总有人站起来问“Pulsar 支持 xxx 吗”这种官网上写着答案的问题，我听了都替他觉得亏。有效问题一定要包含上下文，像一个生产环境的故障报告那样去组织语言。

我常用的提问结构是三段式：第一句说清楚业务背景和规模，第二句描述碰到了什么现象或矛盾，第三句才抛问题。举个例子：“我们有自己的 Kubernetes 集群，跨三个可用区，Pulsar 集群大概 9 个 broker。最近发现追加写入延迟在高峰期会从 5ms 飙到 50ms，顺着排查发现 bookie 的 fsync 频率很高。想请教一下，这个场景下 ledger 的写入确认机制和刷盘配置怎么调，才能既保证可靠性又不让延迟毛刺这么明显？”这种问题抛出来，台上的嘉宾大概率会给出具体参数或定位路径，而不是一句“建议升级版本试试”。问完之后顺手记下回答要点和嘉宾提到的关键配置项，这就是你回去以后压测的起点。

4.3 现场社交和会后资料整理

开发者日存在的意义很大一部分在会场外的走廊和茶歇区。台上的分享是经过修饰的内容，真正的“干货”往往在被问急了的对话里。我的习惯是每一场结束后的休息时间，去找其中一个讲师或组织者，问一句“刚才你提到那个故障场景，能再多说两句吗”，往往会有意外的收获。

会后资料整理也有一套方法。不要等回去一周再整理，那基本等于没有。当天晚上把当天拍的照片、录音、笔记全部过一遍，落出一个“验证清单”来：明天或下周要在自己环境里试什么参数、跟哪篇官方文档对照、给同事转述哪个关键结论。有这份清单，这次活动才算真正进入了你的知识体系。

5. 常见问题与避坑实录

5.1 新手最容易踩的几个坑

我见过不少团队把 Pulsar 引入以后用不好，问题往往不在 Pulsar 本身，而是踩了几个常见坑。

第一个坑是一上来就把分区数拉得很高。有人以为分区越多吞吐越大，结果元数据开销、broker 负载均衡压力、BookKeeper 的 segment 数量全上来了，性能反而下降。分区数是需要根据目标吞吐、消费者数量、消息顺序要求综合计算的，不是越大越好。

第二个坑是过度使用消息堆积。Pulsar 确实能支撑长时间积压，分层存储还能把积压数据卸到成本更低的对象存储，但很多人只看到“能积压”这个能力，就把它当成默认策略，忽略了堆积期间的游标（cursor）管理和后续消费追赶问题。合理的做法是给不同 namespace 设置清晰的消息保留期限和积压阈值告警。

第三个坑是只盯着 broker 层做监控，忽略 BookKeeper。Pulsar 的消息可靠性最终落在 bookie 节点上，磁盘 IO、网络抖动、ledger 的修复过程直接影响端到端时延。现场如果听到生产实践的分享，留意他们是怎么监控 bookie 的，这通常比 broker 指标更能反映真实状态。

第四个坑是“把消息中间件当数据库用”。Pulsar 支持分层存储和长保留策略，但它本质上仍是流和队列的平台，不是做在线查询和复杂关联的数据库。如果有人准备把所有业务状态全部塞进 topic 做长保留，然后每次消费都全量扫描一遍，这种用法基本是在拿自己的运维时间开玩笑。

5.2 关于资料获取和后续学习的建议

参加完活动，热情高涨的时期通常只有两周。这两周里最重要的是把现场听到的概念落到代码和参数上。我建议会后按照一个 30 天学习路线走一遍，比我在这里重复讲概念更有用。

前三天，把官方的 Concepts 文档从头到尾读一遍，尤其是 Topic、Subscription、Message Retention 这几页，读的时候对照你在现场记的笔记。接下来一周，把单机版 Pulsar 跑起来，尝试创建多租户和不同的订阅模式，用生产环境五分之一的消息量做基础链路压测。再花两周，挑一个你业务里真实的痛点场景，比如跨地域复制、分层存储、积压消息追平，配置到自己的测试环境里验证。一个月之后，你再看当时的现场笔记，会有完全不同的理解深度。学习资料入口始终以 Apache Pulsar 官网和社区官方渠道为准，注意甄别网上的过期教程和商业推广内容。

5.3 一个速查表：常见问题的排查思路

最后给一份直接可以抄作业的速查表，都是消息中间件日常运维里最容易碰到的几类问题。适用产品是 Pulsar，但有些排查思路对 Kafka 也有借鉴意义。

这张表不是一个万能诊断工具，它最大的价值是告诉你“先看哪里”。真实的故障往往要结合监控曲线逐层定位，但如果你连第一层检查点都不知道，排查效率就会差很多。把这张表保存在笔记里，遇到问题的时候对照着查，至少能少走一半弯路。

6. 最后说点我自己的体会

我个人参加这种同场开发者日活动有个经验：不要以“听完”为目标，要以“回去之后能用起来”为目标。

有一年我在类似的活动上听了一个关于分层存储的分享，现场感觉平平，就是“把旧数据丢到对象存储”嘛。回来后刚好赶上我们线上一个 topic 的积压容量报警，我试着按分享里的思路配置了 offload 策略，结果磁盘压力直接降下来，运维值班同事还专门跑来问改了什么东西。那次之后我就养成一个习惯，每场技术活动只给自己定一个小目标，可能是一个配置参数的验证，可能是一类问题的排查思路，回来后一定要把它变成一次环境里的实验。这次 COSCon‘25 同场的 Pulsar Developer Day 既然只剩三天，建议你也给自己选一个这样的小目标：可以是亲手跑通一个 Pulsar 单机实例，也可以是带着一个真实的业务痛点去现场找答案。哪怕最后只从一场分享里获得一个能落到自己环境里的思路，这趟活动就没有白去。