[VIP专享]余额宝的故事

余额宝”经过不到一年的发展，已获得大量用户的认可。本文将以故事的形式讲述“余额宝”

背后那些鲜为人知的艰辛历程——如何从传统架构演变为云计算架构。

一年前的现在，在杭州支付宝大楼里有个叫“春秋书院”的闭关室，里面一群紧张而兴奋的年轻人在忙碌着。项目室巨大的落地窗前，站着一个面色凝重的人，他就是天弘基金创新

事业部技术负责人樊振华，一个在金融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中取出相应请求进行处理，处理结果保持到后端数据库中。

幸福的烦恼