经历亿级话单处理优化打磨检验，江苏移动云流一体化到底如何玩转
中国移动通信集团江苏有限公司（后文统一简称为江苏移动）是省内规模最大的通信运营商，公司计费用户数近2亿，日均话单量超200亿。其业务支撑系统包含话单计费、账务处理、服务开通等多个业务场景。
近期，江苏移动引入Apache Pulsar等流原生新技术，结合云原生技术体系，完成了基于流云一体化架构的新一代业务支撑系统全面升级，实现了支撑系统在云原生时代新的演进。面对5G+时代的新挑战，新一代业务支撑系统打造了全新支撑架构，通过跨系统间的资源融合、能力融智、数据融通，实现规模化、敏捷化、智能化、弹性化、自主可控的支撑目标，有效助力公司业务支撑效能提升。本文将介绍江苏移动核心支撑系统面临的挑战与应对挑战的系统演进措施，以及如何结合Apache Pulsar、Ignite和SkyWalk ing等分布式云原生系统提高开发效率并实现智能运维与运营。
面临三大挑战
随着市场竞争加剧，业务需求越来越个性化，江苏移动的核心支撑系统面临诸多挑战。
• 系统性能面临瓶颈
近几年流量业务呈爆发性增长。江苏省用户日均流量从数百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★https://www.infoq.cn/article/LKBS54VlX2VtC9phdN0B生产者发送至下游模块并提交偏移量，批价失败的话单消息写入重试和死信队列，等待后续处理。
流程编排通过可视化界面提供节点拖拽的效果，批价模块根据定义的流程模型执行不同的业务处理逻辑
• 分布式配置中心
通过引入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上查看话单链路和指标数据。
以上一套完整的可观测解决方案可以为计费系统提供高效运维、业务连续性保障的能力。
精细化管控与应用云化
计费系统按照多层次业务隔离来完善系统精细化管理控制。通过Pulsar多租户、Namespace、Topic分层特性来实现物理架构部署的分系统、分业务、分地市多级别隔离，实现硬件资源复用、逻辑数据隔离、业务互不影响，使得系统控制力度从地市级升级到业务级，组件、应用集群全高可用部署：
• 通过多租户区分系统：计费、账务、服务、信控等；
• 通过Namespace区分业务：高清语音、物联网、行业网关、流量等；
• 通过Topic区分地市：苏州、南京、泰州等。
计费系统的所有应用全面云化，计算资源通过PaaS动态调度、弹性伸缩，按需控制系统处理能力，实现整体开发成本和硬件投入的节约。
未来展望
未来江苏移动将在现有架构的基础上，进一步结合算力网络构建云边一体化的计费系统。通过计费策略的智能决策、系统资源的精细控制、业务服务的高效执行以及运营状态的全景洞察，满足未来差异化用户服务需求，有效提升系统的处理能力、开放能力和运营能力。
注：文档中的全部内容属中国移动通信集团江苏有限公司所有。未经允许，不可全部或部分发表、复制、使用于任何目的。
作者简介
王娟，江苏移动计费专家，负责BOSS计费系统的架构演进和维护。面对5G+时代的新挑战，她将Apache Pulsar引入公司IT业务支撑系统，致力于打造新一代高效智能的计费架构，助力公司IT支撑效能提升。