优才点评版：架构师们是靠什么扛住了10亿个红包？

编者按：

微信这么大的流量，尤为是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，咱们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的公共帐号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上仍是至关地有学习的价值 ，优才学院做为培养全栈工程师和将来架师的团队，转载并加以注释，分享给你们。
进入抢红包环节，后台数据瞬间飙升400倍的挑战
今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来讲是一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已是2014年除夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！

发10亿红包，难在哪里？

微信团队总结下来有三大难点：
快——如何保证用户快速摇到红包？
准——如何保证摇到的红包能成功拆开？
稳——如何保证拆开的红包能分享出去？

大量用户在同一时间摇红包，瞬间产生每秒千万级的请求，这个量级的请求若是不加以疏导处理直接到达后台，一定会致使后端服务过载甚至崩溃。上文中除夕当天后台监控数据曲线便能说明一切——在前台重重的分流减压下，后台服务器负载仍然瞬间飙升十倍以上。

**

三大应对策略齐上阵

**
对于以上三个难点，微信后台开发团队主要经过三大应对策略应对：有损服务，柔性可用，大系统小作有损服务-追求高可用和快速响应。

什么是有损服务？有损服务是经过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特点运营策略——在资源必定的前提下，互联网条件变幻无穷的场景中，量力而为，知足用户的核心需求。

微信红包的核心点是摇，拆，分享红包，整个系统设计时必须尽最大可能保证这三个步骤一鼓作气，任何关联系统出现异常的时候立刻进行系统降级，防止引发系统雪崩
。
系统降级能够分为两个方面，一是把核心功能进行分拆和简化，经过辅助轻量化的服务实现，确保最短关键路径的可行，比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再传到红包服务的后端逻辑，下降雪崩的可能性。

点评：有损服务就是让重要的事情先作，重要的人物先行。这在现实中也很常见，军人买票优先，领导视察封路，让领导车先行，我等小民等待也是这个路子。

同时后端采用异步分拆，接收到用户请求时仅进行合法性验证，验证完成后直接告知成功，后续业务逻辑进入异步队列进行处理，减小了用户的等待时间，也极大下降了峰值雪崩的几率。

耗时最长的入帐操做，直接跳过，异步处理

另一方面是采起过载保护措施：
微信红包的过载保护在客户端已提早预埋了策略，在链接失败或超时状况下会有相应提示，减小用户重复请求次数。接入层面也会进行自我保护，针对频繁发出请求的客户端限制响应速度，并对系统负载划分出若干等级，达到不一样阈值时引导客户端使用不一样限速速率；在异常状况出现时，采起减小红包数，异步限流下降拆/分享红包的速率等措施减轻服务器端压力；与此同时，微信红包还有全程压测流程，对整个业务连接进行自动提早评估，防止过载。
点评：在前端挡住对后端流量的进入，好比出现通讯失败时，当前这个用户，对后台已经不会有什么压力了。

这画面你可能没见过，它其实早已在手机待命

在有损服务思想的重重保护下，第一波的摇红包体验活动中，微信红包几乎满分经过考验，其中过载保护的做用至关明显，在客户端、接入层层减压、过滤，最终仅把十万级压力传递到后台。
柔性可用-细化场景把握核心需求。
柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别不一样的用户体验场景，保证尽量成功返回关键数据，并正常接受请求，毫不轻易倒下。
柔性服务更具备产品的思惟性质，意义在于深入理解产品每个场景的核心价值，把握用户在每个场景中的核心需求，设计不一样层次的知足核心诉求的办法，对柔性服务在微信红包中的实践，红包团队也有相应的措施，主要能够分为几大类。
一、系统容灾：
面对大规模的请求量，系统容灾必不可少，容灾通常可分为逻辑层容灾和数据层容灾，此次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核心服务都能作到最多1/3服务器出问题的状况下自动容灾切换以保证服务质量，提升预警级别换取系统的可用性。
二、资源隔离：
顾名思义就是把资源进行隔离减小服务支路间的影响，从逻辑入手，在资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意一个支路出问题影响整个服务链条，这样即便部分服务出现问题也不会影响到整个服务的崩塌。
三、快速拒绝：
当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解决，成本越低，影响越小，前端保护后端的方式来解决问题。

点评：这里面须要指出一点的是，客户端跟Web 系统不一样，作这种操做的前提，是提早预计到关键路径，在客户端的版本更新中，将相关的指令和策略埋入，当接受数据获取异常时，在客户端自动就下降请求频率，好比一次请求失败，用户确定想二次再刷，可是可能实际上没有向后端请求，而是直接返回，请客户稍安勿躁，若是不提早埋入，到有问题时才处理是来不及的。
四、支付分组：
从支付环节入手，将全部红包分为50个组，放在50个单独的set上互不影响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔性可用的一个重要技术手段，这一思惟很是相似于现实生活中的集装箱思惟——经过标准化，规模化的箱体设计，应对复杂多样的货物，使每一个流通环节既独立又不失灵活。
五、流量预加载：
从客户端入手，将语音图片等极消耗流量的资源提早让客户端自动下载预置好，提早将流量洪峰疏导，并在活动当天CDN将准备数百G带宽应对，这块也与过载保护中的快慢分离是相通的，将耗流量的服务提早加载避免高峰期间的冲突。
点评：这是提早准备，从各个路径上，把缓存用到完全。

**

大系统小作-保证进程的功能单一

**
大系统小作应该来讲，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小，减小模块耦合，下降关联性，用多个独立的模块来实现总体系统的功能，大系统小作采用的是化繁为简，分而治之，便于开发和迅速实现。
微信红包如此庞大的后台系统，模块也至关之多，而此次的模块微信开发后台团队采用了系统高度模块化的方式，分红一个个高度自制的小系统，造成高内聚低耦合的格局，每一个模块之间不会过度依赖对方，这样的好处是不会由于任何一个模块而影响所有服务，避免牵一发动全身的风险，实现真正的灰度服务。
点评：下降耦合，增长问题处理时的难度和平时的可维护性。

**

海量服务能力决定成败

**
从2014的滴滴打车，到2015的微信红包，腾讯用一个个案例，去证实自身在海量服务方面的实力。事实上，真正支撑起微信红包顺畅运营的幕后英雄，正是腾讯内部一个叫作“海量之道2.0”的技术体系。有损服务，柔性服务，大系统小作三大手段也是脱胎于此体系中。移动互联网大战硝烟味愈浓，BAT都在为争夺支付入口使出浑身解数，在业务从起步到小跑再到腾飞的过程当中，巨头背后的海量服务能力将对其最终成败有着来愈加深远的影响。

**

总结：

**优才学院一直坚持一个观点，尽管是在移动互联网时代，可是客户端应用开发自己，并非体验的决胜之处，真正对团队挑战的地方，还在于后端，不管是承压能力，仍是安全性等方面，若是这些地方过不了关，整个应用的基础是不扎实的，咱们也认为，技术能力是应用的骨架，若是技术能力，或者说后端能力不强，应用在长到必定程度也会支撑不下去。固然可喜的是，如今有了不少云服务，从Iaas 腾讯云、阿里云，到Paas SAE，另外还有专业的存储云服务，好比七牛，甚至对于代码级服务质量监控 APM 厂商也出现了，国内作得最好的是 OneAPM， 这些服务必定程度上能下降团队的技术要求，以及在平时，能发现本身服务中所存在的问题。进行及早准备。