2020年除夕夜，作为BAT之外第一家放飞春晚旗帜的互联网公司，Aauto Quicker在春晚红包活动中的红包互动共计639次。
1亿次，创造春晚历史上最大的视频点赞记录，站外分享红包数达5.9亿次。对于这个“大考验”，InfoQ。
之前已经详细报道过：《春晚红包：史上最难开卷考试，快手交卷了》。春晚红包极端场景背后，基础设施团队如何交付易用、高可用的基础设施组件和解决方案？如何模拟春晚交通进行预规划和测压？如何拓展核心服务？
近日，InfoQ记者采访了同样是A1的Aauto faster基础设施系统架构师王天舟。
项目基本组成部分负责人(亚图快春晚红包项目)。他给了我们上述问题的详细答案。王天舟在即将召开的QCon全球软件开发大会(北京站)2020上。
，将发布标题为《快手春晚活动基础架构演进》的主题分享。
# #极端的流量放大了技术问题。
对于王天舟来说，春晚最紧张的时刻是前两轮的口头播报。“根据英美烟草前几年的数据，
经验来看，这两轮压力理论上是最高的。虽然我们通过模型计算和预测给出了分析，但是当流量真正到来的时候，还是有一些紧张：如果我们之前的预测模型是错误的，实际流量超过了预测流量，那么我们就会非常被动，需要启动。
方案b .然而，最终的结果是：“春晚压力高峰到来时，距离我们的压力测量能力还有差距。”
播出过程中突发流量的请求量比正常服务高出一个数量级以上，这就需要王天舟团队为突发traffic-核心活动的架构设计也是此次 A1.做额外的定制设计
该项目的最大挑战之一。
“如果每一个请求都以常规方式在这个瞬间处理，口头广播的即时触发量基本上是不可能的，有限的资源也做不到。在这种情况下，我们采用了超级并发的架构设计理念——预先计算核心请求，然后预先分发。”
在春晚红包的极致流量加持下，很多技术问题会被放大。具体到春晚红包的“视频点赞”分发形式，大家能想到的就是把视频放到CDN上，让CDN。
疏导交通。大多数公司也有这样成熟的方案。但是这个计划在这个春晚是行不通的。王天舟告诉我们：“那一天，上亿人同时使用了Aauto Quicker App。
看一个视频，短视频的播放流量超过了国内CDN的总容量，所以需要做额外的设计。"
Aauto选择的设计方案是提前将视频预加载到App中。
走吧。想法很简单，但做起来挑战很大。首先，什么时候做预下载，如何控制带宽以免影响正常的用户体验？其次，视频可能会在春晚发生变化。如何应对变化了的情况？另外，预下载在客户端是如何存在的，不会提前泄露；最后，如何控制预下载的覆盖率：如果覆盖率太低，就会缓解。
CDN的压力有限，高覆盖率对用户的影响会更大。
# #基础设施的架构能力已经过测试。
2019年百度春晚服务器数量为10万台，其中5台。
从百度核心“丰巢”广告系统转移了一万台服务器。基于短视频业务对服务器等基础资源的更高需求，Aauto Quicker为春晚准备的服务器数量不会低于百度。对于基础设施团队来说，硬件不仅考验公司的采购和部署能力，而且在另一个层面上，服务器从十台到一百台、一千台、一万台、十万台…
它还测试基础设施的结构能力。
王天舟解释说：“如果一个公司架构的演进过程是线性慢演进，比如服务器是分批逐步增加的，那么架构可以增量迭代。但是如果像这次一样，我们想利用它。
交付如此规模的服务器需要两个月的时间，尤其是在最后一个月，许多业务部门
据王天洲介绍，Aauto为春晚购买的机器分为几块：一块交付商家直接使用——全用容器交互；另一个是缓存类，DB。
类和中间件中常见的资源组件，由于采用多租户场景，根据容量规划分配资源，不仅准确，而且具有更高的利用效率；此外，需要放在物理机器上的业务场景非常少，这些场景不是通过容器部署的。这部分是另一个场景。因为计算密度高，这部分机器的容量也很容易看出来。
# #把一只猴子扔进电脑房，敲它。
“但是准备工作充分，不可能完全模拟春晚上突然出现的高流量，也就意味着只有一次考验我们的机会。”王天舟在采访中多次强调。在之前的准备工作中，Aauto Quicker准备了时间线计划(脚本)和应急计划(触发器)，这些计划在元旦期间也进行了完整的高保真演练。
对于压力测试，Aauto Facter的方法是用混沌工程的概念注入故障。核心思想是将不同级别的故障随机注入所有服务器，包括单机和服务，模拟部分机器处于高负载、高延迟的状态，导致服务器宕机或半死不活，从而检验高可用设计是否有效。
“我们在服务器架构设计上有两个指标，一个是容量，也就是你能否守住流量；另一个是我们的架构设计能否承受当前容量下硬件的损坏。”在王天舟看来，高可用性设计其实很难验证，因为好的时候就是好的。出了问题，不确定是完全不受影响，半死不活，还是全死。
“我们会根据硬件可能发生的情况。
障频率给出一个列表，单机故障是最容易发生的，其次是机架级别故障，再其次是整个机房级别的故障，包括大家最常见的光纤被拉断的事情。我们按照一个发生概率去排，然后人工模拟这些故障，直接在我们机房里随机去调机器。”“ 就是扔一个猴子在机房里，你随便搞，随便敲 。”
在快手，服务调用、测试、服务治理、服务发现、追踪系统都收敛在基础组件的一个范围内，王天舟他们有全公司所有的调用信息。“机器级别的故障注入没有什么难度，因为这种硬件级别的应用层故障和高延迟都是单机级别的，很容易操作。更高级别的就是抽象粒度的，比如某些网络硬件设施造成某一类服务或者某几类服务产生一个服务容量的下降，我们最怕的就是这个服务半死不活，这种时候就需要对服务级别进行故障注入。”
此外，模拟故障发生之后，熔断后的降级措施也是基础组件部门要提供的能力。不过王天舟强调：“熔断的一些配置对业务来说是可感知的，业务需要知道一件事，就是当熔断发生之后，业务流程应该怎么走。如果业务代码有可能没写对的话，那么一旦发生熔断可能就不符合预期，就会发现很多问题。”
## 架构师是最容易陷入理想主义的一群人
王天舟是“老快手”，他 2015
年加入公司，当年快手的基础架构做过一次大的升级调整――核心的后端架构“换了一次血”。而在那之后，一直都是小补丁的方式去做“修修补补”。所以此次春晚红包这样量级的考验，王天舟此前是没有遇到过的。“虽然我们在做架构设计的时候会有一些前瞻性，比如会考虑未来涨十倍什么样，但实际能不能涨十倍，涨十倍的时候我们的架构能不能扛得住，这些都要在事情真正发生的过程中去发现问题、解决问题。”
王天舟所在团队一共有接近 40 人，从 10 月接到春晚红包的消息后，团队就差不多是”All
in“的状态。这次春晚红包，对基础架构团队来说，是一次巨大挑战。一方面，基础组件的 overhead
在常规压力下其实并不会被凸显，但是春晚极端情况下，基础组件本身的性能开销就变得格外重要。另一方面，基础架构平时面临的业务需求非常多样，但是在春晚红包活动期间，对一些极端需求会非常旺盛（例如超高精度数据统计，例如大量以自适应为基础的可用性组件等），这在以往服务规模不足的时候，未必是一个有效的需求，亦或者之前的解决方案其实是无法胜任的，需要做相应的微调、升级或者重构（例如我们的核心统计
perf 组件，就经历了一次大的重构和架构升级）。
对于春晚红包活动给团队带来的收获，王天舟总结为质的飞跃，“不光是技术能力，还包括个人的视野，人员战斗力以及组织能力。”
提及整个项目下来的整体感受，王天舟的感悟更多是从业务维度来看的。“
基础架构团队最容易面临的两个问题：一是对业务了解不够深入，需求只停留在表面，以建设能力为导向，容易忽略解决问题的效果。二是基础架构组件和方案在业务中推行容易受到阻碍
，如果业务用脚投票，那么基础组件的收敛工作会有极大的挑战，在这种高并发或者挑战较大的活动时，往往容易出现各种意想不到的问题（因为业务选择方案和组件的导向往往更容易倾向于短期利益）。”
站在架构师的立场上，就对架构师的视野提出了比较高的挑战：如何识别业务发展中的短期问题和长期问题，并把行业最佳实践“剪裁”或者“嫁接”到业务当中，让方案对业务更加适用，而不是让业务去适配方案。这些就要求架构师一方面能深入业务，了解业务的特点和一线的实际痛点，另一方面又要对行业内的最佳实践和未来方向保持敏感。
王天舟认为架构师是最容易陷入理想主义的一群人。他个人的经验是：在和业务进行交流时，时刻保持敬畏之心，并且能识别出哪些问题是源于自己的“洁癖”或者“理念”。当出现意见不一的时候，以解决问题为导向，以数据为导向，而不是强调个人倾向、感受或者理念。因为前者相对客观，也容易达成共识，后者更加主观，在很多时候也无法
100% 分出对错。
嘉宾介绍： 王天舟，就职于快手，担当基础架构系统架构师，主要负责快手服务端 Java
开发方向架构、规范和基础组件研发等工作。从业以来一直投入社交领域服务端开发和架构设计，有丰富的相关经验。
