微信红包海量运营:发10亿个红包难在哪里?(组图)

　　柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根据资源消耗，调整产品策略，设计几个级别不同的用户体验场景，保证尽可能成功返回关键数据，并正常接受请求，绝不轻易倒下。

　　柔性服务更具有产品的思维性质，意义在于深刻理解产品每一个场景的核心价值，把握用户在每一个场景中的核心需求，设计不同层次的满足核心诉求的办法，对柔性服务在微信红包中的实践，红包团队也有相应的措施，主要可以分为几大类。

　　1、系统容灾：面对大规模的请求量，系统容灾必不可少，容灾一般可分为逻辑层容灾和数据层容灾，这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核心服务都能做到最多1/3服务器出问题的情况下自动容灾切换以保证服务质量，提高预警级别换取系统的可用性。

　　2、资源隔离：顾名思义就是把资源进行隔离减少服务支路间的影响，从逻辑入手，在资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务的崩塌。

　　3、快速拒绝：当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解决，成本越低，影响越小，前端保护后端的方式来解决问题。

　　4、支付分组：从支付环节入手，将所有红包分为50个组，放在50个单独的set上互不影响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔性可用的一个重要技术手段，这一思维非常类似于现实生活中的集装箱思维——通过标准化，规模化的箱体设计，应对复杂多样的货物，使每个流通环节既独立又不失灵活。

　　大系统小做应该来说，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小，减少模块耦合，降低关联性，用多个独立的模块来实现整体系统的功能，大系统小做采用的是化繁为简，分而治之，便于开发和迅速实现。

　　微信红包如此庞大的后台系统，模块也相当之多，而这次的模块微信开发后台团队采用了系统高度模块化的方式，分成一个个高度自制的小系统，形成高内聚低耦合的格局，每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务，避免牵一发动全身的风险，实现真正的灰度服务。

　　海量服务能力决定成败

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