阅读笔记（一）
这周我读了（支付宝和蚂蚁花呗的技术架构及实践）的感想：支付宝整个平台分成了三层，使其有很大的扩展性，以及业务连续性。
三层如下：
-
运维平台（IAAS）：主要提供基础资源的可伸缩性，比如网络、存储、数据库、虚拟化、IDC等，保证底层系统平台的稳定性；
-
技术平台（PAAS）：主要提供可伸缩、高可用的分布式事务处理和服务计算能力，能够做到弹性资源的分配和访问控制，提供一套基础的中间件运行环境，屏蔽底层资源的复杂性；
-
业务平台（SAAS）：提供随时随地高可用的支付服务，并且提供一个安全易用的开放支付应用开发平台。
架构特性：
逻辑数据中心架构
提出了逻辑数据中心架构，核心思想是把数据水平拆分的思路向上层提到接入层、终端， 从接入层开始把系统分成多个单元，单元有几个特性：
-
每个单元对外是封闭的，包括系统间交换各类存储的访问;
-
每个单元的实时数据是独立的，不共享。而会员或配置类对延时性要求不高的数据可共享;
-
单元之间的通信统一管控，尽量走异步化消息。同步消息走单元代理方案；
分布式数据架构
交易系统的数据主要分为三个大数据库集群：
-
主交易数据库集群，每一笔交易创建和状态的修改首先在这⾥完成，产生的变更再通过可靠数据复制中心复制到其他两个数据库集群：消费记录数据库集群、商户查询数据库集群。该数据库集群的数据被水平拆分成多份，为了同时保证可伸缩性和高可靠性，每一个节点都会有与之对应的备用节点和failover节点，在出现故障的时候可以在秒级内切换到failover节点。
-
消费记录数据库集群，提供消费者更好的用户体验和需求；
-
商户查询数据库集群，提供商户更好的用户体验和需求；
分布式数据架构下，在保证事务原有的ACID（原子性、一致性、隔离性、持久性）特性的基础上，还要保证高可用和可伸缩性，挑战非常大。试想你同时支付了两笔资金，这两笔资金的事务如果在分布式环境下相互影响，在其中一笔交易资金回滚的情况下，还会影响另外一笔是多么不能接受的情况。
根据CAP和BASE原则，再结合支付宝系统的特点，我们设计了一套基于服务层面的分布式事务框架，他支持两阶段提交协议，但是做了很多的优化，在保证事务的ACID原则的前提下，确保事务的最终一致性 。我们叫做“柔性事物”策略。
蚂蚁花呗
蚂蚁花呗是今年增加的一个新支付工具，“确认收货后、下月还”的支付体验受到了越来越多的消费者信赖。跟余额和余额宝一样，蚂蚁花呗避开了银行间的交易链路，最大限度避免支付时的拥堵。据官方数据披露，在今天的双十一大促中，蚂蚁花呗支付成功率达到99.99%、平均每笔支付耗时0.035秒，和各大银行渠道一起确保了支付的顺畅。
蚂蚁金融技术团队可以做到“先胜而后求战”，主要分为三方面技术积累：“谋”，“器”，“将”。
“谋”就是整体的架构设计方案和策略；
“器”就是支持技术工作的各种基础中间件和基础组件；
“将”就是通过实践锻炼成长起来的技术人员。
