春晚红包就像是一只推门的手，门外是未知，门内是创新。
2015年，微信成为央视春晚的座上宾，全民“摇一摇”的红包雨，让电子红包成为春节的新习俗；
2016年，支付宝成为春晚红包的合作方，往年讨论的是有什么新节目，那一年的话题是敬业福和“咻一咻”。
2019年，百度“承包”起猪年春晚的红包，全球观众参与互动红包次数达208亿次，百度系App成为今年红包大战的最大赢家。
今年的春晚也是百度云的一次大练兵，此前从未经历过如此大规模的流量峰值，简单的“抢红包”背后存在三个技术挑战：如何处理极大的临时用户登录量，如何应对瞬时出现的流量峰值，以及如何解决短期的巨大资源需求？
在四个多小时的春晚过程中，一些第三方应用商店纷纷崩溃，百度App没有出现宕机现象，成为第一个扛住春晚红包冲击的互联网公司，百度云近乎完美的结束了这场战役。
抢红包的“丝滑”体验
在海量业务并发的场景里，任何小问题都可能成为大隐患，原生的技术难点无疑是运维的深渊。
不同于往年的是，百度还推出了AI新玩法，语音搜一搜、与明星同框拜年等，多样性的玩法也在考验百度云的AI能力。所幸，在整个春晚的过程中，百度系App的体验足以用“丝滑”来形容：
晚上8点40分，主持人喊出“抢红包开始”的口令时，参与“摇一摇”得红包的用户数迅速过亿，3亿元红包随后被抢光。仅在第一轮“摇一摇”红包中，参与红包互动就多达92亿次。
为了应对第一波流量高峰，百度春晚技术保障部门对登录时的内容加载进行了优化。对于抢红包活动中的出现的瞬间流量洪峰，后台会自动检测变化，快速计算资源需求，智能调度增加系统容量，进行合理的带宽分配。除此之外，百度云在20天的项目筹备期内将短信承接能力至少提升了数十倍。还与运营商合作，在云上部署了一键登录功能，减轻大量用户在第一轮对登录系统的压力。
晚上21点18分，第二轮小视频红包开始，互动次数随即增加到115亿次，对服务器带宽有着极为苛刻的考验。
为了保证小视频红包的用户体验，百度进行了两手准备：一是技术上的优化，对视频、图片进行极致压缩，尽可能降低带宽压力；二是提前规划布局和建设网络资源，比如IDC和CDN在三个礼拜的时间内完成了相当于2018年全年的建设量。此外通过智能调度系统，分钟感知不同地区资源紧张程度，进行相应的资源调度和补给。
晚上22点40分，第三轮的搜索的得红包正式启动，此轮互动还加入了语音搜索的互动玩法。截至23：00，全球观众参与百度APP红包互动次数累计增加到137亿次。
晚上23点30分，最后一轮摇一摇得红包活动开启，用户积极性较第一轮有所削弱，依然有超过70亿次互动产生。
最终统计数据显示，除夕当天百度提供了4轮9亿红包，全球观众参与互动活动次数达208亿次，APP的DAU峰值突破3亿。
春晚红包不宕机的背后是百度春晚技术保障部门提前一个多月的周密规划和准备，每个风险点都匹配了相应的技术解决方案。
比如在扩容IT资源方面，提前规划布局和建设网络资源。而且在时间紧任务重的压力下，北京顺义华威机房在8小时内完成了10000台服务器的物理上架，16小时完成自动化上线交付业务使用，创造了业界服务器交付速度的新纪录。在技术实力之外，体现了百度工程师们高效的执行能力。
智能架构战胜“人肉”
从2015年央视春晚引入红包的玩法开始，几乎所有的互联网巨头都在抢夺红包活动的承办权，但并非所有玩家都似百度这般“幸运”。
站在春晚红包身后的“恶魔”正是宕机，以至于流传着这样一个说法：在春晚上投广告的最低门槛是日活过亿，否则服务器很可能会瞬间崩掉。
早在2015年微信和春晚的合作中，就出现了多次宕机的情况：当晚九点左右微信出现了短暂的宕机，春晚过程中有1.2亿个红包送出，但也有不少网友在社交网络上反映卡顿、消息无法接收、红包发不出去等等。
2016年支付宝拿下春晚合作机会，除夕夜红包活动的总参与人数达到3245亿次，达到2015年春晚互动次数的29.5倍，同样也出现了宕机时刻。
到了2018年，春晚宕机事件已经多次告警，合作方淘宝也提前推导了各自极端情况，并且在2017年双11的基础上扩容三倍。结果却是，不少网友吐槽无法登录注册、绑定亲情号失败、不能组团抢红包等，经历过数次双11挑战的阿里云，也倒在了春晚的流量高峰面前。后来公布的数据显示，春晚当晚的流量峰值是2017年双11的15倍。
宕机的频繁发生，并非是腾讯、阿里没有“一级警备”，相反往往要投入几百人的技术保障团队。春晚红包是互联网巨头们争夺的对象，也是云计算的春节战场，所谓的宕机史，也是云计算的进化史。
坊间流传最广的无疑是阿里双11的故事，早几年的后台保障也普遍被戏称为“人肉”计算。比如2010年以前，互联网公司普遍采用的是IOE系统，IBM的小型机配合Oracle数据库和EMC的存储设备。为了一场双11大考，从年初准备到年尾，可怜最后可能连及格的分数都没有。
一位经历过双11的程序员，形象的还原了那个运维全靠吼、扩容全靠“杀掉”非关键系统的年代：“双11那一天，每个人看自己服务器的系统水位，出现问题吼一嗓子，哪里有空闲的资源调过来，后来容量不够，又把一些非关键系统杀掉。”
再来看百度云在今年春晚的保障，系统随时响应每秒数千万的请求，并支持快速扩展支持更多请求处理，智能取代了“人肉”。有百度技术人员打了一个形象的比方：“整个体系就像一个弹性容器，全自动自如扩容缩容。当遇到流量洪峰时，系统会智能调度，快速接入带宽资源，按照用户任务的不同，匹配适应的容量。”
同时在基础设施层面，百度云的大放异彩与百度早已成熟的网络架构有关。过去十多年，百度网络架构经历了自有业务规模快速增长和To B业务多样需求的考验，具有很好的高可扩展性和灵活性，可以快速调配服务器，支撑快速接入带宽资源，调度系统可以很好的支撑节点的快速扩容，极大的提升了保障服务的可用性和运维效率。
任何奇迹的出现都离不开背后的努力，春晚红包也不例外。
AI To B 小试牛刀
每一场实战，都是对互联网基础设施的一个大考，也是技术迭代的跳板。
正如很多人的观点，没有“黑五”过剩的计算资源，就没有亚马逊押注云计算的决心，没有双11、618这样的电商狂欢节，或许中国云计算的爆发还需要多等几年。同样的例子也出现在云计算的春节战场上，首次迎战的百度云就交出了百分答卷，印证了百度跻身云计算一线阵营的地位，也让百度的对话式搜索、自然语言处理等AI能力曝光在镁光灯下。
我想，其中的受益者不会局限在百度系App，2018年9月份的百度云智峰会上，正式对外推出了兼具深度学习、对话式搜索、自然语言处理等全面AI能力的AI to B平台，并通过云服务框架集成在AI、大数据、云计算方面的能力，帮助企业快速接入云端获取AI能力。
中国互联网上有很多流派，百度恰恰是技术派的典型代表，不宕机的春晚红包，将百度的技术能力完美呈现。而在技术层面的较量背后，一场春晚红包让百度云的AI To B 小试牛刀，注定是整个行业的红利。
网友评论