01
项目背景
目前， 360 公司内部部署了超过上百套 Apache Kafka 集群。由于 Kafka 采用存算一体的架构设计， 其扩缩容和数据迁移的成本较高， 因此在线上环境中多使用小型集群，并在搭建时预留了一定的 Buffer， 后期则很少进行节点的扩展或缩减。这种方式导致了资源利用率低下， 具体表现为：Kafka 平均 CPU 利用率和磁盘利用率不到 20%。对于用户而言， 这无疑增加了运营成本。
Serverless 核心优势在于其无状态特性、 可扩展性和多租户支持。通过根据一天中的流量波动自动调整服务器数量， 为用户提供按需计费的服务模式。作为消息中间件的新趋势， AutoMQ 与阿里云 Kafka Serverless 等产品便是这一领域的佼佼者。它们基于 Kafka 实现了高效的弹性伸缩能力， 能够达到 10 倍的成本节约效果，并支持 10 倍的无损扩展性。
然而， Serverless 也面临着挑战， 例如需要提升故障恢复能力，以及确保集群能够承载更多的主题 （topic）。这篇文章分享 360 内部基于 Apache Pulsar 实现消息中间件的 Serverless 形态。
02
Pulsar简介
Apache Pulsar 是 Apache 软件基金会顶级项目，2012年起源于雅虎，定位为云原生分布式消息流平台，集消息、存储、轻量化函数式计算于一体。其设计初衷是解决传统消息系统（如Kafka）无法满足的大集群多租户、百万级Topic、跨地域复制等需求。
2.1 存算分离
计算层 Broker
1) 无状态 Broker：Broker 主要负责消息的路由和计算逻辑，不存储数据，从而支持弹性伸缩及秒级故障恢复。
2)动态负载均衡：Pulsar 动态调整 Topic 和 Broker 的绑定关系，确保计算节点间的负载尽可能均衡。当 Topic 被重新分配到新的 Broker 上时，服务端会主动向客户端发送关闭请求；客户端收到请求后将重新发起寻址请求，整个过程自动完成且切换平滑。
3) 数据分片：Topic 中的数据根据时间和大小滚动生成新的日志段（Ledger）。新 Ledger 会基于 Bookie 节点的负载情况选择一组新的 Bookie，并将元信息存入 Zookeeper 中，同时并行向 Bookie 节点发起写副本的请求。
存储层 Bookie
1) 自动均衡：由于采用了数据分片存储方式，新增的存储节点能够自动承担工作压力，无需进行数据迁移，极大地提升了集群的扩展能力。
2) 分层存储支持：支持冷热数据分离，可将冷数据卸载至 S3 等低成本存储方案中。
2.2 多租户
Pulsar 原生支持多租户，Topic 的命名规范为：persistent://租户/命名空间/topic
Namespace 可绑定专属 Broker 组，实现计算资源物理隔离，防止租户之间互相影响。
2.3 集群容灾
原生跨地域复制（Geo-replication）
Pulsar 原生支持跨地域复制，支持 namespace 级别和 topic 级别开启，一方面可以实现容灾，另一方面，可以满足跨地域数据汇聚的业务场景。
开启跨地域复制后，Pulsar 内部会开启后台线程，将 topic 的数据异步写入备份集群，数据是双向同步的，如下图所示，生产者P1在A集群生产的数据，消费者C2在B集群也可以消费到。消费进度也支持开启同步，可以在消费者客户端参数中控制开启。
集群级故障转移
开启跨地域复制的 namespace 或 topic，支持故障转移，具体实现有 2 种方法：
1) 客户端支持配置一个外部的服务发现，通过调整外部服务返回的集群信息，客户端发现集群变更后，会重新发起连接实现故障转移。
2) 修改域名解析实现切换：当客户端发现当前集群不可用时，会重新解析域名发起新请求，连接到正常的集群上。
03
智汇云Pulsar特色功能
3.1 Serverless
当前 Pulsar 具备租户级别弹性伸缩能力。具体实现逻辑是：
1) 对于流量较小的业务，使用共享资源组可以实现成本最优。当共享资源组里某个 namespace 里流量足够大时，Pulsar 会自动扩容新的 broker 节点，并将这个 namespace 调度到独享资源组。
2) 在每个资源组内，Pulsar 会按照负载情况，自动扩缩容 broker 节点数量。
Serverless Manager 服务负责实现上述弹性策略控制，主动收集租户/资源组的性能指标，调度 K8s 扩缩资源的副本数，管理 Pulsar 集群隔离属性。
经过压测，目前我们为每个 broker 所在的 Pod 分配了 4 核、16G内存，预估可承载约 200MB/s的写+读流量或 1.5万/s 的生产请求 QPS。
3.2 延迟消息
目前智汇云内部 Pulsar 版本对应 Apache Pulsar 4.0.x 版本，支持将延迟消息的索引持久化到磁盘，从而实现更大规模、更长延迟时间的延迟消息。
Pulsar 延迟消息的使用非常简单，普通类型 Topic 即可支持收发定时/延时消息，调用 SDK 的 API 即可发送定时/延时消息。
//定时消息producer.newMessage() .value(value.getBytes()) .deliverAt(timeStamp) .send();//延时消息producer.newMessage() .value(value.getBytes()) .deliverAfter(delayTime, TimeUnit.SECONDS) .send();使用延迟消息时需要注意：
1) topic 的 TTL 自动确认时间需要比延时消息的时间更长，否则延迟消息会在TTL后自动确认，不投递给消费者。
2) 生产者不可以使用 batch 模式发送，在创建 producer 的时候把 enableBatch 参数设为 false。
3) 消费模式仅支持使用 Shared 模式进行消费，否则会失去定时效果（Key-shared 也不支持）。
04
Pulsar相比Kafka的优势
4.1 性能表现
1) Pulsar 的 E2E P99 延迟在 9ms 以内。存储节点使用了 SSD 磁盘，并且 Bookie 服务开启了跨可用区副本容灾。
2) 相较 Kafka，重新消费大量历史数据对 Pulsar 写性能影响更小，Pulsar 中支持为写数据（Journal）和读数据（Ledger）分配不同的磁盘设备，实现读写I/O隔离，并且配合Bookie数据分片均匀分布的特点，能充分释放和均衡硬件性能。
4.2 成本降低 6 倍
在 Serverless 弹性伸缩的加持下，Pulsar 的资源利用率大大提升。根据我们内部的计费策略，业务从 Kafka 切换到 Pulsar 后，费用可节省 6 倍。
05
总结及规划
当前我们利用 Pulsar 存算分离、多租户、跨地域复制的特性，构建了 Serverless 形态的消息队列 PaaS 平台，对比 Kafka 实现了 6 倍降本。接下来将进一步完善 Pulsar 产品功能，如完善 namespace/topic 管理功能，支持自定义流控和告警，消息追踪等。同时，我们将探索 Pulsar 容灾恢复、故障切换，生态工具等落地，进一步提升 Pulsar 的易用性和服务质量。
更多技术干货，
请关注“360智汇云开发者”👇
360智汇云官网：https://zyun.360.cn（复制在浏览器中打开）
更多好用又便宜的云产品，欢迎试用体验~
添加工作人员企业微信👇，get更快审核通道+试用包哦~
