余额宝的故事

余额宝”经过不到一年的发展，已获得大量用户的认可。本文将以故事的形式讲述“余额宝”背后那些鲜为人知的艰辛历程——如何从传统架构演变为云计算架构。

一年前的现在，在杭州支付宝大楼里有个叫“春秋书院”的闭关室，里面一群紧张而兴奋的年轻人在忙碌着。项目室巨大的落地窗前，站着一个面色凝重的人，他就是天弘基金创新事业部技术负责人樊振华，一个在金融IT领域有着丰富经验的老兵。他看着窗外川流不息的汽车，深深地吸了一口气。

这是一个只有代号但没有名字的保密项目，内部称之为“2号项目”，2号项目的旺旺交流群的签名上写着“2013支付宝秘密武器”，足可见这个项目的重要性。

截止到今天，中国近亿人因为这个项目受益，改变了自己的理财习惯。这个神秘的项目，就是余额宝。那么余额宝的初期业务背景是什么呢？由此引发出对IT系统建设的需求又是什么？

余额宝业务背景

在支付宝上卖基金的想法，在天弘基金电商负责人周晓明心中经过多次的思考和锤炼，已逐渐清晰。他在向阿里小微金服集团国内事业群总裁樊治铭介绍余额宝模式的雏形时，准备了5分钟的内容，但只讲1分钟后，双方即达成一致意见可以做、快速做，并期望余额宝能在6月份上线运营。

双方随即行动起来，进行了简单的分工，支付宝负责余额宝在支付宝端的建设工作，而基金公司端负责与支付宝对接的直销和清算系统的建设重任，就落到了樊振华头上。

这是一个从来没有人做过，也没有人知道该如何做的创新业务，面对支付巨大的用户群体，在仅不足3个月的时间内，该如何设计基金的清算和直销系统，成为了樊振华面临的头号难题。2013年3月，樊振华一行与支付宝技术方进行整体架构沟通，这是传统金融行业建设思路与互联网技术路线的第一次冲突，双方团队在闭关室足足讨论了4天，确定下来一期系统的建设目标和要解决的问题。

当时主要面临以下难点。

1、要能够支持“千万级”用户的系统容量。

a)传统的基金销售系统主要是和第三方销售机构，如银行理财专柜、网上银行进行合作销售。直销系统能够处理每天几万到几十万个用户的开户就完全够用了。但“余额宝”面对的是数以亿计的支付宝用户，用户的开户数量和并发量与传统业务有数量级的差异。

b)传统基金的TA系统面对的用户是以理财为目的的申购和赎回，因此每天清算的交易笔数要求也只有几万到几十万即可满足。但“余额宝”的业务模式里，支付宝用户的每一笔消费，都会转化为一次基金的赎回，又加上海量的潜在用户群，每日清算笔数将会是传统模式的百倍甚至是千倍。

2、直销系统和TA系统的融合。

a)传统的直销和TA是分别独立的系统，但对于接入支付宝这种入口交易空前频繁、数据量极为庞大的需求而言，传统的分离式文件交互方式不能满足效率和优化利用资源的要求。因此，项目组提出了功能整合、功能简化、当前库和历史库分离的技术结构。让直销和清算系统使用同一套数据库，来避免数据拷贝带来的业务时延。

3、7×24小时的基金直销系统。

a)由于渠道的原因，传统基金直销系统的大多数开户出现在银行的工作日。因此系统能够做到5×8小时即可满足大部分客户的需求。但互联网的属性是7×24小时，因此系统也应该具

备7×24小时不间断的服务能力。

4、支付宝与天弘基金双方的数据传输与系统交互。

a)余额宝的直销和清算系统会部署于天弘基金在天津的数据中心，而支付宝的“余额宝”系统部署在杭州，双方之间的通信协议，远距离数据传输面临很大的挑战。

这样，根据早期的建设需求，余额宝一期系统的架构和系统容量规划工作展开了序幕。

一期系统建设

距离上线时间只有不足3个月，樊振华和系统开发商金证科技的技术人员进行了紧张的架构工作。经过数次讨论，双方有了初步的统一意见，并形成了建设目标。

1、基于KCBP/KCXP的集群技术,

a)系统第一要素是要满足创新业务的技术支撑要求，经双方讨论后，决定走较成熟的传统金融技术路线。决定选用金证科技的KCBP/KCXP做集群。金证股份核心业务平台KCBP（Kingdom Core Business Platform）是专门为证券基金交易系统设计的外层交易中间件，同时具有普通交易中间件的特征和功能，KCBP同时也支持跨平台服务的开发与部署。为后续的可能出现的架构调整留下预留空间。

b)金证通讯交换平KCXP（Kingdom Communication eXchange Platform）中间件技术在券商行业有大量应用案例，具有很高的可靠性和可用性。并在数据传输效率、安全性和容错性、负载均衡以及扩展性方面进行了优化，已经足够成熟。

2、基于传统的IOE的基础架构。

a)在如此短时间内，有很多的功能优化，业务流程更改等开发工作，再配合相关的测试，必须控制改动的范围。因此基础架构决定采用传统的HP/IBM/Oracle/EMC的方案，靠使用高端硬件设备的方式，提高一期系统的整体容量和性能。

3、直销和TA的系统整合。

a)为了减少直销系统和TA的数据传输延迟，决定两个系统使用同一套数据库架构。

b)为了避免单点故障引起的业务中断，应用层的直销和TA平均分布在每台服务器上。确保每个应用服务器的角色具备可替代性。

4、跨省的MSTP专线链路

a)天弘基金清算和交易中心在天津数据机房，通过架设两条4M的MSTP专线，连接到支付宝杭州数据机房。两条专线之间互为备份，确保通讯链路安全。

一期系统的架构图如下：

架构解读：支付宝实时开户，申购，赎回等实时请求，和每天的离线对账文件，都通过MSTP专线与一期系统进行通讯。其中实时请求通过RADWARE硬件负载均衡分发到两台前置机，前置机在做完报文解析以后，将请求发送到XP的消息队列。然后由BP以主动负载均衡的机制，从XP中取出相应请求进行处理，处理结果保持到后端数据库中。

幸福的烦恼

然而，在一期系统上线以后，面对业务量暴增的情况，系统遇到了瓶颈同时也出现了新的问题。

2013年6月13日，一期系统如期上线，业务量远超预期，给系统来了一个“下马威”。上线后数分钟内就达到了18万的用户。在2013年6月18日晚上，余额宝的用户量已突破了100万。2013年6月30日，余额宝用户数达到251.56万。

在如此高速的业务增长压力之下，一期系统开始面对前所未有的直销和清算压力的冲击。这个新建的系统，是否能够支撑起如此大的容量冲击？什么时候系统会达到瓶颈？这些问题，悬而未解让樊振华陷入了深深的危机感中。在经过了数个失眠之夜后，他还没找到解决问题的办法，但他清楚地知道，再这样下去，一期系统将会很快面临瓶颈，成为业务增长的绊脚石。

樊振华的担忧很快变成了现实，随着用户量的暴增，数据库的负荷越来越高，实时请求的响应时间开始变缓。清算时间由最初的半个小时慢慢地变成一个小时、两个小时、四个小时……清算系统每天会在凌晨收到支付宝最后一笔确认文件开始清算，天弘基金的后台运营人员会等候清算出结果以后，发送给监管行和支付宝。随着这些人回家的时间越来越晚，抱怨声开始出现，樊振华的压力也随之增大。

系统的扩容势在必行。然而，当樊振华收到金证科技发来报价表，打开第一页时，他惊呆了。如果依然使用IBM/Oracle/EMC的传统架构进行扩容，要达到预定目标，仅仅硬件设备采购及中间件的Licence费用就达到了数千万元人民币。这个数字对于樊振华来讲，甚至对于天弘基金这家公司来讲，是一个天文数字，超过了这家公以往所有对于IT投资的总和。并且设备采购到货就要一个月以上，想在一期系统瓶颈出现前完成扩容几乎不可能实现。 传统的路线走不通，就要找新的方法。当他得知阿里云计算作为一家云计算服务提供商，使用云计算支撑了海量的互联网企业及阿里集团自身业务时，樊振华开始和阿里云计算进行接触。2013年7月，樊振华组织阿里云、支付宝、金证科技的人一起探求解决方案。最终经过慎重思考，樊振华心一横，说了句：“不要再讨论了，上云，上阿里云！”

上云吧，腾飞

上云之路，困难重重，举步维艰。

上云并非一句话那么简单，使用云计算支撑当时国内最大的基金直销和清算系统，前无古人，但开弓没有回头箭。樊振华召集了支付宝、阿里云、金证科技的人一起，启动将直销和清算系统整体迁移到云计算架构，简称二期系统。

阿里金融云为二期系统提供了一下云计算服务ECS（弹性计算服务），RDS（关系型数据库服务），SLB（负载均衡服务）。这三个服务分别对应于一期系统中的HP和IBM服务器，Oracle数据库，硬件负载均衡设备。但这三种服务的单个实例的性能和容量，都比相应的物理设备小上一大截。如何用单机性能更小的云计算服务来支撑那些单机性能更强都难以支撑的系统呢？经过深入的了解，樊振华在心中已经有了答案：“蚁群战术”。

俗话说“三个臭皮匠，顶个诸葛亮”，“蚁群战术”就是要充分利用云计算服务的快速部署能力（5分钟内可以创建数百台ECS），弹性伸缩能力，安全稳定，的特性，使用水平拆分算法，将应用系统水平拆分为数十组甚至上百组平行运行的小系统，这些小系统组合起来，就可以支撑起海量的请求和超高的性能。

此时已经进入到7月中旬。按照对一期系统运行状况趋势的评估，一期系统的容量在没有任何运营推广活动的情况下，只能支撑到9月份便会面临瓶颈。樊振华还为理清楚二期的性能和容量设计目标时，又接到了新的压力：天弘基金和支付宝管理层已经决定余额宝要参加阿里双十一，双十一是网民们年度的购物狂欢节，但对于后台支撑的技术人眼来讲，绝对是

一场恶战。很快，传来了支付宝对天弘提出的双十一支撑要求：

1、实时请求的相应要超过1000笔每秒。

2、清算系统要支持单日3亿笔交易清算，清算时间不得超过150分钟。

3、10月份支付宝会展开相关运营活动，必须在10月份前上线。

面对这样几近变态的要求，只有2两个月的系统改造时间，项目组遇到了巨大的困难：

1、如何进行系统水平拆分：

a)按照“蚁群战术”，将原有系统的业务逻辑水平拆分成多组小系统。如何才能保证拆分尽可能平均和拆分后的扩展性是一个绕不过去的难点。水平拆分依据那个字段来做拆分，需要根据业务特性慎重考虑。一个细节考虑不到，会导致全盘皆输。

2、将Oracle替换为mysql。

a)Mysql无论是单机性能和功能，都远远与单机的oracle无法匹敌。使用mysql代替oracle，原有的存储过程怎么办？一些涉及多表join的操作在mysql下执行效率较低还如何解决。工作量有多大，没人清楚。

3、数据迁移工程浩大，难度极高。

a)一期系统部署在天弘基金在天津的数据中心，而二期系统却部署在阿里云在杭州的节点，如何做到无缝割接？并且考虑到互联网用户的用户体验，一期系统和二期系统在上线期间，不允许出现业务中断，项目组必须在大数据量，异构环境，远程迁移等复杂环境下，实现无缝迁移。做到上线过程最终客户无感知。

4、直销和TA系统的资源争抢问题

a)一期方案将直销和TA进行了融合，来解决数据交互问题。但由于传统的TA与实时请求在不同时段运行，所以采用了主动争抢机制的负载均衡，及贪婪式的CPU占用。以保证充分利用硬件资源完成业务清算。才传统模式下没有问题，但一期系统进行合并以后，TA和实时请求的应用系统部署同一组服务器上，每次TA系统启动清算的时间段，会严重影响实时请求的相应时间，甚至造成响应失败。

5、整个架构保持2年以上的系统扩容能力

a)上云后的系统必须能够满足业务量飞速高涨的情况下，可以根据业务量的大小做到无缝升级。2年之内，不能因为扩容而改变系统架构。在保证扩容性的前提下，经济和投入必须控制在合理范围。

这些问题，不管是樊振华，还是金证科技，在分布式系统和云计算这个领域，虽然了解很多，但真正动刀枪，还是第一次。即使阿里云和支付宝的技术人员，在这么短的时间内，要解决这么多难题，也都不禁捏一把汗。

走投无路，背水一战。

樊振华清楚他已经没有退路，只有往前走才是出路。他召集阿里云，天弘基金，金证科技，支付宝四方的技术人员在闭关室全部进行封闭式开发，一场艰苦的战役就此打响。

“管不了那么多，这些只能一个一个解决，不然怎么办？”樊振华每次面对棘手的困难的时候总会说这么一句。但困难都是终究会被解决：

1、系统水平拆分

a)系统拆分的基本原理很简单，就是按照一个业务字段，比如支付宝协议号作为拆分依据。对字段取哈希值以后根据拆分虚节点的个数进行求模。这样就可以简单的将所有的请求拆分成多份。

b)在二期系统的拆分过程中，经过测算，需要使用50组业务节点，但在拆分的时候，考虑到扩展性。并未简单的拆分成50份。而是拆分成1000份，然后每个节点处理20份的数据。这样做的好处就是将来如果系统遇到瓶颈，需要扩容的时候，不需要对拆分算法进行修改，

而且数据平均迁移的时候只需要以库为级别进行，从而避免了拆表。

2、去oracle

a)去oracle其实并无捷径，都需要扎扎实实的一点点完成。首先是将存储过程等mysql不支持或支持不好的数据库逻辑上移到应用中。

b)其次要将复杂度比较高的sql语句进行拆分，变成多条简单的sql语句。从而提高mysql的执行效率。

c)阿里云的RDS提供的慢sql查询功能，可以将整个系统执行效率比较慢的sql呈现给用户，帮助用户优化SQL语句。

3、数据迁移。

a)数据迁移是这个项目的重头戏，迁移过程中使用全量+增量+数据订正+并行运行检查等几个阶段完成。

b)二期系统在生产环境部署完成后，将在天津的一期系统的全量数据打包，按照指定拆分算法拆成1000份以后，通过专线导入到二期系统中。导入以后，将天津的一期系统前置机转发服务打开，将所有实时请求转发到二期系统，这样两个系统同时处理请求。然后在交易日之后，以一期系统为准，将二期系统中的数据进行订正，补全。这些所有的操作必须在24小时内完成是迁移成功的必要条件。

c)数据迁移成功之后，两个系统实际上在并行运行。需要使用脚本每天对比两个系统中的数据，连续2周数据对比无误以后，由支付宝将请求地址从一期系统切换到二期系统，整个迁移才算完成。

4、直销和TA的再次分离

a)借助云计算快速灵活的机制，将直销系统和TA系统的应用逻辑层进行完全分开，分开后的直销和TA系统分别运行在一组ECS中，两套系统后端连接同一套的RDS数据库服务。这样既能保证TA和直销系统在应用性能上不会发生争抢，而且又不会发生数据传递问题。

5、扩容性保证

a)除了在水平拆分算法的时候就采用双重映射的机制来保证架构本身的扩容性，还充分利用了阿里云云服务可以无缝升级的特性，来进行容量保证。

b)拿RDS数据库来讲，阿里云提供了新1型到新7型等7个型号，性能逐渐增强。最终选择了新5型做为数据库服务器，并没有一步到位采用最高型号。这样当系统出现瓶颈的时候，就可以通过将所有RDS从新5性升级到更高型号来将系统容量翻倍。

架构解读

将清算和直销的集群分为两组独立的集群,但使用相同的RDS数据库服务.这样既避免了在应用层面的资源争抢,又可以做到数据的共享.其中实时请求会先到达4个互为冗余备份的SLB(负载均衡),避免SLB单点故障.SLB将请求转发给5台前置机,前置机会按照拆分算法,将该请求路由到相应的节点进行处理,该节点处理完毕后,数据保存到改组对应的RDS数据库.而每日的对账文件则通过文件服务器进行拆分,然后清算系统的每个节点主动取出自己处理的文件进行清算处理,然后保存到数据库。

历尽磨难，涅槃重生

经过2个多月的封闭式开发，在上线之前，二期系统进行了严格的压力测试，测试结果让樊振华悬着的心终于放下了。

TA系统完成3亿笔订单的清算，可以在6400秒内清算完成返回给支付宝，完全符合项目150分钟。对开户的实时请求，项目目标要求达到1000笔每秒。压测的数据轻松达到5000笔每秒。并且具备11000笔每秒的储备能力随时可放开。 二期系统终于在2013年9月26日上午正式上线成功。在上线的前一天，一期系统每天完成清算需要8个小时，而上线后的那天，二期系统完成了她第一次的清算，只用了不到30分钟。这个结果让那些经历多个不眠之夜的后台运营人员眉开眼笑，终于可以在晚上回家睡觉了。实时请求的响应时间老系统为180ms，上云以后，平均130ms。效果明显。如下图：

万事具备，只欠东风，只有经过“双十一”海量交易量的摧残，才能验证系统是符合设计要求的。2013年11月11日 余额宝首次参加”双十一”大促,完成1679万笔赎回，1288万笔申购的清算工作，成功为639万用户正确分配收益。当天处理了61.25亿元的消费赎回，119.97亿元的转入申购。完成这些所有的清算工作，系统只用了46分钟！

云计算是万能的吗？

总结在上云以后至今的业务发展状况,数据暴增以后,面临的新问题,抛出面临的数据问题,引发思考

这一路走来，就像直销和TA系统经历了分开，合并，再分开的演进路线，让樊振华想起一句话“天下之势，分久必合，合久必分”。过去这么多年，以IOE为主的集中式计算已经告一段落，在这个互联网的时代，云计算和分布式的结合代替集中式计算已经深深植入他的脑海之中。

此时的樊振华，已经和一年前的他截然不同，一年前，他还在为各种硬件选型，采购流程而忙碌。但一年后，他更喜欢在人们面前谈起的是云计算，大数据，分布式，用户体验，互联网的IT架构等名词。

具备强大水平扩容能力的二期系统，足以让这个饱经历练的老兵高枕无忧，休息一阵子，再也不用担心系统容量和高并发的问题。但有一颗种子，在樊振华的心目中开始发芽：他清晰的知道，如今这个二期系统已经不是简单的直销和清算系统，每天沉淀在50个数据库里的海量用户和交易的数据量在暴涨，如何存储这些数据？如何使用这些数据？该如何才能产生最大的价值？

未来如何发展

有了这颗种子，樊振华休了个短假，他又开始了新的征程，投入了大数据的怀抱，这一次，

他选择了阿里云提供的ODPS（开放数据处理服务）来作为自己的大数据平台。ODPS目前是阿里集团进行离线数据处理的平台，其支撑了阿里金融，淘宝等多家Bu的大数据业务。有了这个平台作为后盾，樊振华清晰了很多，他脑海中复现了一幅画面：在不久的将来，通过对目前沉淀的海量数据的分析，可以把握成千上亿的用户的理财需求及不同的风险接受能力。而天弘基金，根据这些客户的情况，提供更多更丰富的理财产品。或许到那一天，让天下所有的人享受到符合自己的理财服务真不是梦想了。