w**z
发帖数: 8232 | 1 微信产品经理和架构师们是靠什么扛住了10亿个红包？
2015-02-21新朋友请加产品中国
微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
是相当地有学习的价值,分享给大家。
400倍的挑战
今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是
一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除
夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！
进入抢红包环节，后台数据瞬间飙升
发10亿红包，难在哪里？
微信团队总结下来有三大难点：
快——如何保证用户快速摇到红包？
准——如何保证摇到的红包能成功拆开？
稳——如何保证拆开的红包能分享出去？
大量用户在同一时间摇红包，瞬间产生每秒千万级的请求，这个量级的请求如果不加以
疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。上文中除夕当天后台监控
数据曲线便能说明一切——在前台重重的分流减压下，后台服务器负载仍然瞬间飙升十
倍以上。
三大应对策略齐上阵
对于以上三个难点，微信后台开发团队主要通过三大应对策略应对：有损服务，柔性可
用，大系统小做
有损服务-追求高可用和快速响应。
什么是有损服务？有损服务是通过精心拆分产品流程，选择性牺牲一部分数据一致性和
完整性从而保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特色运营策
略——在资源一定的前提下，互联网条件千变万化的场景中，量力而为，满足用户的核
心需求。
微信红包的核心点是摇，拆，分享红包，整个系统设计时必须尽最大可能保证这三个步
骤一气呵成，任何关联系统出现异常的时候马上进行系统降级，防止引起系统雪崩。
系统降级可以分为两个方面，一是把核心功能进行分拆和简化，通过辅助轻量化的服务
实现，确保最短关键路径的可行，比方说在接入层置入摇红包逻辑，将每秒千万级请求
转化为每秒万级的红包请求，再传到红包服务的后端逻辑，降低雪崩的可能性。
点评：有损服务就是让重要的事情先做，重要的人物先行。这在现实中也很常见，军人
买票优先，领导视察封路，让领导车先行，我等小民等待也是这个路子。
同时后端采用异步分拆，接收到用户请求时仅进行合法性验证，验证完成后直接告知成
功，后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值
雪崩的概率。
耗时最长的入账操作，直接跳过，异步处理
另外一方面是采取过载保护措施：
微信红包的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提
示，减少用户重复请求次数。接入层面也会进行自我保护，针对频繁发出请求的客户端
限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限
速速率；在异常情况出现时，采取减少红包数，异步限流降低拆/分享红包的速率等措
施减轻服务器端压力；与此同时，微信红包还有全程压测流程，对整个业务链接进行自
动提前评估，防止过载。
点评：在前端挡住对后端流量的进入，比如出现通信失败时，当前这个用户，对后台已
经不会有什么压力了。
这画面你可能没见过，它其实早已在手机待命
在有损服务思想的重重保护下，第一波的摇红包体验活动中，微信红包几乎满分通过考
验，其中过载保护的作用相当明显，在客户端、接入层层减压、过滤，最终仅把十万级
压力传递到后台。
柔性可用-细化场景把握核心需求。
柔性可用是在有损服务价值观支持下的方法，重点在于实际上会结合用户使用场景，根
据资源消耗，调整产品策略，设计几个级别不同的用户体验场景，保证尽可能成功返回
关键数据，并正常接受请求，绝不轻易倒下。
柔性服务更具有产品的思维性质，意义在于深刻理解产品每一个场景的核心价值，把握
用户在每一个场景中的核心需求，设计不同层次的满足核心诉求的办法，对柔性服务在
微信红包中的实践，红包团队也有相应的措施，主要可以分为几大类。
1、系统容灾：面对大规模的请求量，系统容灾必不可少，容灾一般可分为逻辑层容灾
和数据层容灾，这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案，即核
心服务都能做到最多1/3服务器出问题的情况下自动容灾切换以保证服务质量，提高预
警级别换取系统的可用性。
2、资源隔离：顾名思义就是把资源进行隔离减少服务支路间的影响，从逻辑入手，在
资源逻辑中，当A服务同时分派任务给BC服务时，设定单个最大分配上限值，避免任意
一个支路出问题影响整个服务链条，这样即使部分服务出现问题也不会影响到整个服务
的崩塌。
3、快速拒绝：当服务过载时尽早拒绝请求，由服务调用方换机重试避免单一服务器重
试过载，快速拒绝和有损服务中的及早拒绝是一个概念的方法，从过程的源头将问题解
决，成本越低，影响越小，前端保护后端的方式来解决问题。
点评：这里面需要指出一点的是，客户端跟Web 系统不同，做这种操作的前提，是提前
预计到关键路径，在客户端的版本更新中，将相关的指令和策略埋入，当接受数据获取
异常时，在客户端自动就降低请求频率，比如一次请求失败，用户肯定想二次再刷，但
是可能实际上没有向后端请求，而是直接返回，请客户稍安勿躁，如果不提前埋入，到
有问题时才处理是来不及的。
4、支付分组：从支付环节入手，将所有红包分为50个组，放在50个单独的set上互不影
响，单组set出问题最多只影响1/50用户，保证多数人服务不受干扰。分组set化也是柔
性可用的一个重要技术手段，这一思维非常类似于现实生活中的集装箱思维——通过标
准化，规模化的箱体设计，应对复杂多样的货物，使每个流通环节既独立又不失灵活。
5、流量预加载：从客户端入手，将语音图片等极消耗流量的资源提前让客户端自动下
载预置好，提前将流量洪峰疏导，并在活动当天CDN将准备数百G带宽应对，这块也与过
载保护中的快慢分离是相通的，将耗流量的服务提前加载避免高峰期间的冲突。
点评：这是提前准备，从各个路径上，把缓存用到彻底。
大系统小做-保证进程的功能单一
大系统小做应该来说，是一种意识，他的核心思想是将功能复杂较大的系统，化大为小
，减少模块耦合，降低关联性，用多个独立的模块来实现整体系统的功能，大系统小做
采用的是化繁为简，分而治之，便于开发和迅速实现。
微信红包如此庞大的后台系统，模块也相当之多，而这次的模块微信开发后台团队采用
了系统高度模块化的方式，分成一个个高度自制的小系统，形成高内聚低耦合的格局，
每个模块之间不会过分依赖对方，这样的好处是不会因为任何一个模块而影响全部服务
，避免牵一发动全身的风险，实现真正的灰度服务。
点评：降低耦合，增加问题处理时的难度和平时的可维护性。
海量服务能力决定成败
从2014的滴滴打车，到2015的微信红包，腾讯用一个个案例，去证明自身在海量服务方
面的实力。事实上，真正支撑起微信红包顺畅运营的幕后英雄，正是腾讯内部一个叫做
“海量之道2.0”的技术体系。有损服务，柔性服务，大系统小做三大手段也是脱胎于
此体系中。移动互联网大战硝烟味愈浓，BAT都在为争夺支付入口使出浑身解数，在业
务从起步到小跑再到腾飞的过程中，巨头背后的海量服务能力将对其最终成败有着来越
发深远的影响。
总结：优才网一直坚持一个观点，尽管是在移动互联网时代，但是客户端应用开发本身
，并不是体验的决胜之处，真正对团队挑战的地方，还在于后端，无论是承压能力，还
是安全性等方面，如果这些地方过不了关，整个应用的基础是不扎实的，我们也认为，
技术能力是应用的骨架，如果技术能力，或者说后端能力不强，应用在长到一定程度也
会支撑不下去。当然可喜的是，现在有了很多云服务，从Iaas 腾讯云、阿里云，到
Paas SAE，另外还有专业的存储云服务，比如七牛，甚至对于代码级服务质量监控 APM
厂商也出现了，国内做得最好的是 OneAPM， 这些服务一定程度上能降低团队的技术
要求，以及在平时，能发现自己服务中所存在的问题。进行及早准备。
来源: 腾讯大讲堂
产品中国 ：pmtooo
加入我们
1、产品中国资深俱乐部：273121797（业内大咖，腾讯PM、京东PM、淘宝PM正等你加入
）入群格式：公司名称-昵称
2、商务合作QQ：24815601422 投稿：[email protected]
/* */
转载自公众号: 腾讯大讲堂
Pageview 4473584 Report |
a******n
发帖数: 5925 | 2 不错
但跟魏老师的车票系统比，
差老远了
【在 w**z 的大作中提到】
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
: 400倍的挑战
: 今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是
: 一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除
: 夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！
|
N******K
发帖数: 10202 | 3 耍赖 这是要诀
【在 w**z 的大作中提到】
: 微信产品经理和架构师们是靠什么扛住了10亿个红包？
: 2015-02-21新朋友请加产品中国
: 微信这么大的流量，尤其是瞬间的峰值，对于任何团队和架构师都是一个极大的挑战，
: 我们也在想，微信团队会用什么样的办法扛住了抢红包的流量，正巧今天腾讯大讲堂的
: 公共账号就分发出了这篇文章，尽管没有从具体的技术细节上介绍，但在宏观策略上还
: 是相当地有学习的价值,分享给大家。
: 400倍的挑战
: 今年微信红包方式与去年用户与用户之间互发红包相比，摇红包的方式对业务量来说是
: 一个极大的爆发，光是除夕10：30送出的一波红包就达到了1.2亿个，已经是2014年除
: 夕夜峰值的400倍之巨（2014年峰值每分钟被拆开红包数量仅2.5W个）！
|
k***5
发帖数: 583 | 4 "比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再
传到红包服务的后端逻辑，降低雪崩的可能性。" 耍赖 这是要诀 |
d********u
发帖数: 5383 | 5 正确。其实就是---我根本不能保证正确，只要没人搞我就好了。
做网站的技术含量之低早就是共识了。
【在 N******K 的大作中提到】
: 耍赖 这是要诀
|
h*******u
发帖数: 15326 | 6 尼玛只有1%通过
最终才100k IO
【在 k***5 的大作中提到】
: "比方说在接入层置入摇红包逻辑，将每秒千万级请求转化为每秒万级的红包请求，再
: 传到红包服务的后端逻辑，降低雪崩的可能性。" 耍赖 这是要诀
|
k***5
发帖数: 583 | 7 数学不仔细，0.1%
【在 h*******u 的大作中提到】
: 尼玛只有1%通过
: 最终才100k IO
|
