支付宝的技术架构及实践——阅读心得

架构

支付宝的架构设计需要考虑到互联网金融业务的特殊性，比如要求更高的业务连续性，更好的高扩展性，更快速的支持新业务发展等特点。将

整个平台划分为三层：

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

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

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

图示如下。

 

 

可伸缩性的含义：种对软件系统计算处理能力的设计指标，高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够保证旺盛的生命力，通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。简单的说就是做更多的事情。

架构特性

逻辑数据中心架构

双十一大促当天业务量倍增，系统的复杂度越来越高，之前按照点的伸缩性架构无法满足要求，需要一套整体的可伸缩方案，可以按照一个单元的维度进行扩展。能够提供支持异地伸缩的能力，提供N+1的灾备方案，提供整体性的故障恢复体系。于是提出了逻辑数据中心架构，核心思想是把数据水平拆分的思路向上层提到接入层、终端， 从接入层开始把系统分成多个单元，单元有几个特性：

 

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

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

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

 

概念图如下：

 

 

解决了几个关键问题：

 

1.由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城IDC；

 

2.可以实现N+1的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；

 

3.整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现100%的持续可用率；

 

4.该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。

 

 

“异地多活”架构是指，基于逻辑机房扩展能力，在不同的地域IDC部署逻辑机房，并且每个逻辑机房都是“活”的，真正承接线上业务，在发生故障的时候可以进行逻辑机房之间的快速切换。

支付宝“异地多活”架构示意图：

 

 

 

分布式数据架构

支付宝分布式数据架构可伸缩策略主要分为三个维度：

 

1.按照业务类型进行垂直拆分

2.按照客户请求进行水平拆分（也就是常说的数据的sharding策略）

3.对于读远远大于写的数据进行读写分离和数据复制处理

 

图示如下：

 

 

 

支付宝内部交易数据的可伸缩性设计

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

 

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

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

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

 

对于分拆出来的各个数据节点，为了保证对上层应用系统的透明，研发了一套数据中间产品来保证交易数据做到弹性扩容。

 

 

 

数据的可靠性

分布式数据架构下，在保证事务原有的ACID（原子性、一致性、隔离性、持久性）特性的基础上，还要保证高可用和可伸缩性。

根据CAP和BASE原则，设计了一套基于服务层面的分布式事务框架，他支持两阶段提交协议，在保证事务的ACID原则的前提下，确保事务的最终一致性 ，叫做“柔性事物”策略。

 

 

分布式事务框架的流程图：

 

 

实现：

 

1.一个完整的业务活动由一个主业务服务与若干从业务服务组成。

2.主业务服务负责发起并完成整个业务活动。

3.从业务服务提供TCC型业务操作。

4.业务活动管理器控制业务活动的一致性，它登记业务活动中的操作，并在活动提交时确认所有的两阶段事务的confirm操作，在业务活动取消时调用所有两阶段事务的cancel操作。”

 

与2PC协议比较：

1.没有单独的Prepare阶段，降低协议成本

2.系统故障容忍度高，恢复简单

 

关键组件异步可靠消息策略如下：

 

 

关键设计点：

 

1.若在第2、3、4步出现故障，业务系统自行决定回滚还是另起补偿机制；若在第6、7步出现异常，消息中心需要回查生产者；若在第8步出现异常，消息中心需要重试。第6步的确认消息由消息中心组件封装，应用系统无需感知。

2.此套机制保障了消息数据的完整性，进而保障了与通过异步可靠消息通讯的系统数据最终一致性。

3.某些业务的前置检查，需要消息中心提供指定条件回查机制。

 

 

转载于:https://www.cnblogs.com/ssyh/p/10631784.html