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日收到百度春晚要发红包的消息后，百度技术团队首先要想的问题是，如何搭建春晚红包的技术框架，原因很复杂。
