春晚红包的挑战，正是提前练兵的好时机。这场看不见的云计算战争，推动了中国互联网技术整体演进。

2007年，国内情报史专家高金虎出版过一本《看不见的第二战场》，讲述无线电情报与战争的关系。

“看不见的第二战场”，这段话拿来形容BAT春晚红包战背后的云计算技术战再合适不过了。每年的春晚红包战似乎成了BAT的正面战场，三巨头呼风唤雨，在短时间内把红包、福利全都撒出去。

大家明面上能看到是三家发了多少红包、撒了多少现金，背后牵扯到的技术、资源等配置确是错综复杂。

从2014年春节，腾讯就因为“红包”太受欢迎遇到了技术上的“惊险一刻”。2016年、2017年、2018年腾讯、阿里纷纷在云计算战场投入重兵把分布式计算、线上智能容灾这些技术不断普及并逐渐提高。

为支持春晚项目，百度再一次技术进化，让全自动自如扩容缩容，技术体系弹性容器设计，智能调度系统智能感知不同地区资源紧张程度成为日常。

2019年春晚直播期间，百度APP红包互动活动次数达208亿次。还共发出1000万个20.19元的红包，100万个88元红包，10万台小度AI音箱，1万个2019元红包以及若干手气红包。总共邀请全球观众参与共同瓜分了9亿现金红包大奖。

在苹果APP Store、小米应用商店、华为应用商店以及微信红包都在春晚出现崩溃时刻的时候，百度APP历经208亿次红包互动反而没倒。可见背后百度云计算的技术进化速度之快，技术能力之强其他互联网公司均没能出其右。

崩溃不崩溃？这是个问题。BAT春晚红包战背后暗暗较劲的正是云计算技术。它如正面战场背后的情报战一样，看不见摸不着，但却往往起到了决定作用。

春晚“惊险一刻”，家家都要应对

2017年年初，我当时在一家媒体工作时，曾经和腾讯FIT（腾讯支付基础平台与金融应用线）春晚红包技术负责人聊过红包战背后的技术问题。

2014年春节前十几天，腾讯春节红包团队为活跃新年气氛，想到要在微信里加入抢红包功能。一个大约10人，隶属于腾讯FIT技术部门的核心团队主导了开发过程。

春节红包正式上线前，团队内测时便发现，这个“小功能”使用人数远远超过预期：从广州等一线城市开始，发红包的习惯逐渐扩展到二、三、四线城市，直至全国。数据增长得“惊心动魄”，春节红包团队每天都要忙着给红包系统扩容。

春节红包团队当时隐隐觉得，除夕夜可能会出问题，“用户增长量太大了，这个功能一开始架构就是按照小系统来设计的，但临时改动已经来不及了。”

墨菲定律中有这样一条：如果你担心某种情况发生，那么它就更有可能发生。

1月28日，除夕前倒数第二天那个下午，“新年红包”的图标第一次出现在“我的银行卡”界面中，微信红包潮随即引爆全国。

惊险瞬间在除夕夜一触即发，春节红包团队迅速启动了过载保护。过载用户想发红包时，系统会提示“当前系统繁忙”。除夕夜还在加班的程序员们就像是交警一样，在一条堵死的十字路口上不断控制流量。

幸好，当时腾讯FIT技术团队临时调来了10倍于原设计数量的服务器，最终有惊无险地扛住了考验。

此一役后，安全、容灾、性能成了每个春节红包团队需要长期考虑的问题。在2016年以后，腾讯FIT技术逐渐为春节红包构建了一套“多点多活、多地多中心”的分布式交易系统。

后来的微信红包、支付宝红包背后的云计算团队每年都需要“一把屎一把尿”，不断改进春晚红包的技术框架，除夕这天加班加点避免红包宕机。

创业邦在2017年就曾以《支付宝17年新春红包技术体系剖析》一文介绍蚂蚁金服技术团队在春晚前的技术准备，其中这样一段非常值得注意：

蚂蚁金服在终端上采用了限流无感知、资源预下载、用户操作数据缓存、开奖时间离散、数据项与开关动态配置等稳定性操作；在服务端，进行了全链路梳理、全链路压测、限流保护、应急熔断机制等。

百度今年也不例外。2019年1月4日收到百度春晚要发红包的消息后，百度技术团队首先要想的问题是，如何搭建春晚红包的技术框架，原因很复杂。

百度APP不像微信是个日常应用，它是一个刚需但低频的工具型APP，用户用完即走，不会保持长时间在线。但在春晚期间，用户抢红包、集卡会使得使用时长、操作频次大大提高。

同时，春晚红包涉及百度数十个产品、数百个操作场景，这会给百度APP带来高并发、大流量，同时给百度云的服务器、带宽等技术基础设施带来巨大冲击。后果可能是用户打开百度APP缓慢，无法登录账号，点击界面无反应，甚至白屏，更别说抢红包。

因此，百度技术团队需要梳理的问题很多，甚至比腾讯FIT、阿里云团队更要繁琐：

1. 需要针对本次春晚的突发需求，让外网骨干网可以支撑大带宽快速接入；
2. 技术方案确定后，还要解决资源供应问题。比如要在2周内采购到货3000台服务器。还需要运营商资源为百度核心IDC提供近10T带宽和数十个CDN节点等资源；
3. 准备时间过短引发运营商资源提供方面的许多问题，比如商务部门需要和50多个城市的CDN运营商资源紧急谈判；
4. 外部对接结束之后，内部技术团队还需要进行资源部署、系统联调、压力测试。

可以说，2019年以前，几乎每一个春晚红包团队，都会遭到炼狱一般的技术考验，从腾讯到阿里无一幸免。然而，2019年春晚，百度APP的“零宕机”纪录是互联网公司的首创。

你开心抢红包时，程序员却在心惊胆战

春晚时，每一个人都在开心抢红包。你以为只是页面偶尔卡顿了一下、网络延迟了1秒，实际上背后有着无数个技术团队的“紧张时刻”。每一个程序员都是心惊胆战，时时刻刻准备着对系统进行抢救。

对于2019年的春晚红包而言，期间也是考验频频，而背后的百度技术团队总算让这场红包狂欢有惊无险。

简单说，春晚红包带来的技术难点基本是这几个：不可预见的峰值流量瞬间涌入，红包系统架构复杂带来了协调成本，春节返乡导致地区间流量资源分配要临时调整。

1. 不可预见的峰值流量瞬间涌入

淘宝春晚项目技术负责人此前在2018年春晚淘宝多次崩溃时曾出面解释其中的原因——我们真的对春晚的力量一无所知。

以2018年春晚为例，当时淘宝是那年春晚的主角，主要策略是绑亲情账号、发红包。技术团队很早就预估到了登录系统压力。当时基于一些历史数据推导出了极端情况，最终决定以2017年双十一的容量为基础，对登录数扩容3倍。

结果，春晚当晚登录的实际峰值超过了2017年双十一的15倍，尤其新用户的瞬时登录更是完全超出预料。

可以说，互联网公司上春晚，等于是往下沉市场扔了一颗炸弹——这一次据百度技术部门统计，春晚期间登录值可达到日常用户登录峰值的2500倍。

大量用户在同一时间发、抢红包、点页面，瞬间产生每秒千万级，甚至亿级的请求，请求如果不加以疏导处理直接到达后台，会导致服务过载甚至崩溃。

为完成今年春晚的高并发流量考验，百度提前进行服务流量隔离、系统升级、专线新增以及服务器扩容等工作，完善流量峰值时段的体验，还进行了多轮全链路压力测试和多轮的方案预演。

今年春晚百度APP也的确相对平稳，没有出现崩溃的情况。

2. 红包系统架构复杂带来了协调成本

和淘宝注册、登陆系统还不一样，注册登陆一般只有一次响应，注册登陆之后响应就结束了。今年百度的红包系统更多是支付系统，支付系统的响应次数往往是多次的，而且表面上看，一个红包从发出到抢到时间不足一秒，但背后是在红包业务系统、交易支付系统、零钱账户系统这三个层级之间游走——它需要多方提前沟通测试。

因为一个红包如果是通过银行卡发出，必须要先向银行提出申请，银行会进行扣款，扣款成功后，后台会通知支付系统，红包系统到这时才会把红包放出。在其他用户抢到红包后，又会以零钱形式进入用户账户中。

红包几秒钟现金出出进进，都需要耗费服务器资源，由于资金频繁进出银行，部分银行的技术能力又非常有限，百度也需要和银行前期协调，进行承压测试。

百度工程效率部对用户刚登录APP时的内容加载进行了优化。后台系统还会自动检测流量变化，快速计算资源，智能调度早已准备好的冗余资源，增加系统容量，合理分配带宽。这些措施可以让数亿级用户同步登录APP，正常加载服务，不出现白屏。

3. 春节返乡导致地区间流量资源分配要临时调整

抢红包的指令是从全国不同地区下达的，服务器还需要根据不同地区进行响应。

百度系统部一位负责人就提到，因为回家过年，网民会从一线城市下沉到三四线城市。这使得流量结构发生改变，DC数据中心和CDN带宽不得不进行调整。

阿里云2017年也曾遇到过这个问题，当时的解决方案还相对简单。蚂蚁金服技术专家天镜飞在2017年的一场活动中就曾提到阿里是如何应对流量结构变化这个问题的：

华东1机房和华南机房分别承担40%和60%的流量，并且它们都是非云的机器。在新春红包业务上，支付宝将60%的流量切到华东2机房中，并且将其上云。

此外，在华南机房会部署15%的云机器。也就是说，新春红包业务中，75%的机器是在云上运行的，在活动结束后，流量又会切出。

不过，百度吸取前人教训后，把这种应对策略进行了改进调整：提前规划好了不同地区的所需要的网络资源。通过智能调度系统，分钟感知不同地区资源紧张程度，并进行相对应的资源调度和补给。也就是说，流量资源调度分配更智能了。

在这个系统中，整个体系就像一个弹性容器，可以全自动自如扩容缩容。

云计算从“双十一时代”迈向“春晚时代”

2014年-2019年这6年间，BAT应对春晚红包的技术一直处于进步之中。

从最早的懵懵懂懂、毫无认知，对技术难点预估不足，到后来每年都会提前做好准备，但依旧要靠熔断机制来限制流量。再到今天限制为辅，分布式、自动化、智能化为主，云计算技术不断在演进之中。

• 分布式：红包系统可适性强。高度灵活，能应对多种不同环境。某个部件发生突变，不会影响整个系统。在某些部件失效的情况下，仍然能够应对响应，抗风险能力高。
• 自动化：基于需求预期和流量模式进行自动合理规划，不需要太多人工干预，保持相对较低的运营成本。
• 弹性化：可弹性扩展的资源用量，在高峰期可以根据需求按需所取、弹性分配，系统如同弹簧一般可以根据用户抢红包的需求来自动分配资源。

百度使用这样的技术架构中，使得整个技术保障体系就像一个弹性容器，可以全自动自如扩容缩容。当遇到流量洪峰时，系统智能化调度，快速接入带宽资源，据用户任务的不同，匹配适应的容量。

凯文凯利在《失控》一书中曾提到蜂群的一个特征：

蜂群的能力不会因为其中几个成员的损失而丧失机能……必须从简单的局部控制中衍生出分布式控制，必须从已有运作良好的简单系统上衍生出复杂系统。

这段话拿来形容春晚红包这几年来的技术演进再恰当不过了。

在当年的双十一时代，互联网公司的云计算基础设施用来应付每年一度活动期的瞬时高峰流量，但毕竟运用电商的人还是有限的。在如今的春晚时代，流量有了数十倍的增长，互联网公司需要更庞大的云计算基础设施来应对。

正如我在《春晚红包宕机史,也是半部中国互联网技术进步史》中所说的：

春晚的流量规模，未来可能正是5G和物联网时代的“常规需求”。提前排兵布阵，百利无一害。

要知道，2018年全球有70亿台IoT设备，有机构预测到2020年全球将有500亿台设备同时连接网络，2023年则是有790亿设备连接到物联网。5G时代流量每小时所产生的数据高达数百GB，预计将处理比4G多1000倍的数据。

春晚红包的挑战，正是提前练兵的好时机。这场看不见的云计算战争，推动了中国互联网技术整体演进。

如果说过去的云计算还停留在“双十一时代”。BAT历经的春晚红包战之后，云计算正在迈向“春晚时代”。

#专栏作家#

吴俊宇，微信公众号“深几度”。独立撰稿人，人人都是产品经理专栏作家。关注人工智能、移动互联网以及数码家电的产业融合。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议