柔性可用——移动互联网时代的一秒响应秘诀

转自：http://www.cnblogs.com/Kevin-Zhao/articles/4896936.html

移动互联网海量服务有2大特点：每用户收益远低于金融业；业务流量毛刺更加突出，瞬间百倍的业务冲击经常发生。柔性可用将从安民告示、产品设计、技术实现三个方面讨论如何深刻理解业务特点、充分考虑突发和故障，精心设计柔性场景，用低成本提供优雅的海量移动互联网服务。

 

一、0.1度的柔性：如何优雅的做好末日告白

　　末日告白是指产品基本不可用时给用户的安民告示。危险总是发生在我们意想不到的地方，每个产品都需要常备安民告示并定期演练。

关于如何做好安民告示，这里给出一些建议。在协议上建议安民告示相关的服务应该独立部署，跟正常的业务SET分开；相对于业务协议的复杂性，安民告示的协议要尽量简单、可靠、独立；内容方面要说用户最关心的话题，比如账号的安全性，恢复时间等，表达尽量有趣一些；在展示场景上，建议将告示放在产品体验的关键路径上，比如产品的启动界面，产品某一功能的入口，确保用户一定可以看到。

 

二、0.2-0.9度的柔性：硬挺着遭罪、弯弯腰享福

1、柔性的目标

开始之前先讲几个故事。第一个故事是微信红包，在2015春节之前微信红包是每逢高峰必然抽筋，但2015年春节的时候红包流量非常高，表现也非常好。从2015年元旦到2015年春节这段时间微信红包究竟做了些什么呢？

第二个故事：左边是2008年陈老师的作品一面世就引发了qq.com的流量海啸导致qq.com崩溃，右边是马航M370的消息公布之后给QQ.COM带来的流量尖峰更高，但QQ.COM兀自岿然不动。这两次事故之间技术上发生了什么？

第三个故事，2014.01豆瓣盛传QQ某员工因为不满意年终奖愤而格式化服务器导致QQ邮箱崩溃。实际原因是蛇口机房故障3000台服务器出现了问题，导致QQ邮箱瘫痪。我们统计了一下2014年腾讯IDC专线类故障有30多起，服务器的故障有4000多起，为什么只有这一起如此娱乐呢？是巧合么？

第四个故事是2008奥运售票系统，尽管票务中心的同学们此前准备自认为很充分的容量，但售票一开始很快就崩溃了，最后以容军主任辞职收场。

这四个故事带给我们几个问题：微信红包和腾讯网是怎么逆袭的？如何优雅的应对硬件故障频繁发生？如何替容军主任支招？要回答这些问题，我们先看看容主任撞上了哪些忌讳，但被微信红包和腾讯网有效规避。

第一个是“系统雪崩”，一个系统在正常情况下的业务流量曲线应该是平滑的，一旦碰到异常流向曲线可能会变成十分陡峭，尖峰流量一下子超出很多，超出的部分就可能导致系统性能急剧下降，最后导致系统崩溃。

第二个是“用户等待”，大多数人在银行等一个小时都觉得理所当然，但在移动互联网产品的场景下就不一样了，他们会表现出暴怒、狂怒、烦躁，然后是无休止的重刷。结果就是将请求量无限制的放大，把系统推向崩溃边缘。

这两个忌讳都不难想到，一秒响应难在哪里呢？我们之前讲的四个故事对应了移动互联网业务的三种流量模型，微信红包和奥运售票对应的是高峰型，特点是高峰期的业务流量特别高，但峰值时间和大小可预测。马航事件揭示是海啸型，特点是流量峰值与发生的时间与大小不可预测，且峰值往往比高峰型更高。年终奖事件揭示的是故障型，硬件不可靠，故障天天都会有。面对这些流量模型， IOE的解决方案不但成本高，而且扛不住。我们需要符合移动互联网业务特质的方法：柔性可用。

 

2、产品设计的柔性法则

 

2.1、场景还原

它包括：深刻理解产品的核心价值；把握用户在每一个场景下的核心诉求；在每一个核心场景下应该坚持什么，可以放弃什么。看个例子：小明渴了想吃西瓜而家里没有，如果妈妈出去买时间上赶不及，小明哭，但此时小明的核心诉求是解渴，西瓜只是手段，如果放弃手段坚持目标，则一瓶矿泉水也可以解决问题。2015年春节面对可以预计的流量高峰，微信红包团队把摇红包分成两个不同的场景，摇红包和拆红包，摇红包时坚持响应要足够快，放弃了一定要有红包，拆红包坚持响应快和成功，放弃立即入账。

 

2.2、降级服务

它是场景还原分析结果的实际应用。降级服务是在客观条件不满足时的分层折衷，等级划分的粒度与合理性是功力所在。回到小明口渴的例子，在降级服务这个纬度上，除了西瓜矿泉水之外还可以分几个等级，从高到低依次是：柠檬加橙汁，矿泉水，扇子，望梅止渴的故事。还有QQ的例子、红包的例子、QZone相册的例子都是很好的实践。对照三个流量模型中的高峰型和海啸型，降级服务抹平流量尖峰，相对于故障型降级服务可以避免大面积的用户掉线。

 

2.3、局部放弃

如果降级服务相对宏观，需要拉动整个产品体验来看的话，局部放弃则微观一些，它在某一个点上放弃一些体验，而且局部放弃的东西还需要通过其它方法补回来。来看滴滴打车的例子，2014年的时候受春运影响，乘客的付费师傅收不到，20分钟的故障让滴滴付出了60万的代价。腾讯派出的专家团针对滴滴的系统做了一个柔性的手术。效果是在不增加任何设备的情况下系统抗住了75%的高峰请求，为后续的滴滴做更进一步的架构争取了时间。

看这段金融转账的代码， A给B转账全程都使用了严格的事务，非常好非常严谨。但放在移动互联网的环境下就不一定对了，因为耗时会很长、投入也很高。在微信红包的例子中我们把实时入账的环节放弃了，这个简单的动作给我们带来了非常大的自由，更重要的是用户在线的体验非常快。

和降级服务一样，局部放弃可以把高峰期的流量抹平，还可以在故障时避免用户大量掉线。

 

2.4、最终一致

它是局部放弃的有效补充，常常成对出现。回到红包的例子，在局部放弃里说到会延迟入账，实际上大概过了10多分钟红包就入账了，通过这种方式，拆红包时局部放弃，但通过离线的方式实现了最终一致。再看一个例子，A和B聊天，系统把A说的话异步丢给B就返回了，根本没有管B是否有没有收到，这不是砍头吗？回到场景还原来看，A在等了10分钟还没收到B回复时会再发一条，这是B看到了就回复了。这是用户参与情况下帮我们实现最终一致。腾讯手机管家的来电识别也很好的体现了最终一致的法则。

 

3、技术实现的柔性法则

 

3.1、大系统小做

任何大系统都应该是由很多小的、功能相对独立的功能模块组成的，这是一种复杂系统的架构能力，它有故障隔离、快速试错两个好处。看一个生活中的例子，左边是一个大功率的白炽灯，坏处是非1即0，风险很高，右边是由很多的小灯组成的照明系统，任何一个灯坏了就坏了，不影响整个照明效果，而且每个灯可以独立维修，这个案例非常好。

怎么理解大系统小做是复杂大系统的架构能力呢？第一它是对产品和用户核心价值的深度理解，这是我们容易忽略的，要做系统拆分就要把握哪些是核心，哪些是辅助，拆分的粒度是什么样，这都需要对产品和用户有深刻的理解，这是一种架构能力。第二是我个人的理解，大系统小做需要高效稳健灵活的接入层和存储层，还有是要有强大的运营支撑。不只如此模块划分的粒度和合理性是功力所在。

 

3.2、过载保护

来看都江堰的例子：都江堰通过大鱼嘴将岷江分为内江和外江，内江水灌溉成都平原，但带来的风险是成都平原就可能被淹，为此李冰父子又修建了宝瓶口和飞沙堰，通过宝瓶口控制进入成都平原的水流量，再通过飞沙堰让多余的水重新流回外江。这是很好的过载保护的案例。相信很多同学都摇到过这张图，它也是一种过载保护，当微信客户端检测到摇红包太猛或者服务端的流量非常高时都会出这个，降低用户摇晃手机的频率。

关于过载保护的实现，我们有4点建议供参考。第一是从源头上减少无效请求；第二是从接入层开始拒绝；第三是各层互相不信任；第四是要照顾用户的情绪。过载保护解决了什么问题？很显然，抹平了尖峰流量。

 

3.3、冷热分离

这张图是传统金融业的架构示意图，为了保护交易数据的可靠性，从软件到硬件全是双份备份，并且还有异地备份，它的好处是交易和数据都非常可靠。再看QQ相册的实践，并没有像金融行业那样全程双备，原因在于我们的数据量非常大，超出金融行业成百上千倍，所以对于很热的数据比如索引数据，它只占了1%但我们放了4份，摘要数据占了5%我们放了3份，对于原始的相片，热的肥数据大概占了30%，我们放了2份，而冷的肥数据占了存储量的70%，我们只放了1份。我们用这个方法解决了比金融行业大成百上千倍数据量的存储与访问。为什么可以这么做呢？我们来看看微信朋友圈的统计数据，微信朋友圈一天以内的数据量只占总量的0.3%，但访问量占了70%，一个月以外的数据量占比是93.5%，但访问量只占10%，而一年以外的数据量是40%，但访问量是1%，基本一片死寂。从这个数据也支撑了冷热分离的做法。

 

3.4、正本清源

这是一个QQ早期的例子：大约2000年的时候，有段时间QQ每天20:00点到20:30期间峰值都很高，那时候我们很穷，服务器和带宽都不够，怎么办？老板们采取的方法是：因为高峰期同时在线猛涨的原因是挂机比较多，所以就在客户端硬编了一段代码，这个时间段每个PC上只能起两个QQ，立竿见影的把峰值抹平了，我们刚才在过载保护上说过从源头上拒绝，就是这个意思。在腾讯新闻客户端和腾讯视频中客户端都会根据客户端的不同的条件去拉取不同清晰度的内容，也是正本清源的体现，它能起到很好的削峰的作用。

 

三、结束语

在移动互联网领域只会0和1的团队刚刚及格，善于根据产品特性与用户场景深度柔性的团队才足以生存。