余额宝技术架构理解（读后感03）

一期 IOE 架构

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

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

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

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

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

二期云端架构

基于这些原因，需要对一期的系统做优化，怎么优化？二期架构用一个词概括就是上云，充分利用云计算的计算能力，包括云计算对存储的处理能力。

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

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

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

水平拆分

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

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

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

总控

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

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

数据架构

 

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

 

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

二期架构的问题

 

二期架构解决很多问题，但并不是尽善尽美，总结一下还是有几个可以提高的点：

 

• 耦合。首先计算和数据的耦合还是存在的。这实际上是对系统的扩展是不利的。另外，单个计算节点上，在业务上还是存在耦合，我们很多业务上的东西还是存在拆分的可能。

• 数据流转，我们现在数据库层面也是分布式，所以数据的抽取、同步和流转会遇到很多现实的问题。

• 运维。在运维方面除了遇到的传统分布式系统的运维遇到的一些难题之外，我们还在业务层面的运维也会遇到一些现实问题

思考：

• • 从大的方面来讲是全局通盘考虑。我们要把核心和辅助系统通盘考虑，降低数据的冗余，降低数据维护成本。

  • 数据方面要用多不同的存储来解决不同场景的需求，还有刚才提到计算和存储的彻底解耦，做到计算和存储的独立可扩展。

  • 计算方面尽量做到业务上的拆分和轻量化，化繁为简，拆分之后把应用服务化。

转载于:https://www.cnblogs.com/memeda21/p/11051528.html