1.4 典型场景与适用边界

1.4 典型场景与适用边界

本节摘要：任何中间件的价值都只在具体场景里兑现。本节把订单事件流、日志聚合、流式计算源、IoT 遥测四个高频场景逐一放到 Pulsar 上走一遍，看它凭什么接得住；再划出几类不适合的场景并给出替代方案。读完这一章你应当敢于下判断：你的业务该不该把消息托付给这条水道。

什么货适合走水路

先给结论：Pulsar 的长板集中在三处——多团队共享一个集群、数据需要长期保留与回溯、流量形状随时间剧烈波动。只要业务命中其中两条，它就值得进入候选名单。下面用四个场景逐一验证。

**场景一：订单事件流（电商中台）。**订单创建、支付回调、履约变更，每个环节都产出事件，下游有库存、物流、积分、风控、数仓等一堆消费者。这个场景吃的是 Pulsar 的订阅模型：同一条订单主题上，风控用共享订阅并行消费，数仓用独立订阅慢慢补数，互不影响消费进度。某中型电商的真实做法是把订单事件按订单号作为消息键发出，库存域用按键共享订阅保证同一订单串行扣减，而数仓侧用另一个订阅全量落湖——一份事件、两种消费、零复制成本。

**场景二：日志与审计聚合。**几百个服务的日志要集中存储、可检索、按合规要求保留数年。这是长保留与分层存储的主场：热日志留在 BookKeeper 的 SSD 上供实时检索，超过设定周期的自动卸载到对象存储，查询侧无感。相比"Kafka 加一套冷归档管道"的拼装方案，Pulsar 把这事做成了命名空间上的一行配置。

**场景三：流式计算的源头。**Flink、Spark 作业需要可重放、可回溯的输入。Pulsar 的游标与数据分离让每个作业各自持有消费位置，重跑作业把游标拨回去就行；再配合 Schema（第 5 章），流式作业的输入契约可以像数据库表结构一样被管理。

**场景四：IoT 遥测。**海量设备上行小消息，突发流量大（设备批量唤醒时），租户按产品线划分。弹性扩缩容应对突发、租户隔离防止产品线互相拖累，都是 Pulsar 的结构性强项。

场景对照速查

划边界：什么货别上这条船

诚实的边界同样重要。其一，超轻量级场景：一天几千条消息的内部通知、任务派发，用数据库表加定时扫描都绰绰有余，引入 Pulsar 属于高射炮打蚊子，运维成本远超收益。其二，复杂路由为王的集成场景：需要按内容规则把消息分发到几十条支路、头部转换、协议适配，RabbitMQ 的交换机体系至今仍是最顺手的工具。其三，团队没有运维余量时：Pulsar 组件多（Broker、BookKeeper、元数据存储、Proxy），三五个人的小团队首次自建，学习曲线是实打实的成本——这种情况下，要么用托管服务，要么先用 Kafka 跑起来。

还有一类容易误判的场景值得单独提醒：把 Pulsar 当数据库用。它可以长保留、可查询，但本质仍是消息流，没有二级索引与复杂事务连接。需要在消息内容上做复杂查询的，正确姿势是流进数仓或搜索引擎，而不是在消息层硬扛。

一个反例的教训

某内容平台早期选型时被 Pulsar 的功能清单吸引，全量接入，结果发现团队只有两名中间件工程师，却要维护含 Functions、事务在内的完整栈，告警与容量规划都跟不上，半年后把使用面收缩到核心事件流，外围系统迁回轻量队列。教训不是 Pulsar 不行，而是功能的丰富度要乘以团队的承接力再做决策——这句话与 1.3 节的三问连起来，构成本章完整的选型方法。

别漏算的一维：成本结构

场景合不合，还有一维容易在功能兴奋中被漏掉——钱花在哪。Pulsar 的成本结构比多数消息系统更"可拆"：计算（Broker）与存储（Bookie 加对象存储）分开采购、分开扩容，长保留数据的单位成本能靠分层压到很低；代价是起步时的机器种类多、规模小时单位成本反而偏高。给业务做预算时建议直接画两条成本曲线——本业务在"单集群 Kafka"与"Pulsar 加分层"下的三年存储与机器成本，交点出现在数据量与保留时长的哪个位置，比任何定性争论都有说服力。许多"要不要用 Pulsar"的争执，本质是双方都没画这条曲线。

场景演练：给三个假想业务做选型

把方法用在三个假想业务上，练习完整的推理链。

**业务甲：在线教育的课堂互动信令。**特征是瞬时尖峰（下课答题瞬间）、消息极小、允许少量丢失（重复答错无妨）、团队仅一个业务组。推理：流量形状需要削峰，但规模与团队形态都撑不起一套分布式消息集群的自建运维，Kafka 单集群或托管队列已绰绰有余；Pulsar 的租户与分层在这里没有用武之地。结论：不选，理由是团队承接力。

**业务乙：连锁零售的多区域进销存事件。**特征是事件源分散在各区域门店系统、区域之间要求互为灾备、单据流要求按门店键有序、数据需按合规留半年。推理：跨地域复制直接命中"互为灾备"，按键共享命中"门店键有序"，长保留命中分层存储；团队是平台组，服务多业务线，租户隔离值钱。结论：命中长板，Pulsar 是强候选，落地时优先验证跨地域复制的延迟是否满足单据时效。

**业务丙：社交应用的消息推送管道。**特征是超大扇出（一条动态触达百万级在线用户）、延迟敏感、在线连接层自建。推理：扇出这种形状，专业推送基础设施（长连接网关加内存分发）比消息队列更对口，队列只该承担"动态产生到分发调度"之间的削峰段。结论：Pulsar 承担削峰段可以，但别指望它替代连接层——这个误判比"选错消息队列"更常见。

三个演练共同验证了本章的判断框架：先对长板（共享、弹性、保留），再对形状（吞吐、顺序、扇出），最后对承接力（团队与运维余量）。三关全过才立项，任何一关含糊，宁可先上更简单的方案——消息系统的迁移成本永远比引入成本高。

本节要点回顾

• Pulsar 长板三条：多团队共享、长保留回溯、流量弹性，命中两条即可入候选；
• 订单事件流吃订阅模型，日志聚合吃分层存储，流计算吃游标独立，IoT 吃弹性与隔离；
• 超轻量、重路由、无运维余量三类场景应诚实绕开或换方案；
• 别把消息队列当数据库用，复杂查询交给数仓与搜索引擎；
• 功能丰富度必须乘以团队承接力，这是选型最容易漏乘的一项。

第 1 章到此收拢：水道的历史、户籍、横向对比与边界都已入脑。第 2 章镜头推进，拆开河道本身——四层架构里每一层的分工与心机。