余额宝是如何一步步建立云计算架构的？

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

一年前的现在，在杭州支付宝大楼里有个叫"春秋书院"的闭关室，里面一群紧张而兴奋的年轻人在忙碌着。项目室巨大的落地窗前，站着一个面色凝重的人，他就是天弘基金创新事业部技术负责人樊振华，一个在金融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年之内，不能因为扩容而改变系统架构。在保证扩容性的前提下，经济和投入必须控制在合理范围。 

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