腾讯计费:亿万级大促活动自动化保障体系

9月14-15日,GOPS全球运维大会上海站圆满举行,为期两天的运维盛宴,为各位运维人带来了相互交流和学习的绝佳平台,来自腾讯技术工程事业群(TEG)计费平台部的黄宇给大家带来了「亿万级大促活动自动化保障体系」的主题分享。

我们同步了嘉宾现场沙龙分享视频(内含高清PPT),请点击下方「腾讯技术课小程序」卡片即可查看:

同时附上整理好的演讲稿:

黄宇,来自腾讯技术事业群的计费平台部,在鹅厂长期从事虚拟支付、多终端支付、账户存储、风控、结算等领域的工作,带领团队负责腾讯千亿级计费大盘的整体运营和质量,目前主要专注于运营自动化、私有云运维、智能监控等相关建设。

腾讯计费是做什么的

腾讯计费平台是产品端到端在线交易平台,其核心是帮助用户与产品安全、便捷的完成支付和收款,在交易过程中帮助产品盈收最大化。平台承载了公司每天数亿收入大盘,为180+个国家(地区)、万级业务代码、100+W结算商户提供支付渠道、营销、账户托管、风控、结算以及推荐等服务。

如果把腾讯比喻为一个饭店,腾讯计费就相当于门口柜台的收费平台,您可以用微信支付、银行卡、苹果支付、QQ钱包、充值卡抵扣券或其他方式支付你在饭店的消费;这里包括了ToC场景,比如用户往自己的QB账户充值,或者在游戏终端购买道具、游戏币;也包括ToB场景,比如广告主、网红主播、腾讯云客户的扣款收费,都是通过腾讯计费这套平台提供服务。

从收入统计来看,目前在账户托管方面,覆盖了绝大部分ToC ToB业务的有价账户的托管,有价账户的规模现在是360+亿的账户体量;实时交易方面,覆盖了90%以上的内部实时交易;结算出账是全覆盖。

大促营销活动 

大促营销活动是腾讯计费对内提供的一个核心服务,公司业务可以在计费平台上设置各种各样的营销活动,比如首次充值赠送、购买满赠、累计赠送、打折、抽奖、团购、砍价等等,支持的营销活动量级每年有几万个(2018年支持活动4.2W个)。

大家可以看到,像王者荣耀、CF、飞车这些头部游戏,或者腾讯视频、QQ会员这些包月VIP等产品都有几千万甚至上亿的活跃用户量级;如果通过活动进行推广宣传,全量用户的触达后,活动收入会呈现爆发式增长。

营销活动很多彩,然而现实很残酷,活动也有出故障的时候。作为负责公司收入大盘的计费平台,在支持业务营销活动中的风险和压力都是非常大的。尤其是在营销活动保障体系构建完善之前,时常会出现服务容量过载、平台扩容效率低、变更影响等平台问题。

那么为什么会出现各种类型的问题,这里分析总结了腾讯计费大促营销活动的几个特点:

1.活动链路很长,比如一个游戏中QB首充值赠送组合礼包的活动,用户一进来,要进行登录校验、大区查询、角色查询、风控检查、活动信息拉取、下单、支付、组合礼包中物品发货等一连串的调用;由于我们是公司支撑型平台,需要对接那么多业务和平台,单是外部接口就是280+个,所以一个不起眼的环节都可能成为大盘容量瓶颈

2.业务大促活动峰值与平时流量都是几十倍的差异,而且业务间的流量此起彼伏。公共平台的资源是有限的,不可能对不同业务每种活动类型不计成本的堆积设备资源。

3.现网变更频繁,前端版本、后端版本发布,系统配置调整、营销活动规则调整等各种变更每天加起来平均350+次,大家都知道,变更带来的故障通常占到了现网故障的75%以上,所以在这么变更频发的平台上进行营销活动资源扩缩容,高一致的精准度是很难保证的。

4.业务不能彻底隔离:计费平台支持了成千上万个业务,不可能为每个业务做一套隔离的环境。业务大促活动期间,是存在相互干扰的,如果控制不当,单个业务的爆发式流量甚至会带来整个大盘的雪崩效应,这又该如何防范。

如何评估大盘的容量瓶颈

说到大盘容量,大家都会想到春节红包或者双十一大促这样的大流量场景,都需要提前压测的方式来评估容量的瓶颈。

压测的方式一般有几种,一种是把服务组合为一个个SET,或者叫一个个桶,就跟生产车间一样,对每个set提前压测好性能,等需要的时候再按set一个个添加到集群中,这种方式适合于比较标准化、模块关系不复杂,大批量的可扩展场景;

第二种方式是根据现网既有规模,按比例缩小规模进行压测,从而估算现网环境的容量,一般测试或者预发布环境就是这么干的。

第三种方式就是模拟用户构造仿真数据,直接对现网大盘进行压测。前面也介绍了,腾讯计费的场景存在链路长、对接广等复杂性,所以采用第三种压测方式。

为了达到尽量仿真的压测效果,不能针对活动入口进行简单的并发重复执行相同用例,这样无法实现接近现网的仿真效果。前面也提到,不同的渠道、不同的业务或者活动模式,交易经过的内外部链路都不同,所以这里很重要的一点就是构建尽量逼真的压测场景。

根据现网平台入库到TDW的历史流水数据,按活动入口、登陆态、业务代码、支付渠道、版本号等信息,构建出百万级的用例组合。

TDW: Tencent  distributed data warehouse 腾讯分布式数据仓库

Cmdb:config manage database 系统及业务配置管理系统

FlowSvr:流量管理系统

深度仿真压测还要模拟用户端从不同区域和网络进行测试,所以在深圳、上海、天津、成都等不同城市的多个机房各地部署了用例分发SVR和agent,将一个大的压测任务分解到不同机房并行发起执行。

如果用少量的号码压测,很容易命中现网的限频拦截或风控策略,而且有些业务场景测试需要提供号码真实的游戏大区、绑定或者好友关系等信息,所以平台构建了十万级的号码资源库,不同测试号码满足不同的场景条件,用于压测过程轮询使用。 

那么压测用例在执行的时候,就会根据测试场景,自动匹配不同的业务资源和号码资源,替换执行。

关于现网压测还有一点值得注意,因为在直接对现网进行全流程压测,所以一定一定是不能压出问题的,一旦压上去的量级过大肯定会造成现网损失,所以压测速率从0提升到指定速率,建议采用匀速爬坡式提升,过程中一旦发现报错、超时可以立即停止压测。

按需动态分配营销活动资源

通过压测知道了大盘的容量,那么为了安全起见,是不是按最大最全的体量囤积资源就好了?

肯定不能这样,如果您是老板的话,也不会同意这样干是吧。大盘中不同业务场景在不同环节和时段的资源消耗是有差异的,在错峰情况下如何最大限度复用资源非常重要。

在这里的自动化扩缩容设计里,现网大盘由服务组成,服务由系统实例组成,而实例承载的基础是腾讯计费自研的TDF程序框架;扩缩容的核心大脑就是TSM自动化管理平台,压测平台周期性压测现网容量,现网内存、负载、时耗、流量等指标也会分钟级采集汇总,这些数据都会汇总到TSM管理平台,这个大脑再根据策略下达扩容、或者缩容的指令。

这里采用KVM虚拟机构建用于自动扩缩容的资源池,共享资源池会在日常扩容中出库消耗,在缩容中退库,这样持续的循环。资源池分成共享资源池和紧急资源池两个部分,紧急资源池一般是不动用的,就像一个国家的战略物质储备一样,只有在共享资源池出现补给不上的紧急情况才使用。

那么具体什么时候启动自动扩容呢,这里主要采用了多级阀值和趋势预判两种策略,所谓分级阀值就是当服务负载突发突破不同档位时,平台设置了不同的扩容比例和力度。趋势预判策略是根据逐步上升的容量指标,对下一时段的容量水平进行提前趋势斜率分析,并预判提前扩容。

具体的快速扩容操作,像TDF框架和相关基础库文件包,在资源标准化的时候就进行预安装,所以这个环节是不算耗时的;APP程序包按服务中的参照子节点进行发布,特别是权限方面,由于涉及的内外部权限非常多,所以也要参照原节点进行克隆。这个执行过程可以做到分钟级控制。

这里的扩容发布依赖的基础是一个全球发布平台,它通过公司级TSC操控通道向国内和海外,包含自建机房和AWS上的资源进行控制,它支持串行、并行不同的发布模式;具有适配广,高可用和可扩展的特点。

如何确保扩缩容变更精准无误

一开始有提到,在日常频繁变更的现网大盘上进行扩缩容操作,故障风险是非常高的,那么怎么确保这里的变更准确性呢?也就是怎么确保扩容上去的资源服务没有问题。

针对这个问题,这里采用了三种检测机制,一是对新节点通过工具demo进行功能探测,第二是将新扩容节点相对于服务原有节点进行横比扫描分析,第三是对实时监控告警信息的自动化关联。

这里要重点说下扫描检查机制,将扩缩容变更和版本变更等等都收拢到一个变更管控平台,这个平台再针对不同的变更场景发起扫描检查和播测验证;扫描检查是基于监控采集的海量数据,进行细粒度同比以及节点间横比,包括成功率、时耗、错误码等对比分析;拨测验证也就是之前有讲到的业务场景拨测;那么管控平台就是将扫描和拨测两方面的结论综合起来,判断这次扩容变更是否准确,并提交给TSM大脑进行决策。

如何防止大盘雪崩风险

以上介绍了自动化决策和自动化扩缩容的机制,那么是不是有了这些自动化机制就万无一失了呢?

自动化也不能100%的信任,如果极端情况,自动化扩容不能有效工作,我们的现网大盘会不会有被大促营销活动冲垮,进而导致雪崩的风险,这种情况一定不允许发生。

所以平台必须要有一个防止业务间相互冲击、避免大盘雪崩的应对措施;计费平台在入口层增加了按渠道、按业务进行并发限频的策略,当容量扩大或者缩小的时候,这个限频策略会相应的动态调整,服务SET间的流量也可以通过TSM大脑进行灵活的分流调度。通过这样的方式来确保大促活动期间大盘不出现雪崩的风险。

小结

腾讯计费大促活动自动化保障体系,也就是按五个思路来构建。

一是大盘容量的压测机制。

二是快速扩缩容机制,以及资源共享管理、变更扫描,和限频保护措施。

 构建之后,自动化保障体系可以浓缩为如下示意图。

压测平台通过周期性压测及时评估大盘容量瓶颈,监控平台也会实时采集相关容量指标;这些信息汇总之后做成一个实时的大屏,就把它放在公司的办公区域,同事都能看到;那么一旦容量指标突变触发了策略,TSM大脑会及时感知,并下发现网扩缩容的控制指令。这就是大致的调度过程。

这套保障体系建成之后,这两年遇到五一、国庆、除夕这样的重大节假日,或者头部业务周年庆之类的大促活动,都能够顺利支持,所以整个平台保持一个比较高的运营可用度。

早几年除夕的时候,为了应对集中爆发的大促活动,我们得安排一二十个人留守,而且有时得现场临时讨论应急方案;现在呢,每到除夕,只需安排两三个同事留守,看看大盘,做做监控,让大盘自动运行,效果还是非常明显的。

当然,我们这套保障体系目前还做到不够完备,尤其是针对海外支付的,或者采用亚马逊AWS之类的非自建机房场景,在自动化方面还需要持续的建设和提升。这是我们下一步继续努力的方向。

希望腾讯计费大促活动场景的自动化解决方案对您的场景有所参考,谢谢大家!

本文分享自微信公众号 - 腾讯技术工程(Tencent_TEG)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏业余草

多租户 Saas 系统架构的设计思路

原文链接:https://blog.csdn.net/cnpinpai/article/details/9196733...

1.1K50
来自专栏.NET技术与企业级解决方案

C#8.0 中使用默认接口成员更新接口

从 .NET Core 3.0 上的 C# 8.0 开始,可以在声明接口成员时定义实现。 最常见的方案是安全地将成员添加到已经由无数客户端发布并使用的接口。

12840
来自专栏配置 Linux 云服务器

自定义配置 Linux 腾讯云服务器方法 步骤

与快速配置云服务器相比,自定义配置提供您更丰富的镜像平台,以及存储、带宽以及安全组等高级设置,您可根据需求选择合适的配置。

15330
来自专栏SAP ERP管理实践

MM Evaluated Receipt Settlement(ERS) 自动发票校验

Evaluated receipt settlement (ERS) is an automated system used by businesses for...

19420
来自专栏五分钟学算法

10% + 10% = 0.11 ?是 bug 还是 feature ?微软开源的计算器项目告诉你答案!

近日,关于手机计算器10%+10%=0.11的事情火热,多个品牌的手机未能幸免,基本“阵亡”,同时还包括了windows10的自带标准计算器。你的手机阵亡了吗?

11720
来自专栏SAP ERP管理实践

MIR6校验时移动平均价为负的原因及解决

问题:在做发票校验(MIRO)时,出现移动平均价(MAP)为负的错误(Moving average price for material is negative...

9520
来自专栏大数据进阶

java并发包(1)-AtomicReference和AtomicStampedReference

AtomicReference原子应用类,可以保证你在修改对象引用时的线程安全性,比较时可以按照偏移量进行

8110
来自专栏SAP ERP管理实践

SAP 采购预付账款与采购订单关联

前提: SFW5激活ENTERPRISE_BUSINESS_FUNCTIONS,激活 LOG_MMFI_P2P,激活之后我们在创建采购订单时就可以维护预付款...

11810
来自专栏孟君的编程札记

责任链模式浅析

某天你想请个假,比如1到3天,直接主管可以审批;3天以上需要部门主管审批;15天以上需要副总裁审批 ... ...

8630
来自专栏软件成本造价评估

大数据中心平台适合用功能点方法估算吗?

问:大数据中心平台适合用功能点方法估算吗?大数据中心里面的数据集都是业务系统中的数据功能,在业务应用系统中已经记取了逻辑文件。大数据中心包括了这些数据的集成还有...

13620

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励