度小满金融的春晚红包「遭遇战」

本文转载自雷锋网，作者王艺。

农历戊戌狗年的最后一夜，晚9点。当爆竹声响彻大地，北京奎科大厦五楼的一间会议室里，却没有一个人笑得出来。大屏幕的光亮直射在每个人紧张的脸上，在场所有人，都目不转睛地盯着流量监控显示屏上一根陡然升起的立柱，眼看着它所代表的数字就要冲破极限值。

“（复盘的）腹稿我都打好了，”眼前这个穿着灰色冲锋衣的男人对雷锋网AI金融评论说，“当时我们已经做好了降级方案的准备。”时隔近一个月再回想起来，王继平的语气显然轻快很多，在刚刚过去的春晚摇红包活动中，他担任春晚红包度小满金融（原百度金融）方面的总指挥。

这根立柱的升起是所有人始料未及的。在春晚主持人对摇红包活动进行第一轮口播的前十分钟，百度App团队给度小满团队打了个电话，说由于百度App瞬间流量压力过大，团队决定在摇红包最激烈的几分钟将红包展示入口暂时关掉。

“当时我就预计到那里会有很高的流量。”王继平口中的“那里”，是那根立柱所代表的百度App卡券包页面，“用户摇完一看，‘哎？我摇到的东西怎么找不到了。’就到百度App各处去找。我们刚好有一个钱包服务搭载在百度App上，理所当然的，大批用户会打开钱包去查看卡券包。”

核心流量产生了严重的分流，大规模流量突然聚集到卡券包页面去了。

“我们当时为卡券包设计了5万QPS，眼睁睁的看着那根柱子飞速涨上去，马上就要打满所有流量。”王继平说，“在那个时间点，你是做不了任何事情的。所有能用的服务器都已经用上了，多余的一台都没有了。”团队能做的，就只有等待流量冲破阈值，激发降级方案。

21,000、22,000……，当数值涨到25,000的时候，增长速度开始变慢。王继平和团队松了一口气，“峰值离我们准备的5万还有一定距离，我们心里这才觉得稳了。”

“走吧，吃饺子去，饺子都凉了。”王继平转头向身边人说。

春晚红包「遭遇战」

当时接到度小满春晚总指挥的大旗，处在风口浪尖上的王继平并没有享受到冲浪的快感。“我们技术人信奉墨菲定律，凡是会发生的事情注定会发生。”王继平说，“从复杂度和概率学角度来说，春晚红包这个项目大概率是要出事的，圆满成功的概率不到1%。”

好的战争是在想要的时间、地点，和选定的对手用自己希望的方式来打，但春晚红包对度小满显然是一场遭遇战。

说遭遇战并非虚言。当王继平知道这件事情的时候，距离春晚当天仅剩一个月的时间。12月28日，央视的春晚项目竞标敲定百度；1月25日，活动上线。刨除掉前期商业协议及方案制定过程，真正留给产品设计和开发测试的时间仅有两周多。

“时间短，是我们当时遇到的最大问题。”王继平告诉雷锋网AI金融评论，“我相信这件事情如果从从容容地做，有细致的准备和明确的分工，一步一步地演练推进，大概率是能够比较顺利地完成的。”

然而此时，时间成为了度小满最大的敌人。“根本没有办法按照常规方式工作”，王继平说，“如果想成功，我们只能寄希望于三点：勇气、协作与实力。”

时间紧凑，业务又复杂。王继平介绍，从他总指挥的角度看，信贷、理财、保险三大业务线的权益需要串联；除百度App外，贴吧、网盘、地图等其他百度系产品对活动的展示推广需要明确统筹；并且不同场景下预热活动和正式活动的时间步调并不一致，导致用户权益领取状态的准确更新及记录成为挑战。

另外，就单个用户来说，需根据其客群划分情况展示不同的权益刺激。以信贷场景为例，有授信的用户、授信未用信的用户、已用信的用户、结清的用户和新用户收到的权益推广是不同的。

“这是一个N乘N乘N的复杂度关系，”王继平说，“每件单独的事情听起来蛮简单，但所有的事情串联在一起，就会变成一个非常庞大的矩阵。”王继平和团队首先要做的，就是为矩阵上的每一个节点有效地设计展现和承接机制，并对相同的展现承接逻辑做归并，把复杂矩阵压缩成一个可执行的线性的任务列表。

除业务的复杂性外，技术的复杂性更是压在王继平心头的一块大石。

“技术的复杂性主要体现在规模上。”王继平说。度小满金融日常面对的系统需求并非用户每天打开几十次的高频业务，因此高并发并不是度小满的日常战事。“我们做金融业务，强调整体的稳健型，信贷和理财等都是低频刚需的业务。”

日常，就算是用户规模达到几百万的时候，也仅需处理上千量级的并发。但春晚当天，在全国互动的规模体系下，上亿用户在同一时间节点涌入系统，这样的高并发事件是度小满从未经历过的。

“常规来说，加机器就能解决规模的问题。但实际上，机器不是说加就能加的。”王继平介绍，“加机器”这件事对整个中后台及前端架构的可扩展性提出了非常高的要求，“是考验基本功的时候。”

在短期内增加系统规模，意味着团队需要面对一个精细的管理问题。究竟需要有多少系统模块，每一个模块需要承载的流量压力到底有多大，怎样为不同的服务、模块分配最合理的资源，这些问题都要仔细作答。

王继平说，团队拿到的机器数量不多。在百度集团为百度App准备的十万台机器中，只有两千台可供度小满使用。其中70%的计算资源需要砸在支付环节上，用来保证绑卡、签约、红包提现等关键路径上的核心业务不出差错。这样一来，留给信贷、理财、保险等业务环节上的计算资源非常有限。

“我们用技术做了大量的迭代优化，在资源并不充分的情况下，尽量做到单机利用率最高。”王继平说。

另外，机器分散在不同的机房，这又带来了另外一个维度的管理问题。怎样做到南北协同，让新增机器尽快完成上架部署；怎样将服务、数据以最快程度进行迁移；怎样保证所有服务在不同机房做同步和备份；怎样在单机垮掉时做百分百的切换……这些问题在短短两周时间内都要得到妥善安排。

技术问题之外，外部合作又遭遇瓶颈。

度小满自身的大后台，包括征信、银行卡四项验证等第三方服务机构，无法配合度小满处理瞬时的大量并发。团队需要设计算法，将用户的集中请求进行充分的缓冲，变成线性、平稳的后端请求，再一一下发。

王继平将这一过程比喻为构建堤坝，当上面的洪水冲下来，堤坝将水缓冲起来，再慢慢地通过一个小的流量将水释放到下一个区域。“我们做了好几层这样的堤坝。”王继平说。

最后的挑战是压测。在一个复杂的系统中，如何进行360度的压测，找出整个系统（而非单个模块）所承担的问题，把设计短板找出来，并加以调节，是非常考验团队基本功的事情。

“我们做到了，还比较合格。”回首这两周克服的重重障碍，王继平说。

断直连后首次大考

1月14日，人民银行“断直连”工作全面完成，切断此前第三方支付机构直连银行的模式，接入网联或银联。

“这意味着新的清算模式和系统架构模式。”度小满支付业务总经理万涛告诉雷锋网AI金融评论，“这个模式一出来，整个行业的很多事情都改变了。”万涛戏称，断直连后的第一个大考，被百度赶上了。

大考的第一道考题，聚焦产品设计。“为了这次大考”，万涛谈到，“我们支付产品大版本就改动了22次。”

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!