经历亿级话单处理优化打磨检验，江苏移动云流一体化到底如何玩转

深度学习与Python

发布于 2023-03-29 14:17:18

8890

发布于 2023-03-29 14:17:18

文章被收录于专栏：深度学习与python

作者｜王娟

中国移动通信集团江苏有限公司（后文统一简称为江苏移动）是省内规模最大的通信运营商，公司计费用户数近 2 亿，日均话单量超 200 亿。其业务支撑系统包含话单计费、账务处理、服务开通等多个业务场景。

近期，江苏移动引入 Apache Pulsar 等流原生新技术，结合云原生技术体系，完成了基于流云一体化架构的新一代业务支撑系统全面升级，实现了支撑系统在云原生时代新的演进。面对 5G+ 时代的新挑战，新一代业务支撑系统打造了全新支撑架构，通过跨系统间的资源融合、能力融智、数据融通，实现规模化、敏捷化、智能化、弹性化、自主可控的支撑目标，有效助力公司业务支撑效能提升。本文将介绍江苏移动核心支撑系统面临的挑战与应对挑战的系统演进措施，以及如何结合 Apache Pulsar、Ignite 和 SkyWalking 等分布式云原生系统提高开发效率并实现智能运维与运营。

面临三大挑战

随着市场竞争加剧，业务需求越来越个性化，江苏移动的核心支撑系统面临诸多挑战。

系统性能面临瓶颈

近几年流量业务呈爆发性增长。江苏省用户日均流量从数百 TB 增长到数万 TB，话单量、消息量增长，计费系统压力大幅增加。每天近百亿的话单、数十亿的消息对共享文件存储的依赖极高，NAS 逐渐出现 I/O 瓶颈，计费系统无法线性扩展。同时终端用户对提醒的及时性要求越来越高，提醒不及时极易引起用户投诉。

需求开发面对挑战

随着市场竞争的加剧，业务部门对需求交付的时间要求越来越短。现有 BOSS 系统架构越来越复杂，很多功能模块变得十分庞大，业务研发难以做到同时跟进，交付速度跟不上业务要求。

系统运维愈加复杂

随着 BOSS 系统的演进，多地多中心、多云混合的环境已经变成标配，增加了系统的复杂性，大大提高了运维的难度。

演进措施

面对上述挑战，江苏移动采取多项措施，进行针对性解决。通过引入微服务架构、Pulsar 消息平台、分布式内存库 Ignite、云原生架构，提升系统性能、提高开发效率、减轻运维压力。同时通过 PaaS 平台对资源进行的统一管理、调度，BOSS 系统的应用全部运行在 PaaS 平台上，部署、更新使用平台提供的运维工具，有效提升了整体的资源利用率。

设计目标

应对业务需求，计费系统技术架构需要具备四大特性：强一致、高性能、高可用、高可靠。

强一致

计费系统承载用户数近 2 亿，语音、短信、流量等业务日均话单量超 200 亿条，在海量的话单批价规模下，如何确保费用计算零差错，实现强一致性，是计费的最核心问题。

高性能

计费流程在忙时话单数量以数十倍突发，瞬间峰值超百万 TPS，因此计费系统需要具备很高的处理性能。

高可用

计费系统必须具备很强的业务容灾和数据容灾能力，有充分的弹性和容错设计，来保证 7*24 高可用。高可靠在数据存储层，只要话单处理成功就表示数据一定完成落盘，发生如操作系统崩溃、网络异常、磁盘异常等意外宕机时必须能够确保数据不丢；同时，针对分布式任何节点的故障，引发的主机数据损坏等问题，要求系统数据严格不错不丢。

架构概述

提高开发效率

为了支持以上技术要求，江苏移动在系统演进中做了针对性的架构设计与开发。

Serverless 构架

在新一代计费系统中引入 Serverless 架构，函数计算与 PaaS 平台为计费系统 Serverless 化提供应用引擎。在 BaaS 服务层，存储服务、应用监控、日志、数据库、内存库、消息等产品不断向 Serverless 化演进。基于 Serverless 架构计费系统可以根据语音、短信、GPRS 业务的话单流量波动，自动进行资源的分配和销毁，并最大程度化地平衡稳定性、高性能、提升资源利用率。计费系统开发追求完全自动的自适应分配的核心目标：更快地实现业务逻辑，减少在环境搭建和系统连接上的开发时间，将更多的时间聚焦在业务开发上。

微服务化

为实现系统高可用与业务功能快速扩展，新一代计费系统对应用进行了全面的微服务化改造，即微服务化设计。按照不同业务域的功能需求，通过合理的功能拆分，精细化的服务治理，如：服务的注册、发现、熔断、自愈、负载均衡、链路跟踪等实现功能的快速扩展和流量的高效调度，以此达成整体系统的高可伸缩。

流程编排

计费批价模块采用 Dubbo 作为微服务框架，在自主研发的 SNF 消息处理框架中集成 Pulsar 消费者中读取话单消息，通过 Dubbo 消费者调用 Dubbo 服务提供者的业务处理能力，完成话单批价的业务流程。在批价模块中支持流程编排能力，可按照业务需求动态调整流程的处理逻辑。批价完成后，批价成功的话单消息通过 Pulsar 生产者发送至下游模块并提交偏移量，批价失败的话单消息写入重试和死信队列，等待后续处理。

流程编排通过可视化界面提供节点拖拽的效果，批价模块根据定义的流程模型执行不同的业务处理逻辑

分布式配置中心

通过引入 Disconf 配置中心，实现业务应用配置发布、更新统一化，配置更新自动化，并提供操作简易的控制台，方便管理配置版本及配置文件。

幂等性

Pulsar 作为一个可靠的消息中间件，只要消息成功投递到了 Pulsar 中就不会丢失，至少保证消息能被消费者成功消费一次，即“At Least Once”至少一次语义。然而这种可靠的特性在异常的场景下会导致消息可能被多次投递，造成消息重复处理。如：

在消息消费的场景下，消息已投递到消费者并完成业务处理，当消费者给 Pulsar Broker 端反馈应答的时候网络闪断。为了保证消息至少被消费一次，Pulsar 将在网络恢复后再次尝试投递之前已被处理过的消息或将消息投递给同一消费组内的其他消费者来处理，同一条消息在同一个消费组内会被处理两次。
Pulsar Broker 负载均衡时消息重复，包括但不限于网络抖动、Broker 重启以及消费者应用重启，当 Pulsar Broker 或客户端重启、扩容或缩容时，会触发 Rebalance，此时消费者可能会收到重复消息。

但是，计费系统要求话单处理达到 100% 的正确性。因此，计费系统在消费逻辑上需要自我实现幂等性，探索出一个通用的消息幂等的方法，从而抽象出一个通用的框架用以适用各个业务的场景，达到“Exactly Once”有且仅有一次语义的目标。

计费消息幂等性引入了 Ignite 内存库作为存储介质，基于 Ingite EP 天然的事务原子性操作实现幂等。核心就是在 Pulsar 消费者接收到消息之后，根据话单构建的唯一标识在 Ignite 中查重，如果已经消费过，则直接提交偏移量；如果没有，则进行业务操作，并在业务处理成功之后将话单唯一标识写入 Ignite，防止重复消费。同时，存储在 Ingite 中的缓存数据，可以直接利用 Ignite 的 TTL 特性实现数据的自动清理，释放内存库资源。

顺序消息

服务开通系统要求消息按照严格的顺序消费，如服务开通接收到 CRM 的先停机后复机的工单指令，在业务处理时必须严格按照先停机后复机的顺序执行。如果先复机后停机，必然会造成用户的投诉。目前大部分 MQ 支持两种顺序模式，一种是全局有序，要求 Topic 只能有一个 Partition，对生产和消费的并行度有较大的限制；另一种是局部有序，保证 Message 中 Key 的有序生产和消费，例如用户 ID，这也是业务场景使用最多的一种方式。Kafka 和 RocketMQ 采用的是第二种种形式，通过将相同的消息 Key 路由到相同的 Partition 中，单个 Partition 的消息只能被同一个消费者消费。但是在消息量非常大的情况下，系统会出现性能瓶颈，因为相同消费组的消费者个数受限于 Partition 的个数。

Pulsar 的 Key_Shared 模式可以很好地解决这个问题，消费者的消息按照 Key 分配，因此 Key 的分散度越高，消费者的并发度越高，系统的吞吐量也就越高。新一代服务开通系统基于 Pulsar Key_Shared 特性实现消息顺序消费，使相同 Key 的消息被路由到同一消费者上处理，同 Key 的消息经过业务处理后批量更新至目标存储上，在保证消息的顺序性消费的同时提升系统的性能。

追踪与监控：Pulsar+Log4j2+Skywalking 等

随着业务规模的增长，计费系统应用的实例数规模不断增长，核心业务的依赖也变得愈加复杂，开发效率提升的同时故障定位成本也居高不下，特别是当业务出现问题的时候，如何快速完成故障定位成为新的挑战。

计费系统的可观测性按照指标、日志、链路追踪进行分类，围绕 Prometheus 服务、Grafana 服务和链路追踪服务，形成指标存储分析、链路存储分析、异构数据源集成的可观测数据层，通过标准的 PromQL 和 SQL 提供数据大盘展示、告警和数据探索能力，达成全面覆盖业务观测 / 应用层观测 / 中间件观测 / 系统层观测的目标。

指标

Pulsar 原生的指标包含集群总览、消息、Topic、组件 JVM、Bookie 等多项指标。基于 Pulsar 原生的监控能力，江苏移动自主研发 Pulsar Exporter 组件，基于 Spring-boot 框架调用 Pulsar Rest API 和 JMX 指标服务接口，提供扩展 Pulsar 自定义指标的能力，如集群健康状态、磁盘使用率、追单性能、延迟消费等指标，满足计费系统复杂的业务场景和个性化的监控需求。

集群总览

批价追单性能

日志

Pulsar 集群的多个组件 ZooKeeper、Bookie、Broker、Functions Worker 和 Proxy 以分布式的方式部署在多台主机上，因此每个组件的日志文件也分散在多台主机上。当组件出现问题时，由于日志比较分散，我们希望通过对日志进行聚合、监控，能够快速地找到 Pulsar 各个服务的报错信息并排查，使得运维更加具有目的性、针对性和直接性。为了解决日志检索的问题，计费系统采用集中式日志收集系统，对 Pulsar 所有节点上的日志统一收集、管理和访问。

传统的日志采集必须以文件的方式落一次磁盘，缺点是占用了主机磁盘的 IO。为此，在计费系统中 Pulsar 集群基于 Log4j2+Kafka+ELK 实现日志的快速检索。Log4j2 默认支持将日志发送到 Kafka，使用 Kafka 自带的 Log4j2Appender 在 Log4j2 配置文件中进行相应的配置，即可完成将 Log4j2 产生的日志实时发送至 Kafka 中。

Elasticsearch 根据检索字段进行分词，并创建索引。Pulsar 的日志建立了 8 个检索字段，分别是：集群名、主机名、主机 IP、组件名、日志内容、系统时间、日志级别、集群实例。

在 Kibana 页面，根据分词的字段指定查询条件进行检索。

借助 Pulsar SQL，计费系统使用 Pulsar 作为消息总线的同时，支持追踪回溯话单消息，能够动态查询存储在 Pulsar 内部的实时消息，并支持从外部系统提取数据，与 Pulsar 中的话单消息多维聚合分析，以图表的方式输出统计结果。

Pulsar SQL 支持以 JDBC 的方式访问持久化在 Topic 中的话单消息，运维智能分析系统基于 Java SQL 语言结合查询条件、时间范围等进行查询，并实时输出分析结果。

消息链路追踪

计费系统使用 Skywalking 分布式系统性能监视工具对话单消息进行链路追踪和性能监控。

在计费系统的所有环节中集成 Pulsar 的生产者和消费者，在启动模块的应用程序时，使用 Skywalking 的 JavaAgent 探针埋入 Java 程序中，用于收集应用程序和 Topic 中话单消息的指标数据。

通过 Trace 机制，追踪话单消息在 Pulsar 集群中一次全链路调用的完整记录，实现话单消息处理的可观测性。Trace 由所有环节的 Span 组成，每个 Span 使用 APM 插件在 Pulsar 生产者的拦截器上设置 Pulsar 的 Brokers URL 列表、Topic 名称、消息 ID 等 Tag，在 Pulsar 消费者的拦截器上设置 Pulsar 的 Brokers URL 列表、Topic 名称、消息 ID、订阅者名称等 Tag，用于记录应用节点中的关键信息。

话单消息在同一个消费者模块中，业务处理异常重新消费时需要使用 Pulsar 消息系统的重试和死信队列的特性，并使用 Skywalking 监控每条话单在同一个 Topic 和同一个订阅中的重试消费的次数和详情，用于观测话单处理的原因和执行链路的流转。

Skywalking 在追踪话单消息在 Pulsar 集群中的链路执行情况的同时，会采集话单消息在计费系统的每个模块中的性能指标，通过 Skywalking Analysis Core 分析聚合之后，在 Skywalking UI 上查看话单链路和指标数据。