余额宝的故事.pdf

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

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

一年前的现在，在杭州支付宝大楼里有个叫“春秋书院”的闭关室，里面一群紧张而兴奋的

年轻人在忙碌着。项目室巨大的落地窗前，站着一个面色凝重的人，他就是天弘基金创新事

业部技术负责人樊振华，一个在金融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

CoreBusinessPlatform）是专门为证券基金交易系统设计的外层交易中间件，同时具有普通

交易中间件的特征和功能，KCBP同时也支持跨平台服务的开发与部署。为后续的可能出现

的架构调整留下预留空间。

b)金证通讯交换平KCXP（KingdomCommunicationeXchangePlatform）中间件技术在券商行

业有大量应用案例，具有很高的可靠性和可用性。并在数据传输效率、安全性和容错性、负

载均衡以及扩展