余额宝总结起来包括这样几个属性，第一它是一个传统的货币基金，但它把 T + 0 做到极致，另外他管理大量的用户资产。同时他具备极简的用户体验，符合互联网精神。我们在网页、支付宝 APP 或者其他途径能快速方便的进行基金申赎，它的应用渠道也非常多和广。
可以说从余额宝开始，真正的进入一个全民理财的时代，接下来给大家分享一下几个数字。余额宝用户数可以说达到了接近于 1/4 国人数量，日交易峰值可以达到两亿笔，最大并发数可以达到每秒五千笔。欢迎加入大数据学习交流分享群： 658558542 一起吹水交流学习
从余额宝的创新来说可以从两个方面去讲它，一是业务上的创新，他对 T + 0 发挥到极致，是现金管理工具，是底层帐户。还有就是嵌入式直销，把货币基金嫁接到支付宝上去。当时来讲应该是一个在行业内是具有非常大的一个开创意义的一件事情。
技术上创新是今天重点要说的事情：
基金直销和 TA 清算的整合。传统的基金系统直销和清算是分开。直销系统每天要把数据以文件形式导入清算系统里去。这件事情我们做了很大的改进，这么大体量数据来说，每天导入导出这个数据不可想象，在这里做了一个直销和 TA 融合，后面我会有一个详细的介绍。
交易的简化，监管大的框架下，满足监管要求的基础上，我们对交易逻辑做了很大的一个简化。
余额宝是核心业务在云上运行的系统。这是余额宝技术方面的创新。
架构演进历史
一期 IOE 架构
下面介绍一下一期的架构，很明显看到就是传统的 IOE 架构。底层存储是 EMC 存储。中间层就是采用小型机，其中 KCXP 和 KCBP 是金证公司的消息中间件和业务中间件。往上前端是前置解析是用的 WebLogic，负载均衡用的硬件负载均衡。
这个架构对它的定位满足需求首先是支持千万级用户，传统基金销售模式是走代销机构的方式，投资基金用户也是以理财为目的。所以每天可能处理的帐户的开户可能也就是几万到几十万的规模。由于余额宝对接是支付宝，支付宝有庞大的用户群，在用户规模上要达到千万级，这是当时对需求的定位。
第二点就是刚才提到把直销系统和 TA 清算系统做了融合，在数据库层面是共享的，避免数据再做一次导出和导入，对清算也节省了很多时间。
另外一点是传统基金的互联网化。传统基金只需要做到系统的 5 × 8 可用性，对接支付宝以后，要做 7 × 24 小时可用性。
2013 年 6 月，一期系统如期上线，业务规模远远超出我们想象。运营和运维人员反馈清算时间太长，基本上要从凌晨开始到早上八点，每天都是这样，我们感受到巨大的压力。另外当年要参加支付宝这边的双 11 活动，以当时的系统处理能力来讲，肯定是做不到的。
二期云端架构
基于这些原因，需要对一期的系统做优化，怎么优化？二期架构用一个词概括就是上云，充分利用云计算的计算能力，包括云计算对存储的处理能力。
整个架构进行了水平拆分。前面一期架构实际上就是一路的处理，到了二期把它分成多路。
从数据库层面分成多个 RDS（阿里云一款基于MySQL的关系型数据库产品）。另外一个就是去Oracle，很多利用数据库存储过程计算的部分，移到计算单元完成。
第三点是把直销和 TA 再次在计算资源层面分离。余额宝系统的数据处理，包括实时处理和批量处理。过去在一期架构的时候发现清算时，数据库负荷非常高，严重影响实时请求体验。所以在上云之后，在计算资源这块再次对它进行了分离，主要目的是提升客户体验。上云之后，当然充分利用了云计算的优势，其中很主要一个优势就是可扩展性。
水平拆分
接下来详细介绍一下是怎么来做水平拆分。
第一点如何来分，以什么维度来分？最后确定以用户维度，这样最终处理时间与用户交易的均衡程度有关。确定以用户维度进行拆分之后，确定哪些点来进行拆分，同样还是从用户角度出发，帐户、交易、份额、份额明细、份额变动等等。对于历史表直接合到仓库里去了，因为每日清算完之后，当日数据直接把它归档掉。
拆分之后，涉及到这样一个问题，TA 系统因为还要与周边的系统进行交互，交互的接口同样还是文件，数据导入需要先把文件拆成多份，再把每一份导入 TA，数据导出时系统要导出多份文件，再合并为一份。
总控
拆分最大的难点是在总控节点的处理，刚才说了 worker 节点能够保持松耦合，但仍需要通过总控节点进行统一协调，保持事务一致性。
最后数据核对阶段，也是要由总控汇总节点上的数据，按照清算规则对数据进行核对。还有很重要的收益分配部分，采用两个阶段来做，第一阶段由总控节点分配到每个节点上去。，然后在节点范围分配到用户粒度。
下图是上云前后指标上的一个对比，上云前基本上核心清算工作要做八个小时，上云之后在千秒以内可以完成。所以二期上云以后，IT 终于可以喘口气。目前来讲应对春节、双11、国庆长假等场景，系统都能稳定应对这些。
这是上云前后投入产出对比情况，传统的 IOE 架构特点成本很高，硬件成本给企业带来的压力非常大，云计算的好处就是在成本上是可以做到很细的，并且方便按需增加，这是一个非常大的成本上的优势。过去投入四百万只能支持一千万的帐户的量级，现在在投入上可能只是增长一倍，支持用户数已经远远不止一倍了。
数据架构
二期架构可以满足核心交易之后，还要考虑余额宝目前这么大的数据量，怎么把这个数据用好。
近一年来很多工作都是考虑数据后处理这块。其中数据来源于业务数据、日志数据和其他数据。我们推进数据仓库的建设和数据的产出。工具方面我们有很多自主开发的，同时也采用了阿里采云间，以及其他外采工具，具体支撑业务包括生产数据分析、资金预测、数据监控、运营支持，合规风控支持等等。开篇也提到了金融系统数据安全是重中之重，所以这块我们也会有相关的数据安全方面的管理。
二期架构的问题
二期架构解决很多问题，但并不是尽善尽美，总结一下还是有几个可以提高的点：
耦合。首先计算和数据的耦合还是存在的。这实际上是对系统的扩展是不利的。另外，单个计算节点上，在业务上还是存在耦合，我们很多业务上的东西还是存在拆分的可能。
数据流转，我们现在数据库层面也是分布式，所以数据的抽取、同步和流转会遇到很多现实的问题。
运维。在运维方面除了遇到的传统分布式系统的运维遇到的一些难题之外，我们还在业务层面的运维也会遇到一些现实问题。
未来演进思考
对系统未来演进思考，主要分这么几个方面。
从大的方面来讲是全局通盘考虑。我们要把核心和辅助系统通盘考虑，降低数据的冗余，降低数据维护成本。
数据方面要用多不同的存储来解决不同场景的需求，还有刚才提到计算和存储的彻底解耦，做到计算和存储的独立可扩展。
计算方面尽量做到业务上的拆分和轻量化，化繁为简，拆分之后把应用服务化。
数据驱动
我们系统的演进，数据量由单一小量向大量多类转变，同时应用种类从以交易为主到交易、分析和挖掘多种类并存。另外实时性要求也有变化，新的业务模式有时候要求实时或者准实时给用户呈现结果。
对业务来说对不同数据应用采用不同的存储。
比如对于在线交易，可以采用经过阿里支付宝验证过的 OB，专门用于解决金融级的分布式关系数据库的解决方案；
对于批量结算，可以继续沿用多年来在余额宝已经用的很娴熟的 RDS 集群。
对于 2T 到 PB 级的小数仓可以用 PetaData，解决以年度为单位的数据存储。
对于大规模的批量计算，数据仓库这块，我们直接就用 ODPS。
对大表存储可采用 OTS。
对于分析型、挖掘类需求可采用列存数据库。
服务化
关于拆分和服务化治理，后面考虑做的事情是充分利用阿里云的 PaaS 平台技术，把我们大应用拆分为简单的可横向扩展的小应用。
在服务的调用上，每个服务同时是服务提供方也是服务调用方，由 PaaS 平台的中间件统一管理服务。对我们来说是更多考虑如何基于中间件把业务来做好。服务化改造之后肯定会涉及到服务之间的调用。同步调用，可以直接走服务化的接口。
异步调用
异步调用主要靠消息中间件。金融系统对消息中间件的可靠性要求非常高，这块我们还是沿用传统思路，并不想采用开源解决方案去填那些坑，更多考虑采用成熟金融级消息中间件来做这件事情。
下面是一个总图，中间 EDAS 是统一企业级服务化解决方案，然后通过 DTS 解决数据实时同步的问题，采用 CDP 解决离线数据同步的问题。在数据应用上可以满足很多的需求，比如采集系统或者报表展示或者是用户短信的推送等等，这就是我们对整个未来的架构演进的思考。
结语
感谢您的观看，如有不足之处，欢迎批评指正。
如果有对大数据感兴趣的小伙伴或者是从事大数据的老司机可以加群：
658558542
里面整理了一大份学习资料，全都是些干货，包括大数据技术入门，海量数据高级分析语言，海量数据存储分布式存储，以及海量数据分析分布式计算等部分，送给每一位大数据小伙伴，这里不止是小白聚集地，还有大牛在线解答！欢迎初学和进阶中的小伙伴一起进群学习交流，共同进步！
最后祝福所有遇到瓶颈的大数据程序员们突破自己，祝福大家在往后的工作与面试中一切顺利。
