企业官网建设流程全解析

距离 COSCon‘25 开幕还有三天，朋友圈里已经开始刷屏各种开源项目的展位和圆桌议程。如果你和我一样长期做后端和数据平台，有一个同场活动值得专门盯一下：Pulsar Developer Day。这是 Apache Pulsar 社区在 COSCon 期间举办的开发者专场，主角只有一个——消息中间件，而且不是泛泛讲概念，而是围绕 Pulsar 在生产环境落地时的创新实践来展开。对架构师、后端工程师、数据平台团队以及对消息选型有困惑的人来说，这半天到一天的内容密度，很可能比主会场大多数演讲都高。

对于很多团队来说，消息中间件是“上了规模之后才懂的东西”：订单系统需要削峰，微服务之间需要解耦，实时数仓需要稳定的流管道。选型和维护中间件的成本不低，而 Pulsar 恰好是这些年里把存储和计算分开、把多租户和分层存储做成默认选项的代表。这篇文章不打算复述宣传材料。我结合自己用过多个消息系统、也参加过几场开源大会的经验，说说为什么 Pulsar Developer Day 值得去、现场大概率会听到哪些硬核话题，以及哪怕你还没用上 Pulsar，也能从这些实践里得到哪些启发。

1. 消息中间件为什么值得一场“开发者日”

1.1 从同步调用到异步解耦，业务增长逼出来的选择题

很多同学第一次接触消息队列是在面试题里：削峰填谷、异步解耦、流量控制。但工作上真正体会到它的价值，往往是线上出了问题。我印象很深的一个场景：一个下单入口要同时更新订单状态、扣库存、发短信、给用户加积分、同步数据到数仓。平时流量低还好，一到促销活动，数据库连接池先被打爆，短信服务一抖动就拖垮整个链路。明明只是积分多扣了一笔，客户看到的却是“下单失败”。

加消息中间件之后，这个入口只做订单落库，剩下的动作全部通过生产者写入 Topic 去异步消费。接口响应从几百毫秒降到几十毫秒，下游服务出现故障也不会直接阻塞主流程。这就是很多架构从“点对点调用”走向“异步事件”的原因。有人觉得这是多引入了一个故障点，但从架构上看，它更像在业务高峰给系统装了一个可伸缩的缓冲阀。如果你没有过这种切肤之痛，参加开发者日时听到“解耦”这个词可能会觉得平淡；但只要经历过一次促销场景的数据库雪崩，就会明白消息中间件不是在造概念，而是在解决真实问题。

1.2 中间件不是越多越好，选型要讲匹配

“Kafka 已经够用了，为什么要看 Pulsar？”这是我每次谈到消息中间件都会被问的问题。这个问题必须认真回答，因为选型选错了，后面全是运维债。不同中间件的定位和取舍差异很大，我习惯用一张表来帮助团队做初步判断。

选型不是看哪个项目名气大，而是看你的场景有没有对应的痛点。如果只需要一个简单的任务队列，RabbitMQ 很省心；如果主要做日志收集和实时流处理，Kafka 非常成熟；如果业务规模大、多个团队要共用一个集群、消息还需要跨机房复制和长期回溯，那 Pulsar 的存算分离、多租户、分层存储就很有吸引力。开发者日的价值，就是把这类选择题背后的取舍放上台面讲清楚，而不是让你背宣传口号。

1.3 开源大会里的专场活动，为什么值得留一整天

开源项目办开发者日，不是简单拉个横幅把人聚起来合影。它背后是社区把“使用者”变成“共建者”的过程。主会场的演讲多是项目愿景和技术趋势，内容偏宏观；在 Pulsar Developer Day，你能听到的是某个团队怎么从零迁移、怎么压测、怎么排查背压和积压。

我可以负责任地讲，这些内容在官方文档里是找不到的。文档会告诉你“支持多租户”，但不会告诉你多租户的配额怎么规划才不互相挤兑；文档会告诉你“支持 Geo-replication”，但不会提醒你跨机房复制的延迟受什么影响、重连后怎么核对消息一致性。这类只有跑过生产的人才写得出的内容，是开发者日最有价值的部分。所以说它值得留一整天，不是因为是官方活动，而是因为它确实在解决工程问题。

2. Pulsar 的核心创新：为什么它能讲“云原生”

2.1 存算分离：把 Broker 和 BookKeeper 拆开看

Pulsar 最让人印象深刻的架构设计是存储和计算分离。官方把消息处理和存储拆成两层：上层是无状态的 Broker 集群，负责处理客户端请求、管理订阅、路由消息；下层是 Apache BookKeeper 集群，负责持久化所有消息。两层可以独立扩容。

用一个生活化的比喻解释：Broker 就像前台接待，BookKeeper 是带传送带的仓库。前台负责问你在哪寄存、什么时候来取，传送带负责把东西安全入库。传统消息系统里，前台和仓库往往绑定在一起，前台不够了，仓库也得跟着加；Pulsar 把两者拆开以后，接请求能力不够就加 Broker 节点，存储容量不够就加 BookKeeper 节点，成本和场景都清晰了。

这套架构带来的直接好处是扩缩容灵活。Broker 无状态，节点故障后客户端重连很快；存储层可以按 IO 需求单独规划。用过 Kafka 的人知道分区迁移和 rebalance 在某些场景下要谨慎操作，而 Pulsar 对分区数量、Broker 节点增减这类问题要友好得多。做运维的人对这一点体会最深，也是我到现场最想听同行讨论的实战话题之一。

2.2 分段存储与无限保留：消息不只是“临时快递”

另一个核心创新是 Segment 分段存储。消息写入 BookKeeper 时被切分成一段段 segment，写满一个就滚动到下一个。配合分层存储功能，旧的分段可以自动卸载到对象存储，比如 S3、GCS 或者 MinIO。消息可以一直保留，从热数据到冷数据按策略自动迁移。

这对业务来说意味着什么？意味着你不需要靠“消息还在不在有效期”这种蹩脚方式来设计审计方案。我见过很多团队为了追查一条三天前的关键事件，只能去翻业务日志和数据库流水，费时费力；如果消息系统本身能保留半年甚至更久，很多事后溯源就变成一个查询请求。这个能力对金融、供应链、安全审计类业务尤其值钱。你只要把事件的原始消息完整留给消息中间件，未来任何时候都有据可查。当你在现场听到有人讲“无限保留”时，先想想自己的业务有没有这类需求，再决定要不要投入学习。

2.3 多租户、多订阅、跨机房复制同时拥有

多租户是 Pulsar 的原生能力。一个集群能按业务线划分 tenant 和 namespace，分别做配额、权限、隔离策略。我曾经在一个集团项目里见过几十条业务线共用一套消息集群，如果没有多租户隔离，A 业务把流量打满，B 业务全链路受损都是分分钟的事；而有了 tenant 级别的限制，至少能把“坏邻居”控制在某个范围内。

订阅模型也是亮点。独占、共享、灾备、键共享四种模式，基本覆盖了从一条消息只给一个消费者，到一组消费者随机消费、再到按 key 路由的全部场景。跨机房复制则解决了主备和多活的难题，多个集群之间自动同步消息。配合命名规则，业务可以实现“本地读写、异地备份”。这也是不少国际化业务选择 Pulsar 的理由。这类能力对业务的价值，不在于功能列表有多长，而在于高可用方案和运维负担能明显减少。

2.4 这些特性放到真实项目里，是这么被“使用”的

技术特性最终要落到场景里。我看到过三种比较典型的 Pulsar 落地模式。

第一种是订单事件源。订单状态的每个变化都作为事件发布到 Topic，下游的积分、通知、对账、报表各自订阅。这样既解耦了系统，又能从事件流里还原完整业务过程。第二种是 IoT 数据管道。海量设备上报的遥测数据通过 Pulsar 进入流处理框架，再落库到时序数据库。设备端连接风暴能被缓冲，写入尖峰也能被磨平。第三种是日志与审计中心。所有服务访问日志集中到一个多租户集群，按团队隔离，配合分层存储保留 180 天，出问题时直接从消息里回放。你会发现，每个“抽象”的特性背后都有明确的业务收益，这也是开发者日演讲最常见的展开方式：不讲空概念，只讲怎么用、遇到什么、怎么解决。

3. 现场大概率出现的硬核内容，我先帮你划重点

3.1 5 分钟在本地把 Pulsar 跑起来

无论现场 workshop 具体安排是什么，自己动手跑一个单机实例都是最值得做的事。我建议你提前装好 Docker，现场能省很多时间。最简启动命令：

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

容器起来以后，另开一个终端，先创建租户、命名空间和主题：

docker exec -it pulsar bin/pulsar-admin tenants create dev docker exec -it pulsar bin/pulsar-admin namespaces create dev/ns1 docker exec -it pulsar bin/pulsar-admin topics create persistent://dev/ns1/t1

然后测试收发消息。Pulsar 自带命令行工具，一个终端消费：

docker exec -it pulsar bin/pulsar-client consume persistent://dev/ns1/t1 -s sub1

另一个终端生产：

docker exec -it pulsar bin/pulsar-client produce persistent://dev/ns1/t1 -m 'hello pulsar'

这些命令看着简单，但完整走通一遍，你对“租户、命名空间、主题、订阅”这四个层级就有了直观感受。很多人在文档里啃概念半天都入不了门，实际跑一次就全通了。如果现场有动手环节，这个预演能让你把时间花在和讲师交流问题上，而不是耗在环境初始化上。

3.2 压测与调优的关键参数，提前心里有数

开发者日活动通常会有性能相关主题。压测不是拿工具随便打流量，而是要看一组互为因果的指标：吞吐、延迟、积压、重平衡。我自己做压测时会重点盯下面这些参数。

拿批量发送来说，很多刚上手的人一条条发消息，延迟很低但吞吐上不去。打开批量并选合适的压缩算法后，吞吐能成倍提升。反之，消费者端的 receiver queue size 也不是越大越好，预取消息超过下游处理能力，就会在客户端堆积，服务端 backlog 看着不高，实际业务已经卡住。

听压测主题时带着这些基础，你不会被“百万级吞吐”之类的数字吓到，能追问出更有价值的信息，比如“这个数字是在什么消息大小、几个副本、什么硬件条件下测出来的”。没有这些前提的压测数据，参考意义很有限。

3.3 从 Kafka 迁移到 Pulsar，三种常见路线

很多团队想换 Pulsar，不是因为 Kafka 不好，而是被运维痛点折磨够了。从 Kafka 迁到 Pulsar 主要有三条路线。

一是双写双读、灰度切换。业务高峰期同时往两个消息系统写，消费者也各拉一份，对比数据一致性和延迟后逐步切流量。优点是对稳定性最友好，缺点是要维护一套双链路，适合消息量没那么大的业务。

二是协议兼容层 KOP，即 Kafka-On-Pulsar。在 Pulsar 集群里启用 Kafka 协议处理器，让 Kafka 客户端不改代码直接连上 Pulsar。这样先把底层存储换了，业务代码以后慢慢改。很多人担心协议转换的性能损耗，实际要看场景；换来的是 Pulsar 的分层存储、多租户和运维体系。

三是离线迁移工具。Pulsar 社区有 Kafka 回放工具，可以把 Kafka 里的历史消息读出来写入 Pulsar Topic。适合做一次性全量搬迁，存量数据搬到新集群后再切换增量链路。

现场大概率会有团队分享他们选了哪条路线、踩了什么坑。如果你也在评估迁移，带上自己集群的流量模型去听，能问到“按我的分区数，KOP 的 CPU 预估多少”“双写时消息顺序怎么保证”这类真正务实的问题。

3.4 运维监控的第一课：先搞清楚这些指标

消息中间件不是部署完成就结束，监控才是大头。Pulsar 暴露大量 Prometheus 指标，社区也有 Grafana 面板可导入。但盯着满屏图表没有意义，先分清四类核心指标。

• Topic 级积压：consumer backlog 是衡量消费健康度最重要的指标。持续上涨说明消费者处理不过来，要么扩容消费者，要么优化下游写入。
• 服务端请求延迟：broker 排队和等待时间。如果显著升高，优先看 CPU、GC、再查磁盘 IO。
• 存储层指标：BookKeeper 的 journal 写入延迟、ledger 数量。存储层异常会直接推高端到端延迟。
• 复制延迟：开启跨机房复制后，replication lag 是判断多活健康的核心。

监控的关键不是看图，而是知道“接下来该动哪里”。积压涨了去加消费者或优化下游；复制延迟涨了优先查机房带宽和网络抖动；存储写入慢了就去看磁盘型号和 RAID 策略。记住，仪表盘只是线索，真正的功夫在于能顺着指标一步步定位到具体组件。这些方法论，比记住某个具体面板命令更重要。

4. 到现场之后，怎么把“听会”变成“学会”

4.1 别把 talk 当报告会，带着问题去听

很多开发者参加活动习惯“带耳朵不带问题”，听到一堆新名词，回去就忘了。我自己的习惯是，参会前一天把当前业务里最头疼的中间件问题列出三条，例如“消费积压偶发”“跨机房延迟不稳定”“多团队共享集群权限混乱”。听 talk 的时候，不是为了记住演讲者的架构图，而是看他的方案能不能和我的问题建立映射。

如果某一场演讲和你的问题无关，不必有负罪感地硬坐到底，去同一时间段的另一个分会场或者找维护者聊几句，收获往往更大。拿我自己来说，很多时候在走廊里和旁边的人聊十分钟，比在会场坐一下午得到的有效信息还多，这也是开发者类活动最容易被低估的部分。

4.2 提问环节怎么问出好问题

给讲师提问，最忌讳“Pulsar 能不能做 xx”这种过于宽泛的问题。好的问题自带上下文。比如：

• “我们有个 topic 的 backlog 一直在涨，消费者 CPU 没打满，先从哪个指标入手排查？”
• “共享订阅场景下，业务要求不能重复投递，这个前提本身是不是就冲突？”
• “跨机房复制时，如果机房 A 断网半小时，重连后消息顺序会乱吗？”

对维护者来说，具体场景的问题更好回答，也更容易引发后续讨论。如果你有机会问到核心维护者，还可以多问一句：“社区里有没有相关的 Issue 或者提案？”这一句能把你的问题从一次性的现场交流，变成可持续跟踪的社区任务。

4.3 workshop 一定要动手，环境先准备好

开发者日的动手环节通常安排在下午。我强烈建议上午就趁休息时间把笔记本、Docker、样例代码准备好，不要在主持人开始演示后才忙环境。参加过多次 workshop 后你会发现，卡住进度的人多数是现场才拉镜像、改配置。

另外，动手前先瞄一眼讲师给的说明文档。如果现场有网络限制，提前把需要的依赖和镜像都拉到本地，能避免你在海量提问时间里因为基础问题分心。最好的状态是：主持人还在讲，你已经把环境跑起来了，接下来把注意力全部放在“为什么这样配置”上。

4.4 会后 48 小时内的落地动作

参会收益最大的时间在会后 48 小时。我会给自己定三个任务：一是把当天最有触动的一个方案整理成一页笔记，发到团队文档；二是拿本地环境快速复现当天的 demo，确认这个方案在自己环境能跑通；三是挑一个对团队有价值的小改动，排进下周计划，比如“新项目试用 Pulsar 做异步化”或“给现有消息链路补上关键监控指标”。

如果没有这套动作，活动上的兴奋感很快会被日常需求冲淡，下次遇到同样问题还是走老路。我在几次大会后最大的体会是：真正拉开差距的从来不是谁的日程表更满，而是谁听完了真的动手去改了自己的系统。

5. 我在生产环境折腾 Pulsar 时踩过的一些坑

5.1 最容易被低估的两个配置

第一个是内存。Pulsar broker 和 BookKeeper 都是 Java 服务，默认内存配置不一定适合你的业务。如果一台机器同时跑多个角色，要格外注意堆内存预留。我在早期部署时曾把 broker 和 bookie 放在同一批节点，结果 GC 频繁，端到端延迟经常出现毛刺。后来把接入层和存储层拆到不同节点，毛刺明显缓解。

第二个是磁盘。最容易忽略的是 BookKeeper journal 和数据目录的隔离。journal 是顺序写，对延迟很敏感；ledger 数据偏向随机写，更吃容量。如果放同一块盘，两者互相拖累。实操中建议至少两块盘，一块 SSD 做 journal，另一块做数据目录。这个细节官方文档反复强调过，但很多人到生产事故时才想起，开会时可以问问台上团队是怎么规划硬件部署的。

5.2 消息积压排查，不要一上来就加机器

积压是最常见的问题，但根因往往不在消费端，而在上游或模型设计。我一般按这个顺序排查。

• 先看消费速率和写入速率曲线，确认积压是在上涨还是平稳。如果只是短暂高峰，稍等即可。
• 看消费者实例的 CPU、带宽、下游数据库慢查询。多数情况下，消费慢是因为下游写库瓶颈。
• 看是否发生重投。ack timeout 设置太短或客户端异常，会导致同一批消息反复投递，消费者看似忙碌但有效进度很少。
• 最后才考虑扩容。盲目加消费者在独占订阅场景根本没用，因为一个分区只能被一个消费者占用，加多少个实例都白搭。

这套排查思路放到任何消息系统都适用，核心是先排除上游和模型问题，再动资源。如果你在现场听到有人讲“我们加了机器就解决了积压”，先问一句“恢复之后有没有继续查根因”，往往能发现他们后面还有更精彩的故事。

5.3 客户端参数里最容易翻车的三个设置

客户端是使用者接触最多的部分，参数没配好，服务端再稳也白搭。我最常看到三个问题。

• receiver queue size 设得过大。下游消费能力弱时，过大的预取值会造成消息堆积在客户端，出现“服务端没积压、客户端在积压”的假象。
• ack 方式不统一。自动 ack 和手动 ack 混用，代码一多很容易漏 ack，引起无限重投。
• 重试参数绕过死信主题。很多团队图省事不配 DLQ，导致坏消息反复重试，占用整个消费链路。建议一开始就规划好坏消息的去向。

这些坑都不难避开，但几乎每个接入消息中间件的团队都会踩上一两个。跟身边同事稍微复盘一下就会发现，很多线上问题不是中间件本身不稳定，而是客户端用法出了问题。

5.4 给新人的一句话学习路线

如果你想认真入门 Pulsar，我不建议直接从源码开始啃。先跑通本地实例，用命令行和客户端玩熟 Topic 的四个层级；然后读官方文档 Concepts 一节，把订阅模型和存储模型弄清楚；再动手写一个简单的生产消费 demo，把死信、重试、批量这些配置都试一遍；最后再看源码或社区提案，结合自己生产中的问题去研究实现细节。这样三个月下来，你已经能从“能用”走到“知道为什么这样设计”。

最后再分享一点个人经验。参加开源大会的同场活动，我从来不指望一场会改变整个技术栈。真正能改变技术栈的，是你听完后愿意回去做的那一个实验、调整的那一个参数、写下的那一条待办。三天后的 Pulsar Developer Day，希望你在现场既能听到足够多的“创新实践”，更能在会后真的动手，把其中一两条变成自己系统里的改进。这半天到一天的时间，才算没有白花。