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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

腾讯计费大促活动自动化保障体系,也就是按五个思路来构建。一是大盘容量的压测机制,二是快速扩缩容机制,以及资源共享管理、变更扫描,和限频保护措施。

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

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

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

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

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

原文发布于微信公众号 - 腾讯TEG科技云端(TEGYunduan)

原文发表时间:2018-09-20

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

五个为什么(译文)

昨天晚上,我终于把 More Joel on Software 翻译完了。 谢天谢地,总算可以摆脱这本书了。 唯一的感觉就是特别倦怠......检查完译稿以后,...

28712
来自专栏灯塔大数据

探秘|那些你不知道的爬虫反爬虫套路

相爱相杀的爬虫与反爬虫 ? 前言 爬虫与反爬虫,是一个很不阳光的行业。 这里说的不阳光,有两个含义。 第一是,这个行业是隐藏在地下的,一般很少被曝光出来。很...

4599
来自专栏逍遥剑客的游戏开发

Nebula3竟然秘密更新了

1415
来自专栏企鹅号快讯

小程序再添新入口,开放微信外部流量入口,QQ浏览器直接打开小程序

最近小程序的动作不断,就在今天,小程序可以在QQ浏览器里打开,首页入口也即将开放!这一年以来,小程序频繁更新了将近 100 次,现在又在QQ浏览器上面增加了新的...

4028
来自专栏大数据钻研

所有程序员都应该遵守的11条规则

我是一个倾向于生活在规则下的人。 现在,这些规则大部分是我本人为自己设立的-但它们依然是规则。 我发现为自己创建规则可以让我过得更好,因为这样做可以提前决定一些...

3438
来自专栏我是极客人

0.5M安装包,最小浏览器颠覆你的IT观

这是我使用一点浏览器发自内心的感叹(回头想一想,我觉得这句话可以投稿给一点浏览器做绝佳广告词了)。

6372
来自专栏数据和云

细数那些你可能不知道的国产数据库

在之前中秋团圆之时,我们曾经绘制了一幅数据库的团圆照,这幅图中包含了多少种数据库,您现在数的清吗?图中又有多少国产数据库?

1.3K4
来自专栏BestSDK

4个核心要点揭开爬虫真面目,小心被反爬!

爬虫与反爬虫,是一个很不阳光的行业。   这里说的不阳光,有两个含义。   第一是,这个行业是隐藏在地下的,一般很少被曝光出来。很多公司对外都不会...

4705

想知道Tableau适不适合你?以下10点助你一臂之力

译者注:文章源址:https://blog.openbridge.com/is-tableau-right-for-you-10-point-checklist...

1.5K7
来自专栏前沿技墅

大数据运维三十六计

5054

扫码关注云+社区

领取腾讯云代金券