腾讯计费平台

腾讯计费(米大师)是孵化于支撑腾讯内部业务千亿级营收的互联网计费平台,汇集国内外主流支付渠道,提供账户管理、精准营销、安全风控、稽核分账、计费分析等多维度服务。平台承载了公司每天数亿收入大盘,为 180+ 个国家(地区)、万级业务代码、100W+ 结算商户提供服务,托管账户总量 300 多亿,是一个全方位的一站式计费平台。

腾讯计费的核心痛点

在体量如此庞大的腾讯计费场景下,我们要解决的核心问题就是如何确保钱货一致。腾讯计费自研了分布式交易引擎 TDXA,这是一套交易控制解决框架方案,致力于解决交易过程中应用层逻辑一致性问题。从业界现状看,TDXA 也是少有的专注于应用层的交易事务解决方案提供者,整体架构如下:

  • TM:分布式事务管理器。作为 TDXA 的控制大脑,采用去中心化模式,提供高可用服务,支持纯接口调用的 TCC 以及 DB 混合事务。在执行效率方面借助协程异步框架 TDF 以及 TDSQL 异步事务(Prepare 后可以关闭链接)能力支撑全公司的计费业务。
  • CM:作为 TDXA 的配置中心,引入可灵活注册的跳转控制机制,即时构建事务流程有向图,可以自动对流程的正确性和完备性进行检查,并以图形界面展示给用户,在图形界面进行管理。
  • TDSQL:自研金融级分布式数据库,具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性,为用户提供完整的分布式数据库解决方案。
  • MQ:为 TDXA 提供高一致、高可用的消息通道能力,结合事物状态表最终对各种异常进行收敛。

MQ 在计费场景的应用

围绕计费高一致目标,MQ(message queue)在腾讯计费中的应用可以分为在线服务和离线准实时服务。

在线服务场景

失败和超时,腾讯计费覆盖 80+ 特点各异的渠道,300+ 不同业务逻辑,单个支付逻辑常横跨众多不同的内外部系统,调用链路比较长,异常出现的概率相对也会比较大,特别是网络超时(比如海外支付业务)。

TDXA 在处理这类情况会配合本地事务状态库,通过消息队列、消息到期重发,从断点开始继续执行整个交易事务,保证每日亿级交易请求的一致性。

离线准实时服务场景

怎么证明计费系统的高一致呢?那就必须通过第三方对账系统来验证,对账时间粒度越小,就能越早发现问题。在互联网移动支付行业,用户体验是第一位,倘若在玩王者荣耀时,购买英雄后没有及时发货,势必会影响用户体验,甚至遭到投诉。

借助 MQ 实时管理能力以及流式计算框架对计费流水进行实时对账和监控,与 TDXA 相辅相成,共同保证整个交易的时效性和一致性。

其它场景

当遇到王者荣耀周年庆活动时,交易请求会突发 10 倍以上的流量增长。借助 MQ 削峰填谷的能力,交易流水查询和推送以及 Tips 通知等场景能够顶住洪峰压力。

同时,在付费用户画像场景对用户行为数据进行实时挖掘分析,能为业务提供更智能的营销服务。

为什么选择 Pulsar

腾讯计费系统对分布式消息队列的要求如下:

  • 一致性要求:计费场景要求数据一条不能丢,这是最基本的诉求。
  • 高可用要求:需具备容灾能力,在异常情况下能够自动修复。
  • 海量存储需求:在移动互联网时代,产生大量的交易数据,需要具备海量堆积能力。
  • 快速响应要求:在亿级支付场景下,要求 MQ 能提供平滑的响应时间,尽可能控制在 10ms 内。

目前业界使用比较多的是 Kafka,主要场景是大数据日志处理,较少用于金融场景。RocketMQ 对 Topic 运营不太友好,特别是不支持按 Topic 删除失效消息,以及不具备宕机 Failover 能力。我们选 Pulsar 是因为其原生的高一致性,基于 BookKeeper 提供高可用存储服务,采用了存储和服务分离架构方便扩容,同时还支持多种消费模式和多域部署模式。Kafka、RocketMQ 和 Pulsar 的对比如下:

对 Pulsar 的功能优化

Pulsar 的开源生态为开发者提供了广阔、灵活的开发空间,为了在腾讯计费场景中更好地应用 Pulsar,我们对 Pulsar 做了一些功能优化:

  1. 支持延迟消息和定时重试(2.4.0 支持)。
  2. 支持二级 Tag。
  3. 完善控制台,支持消息查询和消费追踪。
  4. 完善的监控和告警体系。

延迟消息

在计费场景中,延迟消息是比较常见的需求,比如交易引擎中超时处理,又或者团购砍价活动等。

对于失败超时重试场景,并不需要在短时间内大量重试,因为很可能还是失败,依次扩大时间间隔进行重试是比较合理的。采用 Delay Topic,定时对每个队列的头部进行到期时间检查,高效地把消息投递出去,理论上可以支撑无限大的延迟消息。

Delay Topic 基本上能满足绝大部分场景,也有少数其它场景需要指定任意延迟时间。采用 Time wheel 的方式可精确到秒,但需要维护索引关系,不太适合大规模的延迟消息。

在不改变 Pulsar 内部存储模式的前提下,我们支持这两种模式,支撑了王者荣耀英雄砍价活动。

二级 Tag

腾讯计费有上万个业务代码,为了提高安全性,需要按业务同步交易流水。如果按业务代码创建 Topic,需要创建上万个 Topic, 这样会增加管理 Topic 的负担;如果一个消费者需要消费交易流水的所有业务,则需要维护上万个订阅关系。

我们在消息元数据中加入 Tag 属性,用户在生产消息时可设定多个 Tag ,消费时 broker 端会过滤掉不匹配的 Tag。

控制台

消息队列在线上大规模使用需要具备一个完善的控制台。用户经常会问以下几个问题:

  • 这条消息的内容是什么?
  • 这条消息的生产者是谁?
  • 这条消息被消费了吗?消费者是谁?

针对于这几个问题,我们对消息的整个生命周期(即从消息产生到消息被消费)进行追踪。

我们对 Pulsar 消息元数据加入生命周期相关数据(由于消费时间和消费地址不是消息本身的属性,因此不能将它们直接加在消息元数据中,但可以通过 ES 中流水日志关联查询到它们的信息),再注册 Topic、生产组、订阅关系以及权限,提供统一接入流程管理。

监控告警

我们在 Pulsar 中加入系统监控数据采集组件,数据最终对接计费平台部的鹰眼运营平台,可以自定义告警规则,按业务秒级精准告警。如有临时突发情况,鹰眼平台会根据当前负载情况生成扩容方案,并支持一键扩容。

告警有以下类型:

  • 积压告警:在线服务中,如果出现大量消息堆积,说明后端消费成为瓶颈。此时需要及时告警,通知相关人员进行处理。
  • 延迟告警:在交易记录查询场景中,要求购买记录在 1 秒内查出。撮合监控组件采集的生产流水和消费流水,能统计出每条消息生命周期。
  • 失败告警:常规统计流水中的错误信息,从业务、IP 等多维度进行监控告警。

总体架构

如前文所述,腾讯计费优化了 Pulsar 四大模块的功能,由此搭建了以下架构:

  • Broker 作为消息队列代理层,负责消息的生产和消费请求,支持水平扩展,根据负载按 Topic 自动进行均衡。
  • BookKeeper 作为消息队列的分布式存储中心,可配置多个消息副本,在异常情况下具备 Failover 能力。
  • ZooKeeper 作为消息队列的元数据和集群配置中心。
  • 支持多种消费模式,其中 Shared 模式下的消费者突破对分区个数的依赖, function 模式非常适合简单的交易流水清洗场景。
  • 提供了统一的 HTTP proxy 接入能力,方便其它语言接入。
  • 腾讯计费还有部分业务是 JS 和 PHP 等语言,提供了统一的 HTTP proxy 接入能力,并对客户端加上生产失败重试能力,提升生产成功率。集群出现异常时,客户端会做降级处理,将消息发送至本地或发送至容灾集群。

以上是我们对 Pulsar 所做的功能优化。我们会继续和 Apache Pulsar 社区合作,把这些优化的功能贡献给社区,希望帮助到社区的其他用户。我们也希望更多的用户加入 Pulsar 社区,共同完善 Pulsar 功能。

Pulsar 在腾讯计费的使用情况

分布式消息队列目前基本上覆盖了大部分计费系统,很多已经成为了支付环节的关键路径。Pulsar 稳定提供的高一致、高可用的消息通道能力,助力计费交易引擎稳定高效运转。目前,Pulsar 已在腾讯计费大规模使用,经受住了业务洪峰的压力和交易一致性的考验,达到了 5 个 9 的高可用率。

总结

Pulsar 是一个年轻的开源项目,拥有非常多吸引人的特性;Pulsar 社区发展迅猛,在不同的应用场景下不断有新的案例落地。我们会持续关注并和 Apache Pulsar 社区深入合作,把优化的功能奉献给 Pulsar 社区,和社区其他用户一起进一步完善、优化 Pulsar 的特性和功能。

腾讯计费历经 15 年打磨,提供一整套的高一致计费平台,经受住了腾讯公司内部付费业务的考验。腾讯计费平台是一个中台型的产品,已经在腾讯云上开放给外部的合作伙伴,目前已应用在多个领域,欢迎关注联系。

文章来源于腾讯云开发者社区,点击查看原文