快手基础架构演进：如何支撑春晚红包极端流量场景

2020 年除夕，作为 BAT 以外第一家扛起春晚战旗的互联网公司，快手在当天的春晚红包活动中，红包互动总量达到 639 亿次，创春晚史上最大的视频点赞纪录，红包站外分享次数达到 5.9 亿次。对于这场“大考”，InfoQ 此前曾经做过详细报道：《春晚红包：史上最难开卷考试，快手交卷了》。在春晚红包这一极端场景背后，基础架构团队如何交付易于使用的高可用基础组件和方案？如何模拟春晚流量进行预案、压测？如何进行核心服务的扩容？

近日 InfoQ 记者采访了快手基础架构系统架构师王天舟，他也是此次 A1 项目（快手春晚红包项目）基础组件方面的负责人。就以上问题，他为我们进行了详细解答。王天舟在即将召开的 QCon 全球软件开发大会（北京站）2020 上，将发表题为《快手春晚活动基础架构演进》的主题分享。

极端流量让技术问题被放大

对于王天舟来说，春晚当天最让他紧张的时刻是前两轮口播。“按照往年 BAT 的经验，这两轮的压力理论上是最高的。虽然我们经过模型推算和预测给出了分析，但是当流量真正来临时，还是有一些紧张：如果我们之前的预测模型出现错误，实际流量超出预测流量，那么我们就会非常被动，就需要启动 Plan B 了。"不过最终结果是：”春晚当天峰值压力来临时，其实距离我们压测容量还有差距。“

口播时候的突发性流量，其请求量要比正常服务高一个数量级以上，这就需要王天舟的团队为突发流量做额外的定制化设计——核心活动的架构设计也是此次 A1 项目最大挑战之一。

”口播瞬间触发的量，如果用常规方式——每一个请求都在这一瞬间处理好，基本上是不可能的，有限的资源做不到这件事情。在这个情况下，我们采用了超高并发的架构设计理念——把核心请求进行预计算，然后提前预下发。“

在春晚红包这样极端流量加持下，很多技术问题会被放大。具体到此次春晚红包的“视频 + 点赞”发放形式，大家能够想到的就是把视频放到 CDN 上，让 CDN 去扛流量。大多数公司也都具备这样的成熟方案。但是这个方案放在此次春晚就行不通了。王天舟告诉我们：”当天主持人口播一瞬间，数亿人同时用快手 App 看一条视频，短视频的播放流量是超过中国 CDN 总容量的，所以就需要去做额外的设计。“

快手选择的设计方案是，提前把视频预加载到 App 上。思路简单，但真正做起来面临的挑战非常大。首先，什么时候去做预下载、怎样控制带宽才能不影响用户正常的体验？其次，视频有可能在春晚当天会变，怎么应对变的情况？另外，预下载如何存在客户端上不会被提前泄露；最后，预下载的覆盖率如何把控：覆盖率过低对缓解 CDN 压力作用有限，覆盖率过高对用户的影响就会比较大。

基础设施的架构能力经受考验

2019 年，百度春晚的服务器数量是 10 万台，其中有 5 万台服务器是从百度核心的“凤巢”广告系统下让渡而来。基于短视频业务对服务器等基础资源的更高要求来看，快手为此次春晚活动准备的服务器数量不会低于百度。对于基础架构团队来说，硬件不仅考验公司的采购以及部署能力，从另一个层面上，服务器从十到一百、一千、一万、十万… 更考验基础设施的架构能力。

对此王天舟解释：”如果一个公司的架构演进过程是一个线性的缓慢演进的话，比如服务器是一批一批逐渐增长，那么架构就可以进行渐进式迭代。但是如果像我们这次一样，要用 2 个月时间去进行如此规模的服务器交付，尤其最后一个月，很多业务要跑在降级模式下，压力和挑战就会很大。不过还好最终我们架构都赶上了。“

据王天舟介绍，此次快手为春晚采购的机器被分成了几块：一块是交付给业务直接使用——全部使用容器的方式交互；另外一块是缓存类、DB 类、中间件方面的公共资源组件，因为采用了多租户场景，按容量规划去分配资源，不仅精确，而且利用效率也更高；此外还有极少数业务场景需要放到物理机上，没有通过容器方式部署，这部分是另外一个场景，因为运算密度高，所以这部分机器的容量也很容易察看。

扔一个猴子在机房，随便敲

“不过准备工作再足，也无法完全模拟春晚当天的突发高流量，这意味着考验我们的机会只有一次。”采访中王天舟多次强调。在之前的准备工作中，快手准备了时间线预案（剧本）和紧急预案（触发式），这些预案在元旦期间也都进行了完整的高拟真演练。

对于压测，快手的做法是用混沌工程的理念做故障注入，核心思路是在包括单机、服务在内的所有服务器上随机注入不同级别的故障，去模拟部分机器高负载、高延迟导致服务器宕机或半死不活的状态，从而检测高可用设计是否行之有效。

“我们在服务端架构设计当中有两个指标，一个是容量，就是你是不是能扛住流量；另外一个就是在当前容量下，我们的架构设计是否能承受住硬件的损坏。”在王天舟看来，高可用设计其实验证起来比较困难，因为它好的时候就是好，出问题的时候，到底是完全不受影响，还是有一半挂掉，还是全挂了，都不确定。

“我们会根据硬件可能发生的故障频率给出一个列表，单机故障是最容易发生的，其次是机架级别故障，再其次是整个机房级别的故障，包括大家最常见的光纤被拉断的事情。我们按照一个发生概率去排，然后人工模拟这些故障，直接在我们机房里随机去调机器。”

“就是扔一个猴子在机房里，你随便搞，随便敲。”

在快手，服务调用、测试、服务治理、服务发现、追踪系统都收敛在基础组件的一个范围内，王天舟他们有全公司所有的调用信息。“机器级别的故障注入没有什么难度，因为这种硬件级别的应用层故障和高延迟都是单机级别的，很容易操作。更高级别的就是抽象粒度的，比如某些网络硬件设施造成某一类服务或者某几类服务产生一个服务容量的下降，我们最怕的就是这个服务半死不活，这种时候就需要对服务级别进行故障注入。”

此外，模拟故障发生之后，熔断后的降级措施也是基础组件部门要提供的能力。不过王天舟强调：“熔断的一些配置对业务来说是可感知的，业务需要知道一件事，就是当熔断发生之后，业务流程应该怎么走。如果业务代码有可能没写对的话，那么一旦发生熔断可能就不符合预期，就会发现很多问题。”

架构师是最容易陷入理想主义的一群人

王天舟是“老快手”，他 2015 年加入公司，当年快手的基础架构做过一次大的升级调整——核心的后端架构“换了一次血”。而在那之后，一直都是小补丁的方式去做“修修补补”。所以此次春晚红包这样量级的考验，王天舟此前是没有遇到过的。“虽然我们在做架构设计的时候会有一些前瞻性，比如会考虑未来涨十倍什么样，但实际能不能涨十倍，涨十倍的时候我们的架构能不能扛得住，这些都要在事情真正发生的过程中去发现问题、解决问题。”

王天舟所在团队一共有接近 40 人，从 10 月接到春晚红包的消息后，团队就差不多是”All in“的状态。这次春晚红包，对基础架构团队来说，是一次巨大挑战。一方面，基础组件的 overhead 在常规压力下其实并不会被凸显，但是春晚极端情况下，基础组件本身的性能开销就变得格外重要。另一方面，基础架构平时面临的业务需求非常多样，但是在春晚红包活动期间，对一些极端需求会非常旺盛（例如超高精度数据统计，例如大量以自适应为基础的可用性组件等），这在以往服务规模不足的时候，未必是一个有效的需求，亦或者之前的解决方案其实是无法胜任的，需要做相应的微调、升级或者重构（例如我们的核心统计 perf 组件，就经历了一次大的重构和架构升级）。

对于春晚红包活动给团队带来的收获，王天舟总结为质的飞跃，“不光是技术能力，还包括个人的视野，人员战斗力以及组织能力。”

提及整个项目下来的整体感受，王天舟的感悟更多是从业务维度来看的。“基础架构团队最容易面临的两个问题：一是对业务了解不够深入，需求只停留在表面，以建设能力为导向，容易忽略解决问题的效果。二是基础架构组件和方案在业务中推行容易受到阻碍，如果业务用脚投票，那么基础组件的收敛工作会有极大的挑战，在这种高并发或者挑战较大的活动时，往往容易出现各种意想不到的问题（因为业务选择方案和组件的导向往往更容易倾向于短期利益）。”

站在架构师的立场上，就对架构师的视野提出了比较高的挑战：如何识别业务发展中的短期问题和长期问题，并把行业最佳实践“剪裁”或者“嫁接”到业务当中，让方案对业务更加适用，而不是让业务去适配方案。这些就要求架构师一方面能深入业务，了解业务的特点和一线的实际痛点，另一方面又要对行业内的最佳实践和未来方向保持敏感。

王天舟认为架构师是最容易陷入理想主义的一群人。他个人的经验是：在和业务进行交流时，时刻保持敬畏之心，并且能识别出哪些问题是源于自己的“洁癖”或者“理念”。当出现意见不一的时候，以解决问题为导向，以数据为导向，而不是强调个人倾向、感受或者理念。因为前者相对客观，也容易达成共识，后者更加主观，在很多时候也无法 100% 分出对错。

嘉宾介绍：

王天舟，就职于快手，担当基础架构系统架构师，主要负责快手服务端 Java 开发方向架构、规范和基础组件研发等工作。从业以来一直投入社交领域服务端开发和架构设计，有丰富的相关经验。

活动推荐

在 QCon 北京 2020 的演讲中，王天舟老师将介绍快手基础架构团队在应对春晚活动挑战时，做了哪些技术层面的改造和升级，并如何最终在业务落地，发挥效果，点击了解详情。