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

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