独家专访抖音春晚互动总指挥：如何做到 27 天成功交付？| 顶尖技术团队访谈

优秀的产品背后，必定有优秀的团队做支撑。《顶尖技术团队访谈录》系列采访以国内知名公司的 IT 技术团队为线索，展示他们的文化、思想与经验。本期，InfoQ 走进抖音春晚红包支持团队，了解扛起 703 亿红包互动总数和累计 12.21 亿春晚直播间观看人次的抖音背后的技术平台和研发团队。

2020 年 9 月 24 日，中央广播电视总台宣布拼多多成为中央广播电视总台 2021 年《春节联欢晚会》独家红包互动合作伙伴。2021 年初，一系列事件将这家公司推上舆论的风口浪尖，与此同时，春晚红包出现史上首次交棒，抖音顺利接棒，成为 2021 年总台春晚独家红包互动合作伙伴，此时距离 2021 年《春节联欢晚会》的正式播出已不足一个月。

“差不多 27 天吧，我们只有这么多时间备战春晚红包，一直到腊月 28，我们都还在接需求，疫情其实也没有完全结束，不确定的因素太多了。”抖音春晚红包总指挥顾修铭对 InfoQ 如是说道。

众所周知，春晚红包堪称是互联网公司的宕机血泪史，再强的系统在海内外超过 10 亿人的观看规模面前都会如履薄冰，即便扛过了除夕夜，也难抵用户同时提现带来的流量冲击。与此同时，抖音背后的技术团队还面临着史上最短的准备周期，开局仓促的抖音最终是如何抗住 703 亿红包互动流量冲击的？这是一个怎样的基础设施架构？本文，InfoQ 希望通过抖音春晚红包总指挥顾修铭的讲述还原备战全过程。

抖音春晚红包：四地研发团队协同作战

2021 年除夕刚过，抖音官方发布捷报显示：抖音春晚红包互动总数高达 703 亿，春晚直播间观看人次累计 12.21 亿，直播间实时在线最高人数 498.46 万，新媒体行动总曝光量 813 亿，用户云拜年视频总播放量 506 亿，云拜年视频总点赞量 62 亿。字节跳动旗下的火山引擎为抖音春晚互动提供了技术支持，保障活动顺利完成。

这一串数据的背后有着抖音北京会场、上海会场、深圳会场、杭州会场四地研发同学的努力，顾修铭在接受 InfoQ 采访时表示，这些同学主要来自于抖音、火山引擎以及其他中台部门，每天早上都会开站会，平时通过飞书等各种方式实时在线交流。

回顾整个过程，顾修铭认为，“仓促上阵”带来了诸多困难，唯一的解决办法来自日常的积累。

“事实上，接手的时候我们都还不确定具体需求是什么。对研发来说，确定的需求和时间节点远优于不确定的需求和确定的时间节点。”

这不是抖音首次与春晚合作，但作为第一身份承接春晚红包，却是第一次。在接到通知之后，抖音研发团队迅速盘了下自己当时的处境：

1. 需求不确定。事实上，抖音的产品团队几乎与研发团队同时得知需要为春晚红包做准备，需求本身的变数又比较多，需要不停地迭代，很难短时间内给出最终确定版本，研发时间格外紧张。

2. 活动形式复杂。抖音这次共准备了 20 余亿元红包，其中 12 亿元红包在除夕当晚发放，另外超过 10 亿元红包给抖音火山版 APP 和抖音极速版等 APP。此外，从小年夜 2 月 4 日起，打开抖音拍全家福视频、贺岁照、集灯笼，完成任务即可抢红包，最高还可获得 8888 元锦鲤红包，活动链路变长的同时出错的可能性也增加了。

3. 抖音本身是一个短视频为主的应用，占据的 CDN 资源较多，即使内部资源没问题，客户端也可能由于带宽限制而出现问题。此外，抖音本身的日活、月活已经相当高了，抖音官方曾在 2020 年 9 月份表示日活已经突破 6 亿，春晚红包的放大效应会将这一数值逼近极限。与此同时，这也表明很多用户其实已经预装了该应用，除夕当晚同时打开会导致瞬时流量集中爆发。

4. 资金安全。涉及到大额的金钱发放时，就需要考虑风控问题，这也是非常重要的。

相比于前几届春晚红包，疫情也为本届增添了几分不确定性。“1 月份的时候，北京的疫情其实没有完全结束，我们当时比较担心大年三十那天因为管控措施无法集中办公，北京会场这边一千多研发人员就需要通过远程的方式进行整体协作，这本身也是一个风险。”

在想清楚自己的处境之后，研发团队开始想办法逐个解决问题。

27 天，基础设施准备就绪

在春晚红包这件事情上，大厂们吃过的亏各有不同。说简单也简单，无非是基础资源准备，技术架构优化，以及充分的压测和演练，但面对庞大的流量洪峰和“挑剔”的用户，一步错则全盘皆输，难度陡然升级。

“当务之急是确定需求，这样研发团队才好做事情”，对于需求本身存在的不确定性和持续迭代，研发团队最终决定在腊月 28 之后停止接单，所有需求在腊月 28 号之前完成。“这件事情达成共识之后，需求团队很快就给了我们初版。”

拿到需求之后，整个团队迅速按照活动链路、核心业务、常规业务，以及基础资源支持分成四组。其中，活动链路主要指的是春晚红包一系列活动相关的链路，比如用户打开抖音抢红包等；核心业务链路主要指的是抖音的信息流、视频发布、搜索、直播、电商等场景，例如发视频的链路是非常长的，后端需要处理带宽资源、视频审核之类的；常规业务指的是抖音之外的其他产品，需要跟进资源分配情况。

“事实上，技术层面的大部分能力得益于我们平常的技术积累，只不过在这一次春晚红包活动中得到了大规模落地。”

离在线混部平台

“我们也看到了一些开发者对春晚红包的讨论，大家最关心的第一个问题就是资源够不够。但其实对我们来说还好，主要得益于我们的离在线混部能力。”

抖音是比较纯粹的 PaaS 部署模式，由火山引擎云原生团队提供支持，扩缩容非常方便。离在线混合部署则可以更容易得发挥这种部署模式的好处，研发人员可以从整个平台清楚看到抖音每个业务的资源占用情况，对机器的把控力也比较强，假设分给某业务 100 台机器而实际的 CPU 利用率不到 10%，系统可以自动快速筛选出闲置机器并分配给其他活动，甚至不需要业务主动发出扩容请求，这也可以极大降低成本。

此外，一旦出现需要立即响应的突发资源请求，也可以快速顶上，因为离线任务是有优先级之分的，可以将中低优任务的资源先分给需要的业务，这个是非常灵活的。

存储能力

字节跳动经过多年发展内部已经具备了完善的存储产品矩阵，比如图存储、对象存储、KV 存储以及传统的关系型数据库，这保证了春晚红包活动可以根本不同的数据类型选择不同的存储方式，且多套存储产品之间互为灾备，一个挂了可以快速切换到另一个，切换的过程中如何保证数据的一致性还是非常重要的，这需要靠平时技术能力的积累。

此外，字节跳动本身的存储量级也比较大，KV 存储的量级可以达到几十亿 QPS，规模小的业务也可以达到上千万 QPS，所以可以在春晚红包活动中自然而然的顶住超大量级的存储流量。

流量接入能力

对于短视频应用来说，日常主要是将视频分发到 CDN 上，即把视频文件发送到离用户最近的地方，利用 CDN 节点分担用户观看流量，但这种方式只适合静态资源，春晚红包依靠主持人口播抢红包的时间节点，显然没办法是静态的，其中是有计算逻辑的，这就需要一套完善的流量接入调度体系。顾修铭表示，抖音在客户端利用火山引擎云原生能力，对流量和网络系统进行调度，拥有良好的边缘计算能力，可以保证多层调度，从而很好地解决如下问题：

1. 流量瞬时爆发的问题。用户打开应用的瞬间会产生很多请求，每个业务都希望可以在启动阶段做初始化，就会导致启动阶段占据的带宽较多，解耦成本也比较高，如果打开应用都有问题，用户肯定不会参与后面的红包雨活动了，多层调度可以解决这个问题；

2. 多层调度意味着具备很好的容灾能力，抖音的边缘机房数量有数百个，即使某个机房出现问题，也可以做到良好的调度。此外，边缘机房的数量也在一定程度上反映了接入点的数量，这可以保证处在弱网环境下的用户也可以有很好的体验和接入质量。

与此同时，要保证系统不雪崩，也就是一个系统损坏不会造成大规模瘫痪，还需要做好服务治理和流量隔离。

全天候压测、十余次预演

“开始准备的第 8、9 天之后，我们的压测系统就开始全天候开着”。

之所以让压测系统一直开着，主要是因为需求在不断迭代，一旦上线新的需求或者技术本身进行了迭代优化都需要重新进行压测。顾修铭表示，压测是分流量、分阶段和分场景进行的，初期以分段压测为主，比如只压存储、只压业务，后期开始进行全链路压测。此外，很多功能都需要在压测的情况下进行验证，比如容灾能力、资金安全等，团队需要模拟峰值流量下的资金分配、容灾情况。

在抖音内部，前后共进行了十余次春晚红包活动预演，主要分为活动链路（为春晚红包设置的各类活动）和常规业务两部分，由于常规业务本身没有过多迭代，一开始便进入压测范围，然后逐步增加流量，比如 130%、150%、200%...... 真正开始将活动链路和常规业务结合起来预演是从 2 月 2 日开始的，这也是第一次完全模拟除夕当晚做的预演。

动态引擎框架 Lynx

Lynx 是一套客户端动态引擎框架，类似于 React Native ，可以做到即使客户端发布之后依然可以很好地进行动态迭代，这一点非常重要，因为客户端发版是需要周期的，而抖音春晚红包团队只有 20 多天的准备时间，按照客户端的发版节奏走肯定是来不及的，Lynx 起到了很大的作用，这也是抖音 2019 年参与春晚红包后得到的收获之一。

2019 年，抖音以第二身份参与了春晚红包活动，当年采用的全部是 Native 的方式，导致需求变动成本非常高昂，于是当年的复盘文档中就出现了搭建动态引擎框架的需求，整个团队迅速完成了立项、调研及研发的工作，今年这套框架第一次大规模应用落地，效果颇好。

活动复盘

顾修铭认为，从用户侧来看，没有感受到明显的卡顿或者大致流畅就可以了。但对于抖音春晚红包战队而言，需要考察业务是否达到预期，以红包雨为例，发出去的红包数量和实际领取金额、发送成功率、稳定性等都是业务指标，任何一个指标出现异常都是事故。

面对如此重大的项目，顾修铭表示只靠临时抱佛脚是不可能的，需要技术团队本身有相当丰厚的技术积累，这一点其实也是业界普遍认可的，要想春晚发红包，产品日活先过亿。原因很简单，用户量过低，技术很难支撑起春晚级别的高并发流量。“这就跟考试一样，平常不努力，只靠临时抱佛脚是不可能取得好成绩的”。

其次是企业文化，像这么大型的活动很难找到一个人把方方面面的事情全部考虑到，这么复杂的业务需要很多人在一起协作，但每个人都是独立个体，没办法做到从上到下像复制粘贴一样想法完全一样，这很依赖团队的战斗力和凝聚力，只要每个人将自己负责的工作做到极致就可以保证春晚红包活动的顺利执行，“我们内部有一个非常长的操作手册，规定了大家协同时按照何种格式填写内容，可以看到大家考虑到了每一个可能的故障或者异常情况，互相弥补而不是互相推诿，这是极为重要的。”

应受访者要求，文中的顾修铭为化名

相关推荐：

中国顶尖技术团队访谈录（2021年第一季）