微信巨大的流量，尤其是瞬时峰值，对任何一个团队和架构师来说都是一个很大的挑战。我们也在想，微信团队会用什么方式来处理抢红包的流量，正好今天腾讯大讲堂的公众号发了这篇文章。虽然没有介绍具体的技术细节，但是在宏观策略上还是有相当的学习价值的，分享给大家。400倍的挑战今年的微信红包方式与去年用户之间互换红包相比，摇红包的方式在业务量上是一个巨大的爆发。仅除夕10点30分发出的红包浪潮就达到了1.2亿个红包，已经是2014年除夕峰值的400倍（高峰时每分钟打开的红包数）2014年仅为2.5W）！进入抢红包阶段，后台数据瞬间飙升，发放10亿红包。有什么困难？微信团队总结出三大难点：快——如何保证用户快速摇红包？准确——如何保证你摇的红包能成功打开？稳定——如何保证打开的红包能被分享？大量用户同时摇红包，瞬间每秒产生千万级请求。如果这种数量级的请求没有经过通道就到达了后台，那肯定会导致后端服务过载甚至崩溃。上面跨年夜的后台监控数据曲线可以说明一切——在前台的重度分流和解压下，后台服务器负载依然在瞬间暴涨了十几倍。三大应对策略登场针对以上三大难点，微信后台开发团队主要采用三大应对策略：有损服务、灵活可用、大系统小有损服务——追求高可用和快速响应。什么是有损服务？有损服务是将产品流程仔细拆分，有选择地牺牲部分数据的一致性和完整性，以保证大部分核心功能的运行。这是腾讯在PC时代积累下来的特色运营策略——在一定资源的前提下，在瞬息万变的互联网条件下，力所能及地满足用户的核心需求。微信红包的核心点是抖音、拆解、分享红包。在设计整个系统的时候，一定要尽量保证这三个步骤一气呵成。当任何相关系统出现异常时，系统会立即降级，防止系统雪崩。系统降级分为两个方面。一是对核心功能进行拆分和简化，通过辅助轻量级服务来保证最短关键路径的可行性。千万级的请求转化为每秒数万次的红包请求，再传输到红包服务的后端逻辑，减少雪崩的可能性。点评：损职就是让重要的事情先做，重要的人先走。这在现实中也很常见。军人优先买票，领导视察封路，让领导先走，我等老百姓等。同时后端采用异步拆分。当收到用户请求时，只进行合法性验证。验证完成后直接通知成功，后续业务逻辑进入异步队列处理，减少了用户的等待时间，大大减少了高峰雪崩。可能性。耗时最长的入账操作直接跳过，异步处理是采取过载保护措施的另一个方面：微信红包的过载保护策略已经预埋在客户端，一旦出现超载就会有相应的提示连接失败或超时。减少用户重复请求的次数。接入层也会进行自我保护，对频繁发送请求的客户端进行响应速度限制，将系统负载分成几个等级。当达到不同的阈值时，将引导客户端使用不同的限速率；红包数量、异步限流、降低拆/分红包速率等措施，减轻服务器压力。同时，微信红包还有全流程压测流程，提前对整个业务环节进行自动评估，防止过载。点评：在前端屏蔽来自后端的流量。比如当出现通信故障时，当前用户将不再对后台有任何压力。这张图你可能没见过，但它已经在手机上待机了。在破坏服务思想的重重保护下，在第一波抖音红包体验活动中，微信红包几乎通过了考验，过载保护的作用相当明显。client层和access层经过解压过滤，最后只有10万级的压力传给后台。灵活易用——细化场景，把握核心需求。灵活可用性是一种受有害服务价值支持的方法。重点是它会实际结合用户使用场景，根据资源消耗调整产品策略，设计多个层次的用户体验场景，保证关键数据尽可能成功返回，并正常接受请求，永不掉线.灵活的服务本质上更像产品。其意义在于深刻理解产品每个场景的核心价值，把握每个场景用户的核心需求，设计不同层次的方法来满足核心需求。在实践中，红包团队也有相应的措施，可以分为几类。1、系统容灾：面对大规模请求，系统容灾必不可少。一般来说，容灾可以分为逻辑层容灾和数据层容灾。此次微信后台开发团队采用了30%切换的逻辑层方案，即核心服务可以在至多1/3的服务器出现故障时实现自动容灾切换，保证服务质量，提高预警性水平以换取系统可用性。2、资源隔离：顾名思义就是隔离资源，减少业务分支之间的影响。从逻辑出发，在资源逻辑上，当A服务同时向BC服务分配任务时，设置单个最大分配上限，避免任意一个分支出现问题影响整个服务链，这样即使部分服务出现问题，不会影响整个服务的崩溃。3、快速拒绝：当服务过载时，第一时间拒绝请求，服务调用方换机重试，避免单台服务器重试过载。lossyservice中的fastrejection和earlyrejection是概念上的方法，从流程的源头解决问题，解决问题，成本越低，影响越小。前端保护后端解决问题。点评：这里需要指出的是客户端不同于web系统。做这种操作的前提是提前预测关键路径，在客户端的版本更新中嵌入相关的指令和策略。当接收数据异常时，客户端自动降低请求频率。比如一个请求失败了，用户肯定想再刷一次，但可能并没有真正向后台请求，而是直接返回了。请耐心等待，如果不是提前埋起来，等有问题再处理就来不及了。4、支付分组：从支付环节开始，将所有红包分成50组，分别放在50个独立的集合上，互不影响。单个群集出现问题最多只会影响1/50的用户，保证大部分人的业务不会受到影响干扰。组集也是实现灵活性和可用性的重要技术手段。这种思维与现实生活中的集装箱思维非常相似——通过标准化、大型化的集装箱设计，可以应对复杂多样的货物，让各个流通环节独立灵活。不失弹性。5、流量预加载：从客户端开始，让客户端自动下载和预置音频、图片等消耗流量大的资源，提前分流流量高峰，CDN会准备上百个活动当天的千兆字节带宽。区块链在过载保护方面也加入了快慢分离，提前加载耗流量的业务，避免高峰期的冲突。点评：这是提前准备，所有路径都充分利用了缓存。大系统，小操作——保证进程的功能单一。大系统，小操作应该说是一种意识。其核心思想是将功能复杂的大系统分解成小系统，减少模块耦合，减少相关性，使用多个独立的模块来实现整个系统的功能，将大系统和小工作简化、分割和征服，便于开发和快速实施。微信红包这么庞大的后台系统，模块相当多。此次模块微信开发后台团队采用高度模块化的体系，将其划分为高度自制的小系统，形成高内聚、低耦合的格局。各个模块之间不会过度依赖。这样做的好处是所有的服务都不会受到任何模块的影响，避免了牵一发而动全身的风险，实现了真正的灰度服务。点评：减少耦合，增加平时问题处理和可维护性的难度。海量服务能力决定成败从2014年的滴滴打车到2015年的微信红包，腾讯用一个个案例证明了自己在海量服务方面的实力。事实上，真正支撑微信红包顺利运营的幕后功臣，是腾讯内部一个名为“海量之路2.0”的技术体系。有损服务、灵活服务、大系统小运营这三种方式也是脱胎于这个系统。移动互联网大战硝烟渐浓，BAT拼命争夺支付入口。在业务从起步到小跑再到腾飞的过程中，巨头背后庞大的服务能力将对其最终成败产生深远影响。.
