阅读笔记（一）

这周我读了（支付宝和蚂蚁花呗的技术架构及实践）的感想：支付宝整个平台分成了三层，使其有很大的扩展性，以及业务连续性。

         三层如下：

1. 运维平台（IAAS）：主要提供基础资源的可伸缩性，比如网络、存储、数据库、虚拟化、IDC等，保证底层系统平台的稳定性；

2. 技术平台（PAAS）：主要提供可伸缩、高可用的分布式事务处理和服务计算能力，能够做到弹性资源的分配和访问控制，提供一套基础的中间件运行环境，屏蔽底层资源的复杂性；

3. 业务平台（SAAS）：提供随时随地高可用的支付服务，并且提供一个安全易用的开放支付应用开发平台。

架构特性：

   逻辑数据中心架构

   

提出了逻辑数据中心架构，核心思想是把数据水平拆分的思路向上层提到接入层、终端， 从接入层开始把系统分成多个单元，单元有几个特性：

1. 每个单元对外是封闭的，包括系统间交换各类存储的访问;

2. 每个单元的实时数据是独立的，不共享。而会员或配置类对延时性要求不高的数据可共享;

3. 单元之间的通信统一管控，尽量走异步化消息。同步消息走单元代理方案；

分布式数据架构

交易系统的数据主要分为三个大数据库集群：

1. 主交易数据库集群，每一笔交易创建和状态的修改首先在这⾥完成，产生的变更再通过可靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数据库集群。该数据库集群的数据被水平拆分成多份，为了同时保证可伸缩性和高可靠性，每一个节点都会有与之对应的备用节点和failover节点，在出现故障的时候可以在秒级内切换到failover节点。

2. 消费记录数据库集群，提供消费者更好的用户体验和需求；

3. 商户查询数据库集群，提供商户更好的用户体验和需求；

分布式数据架构下，在保证事务原有的ACID（原子性、一致性、隔离性、持久性）特性的基础上，还要保证高可用和可伸缩性，挑战非常大。试想你同时支付了两笔资金，这两笔资金的事务如果在分布式环境下相互影响，在其中一笔交易资金回滚的情况下，还会影响另外一笔是多么不能接受的情况。 

根据CAP和BASE原则，再结合支付宝系统的特点，我们设计了一套基于服务层面的分布式事务框架，他支持两阶段提交协议，但是做了很多的优化，在保证事务的ACID原则的前提下，确保事务的最终一致性 。我们叫做“柔性事物”策略。

蚂蚁花呗

蚂蚁花呗是今年增加的一个新支付工具，“确认收货后、下月还”的支付体验受到了越来越多的消费者信赖。跟余额和余额宝一样，蚂蚁花呗避开了银行间的交易链路，最大限度避免支付时的拥堵。据官方数据披露，在今天的双十一大促中，蚂蚁花呗支付成功率达到99.99%、平均每笔支付耗时0.035秒，和各大银行渠道一起确保了支付的顺畅。

蚂蚁金融技术团队可以做到“先胜而后求战”，主要分为三方面技术积累：“谋”，“器”，“将”。

“谋”就是整体的架构设计方案和策略；

“器”就是支持技术工作的各种基础中间件和基础组件；

“将”就是通过实践锻炼成长起来的技术人员。

 从此可以看出，其实最后起决定作用的不是 “谋”方面的理论层面的分析设计，最重要的是落地“器”和“将”的层面。有过硬高稳定性的各种基础设施工具的和身经百战被“虐了千百次”的技术人员的支撑才是最后取胜的关键。而这个两个层面的问题是不能通过分享学到的，是要通过日积月累的，无数流血流泪趟雷中招锻炼出来的，没有近路可抄。

希望以后每个人都会“谋”，“器”，“将”，将事情做到更好。

                                                                                                                                       文章部分转至： 蚂蚁金服11.11：支付宝和蚂蚁花呗的技术架构及实践