在 2021 年春节联欢晚会上，面对高达 703 亿的红包互动总数和累计 12.21 亿的春晚直播间观看人次，抖音技术团队和火山引擎云原生团队通过云原生化的基础架构设计和敏捷开发流程设计，保障了红包互动活动的安全、稳定、顺畅开展。本文主要介绍了火山引擎云原生团队在本次活动中的一些贡献！
2021 年 2 月 12 日凌晨，字节跳动各地办公楼依然灯火通明。线上，各个春晚支持团队仍在飞书工作群里激烈交流着……此时距离 12 亿红包发送活动结束已经过了一个多小时，本次春晚的云计算设施保障团队——火山引擎云原生团队——还在一遍遍校对着，见证一个个数据被写进抖音《2021 春晚数据报告》。
这是这个团队第一次正面应对春晚的“流量大考”。他们见证了春晚互动数据的再一次打破纪录，也获得了春晚互动零卡顿、零宕机的佳绩。
官宣成为央视《春节联欢晚会》独家互动合作伙伴，对字节跳动内部的各个团队来说，都意味着业界的信任和新的技术挑战：
按照往年的经验，企业承接春节春晚合作项目至少需要筹备 2-3 个月。而抖音在短短 27 天内就完成了从底层云基础设施建设，到上层数十种互动类新玩法的上线，这离不开背后的抖音技术团队和火山引擎云原生团队。事实上，为了支持除夕当晚数亿级 QPS 抢红包请求，两大支撑团队在短时间内跨多个机房完成了服务器的协调，为整个活动提供了充足的计算资源支撑；凭借云原生基础设施，抖音平稳应对了流量洪峰，用户的红包互动体验也自然流畅。
2021 年，抖音技术团队和火山引擎云原生团队为春晚活动准备的服务器数量是 12 万台。相比前几年春晚背后的服务器台数，这一数字并没有太多增长，但它之所以能顺利保障流量峰值时期所有在线服务的稳定，离不开两个关键：
其中，第一个关键保障了两大支撑团队在 27 天内极限完成所有服务器的部署；第二个关键有效控制了字节跳动在春晚活动支撑上的支出成本。
单纯按照波峰准备资源易导致资源浪费
企业在部署业务时，为了使业务能安然度过高峰，必须按照高峰的流量预估准备资源。但众所周知，互联网在线业务的流量具有明显峰谷潮汐变化，当业务处于流量低谷时，很多资源会被浪费掉且无法通过超售进行回收。以抖音为例，它在波峰波谷间资源利用率的差距可能达到 40%，而春晚更是一个极端的峰值场景。为了避免支撑春晚的计算资源在活动结束后成为浪费，除了少量采购新服务器，这次火山引擎云原生团队将提高集群整体资源利用率作为主要技术方案。方案一：离线资源拆借。字节跳动内部有很多离线任务需要资源进行调度，例如模型训练等，但这些任务在时间上并没有特殊约束。火山引擎对这部分业务所占用的机器进行了拆借，设置离线出让策略后，这些服务器可以在 5 分钟内转换成在线可用状态，并通过服务弹性扩缩组件，根据资源需求配置完成活动所有服务的统一等比例快速扩缩。方案二：在线混部出让方案。春晚当天，字节跳动还有大量服务器在支撑其他在线服务。所谓在线混部出让，即在保证其他业务稳定不受影响的前提下，在这些机器上插入部分春晚作业，例如抖音平台大量投稿短视频的码率转换和抽帧任务。火山引擎通过 FaaS+Virtual Kubernetes，配合单机维度的 QoS 管理和隔离手段，将业务申请的冗余资源和在线业务波谷时段的冗余资源供给春晚活动使用。同时，为了缓解任务冷启动带来的延时影响，火山引擎也通过 Pod 维度的 Warm Up 池保证了资源的极致弹性。基于上述两种技术方案，团队利用有限硬件设备，为春晚活动提供了充足的算力支撑。
解决计算资源问题后，摆在众人面前的第二个问题是存储。除夕当晚，抖音共迎来 703 亿次春晚红包互动，亿级高并发抢红包、拆红包行为，给后端数据库造成了巨大压力。为了确保活动的平滑顺畅不宕机，火山引擎采用自研架构的 Redis 系统提供缓存服务：通过集中化元数据存储，实现了节点和集群性能的海量扩展；通过异步和多线程 IO 优化，将热点数据打散和智能搬迁，大大降低 Redis 的长尾时延。在红包雨活动期间，该系统凭借字节跳动庞大的集群数量和机器规模，支撑超过 2.5PB 数据。在大规模分布式系统中，通过消息队列进行异步削峰也是有效应对海量流量冲击的手段。面对红包雨活动，火山引擎采用存储和计算分离架构，所有持久化存储都放在池化存储中，由池化存储组件来保证数据的一致性和可靠性，以及相应的灾备和 Geo-replication 能力。而计算层节点则可以保持本地无状态，专心处理消息队列系统的计算逻辑，并实现极致弹性扩展。在关系型数据库性能保障层面，火山引擎自研的云数据库系统采用云原生架构设计，通过高可用容灾架构、智能自适应限流、日志数据分离、日志即数据库、Multi-master、新型硬件（RDMA +AEP）等技术，读写 QPS 达到数千万级别，保障了红包雨活动期间抖音的稳定运行。
自研分布式图数据库系统 ByteGraph
而面对抖音在整个春晚红包活动中提供的红包雨、集灯笼、答题分红包等多种互动玩法，抖音技术团队和火山引擎云原生团队将字节跳动自研分布式图数据库系统 ByteGraph 用在了生产环境。在红包活动中，相比常见的 KV 存储系统和 MySQL 存储系统，图数据库在应对春晚千万级并发查询方面有更大的性能优势和更简洁高效的接口。而 ByteGraph 历经字节跳动丰富在线存储场景，在功能上已演进得愈加完善。在春晚“拍视频过年”活动中，火山引擎自研的对象存储在幕后为数亿用户提交的短视频内容提供可靠稳定存储。同样的，抖音用户在春节期间观看的包括超过 506 亿播放次数拜年视频在内的所有短视频内容，也均存储在 10EB 级超大规模对象存储服务中。
春节期间，字节跳动各业务平台纷纷上线节日活动，流量井喷为 CDN 带来了一次集中压力测试。抖音作为一个 DAU 高达 6 亿的全民 APP，其日常波峰流量已经非常惊人，在春晚活动场景下，由于存在 APP 常规流量增长、口播场景需要集中冷启动流量以及红包活动流量，多重增长需求叠加后，除夕当晚，抖音的流量峰值高达日常的 3 倍以上。如何在短时间内为这些流量提供网络接入加速线路服务，也是技术支撑团队要解决的一大难题。基于在抖音、抖音火山版、西瓜视频等内部业务场景中的多年实践， 火山引擎在本次春晚活动中采用了自研的端云配合融合加速线路方案。该方案提供全面覆盖边缘节点和终端设备的拨测能力，支持灵活的 L1/L2 回源控制、专线/公网回源无缝切换，可自动进行流量控制、运行时探测线路优选、容灾等，在底层分布式架构上实现了低时延、高弹性、易维护，提升了用户体验。春晚直播和红包活动有高可靠、高并发的场景需求，解决流量接入后，当流量洪峰经过各线路最终汇聚到 IDC，支撑团队根据红包活动流量需求特点，将大量新增业务逻辑就近接入边缘汇聚机房，既保证了网络的低时延，也减少了对核心 IDC 机房的压力。同时，边缘汇聚机房采用 IaaS 虚拟化技术，可实现非活动业务快速切换，在短时间内为 PaaS 服务以及红包雨计算服务提供了数倍于常态的资源需求。
对于春晚流量高峰场景，支撑团队也在调度层面做了大量工作。首先是流量的分级治理和合理降级。基于 BAM 接口分级管理平台的业务流量分级信息，团队采用 AppSettings + TNC + TTNet + HttpDNS 在移动端请求发起、域名解析等阶段开展多层降级手段。针对冷启场景，火山引擎也安排了专项降级治理和分时间段降级配置。最终，在用户体验无明显损失的情况下，春晚红包活动以平稳的流量波动度过 6 次口播冷启及红包活动的峰值叠加时刻。其次是特性多元、性能强大的调度系统。得益于在字节系 APP 中积累的流量调度经验，火山引擎的调度方案在传统域名调度能力基础上，可以基于统一移动端网络库，根据用户 IP 等信息判断其所在位置，并将其流量调度到最近的机房中去，进而实现流量合并、隔离等调度需求。针对移动端，团队的调度系统具备十万分之一级别的流量切换精度、数亿级别在线客户端配置管理、千万级并发请求更新调度配置能力，可以在 24 小时内实现 99.5% 配置覆盖。因此在春晚高并发大流量场景下，该系统为抖音应对局部容灾、整机房大规模容灾等场景提供了充分能力支撑。第三是高度自动化的容灾能力。春晚场景下，当端上发现当前接入点请求异常时，完全依赖人工判断进行切换操作会导致较高的时间成本和失误风险。为了确保故障出现时能快速切换到对等接入点的 IP/域名，支撑团队为移动端重点流量的调度提供了自动容灾能力，将故障对用户的影响时长降至 1 分钟内，保障了用户在活动中的整体体验。
回顾本次活动的支撑工作，时间短、资源缺、性能要求高、容灾压力大，这些考验对临危受命的抖音技术团队和火山引擎云原生团队而言是前所未有的。但两个团队承受住了压力，通过云原生基础设施应对流量洪峰，通过多机房协同为红包雨活动提供算力，最终通过了“流量大考”。结合春晚的实践成果，火山引擎已计划向外开放这套基于云原生技术打造的统一、健壮的基础底层服务，帮助更多企业应对由全面互联网化带来的在线业务服务压力和指数级增长数据处理压力。除了高并发流量应对能力，在业务敏捷交付和迭代层面，火山引擎这次也展示了大量以应用为中心的云原生核心设计，请期待我们的下一篇技术分享！
