业务痛点

江苏移动的第三代业务支撑系统基于 X86，构建于 2014 年。近几年，业务量、工单量大幅增长，同时 5G 时代 CHBN 业务应用百花齐放，消息数、话单数、信令数据都出现 10 倍以上的爆发式增长，硬件设备不断扩容，提醒时延持续下降，支撑系统面临诸多挑战。

基于 x86 计费系统架构

1、海量数据处理

近几年用户日均使用流量从数百 TB 增长到数万 TB，随着 5G 大规模商用，消息量、话单量、信令量持续暴增，使得支撑系统的处理压力不断大幅增加。

2、客户感知要求更高

5G 用户 PCRF 双开，开通工单量成倍增长，要求工单处理效率不断提升，保障业务及时开通；5G 流量使用更快，用户对流量费用更为敏感，业务部门要求进一步提速。

3、硬件资源不断投入

随着业务量增加，计算、存储资源需要不断增加才能满足业务发展需要，硬件资源成本不断增加。

当前业务痛点

其他 MQ 解决方案

在江苏移动生产环境的多个系统中，已经在使用的消息中间件有 Apache Kafka、Apache RocketMQ 和 Apache ActiveMQ 等。

Kafka 不是无状态的，每个 broker 都包含了分区的所有日志，如果一个 broker 宕机，并非任意一个 broker 都可以接替它的工作。如果工作负载太高，也不能随意添加新的 broker 来分担，broker 之间必须进行状态同步。随着 Topic 数量的大幅增加，它的性能急剧下降。

RocketMQ 支持的客户端语言不多，没有在 MQ 核心中实现 JMS 等接口，有些系统迁移需要修改大量代码。

ActiveMQ 主要基于解耦和异步，较少在大规模吞吐的场景中使用，偶尔会有较低概率丢失消息，官方社区现在维护越来越少，几个月才发布一个版本。

我们从功能、性能、扩展性、吞吐和延迟方面，对这几个 MQ 做了深入调研和测试，具体分析结果如下。

在业务上，计费系统对数据的可靠性要求极高，必须保证不丢单，不重单，不错单。在性能上，计费系统要求消息系统必须稳定可靠、高性能、可水平扩展。这几种中间件解决方案不能完全满足我们的业务需求，我们开始尝试寻找替代方案。

为什么选择 Pulsar

如上所述，计费系统需要稳定、可靠的消息系统来处理海量数据，具体要求如下。

一致性：计费系统对数据的可靠性要求极高，必须保证不丢单，不重单。

低延时：在海量话单的计费场景下，要求 MQ 能提供平滑的响应时间，减少话单处理的延时，提高系统的吞吐量。

高可用：具备容灾能力，在异常情况下能够自动修复，避免造成系统无法提供服务的局面。

海量存储：5G 流量时代会产生数以亿计的话单数据，要求 MQ 具备海量存储的能力，在线分析引擎可以基于海量话单实时多维分析。

Apache Pulsar 是下一代分布式消息流平台，Pulsar 采用流原生架构、存储计算分离，支持结构化 Schema 与 SQL、分级分层存储、函数计算、跨地域复制等，运维简单，交付能力强。越来越多的企业正在使用 Pulsar 或者尝试将 Pulsar 应用到生产环境中。

我们调研 Apache Pulsar 后，发现 Apache Pulsar 的分层架构方便我们水平扩容，跨地域复制能够实现异地容灾，分层存储可以无限扩容并降低运维成本，运维监控都很方便。

水平扩展

由于 Pulsar 的存储设计基于分片，Pulsar 把主题分区划分为更小的块，称其为分片。每个分片都作为 Apache BookKeeper ledger 来存储，这样构成分区的分片集合分布在 Apache BookKeeper 集群中。这样设计方便我们管理容量和水平扩展，并且满足高吞吐量的需求。

容量管理简单：主题分区的容量可以扩展至整个 BookKeeper 集群的容量，不受单个节点容量的限制。

扩容简单：扩容无需重新平衡或复制数据。添加新存储节点时，新节点仅用于新分片或其副本，Pulsar 自动平衡分片分布和集群中的流量。

高吞吐：写入流量分布在存储层中，不会出现分区写入争用单个节点资源的情况。

跨地域复制

Pulsar 自带的跨地域复制机制（Geo-Replication）可以提供一种全连接的异步复制。计费系统使用跨地域复制机制提供额外的冗余，防止异常情况下服务无法正常运作，实现异地容灾。

分层存储

Pulsar 采用基于 Segment 的架构，允许 Topic backlog 大量增长。如果不设限制，随着时间的增加，代价会越来越高， 通过分层存储，在 backlog 中的旧消息可以从 BookKeeper 卸载数据到可无限扩展的廉价云原生存储（例如 Google Cloud Storage、AWS S3）或文件系统，构建高性能的消息集群，并降低运维成本。如果不发生变化，客户端仍然可以通过 backlog 去访问这些卸载的数据。

运维监控

Pulsar 自带 Dashboard，可对 broker、bookie、ZooKeeper 集群和 Topic 等进行监控和统计，方便运维管理。

Pulsar Grafana 监控页面

Apache Pulsar 功能丰富，云原生架构支持水平扩展，读写分离，支持多租户，支持 Java、Python、Go，C++ 等多种客户端，支持百万 topic，吞吐高，延迟低，完全符合我们的业务需求。经过多轮的专家评估、技术选型、测试验证，最终决定全面引入以 Pulsar 为代表的流原生技术，实现新一代业务支撑系统的全面演进。

Apache Pulsar 在江苏移动应用

江苏移动基于 Pulsar 构建了新一代计费系统，核心包含以 Pulsar 为核心的流原生技术框架和以 ServiceMesh 为核心的微服务框架。

流原生框架：面对话单计费、消息提醒、服开信控等流处理应用，基于 Pulsar 实现统一的框架封装，提供分布式消息队列、分布式计算引擎、I/O 连接器、SQL 引擎、负载均衡、分布式分层存储、多租户隔离、热发布、链路跟踪、弹性伸缩等通用能力，简化流处理应用的复杂度，提升支撑效率。

微服务框架：面对分拣、资料求取、批价、扣款等服务，以 ServiceMesh 为核心，提供负责均衡、服务发现、服务路由、熔断限流、监控度量等通用能力，统一服务框架，拉齐各系统服务治理能力，提升支撑效率。

基于 Pulsar 流原生架构，江苏移动重构了海量话单流和事件流的实时处理，构建实时数据仓库和事件处理中心，极大提高了业务处理效率，提升了消费提醒的及时性和客户感知。本部分重点介绍 Apache Pulsar 在流原生计费中心的实践应用。

基于流原生的计费中心

计费系统中 Topic 的规划

Pulsar 的“租户”（Tenant）为 Pulsar 提供了便捷的管理和隔离。Namespace 是“租户”下的一个管理单元，通过“租户”和 Namespace，Pulsar 提供了层级化的 Topics 管理。

以下是计费系统中 Topic 的划分结构。

A/B Topic 切分

在计费系统中为了方便经营分析收入的报表能够按天统计分析，保证每天的清账（清单和账单）一致，采取换天的策略。流原生为了实现换天的业务逻辑，采用 A/B 队列名称的方式，按天切换。在换天的过程中，判断 Topic A 中的消费是否已经消费完毕，并且满足换天条件，当满足换天的条件就立即将消费 Topic 切换到 B。

Pulsar 的多租户和 Namespace 为计费业务划分了清晰的界限和隔离，按照业务逐级展开，避免了业务上对 Topic 使用的混淆；并且每个租户都可以应用自己的身份验证和授权方案，还可以管理存储配额，消息 TTL 和隔离策略。

Pulsar Schema

基于 Pulsar Schema 的结构化消息体

Function 流处理

业务模块采用 Function 分布式流处理框架，无需部署第三方流处理框架，如 Storm、Flink、Spark Streaming 等，Function 提供了多种处理保证机制，至多一次、至少一次、有且仅有一次，保证消息处理不丢失。Function 的热更新能够快速更新业务处理逻辑，水平扩展并发实例数，提升 TPS 处理能力。

Pulsar Functions 在计费中心的应用

基于 Pulsar 流原生技术，结合微服务及 AI 能力，江苏移动打造了新的计费架构，实现计费系统“规模化、消息化、微服务化、敏捷化、弹性化、智能化”支撑，大幅提升处理效率。通过服务化以及主流程全消息化，话单处理性能显著提升，存储 I/O 交互降低了 90%。通过弹性伸缩及智能调度，实现资源忙闲时灵活调度及全局共享，资源利用率提升了 35%。通过灰度发布及敏捷交付，实现上线过程流水线式交付及话单处理不中断，提升客户满意度。

生产集群能力

使用 Pulsar 过程中遇到的问题及解决方案

Apache Pulsar 很好地解决了我们的业务需求，但 Pulsar 也并非十全十美。在使用 Pulsar 的过程中，我们也遇到了一些问题，比如 bookie 节点内存溢出（OOM）和 BookKeeper 断连导致 Pulsar 进程退出。在 Pulsar 社区小伙伴的大力帮助和支持下，我们对相关配置做了优化。

1、Bookie 节点内存溢出

为了提高 bookie 消息的读写性能，Pulsar 采用了堆外内存的方式。在测试过程中，我们使用 Pulsar 默认配置时，常会出现 bookie 节点内存溢出的问题。为了解决这个问题，根据业务情况，我们调整了堆外内存配置和 Cache 等参数（如下），优化了 Pulsar 内存。

2、ZooKeeper 断连导致 Pulsar 进程退出

Pulsar 的核心组件 broker、bookie 对 ZooKeeper 有很强的依赖，broker 与 bookie 作为ZooKeeper 的客户端与 ZooKeeper 服务端频繁交互。如果 ZooKeeper 连接超时，broker 和 bookie 会发生异常退出，因此设置合理的 ZooKeeper 连接参数至关重要。我们修改了 ZooKeeper 的连接超时属性值，让超时时间大于垃圾回收（GC）时间，保证连接的可用性。具体配置如下。

未来规划与展望

面对 5G+ 时代的新挑战，我们借鉴业界先进经验，打造了流原生技术框架，构建了新一代高效智能的业务支撑系统，实现规模化、敏捷化等支撑目标。后续将继续推进新一代业务支撑系统的建设，将 Pulsar 作为统一的消息系统，并基于 Flink + Pulsar 构建流批一体实时计费引擎。

总结

Pulsar 作为下一代云原生分布式消息流平台，与其它 MQ 相比，有其独特的功能和优势。我们基于 Pulsar 重构了 5 G 时代新一代业务支撑系统，充分利用 Pulsar 的各项特性，并根据实际的业务场景，作出相应的优化和适配。这套基于流原生架构的新一代业务支撑系统，已在江苏全省上线。我们会继续逐步扩大 Pulsar 的应用范围，和大家一起见证 Pulsar 流原生技术的演进。