2020 Google开发者大会重磅开幕 了解详情

春晚红包:史上最难开卷考试,快手交卷了

2020 年 2 月 11 日

春晚红包:史上最难开卷考试,快手交卷了

春晚红包史堪称互联网公司宕机血泪史,再强的高并发能力在海内外超过 10 亿人的观看规模面前都显得那么脆弱。在互联网人的固有印象里,春晚活动是 BAT 三家轮番坐庄的技术盛事,毕竟只有具备足够的用户体量,才可能有足够的技术能力支撑起春晚级别的高并发流量。今年除夕,作为 BAT 以外第一家扛起春晚战旗的互联网公司,快手在今年的春晚红包活动中,红包互动总量达到 639 亿次,创春晚史上最大的视频点赞纪录,红包站外分享次数达到 5.9 亿次。除夕前一天,面对严峻疫情,技术团队紧急开发,快手在春晚红包活动提现环节上线“助力武汉”红包捐赠功能。


快手是如何准备这场“春晚红包”战役的?在筹备压力最大、最忙碌的春晚前一周,InfoQ 记者在位于北京上地西路的快手总部采访了包括资源调度、基础设施架构、应用启动、客户端稳定性在内的多个部门技术负责人,还原出一个全貌。


代号 A1,快手春晚交卷



中国互联网信息中心发布的《中国互联网络发展状况统计报告》显示,截至 2018 年 12 月底,中国网民规模达 8.29 亿,手机网民规模达 8.17 亿。移动互联网前所未有地普及,也造就了世界互联网史上那些罕见的高并发流量场景:以双十一为代表的电商大促、春运放票时的 12306 系统,以及每年除夕的春晚红包大战。


2020 年春晚红包活动,是在中国互联网传统豪强 BAT 以后,第一次出现新兴面孔,这家公司的名字是:快手。


从 1 月 24 日晚 8 点到次日凌晨,快手共发放 10 亿元现金红包,这个金额创下了春晚红包的新记录。在曾经让微信抢先支付宝半个身位的 2015 年,微信发了 5 亿红包;2016 年,支付宝发了 8 亿红包;2019 年,百度发了 9 亿红包。


除了 10 亿现金红包,快手为这次春晚投入的还有集卡活动的 1 亿现金,以及支持当天春晚的 10 万台(其中包括 2 万台云端)服务器。


除了真金白银的投入之外,人力上也是一场“豪赌”。InfoQ 记者了解到,快手春晚红包项目组特意在开始筹备时去找百度、阿里的同学取经。“夸张点说,我们人力上比人家少了一个零。”


春晚红包项目在快手内部的代号是 A1,这个名字源自快手在北京西二旗的总部楼栋排布。快手总部园区有 ABCDEF 共 6 栋办公楼,各个团队的工位分散在这 6 栋办公楼里,而在春晚红包项目确定以后,为了工作上的协同顺畅,整个项目攻坚组在 A 座开辟出了春晚战场,包括设计、研发、产品等成员都聚集在这里。因为项目的参与度很广,出于严格的保密考虑,最终将春晚项目的代号定做 A1,也契合了春晚红包这个项目的重要性。


“从爬泰山到登珠峰”


罗振宇在 2019 的跨年演讲中曾提到:得到原本打算在春晚投放广告,但是被劝住了,因为有一条不成文的规定——要想春晚打广告,产品日活先过亿。原因很简单,用户量过低,技术很难支撑起春晚级别的高并发流量。这也是最近几年,春晚红包项目被互联网豪强 BAT 三家垄断的原因所在。


  • 2015 年,微信与春晚首次合作,当晚八、九点左右有短暂时间的微信与红包宕机。此后的每个除夕,微信红包都曾出现不同程度的宕机问题。

  • 2018 年,淘宝接过了春晚活动大旗,以 2017 年双十一容量为基础对登录扩容 3 倍,却在 15 倍的流量面前败下阵来。

  • 2019 年,百度春晚红包活动主站相对平稳,第三方应用商店却在汹涌的流量面前全线宕机。

  • 2020 年,快手接下了春晚战旗。


面对春晚的顶级流量,即使平时服务亿级日活用户的快手,内部也将 A1 项目称之为“从爬泰山到登珠峰”。


这不是快手与春晚的首次合作,但作为春晚红包活动的承接者,却是快手的第一次。对春晚而言,这同样是一次全新的体验,因为春晚红包第一次走入了视频红包时代。在除夕当晚的央视春节联欢晚会上,快手以“点赞中国年”为红包互动主题,推出 5 轮抢红包活动,并采用“视频 + 点赞”的全新玩法。不过玩法新代表着挑战也新,快手独特的短视频场景业务所带来的挑战在春晚流量面前愈加凸显。


首先,看下快手这款 App 的属性。快手 App 所代表的短视频社区类 App,一直有着用户粘性高、使用时间长的特性。每天大规模的视频作品发布和播放,还有实时的直播和用户互动,对流量而言上下行压力已经不小,而这些流量在快手机房中都是共用的,这对春晚活动在架构设计方面提出了更多更高的要求。


其次,短视频 + 直播场景,相对往年春晚活动,对于资源尤其是 CDN 和带宽的占用率更大。 在一定时间内,中国 CDN 总量和商用带宽资源的供应总量相对是稳定的,但视频红包场景下,数亿人同时打开动辄数十 M 的视频文件,还有数千万用户同时涌入春晚直播间,所需要的资源,比起往年春晚要超过几个量级。如何预估春晚流量,设计技术方案减轻压力?如何精准计算需要采买的服务器、CDN、带宽资源?在除夕全网资源吃紧的情况下,这是一大难题。


第三,活动策略与第三方沟通难题。今年的快手春晚,除了冲击 3 亿 DAU 的目标以外,同样也有产品拉新的战略考量。2019 年百度春晚拖垮了包括 App Store、微信应用宝在内的各大主流应用市场,影响了百度的拉新目标。今年的快手势必不愿重蹈覆辙,但第三方应用市场,尤其是 App Store 和微信,沟通更加困难,却是木桶中那个不得不解决的短板。


春晚红包立项,面对这场硬仗,怎么整?


万变不离其宗,却又不可同日而语


中国互联网圈有一句戏言:没有中国人搞不垮的网站。此言诚不我欺,这个网民人数超过 8 亿的国度,在多年电商大促、秒杀场景、12306 每年春运带来的技术大讨论的洗礼下,科技公司们应对高并发流量的能力逼近了软硬件性能的极限。


纵观最近几年各大厂春晚红包活动,技术向的解决方案可谓万变不离其宗,无非是基础设施(服务器、CDN、带宽)的准备、内部架构的升级(核心链路升级、降级方案)等实现方式。说起来好像很简单,但在极致的流量面前,难度却不可同日而语。


基础设施准备与架构升级


2019 年百度春晚的服务器数量是 10 万台,其中有 5 万台服务器是从百度核心的“凤巢”广告系统下线让渡而来。基于短视频业务对服务器等基础资源的更高要求来看,快手为此次春晚活动准备的服务器数量不会低于百度。需要注意的是,服务器并不单纯是物理机组成,还有相当规模的云服务器,这又多出了跟各大云服务商沟通性能资源的问题。


短视频领域惯用的解决方案是将视频放到内容分发网络(CDN)上,既把视频文件输送到离用户最近的地方,又利用大量 CDN 节点分担用户观看的流量,这是业界成熟的解决方案。但在春晚视频红包的数亿瞬时流量面前,这个方案却是完全顶不住的。春晚主持人口播抢红包的时间节点,预估出来的视频播放瞬时流量会超过中国的 CDN 带宽容量总和,快手预估如果要保证春晚活动的体验,至少需要数百 TB 带宽资源。架构师们需要设计高效的资源预分发策略,并建立准确的带宽预测模型,基础设施建设人员也要做好合理的采买准备。


基础架构一般都是线性演进的,大的基础架构升级频率不会很高,每年也就是小修小补一下。但这次春晚活动,倒逼着快手的架构超前升级了。


基础架构负责人向 InfoQ 记者如此介绍。他是一名老“快手”,2015 年就加入了公司,一直负责基础架构的设计与实现。这次的春晚红包活动他参与了核心架构设计工作。


精心设计核心链路


架构上第一个挑战是让用户顺利“进门”。


日常情况下,用户首次启动快手 App 会有近百次与服务端的交互。可以想像在春晚活动开启时,数亿用户同时启动快手 App 会带来怎样的流量洪峰,如果不做降级处理很可能直接冲垮服务器,这是红包活动面临的一个挑战:如何让用户可以顺利“进门”抢红包,而不是被宕机的服务器挡在门外。


为确保用户“进门”环节的应用启动平稳度过,技术团队在保证主要功能不受影响的前提下,设计了协议降级、频率限制、过载保护、协议瘦身、延迟打散、CDN 兜底、业务逻辑优化等策略,使得系统可以承受亿级别 QPS 的流量冲击,通过 5 道“闸门”层层控制洪流,将发生“洪灾”的概率几乎降为 0。


另外春晚的直播场景随时可能出现紧急状况,比如主持人口播红包时间随时可能调整。为了能在这样的紧急状态下,将核心指令下发到每个用户,快手技术团队为此精心设计了核心指令控制系统,一键式下发,最快可以做到一分钟之内将指令触达所有用户,做到有备无患。


登录注册面临平时数百倍挑战。


从往年春晚红包经验来看,登录注册页面是击穿服务器的又一道坎。登录注册好比是用户拿到红包的钥匙,春晚当天必然有大量新用户注册并登录快手 App,快手预估除夕当晚登录注册页面的挑战可能达到平时的数百倍。为此快手准备了超平时登录峰值数百倍的容量,在增加容量的同时,快手也做了登录流程梳理和简化。从客户端到服务器总共做了几十项优化,为的就是让用户能“秒登”快手 App,拿到红包。


快手 App 登录量的爆发,对第三方服务也是巨大的挑战,比如三大运营商的一键登录、短信网关以及腾讯三方授权都会受到冲击。为了达到预期容量,三大运营商、微信团队分别和快手登录团队一起为春晚定制了服务。


抢红包作为活动核心,如何顶住瞬时洪峰,精准发出 10 亿现金。


大部分用户都会在活动开始的瞬间进入活动并开始抢红包,考虑到快手庞大的用户在线数叠加上春晚口播带来的用户洪峰,这基本是一个极限流量。按照该流量进行设计不仅需要非常高的资源成本,而且要求更高的系统复杂度和容错性。为此,快手针对活动特性做了一定程度用户侧感知不到的打散削峰设计:技术和产品一起做了多项针对性设计和优化,既保证用户的实时参与感,又能确保服务端压力在可控范围内。


一轮红包只有 10 分钟左右,现场几乎没有任何修复调整的机会,团队只能把功夫花在设计实现上,针对各种异常做层层的保护和柔性降级,并通过一系列的故障演练来进行验证。发钱环节同样对系统要求极高,几十分钟内发出 10 亿现金,还不能有 bug,架构上团队做了很多精心设计,比如保证核心操作的幂等性、多维度预算控制、多种熔断检查、根据流量动态调度发钱速度等能力。


短视频领域常用的视频分发方案都是把视频放到 CDN 上,让 CDN 去扛流量。这没什么毛病,但遇上春晚级别的流量,它就浑身都是毛病。


记者了解到,在全网 CDN 总容量有限的前提下,音视频技术团队设计了大规模资源预分发方案,将视频提前预缓存到客户端、而非 CDN 上。针对如何优化预分发资源覆盖率,如何控制带宽使用量,如何控制下载速度和实际保障用户体验,春晚当天视频素材发生变更如何处理,内容泄露风险如何规避等挑战,做了一套完整的解决方案。同时针对可能出现的用户无法播放视频的极端情况,也设计了一套降级方案:自动将视频转换为低码率或图片模式,做到用户侧弱感知或无感知,保障核心红包环节的用户体验。


除夕前一天提现页面增加“助力武汉”红包捐助功能,短时间内完成高速路上换引擎。


另外据快手研发团队相关负责人告诉 InfoQ 记者,春节前期,新型冠状病毒肺炎疫情形势严峻,牵动着每一个人的心,正在准备春晚项目的快手团队商讨之后决定在提现页面增加“助力武汉”的红包捐赠功能,用户可以选择将红包金额捐助武汉,快手在此金额的基础上配捐 10%,平台联合用户一起助力武汉抗击疫情。确定上线该功能已经是除夕前一天的凌晨,留给开发的时间非常紧迫,经过连夜的开发测试,初一早上 6 点该功能如期上线。


重保稳定性


根据墨菲定律,假设光纤被挖断的极端情况一定会发生,我们应该怎么办?


这是快手同学在一次次演习中,预想的极端场景。虽然这样的场景听起来有些“疯狂”,但为了保证春晚那一刻的绝对可靠,团队需要把所有异常和灾难处理都考虑进去。据了解,快手春晚所有核心服务都设计了多机房容灾,在任何单机房或专线故障的时候保证不影响活动。基本所有能想到的异常都有精心设计降级方案,做到层层兜底,力求万无一失。


春晚所有预案都依赖于配置下发系统,它必须做到将配置低延迟、高可靠地投递到每一个节点。


在服务端的优化方面,对整个上报链路的监控体系全面升级。快手现有的服务上报链路是一个多维度、高复杂度的系统,服务的调用量级随着流量的上升可能呈倍数增长。核心思路是在上报过程中做压缩和降级,将不重要的数据做归并,将异常、高延迟数据上报,减轻系统压力。


配置下发系统也有一整套的监控、加固体系,核心思路是对配置做分级,在系统内多层下发,最终做到进程内缓存,每台物理机都有缓存,一旦出现故障,起码能拿到一份上一次的数据。


如果春晚是大考,那么全链路压测就是模拟考。


全链路压测是应对高并发流量洪峰的“核武器”,所有服务的高并发能力都需要通过压力测试来确定和验证。除夕活动前的多轮压测经历了从小到大,从单接口到单集群再到全链路的过程。全链路压测对整个团队来说,并不是简单的 QPS 增长,更多的是资源协调、风险把控、结果评估等综合方面的考验。其目的就是让春晚当天应该发生的流量,提前发生,并且验证系统在该情况下表现是否良好。一次一次的验证,一次一次的优化,最终确保春晚高并发能力万无一失。


在进行抢红包的全链路压测中,不但要验证系统的高并发能力,还要精确控制并发逻辑,保证红包分配策略正确。在很多场景下,全链路压测不但需要担负高并发性能校验的职责,还要确认超高并发条件下功能是否符合预期。


客户端优化优化再优化!


春晚活动流量是一把双刃剑,对于技术团队来说是一座珠峰,但对产品拉新而言,不啻于坐上了一艘快速升空的火箭。对于客户端团队的同学们而言,如何把安装包极限瘦身以减小应用商店 CDN 压力,并提升用户下载安装速度、梳理出客户端的降级方案、适配复杂的用户机型,也是一大难题。


经过一个多月的努力,团队通过资源压缩、转移到 CDN、使用上云工具等十八般武艺,让客户端的安装包瘦身超过 30M,启动时间降低了 30%。做到了资源、图片的预下载覆盖率超过 95%,提升了新用户的产品体验。


在系统里放一只“猴子”,可劲闹腾吧!


业界常说架构要做到高并发、高可用。高并发很好理解,高可用却很难衡量。究竟什么样的高可用设计是行之有效的呢?在此以前,这是一种薛定谔的状态,只有真到出问题的时候,才能得到验证。“准备工作再足,也无法完全模拟春晚的突发高流量,这意味着考验我们的机会只有一次。”快手的做法是用混沌工程的理念做故障注入,核心思路是在包括单机、服务在内的所有服务器上随机注入不同级别的故障,去模拟部分机器高负载、高延迟导致服务器宕机或半死不活的状态,从而检测高可用设计是否行之有效。


音视频的保障


互联网的光鲜亮丽好像都在灯红酒绿的城市之中,鲜为人知的是,中国农村网民的规模已经突破了 2.25 亿。在中国农村智能手机上网已经前所未有地普及,但千元机型仍是主流。此外,不同地区互联网普及程度不一,网速快慢有别,山区和城市的信号不可相提并论,不同机型在性能、屏幕分辨率等方面都存在大大小小的差异。同一个视频、直播间下,如何让这些变量不一的网民都能享受到种种限制条件下的最佳体验效果?


快手音视频技术团队利用工程结合算法、数据驱动的理念,从移动端到服务端进行无死角的音视频体验优化。用户在任何地方用任何设备,都可以顺畅地拍摄、制作、上传视频。


此次春晚快手红包的核心玩法是:五轮口播时刻点赞一支 45 秒钟的视频,并领取红包。为了保证口播时刻每个用户都可以流畅地观看视频,快手音视频技术部联合 Y-tech 实验室,将视频播放与复杂的动效、音效渲染结合起来,把性能优化到极致:即使在最低端的手机上,也能够在保证播放视频零卡顿前提下,同时流畅的进行领红包特效互动。


此外,在峰值流量时,把几十 M 大小的 45 秒视频分发给数亿用户也是不小的挑战。为了这一目标,快手采用了智能视频压缩算法,对数十段视频内容做画质增强和压制。


口播时刻播放的视频素材取自数百位快手用户的 UGC 素材,画质参差不齐。为了保证每一帧的播放效果,需要人工识别各种画质问题如模糊、块效应、偏色等,通过算法优化到主观最佳状态,最后针对不同的内容和场景复杂度,再输出尽可能小的视频文件。为此音视频团队配合内容团队不断更新素材,视频素材压缩和分发工作一直持续到除夕前一晚。


最终,除夕当晚互动次数达到破纪录的 639 亿,单分钟视频播放次数过亿。


此外,快手 App 对春晚也进行了全程直播。海量用户涌入活动页面等待红包期间,或者抢完红包回到主页后,大概率会进入直播间观看春晚节目。



为了保障超高并发直播的稳定性和质量,直播团队做了大量工作。首先是信号源,主力源采用央视官方信号,备用源从有线电视到卫星信号准备了多路,甚至在员工家里都架设了备用信号采集设备。各路信号汇总到播控作战室,由一个专门团队负责重点保障,保证在任意信号源故障时无缝切换到备播源。在直播分发方面,快手调集了全网的一线 CDN 资源,通过大数据精准调度和质量监测,保障用最高质量的直播流覆盖全国乃至世界各个角落。


除夕当晚,快手春晚直播间累计观看人次 7.8 亿,最高同时在线人数 2524 万。


沟通!沟通!沟通!


从 2015 年微信开始做春晚红包起,每年春晚的应用商店都会受到海量下载请求的冲击,出现不同程度的服务不可用,我们今年希望他们能够抗住压力。


应用市场是春晚活动的一扇大门,如果新安装用户在这一步卡住进不来,就不会有机会参与后续红包活动了。快手今年有专门负责与第三方应用市场沟通的团队,力保应用商店不出问题。这并不是一件容易的事情,国内应用商店比较碎片化,安卓主要有华为、小米、OPPO、Vivo、魅族、腾讯应用宝等,再加上苹果 App Store,一共七家比较成规模的应用市场需要逐一沟通。


有的应用商店说:这有啥可准备的?基本准备不了。


准备不了也得准备,为了保住应用商店不挂,该团队挨家挨户地扫了一遍各大应用商店。这里的问题在于,App Store 在国内没有太多商业化,还需要跨国协作难度比较大。


于是团队带着完整的方案一起去拜访了 App Store。春晚流量是什么级别的?应用商店的瓶颈在哪儿?技术层面的后台架构是怎么样的?几乎把应用商店在这次春晚活动面前要用到的技术全面盘点了一遍,并且将快手自研的曲线拟合技术背后的数据和逻辑共享给了应用商店。


为了保住应用商店,快手团队需要分资源(CDN、带宽),给人手(提供技术支持),给方案(讲清完整的活动逻辑)。


我们不是说应用商店点头了就放心了,而是要看到对接的技术部门真的接到需求了才能安心。


在公司内部,沟通同样不是一件简单的事儿。


启动优化环节的两位负责人,其中一位同学刚入职快手两周就被拉进了 A1 项目,另外一位则是快手“老司机”。这个组合的关键工作之一是与各个业务线沟通,把设计好的降级方案落地下去,死保春晚活动的红包服务,把其他相对不重要的接口“全部干掉”。


这个组合在与各个业务线沟通的过程中遇到了很多挫折,但最开始的沟通问题却是出现在他们内部。那位“老司机“在采访的时候笑着说:“最开始的时候可烦他了,刚来啥都不懂还指指点点。”随着项目的深入,两人信任度逐渐加强,项目团队形成了强大的凝聚力:“胜则举杯相庆,败则拼死相救”,两人互相扶持前进,在一个多月的时间里梳理完了业务线涉及启动的近 100 个接口,只留下了个位数的核心接口不做降级。


沟通方式可以有两种,一种是强势的一刀切,另一种是深入到业务里面去,友好沟通。虽然后者实施起来更费劲,但我们还是决定跟业务同学耐心沟通。“钉子户”还是有的,最终我们是靠着更高层对齐了目标,推进了下去。


与业务方“斗智斗勇”,把近 100 个接口干到只剩个位数,这是外界认为不善沟通的技术人,沟通出来的成果。


一些人的红包战,14 亿人的春节


每年的春晚红包活动,都有各大互联网厂商旗下开发、产品、项目、设计人员们忙碌的身影。这个团队的规模不可谓不大,有的甚至机房值班人员就能有 500-1000 人。但在 14 亿人的春节传统面前,这些人却又只是沧海一粟。


IT 技术的价值在于,放大了个体的声音与价值,让每个渺小的人都能发出更大的声音,让这些千人规模的团队可以支撑十多亿人的高并发热情。春晚活动发展至今,其背后的技术实力、巧妙的解决方案已经不再是最重要的核心,这群互相扶持、一起攀登珠峰的人和他们背后的故事才是。


这次春晚红包大战开始前,我们对每一个接受采访的快手技术专家都问了同一个问题:“你对这次春晚红包活动有多少信心?”受访者坦言,备战春晚就像跟一群学霸一起准备高考一样刺激,可能一开始信心只有 50%,随着准备越来越多,信心增加到 70% 以及增加到更多;到了备考最后一段时间,觉得该做的事儿、能做的事儿都做了,就差考试了。


虽然内测、公测能提前发现一些问题,但春晚当夜高达数亿 DAU 的流量却不可能在前期完全模拟出来,这是一场只有一次机会的技术大考。对于每一个参与其中的技术人来说,所能做的就是守在电脑前面,等待每一次流量尖峰的到来。


快手交卷了,你呢?


2020 年 2 月 11 日 15:40 2639
用户头像
小智 InfoQ 主编

发布了 388 篇内容, 共 301.0 次阅读, 收获喜欢 1636 次。

关注

评论 2 条评论

发布
用户头像
这个真是不容易啊,中间虽然稍微断了一下,整体来说还好
2020 年 02 月 11 日 21:45
回复
极客邦小伙伴们写的文章很专业,点赞!
2020 年 02 月 12 日 09:32
回复
没有更多评论了
发现更多内容

架构师训练营第四周作业

Geek_2dfa9a

架构师训练营第四周学习总结

赵凯

互联网架构设计

区块链系列教程之:比特币中的共识

程序那些事

比特币 区块链 共识与信任 分叉

week04总结

seki

系统架构知识总结

史慧君

关于系统架构学习总结

imicode

揭秘金山云云游戏PaaS服务平台背后的视频编码技术

Geek_116789

Homework- 典型的大型互联网应用系统

River Tree

Homework 大型互联网应用系统

第四周学习总结

天之彼方

第四周-命题作业

天之彼方

week3课题作业

架构师训练营 0 期第四周

Blink

架构师训练营第四周课后作业

赵凯

高并发 高并发系统设计

大型互联网系统技术总结

dapaul

极客大学架构师训练营

架构师训练营第四周作业

极客大学架构师训练营

如何做互联网系统架构

dapaul

极客大学架构师训练营

架构师训练营第 4周 _ 课后作业

方舟勇士

课程作业

week04作业

seki

【第四周】命题作业——大型互联网系统的技术解决方案和手段

三尾鱼

极客大学架构师训练营

Redis系列(四):天天用着Redis集群,主从同步该知道吧?集群工作原理是否需要了解下?

z小赵

Java redis 高并发 高并发系统设计

大型网站技术架构--概述

wei

架构师训练营 第四周 学习总结

亮灯

架构师训练营总结 -4

River Tree

极客大学架构师训练营 学习总结

架构师训练营第4周作业

aoeiuvzcs

架构师训练营第 4 周 _ 学习总结

方舟勇士

课程总结

点赞功能,你用 MySQL 还是 Redis ?

Java小咖秀

MySQL redis 分布式 分布式系统 经验

大型互联网应用系统使用技术方案和手段

wei

想解耦必分层

菜根老谭

程序员 架构思维 分层思维

第四周总结

安阳

架构师训练营第四周总结+作业

林毋梦

一个典型的大型互联网应用系统使用了哪些技术方案和手段

史慧君

2020中国技术力量年度榜单盛典

2020中国技术力量年度榜单盛典

春晚红包:史上最难开卷考试,快手交卷了-InfoQ