我所经历的“余额宝”的那些故事

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

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

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

　　余额宝业务背景

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

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

　　这是一个从来没有人做过，也没有人知道该如何做的创新业务，面对支付宝巨大的用户群体，在仅不足3个月的时间内，该如何设计基金的清算和直销系统，成为了樊振华面临的头号难题。

　　2013年3月，樊振华一行与支付宝技术方进行整体架构沟通，这是传统金融行业建设思路与互联网技术路线的第一次冲突，双方在闭关室足足讨论了4天，确定下来一期系统的建设目标和要解决的问题。

　　当时主要面临以下难点。

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

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

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

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

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

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

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

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

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

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

　　一期系统建设

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

　　1. 基于传统的IOE基础架构。

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

　　2. 直销和TA的系统整合。

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

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

　　3. 跨省的MSTP专线链路。

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

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

图1  一期系统构架图

　　幸福的烦恼

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

　　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）、弹性伸缩能力和安全稳定等特性，使用水平拆分算法将应用系统水平拆分为数十组甚至上百组平行运行的小系统，这些小系统组合起来可以支撑起海量的请求和超高的性能。

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

1. 实时请求的响应要超过1000笔每秒；
2. 清算系统要支持单日3亿笔交易清算，清算时间不得超过150分钟；
3. 2013年10月份支付宝会展开相关运营活动，系统必须在10月份前上线。

　　面对这样严酷的要求，且只有两个月的系统改造时间，项目组遇到了巨大的困难。

　　1. 如何进行系统水平拆分？

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

　　2. 将Oracle替换为MySQL。

　　无论是单机性能还是功能，MySQL都无法与单机的Oracle匹敌。使用MySQL代替Oracle，原有的存储过程该怎么办呢？一些涉及多表join的操作在MySQL下执行效率较低该如何解决？工作量有多大？没人清楚这一系列问题的答案。

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

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

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

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

　　5. 整个架构保持两年以上系统扩容能力。

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

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

　　走投无路，背水一战

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

　　“管不了那么多，这些问题只能一个一个解决。”樊振华每次面对棘手的困难时总会说这么一句。最终困难都被解决了。

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

　　在二期系统的拆分过程中，经过测算，需要使用50组业务节点，但在拆分时，考虑到扩展性，并未简单地拆分成50份，而是拆分成1000份，然后每个节点处理20份数据。这样做的好处是将来如果系统遇到瓶颈，需要扩容时，不需要对拆分算法进行修改，而且数据平均迁移时只需要以库为级别进行，从而避免了拆表。

　　2. 去Oracle。首先是将存储过程等MySQL不支持或支持不好的数据库逻辑上移到应用中。

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

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

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

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

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

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

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

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

图2  二期系统构架图

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

　　历尽磨难，涅

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠