演讲回顾｜中原银行开源消息中间件的落地实践

本文整理自王东在 Pulsar Developer Day 2025 上的主题演讲，一起来看 Pulsar 如何赋能银行消息系统实践！

中原银行概况

中原银行成立于 2014 年 12 月，由河南省内 14 家城商行合并而成，是河南省唯一的省属法人银行；中原银行于 2017 年在香港上市，并在 2022 年合并三家地方银行后，总资产突破 1.4 万亿元，获得了包括福布斯"世界最佳银行"、"年度十佳城市商业银行"在内的多项荣誉，成为中部地区具有重要影响力的商业银行。

第一代消息队列的选型和挑战

2018 年，基于当时的主流技术评估，中原银行选择了 RabbitMQ 作为第一代消息中间件。选型主要基于几个考量：首先是可靠性，它提供了集群元数据和消息的持久化、生产者的 Confirm 确认机制以及消费者的 ACK 机制；其次是高可用性，支持镜像队列和 quorum 队列等多副本模式；再次是性能，在无积压时能做到毫秒级延迟，并且通过连接与通道复用、消费者动态调整支持高吞吐；最后是易用性，其轻量级、存算一体、部署简单和插件丰富的特点，降低了初始使用门槛。

然而，随着业务量增长和系统复杂度提升，这套架构的运维挑战日益凸显。首要问题是脑裂风险，网络抖动容易导致节点通信异常，队列状态显示为红色，严重时引发集群分裂。脑裂之后的数据副本可能分叉，恢复过程困难，数据一致性难以保证。系统的稳定性高度依赖网络质量，容错能力弱，故障恢复时间长。在架构上，存算一体的模式导致扩展性弱，计算和存储资源无法独立扩展，只能通过手动添加节点来实现，操作笨拙且不灵活。此外，RabbitMQ 对消息堆积敏感，仅支持百万级别的堆积，超出后容易触发流控，影响生产。在性能上，其主从队列只有主队列提供服务，在高并发场景下，主节点容易成为瓶颈，处理能力下降。

第二代消息队列：为何选择 Pulsar

第二代消息队列的核心目标是实现架构革新及资源提效 。Pulsar 的架构采用了存算分离的设计，将 Broker 与 BookKeeper 解耦，使得计算层与存储层能够独立扩展。这带来了动态伸缩的能力 ：计算层可以灵活应对突发的流量高峰，而存储层则能按需扩展以确保消息的持久化能力。这一架构变化与行内已有的 Redis 等组件形成了资源互补，整体资源利用率提升了 30% 以上。

在云原生架构的支持上，Pulsar 原生支持 Kubernetes 部署，能够充分利用 K8s 的动态调度能力。通过引入 Operator 机制，实现了对消息队列集群的全生命周期自动化管理，极大降低了人工运维的干预成本和出错概率。

在高稳定性及高可用性方面，Pulsar 通过内置的 fence 机制主动预防集群脑裂，这相比 RabbitMQ 的事后恢复是本质上的改进。多副本机制确保了消息不丢失，并且其对网络丢包和延迟的容忍度更高。

最后，Pulsar 的性能及功能满足未来业务需求。其强大的扩展能力，例如 Pulsar Functions 和丰富的 IO 连接器，能够支持多样化的消息处理场景。这很好地适配了银行在数字化转型过程中，对消息应用场景多样化和消息量级大幅提升的需求。

基于 Pulsar 的深度定制与改造

为了更好地满足金融级消息中间件的严苛要求，中原银行基于开源的 Pulsar 进行了深度定制与改造。

1）交互逻辑

在交互模式上，改造的核心是引入了"管理 Proxy"。这一设计解决了银行在多区域部署多套生产集群时面临的跨区域网络隔离难题。无需为每个集群单独开通复杂的网络策略，只需确保各区域集群与管理 Proxy 网络连通即可。管理端仅需部署一套，通过这个统一的 Proxy 实现对全域所有集群的管理，大幅简化了网络架构和运维复杂度。

2）功能模块

客户端 SDK 被设计为分层结构：基础层提供认证、消息收发、断线重连等核心功能；高阶层则提供批量消息、消息压缩等高级能力，供业务按需选用。在运维层，强化了对云原生部署、多模式集群部署、扩缩容和拓扑维护的支持。管理端则新增了多租户管理、 namespace 与 topic 管理等元数据管理功能，并集成了限流、分区顺序化等满足金融业务需求的高级管控能力。

3）集群部署

最初的部署模式是双中心部署，即生产中心与同城灾备中心通过 Pulsar 的跨地域复制机制保持数据同步，形成主备模式。这种模式的缺点是 RTO（恢复时间目标）较长，切换需要手动或自动过程；同时，灾备中心的资源在平时处于闲置状态，利用率低；容灾能力也仅能容忍单节点或单中心部分故障。

当前已演进到跨中心部署模式 。将生产中心和同城中心的所有节点组织成一个大集群，所有节点同时对外提供服务，实现了真正的双活。以 ZooKeeper 部署为例：5个节点分别部署在生产中心（2 节点）、同城中心（2 节点）以及一个部署在公有云上的仲裁节点（1 节点）。这种部署确保了即使单个数据中心整体失效，集群依然能基于多数派原则保持可用。其优势非常明显：资源利用率达到100%，故障恢复可达秒级，并且能够容忍单个数据中心整体故障，容灾能力大幅提升。

未来展望

消息平台的智能化是下一步的重点方向。

1）智能诊断分析助手

计划整合 Pulsar 官方文档、源码知识、内部运维知识库以及历史故障数据，训练专用的大语言模型。该助手可由监控告警或日常巡检任务触发，自动分析消息队列的异常问题，并提供初步的诊断结论和解决方案建议。更进一步，它能基于历史消息流量趋势进行预测，实现故障预警和消息积压的预防。

2）智能运维助手

目标是构建一个聚合了测试环境数据、产品文档、已知问题解决方案等信息的智能知识库。通过自然语言问答接口，为开发者和运维人员提供即时的、精准的运维支持，降低技术门槛。

3）消息队列 for AI

正在探索 Pulsar 对多 Agent（智能体）通信模式的支持能力。银行内部的 AI 应用场景，如智能客服、风控模型协同等，未来可能需要高效、可靠的多 Agent 通信基础设施。这一方向也参考了行业领先云厂商提出的 AI 原生消息队列技术路线。

现场 Q&A 摘要

交流环节，对几个关键问题进行了深入探讨。

关于客户端SDK定制化改造，核心设计思想是能力分层。基础能力层封装了认证、消息收发、断线重连等所有业务都必需的共性功能。高阶能力层则包含消息压缩、批量处理等，供特定业务场景按需启用。这种设计使得SDK更轻量化，对于无需高级功能的系统，可以仅引入基础包，降低依赖复杂度。当消息体较大时，业务方可以方便地启用压缩功能，有效降低网络带宽消耗。

关于多中心部署的实际效果，部署模式是生产中心与同城中心形成双活架构，依赖 Pulsar 跨地域复制保障数据最终一致。该架构下，单节点故障不影响集群整体服务，通过健康检查可实现秒级故障切换，客户端断线重连可达毫秒级恢复。以郑州实际部署为例，东西两个数据中心相距约 40 公里，通过高质量专用网络，将延迟严格控制在 1-2 毫秒内，满足了金融业务对实时性的苛刻要求。

关于智能化消息平台，除了前述的智能诊断和运维助手，一个典型应用场景是基于历史消息趋势预测实现动态扩缩容。例如，银行每月 15 日左右的贷款催收业务会形成规律性的消息高峰，平台通过分析历史数据预测这一趋势，提前自动扩容计算资源，从而预防消息积压，保障业务平稳运行。

从 RabbitMQ 迁移到 Pulsar 遇到的问题：迁移过程中的一个主要难点在于，最初考虑复用 RabbitMQ 的某些插件或适配层来降低迁移成本，但测试发现这些方案性能不稳定，且会带来较大损耗。最终放弃了折中方案，决定让业务系统直接替换客户端 SDK。这虽然带来了必须修改代码的"阵痛期"，但保证了迁移过程中消息的零丢失，并实现了最终的平稳过渡。这印证了一个道理：在核心基础设施升级上，有时"短痛"优于"长痛"，彻底的替换比复杂的兼容更为可靠。

实际运维中处理跨地域数据同步延迟问题：延迟是跨中心部署的生命线。在郑州双中心部署中，将网络延迟严格控制在1 -2 毫秒内，这是通过在 40 公里距离上搭建高性能专用网络实现的。运维经验表明，若跨中心网络延迟大于 3 毫秒，则不建议采用跨中心集群部署模式，而应考虑其他架构。在部署时，采用了 Pod 反亲和策略与机架感知配置，确保副本分散在不同的物理机架甚至数据中心，这样即使单个中心故障，也不会导致整个服务不可用。