“ 导语：QQ每年都会开展春节红包活动项目， 而每年启动立项，都要投入大量的开发人力，满足业务需求快速迭代的同时，保证红包业务的稳定和运营质量。 另外，由于活动百万量级的请求量，导致红包项目须要投入巨大的系统资源来支撑。在降本增效大背景下，红包业务亟需瘦身优化，文主要从成本维度出发，总结下今年红包在开发设计过程中，对如何降低红包业务各项资源成本和系统复杂度的优化和思考。（PS：具体成本数据已脱敏，仅保留优化比例）”

01

—

活动介绍

红包活动期间， 用户登录手Q就会收到下拉刷一刷提示引导跟一个下拉吊坠， 用户可通过下拉操作，参与刷一刷抽奖， 过程中随机获得福币和金额不一的现金奖励。刷一刷结束后用户可进入红包主会场页面， 继续抽取福币奖品，或点击彩蛋福币，玩多款趣味小游戏， 积攒游戏分数和福气值， 以获得更大的现金奖励。

今年和往年相比，最大的亮点就是活动引入全新的福气值体系，升级了激励玩法，游戏道具接入广告，通关即可赢取现金和福气值，吸引用户积攒福气值，赢取锦鲤大奖。

这一玩法升级，助力今年红包新增了以下亮眼的运营成绩：

● 小游戏现金激励，激发用户分享意愿，裂变分享用户新增200%。

● 游戏道具接入广告， 额外新增百万量级别的广告收入。

● 小游戏总参与人数较去年提升6.5%， 人均游戏时长15+分钟。

02

—

系统架构

红包业务系统架构如下图所示：

业务访问层：客户端接入访问刷一刷抽奖， H5接入访问主会场(抽奖、福气排行、背包等)和游戏(游戏排行、游戏信息，提交分数等)网关接入层： 使用手Q统一接入平台sso， 提供接入鉴权、过载保护、染色路由、链路跟踪等基础能力。

业务逻辑层：红包业务主要服务有两个，一个是抽奖服务， 提供奖品管理、限频限量、秒级防刷、概率控制、柔性降级等抽奖相关的基础能力， 另一个是主会场服务， 提供福袋生成、好友排行、游戏广告、福气值、分会场引流等主会场相关的基础功能。

存储层：存储层经过两年的迭代，已将未上云的存储组件grocery和ckv， 逐步切成了维护成本更低且已经上云了的腾讯云Redis。

依赖服务：主要的外部依赖有 QQ支付现金接口（发放现金奖励）、QQ公众号接口（通知用户中奖结果）、QQ基础关系链（昵称、头像、好友列表）。

运维监控：本次活动服务部署迁移到了123平台， 使用了伽利略/007、鹰眼、atta和灯塔等监控系统，同时通过红包上报服务实时上报数据看板，保障红包服务在活动期间平稳运行。

03

—

红包系统资源成本过高，如何优化降低成本？

1. 背景

在降本增效的大背景下， 红包项目在一开始开展工作的时候， 就重新梳理了去年活动期间红包各资源项的成本， 我们发现，CDN资源成本占了所有资源成本的90+%， CDN资源成本占比这么高，是否合理呢？于是， 我们开始对CDN的流量进行分析。

2. 流量成本分析

红包系统为了提升用户体验， 避免活动上线时的瞬时流量冲击，导致服务不可用， 我们会对红包的素材资源进行预下载，所以红包的CDN流量请求持续时间，会比活动的持续时间更长， 达到了18天， 在此期间，红包多个域名加起来的日平均流量接近1.2T。

以下是去年三个主要域名的CDN流量曲线：

1. 离线包域名：给前端代码和资源做预下载使用。

2. 在线域名：客户端文件和图片资源做预下载，前端和客户端线上下载使用。

3. 大文件域名：视频文件做预下载和线上拉取时使用。

结合域名对应的资源项， 我们对CDN各项资源的流量和成本进行了分析，我们发现了几类问题：

● 低ROI资源占用：视频资源很多都是低ROI资源，占用过大，基本都大于3M, 而曝光量占总用户量比例却比较低（百万级/亿级），但仍占用了全量的下载带宽。

● 全量曝光下载：去年的素材资源大部分都是全量曝光下载， 利用率低， 部分二级、三级页面和资源在活动期间的访问频率低。

● 无效下载：大部分卡券资源属于定向资源， 有着明确的黑白名单，无需全员下发。

● 流量不均：预下载期间， CDN的流量不均， 波峰波谷相差极大， 没有最大化地利用每天的CDN带宽成本。

3. 优化方案

上述分析的几类问题， 我们进行了有针对性的优化：

● 精简低ROI资源：除了必要的转场视频，其他低ROI的视频资源，应去尽去，应缩尽缩。

● 资源包分级分类压缩：一级页面的资源尽量内嵌进安装包， 二级页面则进行分类压缩， 按需进行预下载， 针对三级页面等一些低频资源，则不做预下载， 需要时再实时获取。

● 精准覆盖：针对卡券这类定向资源， 我们只需要下发给白名单用户， 精准覆盖到对应的人群就可以了。

● 预下载流控系统：削峰填谷，高峰限流， 低谷补发，最大化利用当天CDN资源成本。

4. 预下载流控方案设计

去年的预下载方案如上图所示，我们是通过Manager配置系统， 灰度放量指定的号码段来下发资源配置， 然后通过观察用户的覆盖数和CDN峰值， 来决定是否放量， 这种方式的弊端如下：

● 操作繁琐：每次发新的素材配置版本， 都须要手动限速放量，人工观察数据，发布周期内，需要发布人一直盯着，操作繁琐，成本也比较高。

● 可控度低：每次灰度的量要非常地小心，因为每个时间段放量的合理阈值（与手Q在线人数正相关）是不一样的，如果放量过大， 很容易就会让CDN的峰值过高，导致当天的CDN成本升高， 控制放量的颗粒度太大。

今年的预下载流控方案如上图所示， 客户端到预下载服务来获取资源配置文件，预下载服务进行基本的单机限流、全局、资源白名单控制后， 再根据当前的CDN峰值、当前的请求量以及配置的CDN阈值， 实时计算当前需要下发的配置文件数，跟当前已下发的配置数进行对比，如果高了，则返回空配置包，如果低了，则正常下发配置。这套方案的优势如下：

● 自动限速控制：发布周期内，不再需要人工观察和操作， 降低了操作成本和风险。

● 削峰填谷：防止过大的流量波动，可以做到更细颗粒度的放量控制，最大化地利用当天的CDN资源成本。

可见今年的流控方案，不管从服务稳定性、还是成本、风险可控度上， 都明显优于去年的manager灰度放量方式， 而且也不需要时时刻刻地看监控，手动放量。

5. 优化效果

今年的CDN流量曲线如上图所示， 其中1.14号前是预下载流量，1.14号后为线上流量。

预下载：

● 灰度预下载期间(5~8号)， CDN阈值控制在40Gbps以内

● 放量预下载期间（9~10号）， CDN阈值控制在70Gbps以内。

● 更换资源放量期间（11~13号），CDN阈值控制在200Gbp以内

前期灰度和放量期间， 流量非常稳定均匀， 最大化利用了CDN流量成本，后期由于更新了素材资源版本， 为了尽快提升资源覆盖率， 将CDN阈值提升到200Gbps，11号和12号的流量出现波动，夜间低谷时为跑满， 但成本依然控制在可承受的200Gbps范围， 同比去年峰值（600Gbps）下降了66%。

线上流量： 14号活动上线后， 实时流量没有出现太大的尖峰， 峰值为180Gbps,同比去年峰值（400Gbps）下降了55%。

可见新方案的流量控制效果符合既定预期，相应的CDN成本，也同比去年下降了81%。

04

—

红包系统复杂度高，如何提高开发运维效率？

1. 背景

去年红包系统的调用链路如上图所示， 目前我们的问题现状有：

● 有状态服务：采用了一致性Hash + 本地缓存Memcached。

● 运维部署成本高：往年服务部署在CVM机器上，通过织云进行部署更新，大部分服务仍是C++服务。

非标准化的有状态服务，致使红包系统的复杂度过高，极大消耗了开发人力，不利于红包业务的持续运营。上云并做云原生改造， 降低红包系统的复杂度，就成了一项必要而又紧迫的任务。

2. 优化点一：链路节点优化，无状态服务改造

导致红包系统复杂度高的原因，最直接的便是， 采用了一致性Hash + 本地缓存Memcached。往年之所以采用这套方案， 是因为以下几点原因：

● 挡量：缓解对存储层的访问压力。

● 省流：节省逻辑层到存储层的流量带宽。

● 稳定：历经多年红包活动的考验。

但这套方案， 必须让同一用户的所有请求， 都路由到同一服务节点，使得服务成了有状态服务，因此也衍生了很多问题：

● 架构和代码复杂度高：开发同学需要写额外的代码逻辑， 来理解和处理状态，例如A用户抢了B用户的福袋， 这时需要去写B用户的福袋存储，那我们必须重新发起一条rpc请求，给同在逻辑层的另一个服务节点，通知其写B用户的福袋存储，并更新本地缓存， 否则，下次B用户上来读取福袋存储的时候， 就会拉到旧数据。

● 流量不均，跳变不止：不管采用哪种一致性hash算法，都是无法保证请求像无状态服务一般，均衡地落到各个服务节点上， 并且不出现跳变的情况， 而一旦出现了跳变，就需要有相应的容错处理措施， 避免数据出现不一致的问题。

● 扩缩容风险高：线上服务扩缩容的时候要非常小心，避免扩容时，新扩节点没有缓存而透传流量，把存储打崩的情况，缩容的情况也类似。

● 机器成本：使用一致性hash的场景有：

○ 用户请求经由接入层路由访问逻辑层服务

○ 逻辑层服务间路由访问

○ 服务本身有状态引发额外rpc请求，进行更新写存储和缓存

为了保证上述调用场景的一致性hash算法和sdk client的语言、版本是一致的，避免存在一种场景跟其他场景路由到的节点不同，导致无法命中本地缓存的情况， 我们须要在sso接入层后面额外新增一个红包proxy服务来保证这一点， 而因此也多加了1200+核的机器成本。

鉴于上述的问题弊端，我们做的第一个优化便是，做链路节点优化，去掉一致性hash和本地缓存，将服务都改造成了无状态服务。

但去掉本地缓存， 就意味着逻辑层会透传流量到存储层， 原本到达存储层的请求， 会进一步放大， 存储层能否抗住，抗住的成本能否承受， 有没有什么风险呢？基于这些问题，我们在做完链路优化后， 就进行了一轮压测验证。

我们按照去年现网请求量的三倍进行压测，存储redis的配置规格则跟去年保持一致，压测结果发现，到达redis存储层的请求，从236W升高到658W, 请求扩散倍数由去年现网的1.92倍增大到了5.35倍，即使如此，我们观察到redis的CPU在44%左右， 所以证明当前新方案下，存储层不增加成本的情况下，依然是可以抗住红包三倍流量的访问压力的。

不过秉着应优尽优, 尽可能降低对redis访问压力的原则，我们在这个基础上，对加福气值、游戏排行、福气值排行等对redis有大访问量的场景，进行了请求聚合优化，同时把这个聚合优化逻辑，封装成了一个通用的wrapper client， 让大部分使用到redis的访问场景，都能共享这一优化。

3. 优化点二：服务上云标准化改造

如前所述， 往年红包服务是部署在CVM机器上，通过织云进行部署更新，且大部分服务仍是C++服务，运维、部署、开发成本极其地高， 所以近两年的红包项目，都致力于标准化服务，将一些未上云或者已经落后不维护的组件框架，逐步重构切换至已上云且更符合云原生的组件和平台上来， 并且对服务提供的能力、功能接口进行封装服用， 主要体现如下：

● 服务部署标准化：服务部署从CVM机器，迁移至123平台容器上， 方便快速搭建、部署。

● 存储标准化：将grocery存储，切换到redis， 部分bitmap迁移到redis， 提高容错容灾能力，方便运维。

● 代码标准化：将C++ Spp服务， 重构切换成trpc-go服务， 提升开发、问题定位效率。

● 服务能力复用：封装复用抽奖、主会场、CDN限速等服务能力， 避免来年新的红包活动，又要重复开发。

4. 优化效果

经过上述优化， 有效地降低红包系统的架构和代码复杂度，提高了开发运维效率，极大降低了红包业务持续运营的成本， 人力成本同比下降了50%， 相关的搭建、部署成本也都下降了80%+， 而且新一年的红包活动， 以目前的技术架构，我们的成本还能再往下压一压。

作者:ronnyhuang

来源:微信公众号:腾讯VATeam

出处:https://mp.weixin.qq.com/s/ElIuJlFwWvTxAoEDOBADyQ