余额宝技术架构及演进

时间 2019-12-01

原文原文链接

余额宝技术架构及演进

原创 2016-07-14 陈雨高可用架构高可用架构

导读：余额宝开启了划时代的意义，开启了全民理财时代。上个月微博商业产品部联合天弘基金等金融技术团队策划了首届互联网金融系统沙龙，围绕在互联网金融过程当中碰到技术架构问题与业界展开分享及交流。本文是陈雨在沙龙上的演讲，受权高可用架构首发。前端

陈雨，具备 8 年的软件研发和技术管理工做经验，专一于互联网金融、云计算、大数据等领域的发展动态和创新，目前在天弘基金负责基金注册登记系统架构和研发工做。web

余额宝总结起来包括这样几个属性，第一它是一个传统的货币基金，但它把 T + 0 作到极致，另外他管理大量的用户资产。同时他具有极简的用户体验，符合互联网精神。咱们在网页、支付宝 APP 或者其余途径能快速方便的进行基金申赎，它的应用渠道也很是多和广。
数据库

能够说从余额宝开始，真正的进入一个全民理财的时代，接下来给你们分享一下几个数字。余额宝用户数能够说达到了接近于 1/4 国人数量，日交易峰值能够达到两亿笔，最大并发数能够达到每秒五千笔。截止 2016 年上一季度公开披露信息，规模已经达到六千亿以上。安全

从余额宝的创新来讲能够从两个方面去讲它，一是业务上的创新，他对 T + 0 发挥到极致，是现金管理工具，是底层账户。还有就是嵌入式直销，把货币基金嫁接到支付宝上去。当时来说应该是一个在行业内是具备很是大的一个开创意义的一件事情。
微信

技术上创新是今天重点要说的事情：架构

基金直销和 TA 清算的整合。传统的基金系统直销和清算是分开。直销系统天天要把数据以文件形式导入清算系统里去。这件事情咱们作了很大的改进，这么大致量数据来讲，天天导入导出这个数据不可想象，在这里作了一个直销和 TA 融合，后面我会有一个详细的介绍。并发
交易的简化，监管大的框架下，知足监管要求的基础上，咱们对交易逻辑作了很大的一个简化。app
余额宝是核心业务在云上运行的系统。这是余额宝技术方面的创新。

架构演进历史

一期 IOE 架构

下面介绍一下一期的架构，很明显看到就是传统的 IOE 架构。底层存储是 EMC 存储。中间层就是采用小型机，其中 KCXP 和 KCBP 是金证公司的消息中间件和业务中间件。往上前端是前置解析是用的 WebLogic，负载均衡用的硬件负载均衡。

这个架构对它的定位知足需求首先是支持千万级用户，传统基金销售模式是走代销机构的方式，投资基金用户也是以理财为目的。因此天天可能处理的账户的开户可能也就是几万到几十万的规模。因为余额宝对接是支付宝，支付宝有庞大的用户群，在用户规模上要达到千万级，这是当时对需求的定位。

第二点就是刚才提到把直销系统和 TA 清算系统作了融合，在数据库层面是共享的，避免数据再作一次导出和导入，对清算也节省了不少时间。

另一点是传统基金的互联网化。传统基金只须要作到系统的 5 × 8 可用性，对接支付宝之后，要作 7 × 24 小时可用性。

2013 年 6 月，一期系统如期上线，业务规模远远超出咱们想象。运营和运维人员反馈清算时间太长，基本上要从凌晨开始到早上八点，天天都是这样，咱们感觉到巨大的压力。另外当年要参加支付宝这边的双 11 活动，以当时的系统处理能力来说，确定是作不到的。

二期云端架构

基于这些缘由，须要对一期的系统作优化，怎么优化？二期架构用一个词归纳就是上云，充分利用云计算的计算能力，包括云计算对存储的处理能力。

整个架构进行了水平拆分。前面一期架构实际上就是一路的处理，到了二期把它分红多路。

从数据库层面分红多个 RDS（阿里云一款基于MySQL的关系型数据库产品）。另一个就是去Oracle，不少利用数据库存储过程计算的部分，移到计算单元完成。

第三点是把直销和 TA 再次在计算资源层面分离。余额宝系统的数据处理，包括实时处理和批量处理。过去在一期架构的时候发现清算时，数据库负荷很是高，严重影响实时请求体验。因此在上云以后，在计算资源这块再次对它进行了分离，主要目的是提高客户体验。上云以后，固然充分利用了云计算的优点，其中很主要一个优点就是可扩展性。

水平拆分

接下来详细介绍一下是怎么来作水平拆分。

第一点如何来分，以什么维度来分？最后肯定以用户维度，这样最终处理时间与用户交易的均衡程度有关。肯定以用户维度进行拆分以后，肯定哪些点来进行拆分，一样仍是从用户角度出发，账户、交易、份额、份额明细、份额变更等等。对于历史表直接合到仓库里去了，由于每日清算完以后，当日数据直接把它归档掉。

拆分以后，涉及到这样一个问题，TA 系统由于还要与周边的系统进行交互，交互的接口一样仍是文件，数据导入须要先把文件拆成多份，再把每一份导入 TA，数据导出时系统要导出多份文件，再合并为一份。

总控

拆分最大的难点是在总控节点的处理，刚才说了 worker 节点可以保持松耦合，但仍须要经过总控节点进行统一协调，保持事务一致性。

最后数据核对阶段，也是要由总控汇总节点上的数据，按照清算规则对数据进行核对。还有很重要的收益分配部分，采用两个阶段来作，第一阶段由总控节点分配到每一个节点上去。，而后在节点范围分配到用户粒度。

下图是上云先后指标上的一个对比，上云前基本上核心清算工做要作八个小时，上云以后在千秒之内能够完成。因此二期上云之后，IT 终于能够喘口气。目前来说应对春节、双十一、国庆长假等场景，系统都能稳定应对这些。

（点击图片查看大图）

这是上云先后投入产出对比状况，传统的 IOE 架构特色成本很高，硬件成本给企业带来的压力很是大，云计算的好处就是在成本上是能够作到很细的，而且方便按需增长，这是一个很是大的成本上的优点。过去投入四百万只能支持一千万的账户的量级，如今在投入上可能只是增加一倍，支持用户数已经远远不止一倍了。

数据架构

二期架构能够知足核心交易以后，还要考虑余额宝目前这么大的数据量，怎么把这个数据用好。

近一年来不少工做都是考虑数据后处理这块。其中数据来源于业务数据、日志数据和其余数据。咱们推动数据仓库的建设和数据的产出。工具方面咱们有不少自主开发的，同时也采用了阿里采云间，以及其余外采工具，具体支撑业务包括生产数据分析、资金预测、数据监控、运营支持，合规风控支持等等。开篇也提到了金融系统数据安全是重中之重，因此这块咱们也会有相关的数据安全方面的管理。

二期架构的问题

二期架构解决不少问题，但并非尽善尽美，总结一下仍是有几个能够提升的点：

耦合。首先计算和数据的耦合仍是存在的。这其实是对系统的扩展是不利的。另外，单个计算节点上，在业务上仍是存在耦合，咱们不少业务上的东西仍是存在拆分的可能。
数据流转，咱们如今数据库层面也是分布式，因此数据的抽取、同步和流转会遇到不少现实的问题。
运维。在运维方面除了遇到的传统分布式系统的运维遇到的一些难题以外，咱们还在业务层面的运维也会遇到一些现实问题。

将来演进思考

对系统将来演进思考，主要分这么几个方面。

从大的方面来说是全局通盘考虑。咱们要把核心和辅助系统通盘考虑，下降数据的冗余，下降数据维护成本。
数据方面要用多不一样的存储来解决不一样场景的需求，还有刚才提到计算和存储的完全解耦，作到计算和存储的独立可扩展。
计算方面尽可能作到业务上的拆分和轻量化，化繁为简，拆分以后把应用服务化。

数据驱动

咱们系统的演进，数据量由单一小量向大量多类转变，同时应用种类从以交易为主到交易、分析和挖掘多种类并存。另外实时性要求也有变化，新的业务模式有时候要求实时或者准实时给用户呈现结果。

对业务来讲对不一样数据应用采用不一样的存储。

好比对于在线交易，能够采用通过阿里支付宝验证过的 OB，专门用于解决金融级的分布式关系数据库的解决方案；
对于批量结算，能够继续沿用多年来在余额宝已经用的很娴熟的 RDS 集群。
对于 2T 到 PB 级的小数仓能够用 PetaData，解决以年度为单位的数据存储。
对于大规模的批量计算，数据仓库这块，咱们直接就用 ODPS。
对大表存储可采用 OTS。
对于分析型、挖掘类需求可采用列存数据库。

服务化

关于拆分和服务化治理，后面考虑作的事情是充分利用阿里云的 PaaS 平台技术，把咱们大应用拆分为简单的可横向扩展的小应用。

在服务的调用上，每一个服务同时是服务提供方也是服务调用方，由 PaaS 平台的中间件统一管理服务。对咱们来讲是更多考虑如何基于中间件把业务来作好。服务化改造以后确定会涉及到服务之间的调用。同步调用，能够直接走服务化的接口。

异步调用

异步调用主要靠消息中间件。金融系统对消息中间件的可靠性要求很是高，这块咱们仍是沿用传统思路，并不想采用开源解决方案去填那些坑，更多考虑采用成熟金融级消息中间件来作这件事情。

下面是一个总图，中间 EDAS 是统一企业级服务化解决方案，而后经过 DTS 解决数据实时同步的问题，采用 CDP 解决离线数据同步的问题。在数据应用上能够知足不少的需求，好比采集系统或者报表展现或者是用户短信的推送等等，这就是咱们对整个将来的架构演进的思考。

Q&A

提问：都切到云上，数据安全上怎么考虑？

陈雨：以前讲到金融要求是私有云，咱们是在阿里金融云上，并非在公有云上，可理解为物理上是隔离的。

提问：接口交互的技术是文件，文件的完整性和一致性如何保证的？大家本身要处理它吗？为何要用文件的方式？

陈雨：咱们对接是支付宝，文件的正确性和准确性由支付宝保证。咱们须要对大文件按节点数拆分红小文件，而后并行处理。接口必须用文件方式，金融行业不少系统对接最后要走文件接口，文件是用来对账的准确性保障，实时不是那么可靠。

提问：说到计算和数据耦合，输入输出解开，具体大致上是怎么实施它？

陈雨： RDS 来是单机数据库产品，经过分布式中间件 DRDS 或其余解决方案，以实现计算节点像使用单机数据库同样使用数据库集群。

提问：我们有基于用户纬度拆分，主要是什么缘由致使咱们要这么拆，基于用户纬度拆分，有没有比较坑的地方或者咱们怎么避免它？

陈雨：基于用户的拆分，一方面签约协议号是跟支付宝的接口，还有一个考虑是以用户为维度的查询需求相对多。固然其余非用户纬度查询就费点事了。

提问：我是互联网金融从业者，刚才您提到咱们余额宝系统，有清算系统是吧。不知道清算是有内部清算和外部清算，咱们这边清算是怎么作的？好比说内部清算是指交易明细和你的账户余额之间的比对。你外部清算多是你本地的数据和银行数据之间的比对。

陈雨：我所说的清算是你所说的第一种。天天作一次内部比对，计算用户的份额和收益。

提问：以前也用过其余的消息中间件，你刚才提到成熟的消息中间件不是开源，咱们其余从业者不能用到是吧？

陈雨：这涉及到一个生态圈的问题，若是进入阿里云的生态圈，可充分享用云计算资源。若是确实是在生态圈以外，可选择它的对应开源版本。开源版本在版本更替上或者服务方面，跟阿里云上存在必定的差异。

相关阅读

点击连接阅读相关文章

想更多了解本期互联网金融系统沙龙内容，请关注「ArchNotes」微信公众号以阅读后续文章。转载请注明来自高可用架构及包含如下二维码。

高可用架构

改变互联网的构建方式

长按二维码关注「高可用架构」公众号

微信扫一扫
关注该公众号

null