每年的“双11”都是电商盛会，也是消费者的狂欢日。 今年的双11意义尤为重大。 已发展成为全球电商和消费者的一场盛宴。 对于技术人员来说，双十一无疑成为了一次大考，考虑到整体架构、基础中间件、运维工具、人员等。

准备一场成功的大促不仅仅是针对活动本身的系统和架构的优化，比如：流程控制、缓存策略、依赖管控、性能优化……也离不开长期的技术积累和抛光。 接下来我简单介绍一下支付宝的整体架构，让大家有一个初步的了解。 那么我就以在这次大促中大放异彩的“蚂蚁花呗”为例，简单介绍一下新业务如何从头开始准备大促。 的。

建筑学

支付宝的架构设计应该考虑到互联网金融服务的特殊性，比如更高的业务连续性、更好的高扩展性、更快地支持新业务发展等。 其当前结构如下：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

整个平台分为三层：

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

技术平台（PAAS）：主要提供可扩展、高可用的分布式事务处理和服务计算能力，可以实现弹性资源分配和访问控制，并提供基础中间件运行环境，屏蔽底层资源的复杂性。 ;

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

建筑特色

数据中心逻辑架构

随着每年双十一促销当天的业务量成倍增长，支付宝面临着越来越大的挑战：系统容量越来越大，服务器、网络、数据库、机房都相应扩大，这使得支付宝面临着越来越大的挑战。带来了一些比较大的问题，比如系统规模越来越大，系统复杂度越来越高。 以往基于点的可扩展架构已经不能满足需求。 我们需要有一套可以基于一个单元的整体可扩展的解决方案。 维度被扩展。 可以提供支持远程扩展的能力，提供N+1容灾解决方案，提供完善的故障恢复体系。 基于以上需求，我们提出了逻辑数据中心架构。 核心思想是将数据水平拆分到接入层和终端，从接入层开始将系统划分为多个单元。 有多少个单位？ 特征：

每个单元对外界都是封闭的，包括系统之间交换对各种类型存储的访问；

各单元实时数据独立，不共享。 不需要高延迟的成员或配置数据可以共享；

单元之间的通信统一控制，尽量采用异步消息。 同步消息路由单元代理解决方案；

以下是支付宝逻辑机房架构概念图：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

该架构解决了几个关键问题：

通过最大限度地减少跨单元交互和使用异步，可以实现异地部署。 整个系统的横向扩展性大大提高，不再依赖同城IDC；

可实现N+1异地容灾策略，大幅降低容灾成本，保证容灾设施真正可用；

整个系统没有单点，大大提高了整体的高可用性； 同城、异地部署的多台单元可作为互备容灾设施，并可通过运维管控平台快速切换，实现100%连续性。 可用性;

在该架构下，业务层面的流量入口和出口形成统一的可控可路由的控制点，整个系统的可控性大大提高。 基于这个架构，以前难以实现的运维管控模型，如在线压测、流量控制、灰度发布等，现在都可以非常轻松地实现。

目前，新架构的主城框架已于2013年完成，并顺利面临双十一的考验，为整个架构的落地提供了良好的证明。

2015年，我们完成了基于逻辑机房、远程部署的“异地多活”架构的实施。 “异地多活”架构是指基于逻辑机房的扩展能力，将逻辑机房部署在不同区域的IDC中，每个逻辑机房都是“活”的，能够真正承担在线业务，可以出现故障时快速执行操作。 逻辑机房之间快速切换。

这比传统的“两地三中心”架构提供了更好的业务连续性保障。 在“异地多活”架构下，一个IDC对应的故障恢复IDC是一个“活”的IDC，平时承担正常的线上业务，始终保证其稳定性和业务正确性。

以下是支付宝“异地多活动”架构示意图：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

除了更好的故障应急能力外，我们还具备基于逻辑机房的“蓝绿发布”或“灰度发布”的验证能力。 我们将单个逻辑机房（以下简称LDC）划分为两个逻辑机房A和B。机房A和B在功能上完全等效。 正常情况下，呼叫请求会根据对端概率随机路由到A或B。 当蓝绿模式开启时，上层路由组件会调整路由计算策略，隔离A、B之间的调用。A组内的应用程序只能互相访问，B组内的应用程序不能访问。

那么蓝绿发布流程大致如下：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

。 发布前，将“蓝色”流量调整为0%，并分2组乱序发布所有“蓝色”应用。

。 观察 1% 的“蓝色”排水。 如果没有异常，逐渐将分流比例提高到100%。

。 “绿色”流量为0%，所有“绿色”应用分2组乱序发布。

恢复日常运营状态，蓝、绿单位各承担50%的线上业务流量。

分布式数据架构

2015年双十一高峰期，支付宝每秒处理的支付峰值达到85,900笔，成为全球最大的支付系统。 支付宝已经是全球最大的OLTP处理器之一。 其对交易的敏感性使得支付宝的数据架构有别于其他互联网公司。 但它继承了互联网企业特有的庞大用户量。 最重要的是支付宝的交易成本比例。 传统金融企业比较敏感，所以支付宝数据架构的发展是一部低成本、可线性扩展、分布式数据架构的演进史。

现在支付宝的数据架构已经从集中式小型机和高端存储升级为分布式PC服务解决方案。 整体数据架构方案尽可能独立、标准化。

支付宝的分布式数据架构可扩展性策略主要分为三个维度：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

按业务类型垂直划分

根据客户要求进行水平拆分（也称为数据策略）

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

下图展示了支付宝内部交易数据的可扩展性设计：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

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

在主事务数据库集群中，每个事务的创建和状态修改首先在这里完成。 由此产生的变化然后通过可靠数据复制中心复制到另外两个数据库集群：消费记录数据库集群和商户查询数据库集群。 该数据库集群的数据被水平分割成多个部分。 为了同时保证可扩展性和高可靠性，每个节点都会有相应的备份节点和节点。 如果发生故障，可以在几秒钟内切换到。 节点。

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

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

对于每一个分离的数据节点，为了保证对上层应用系统的透明性，我们开发了一套数据中间产品，以保证交易数据的弹性扩展。

数据可靠性

分布式数据架构下，在保证事务原有的ACID（原子性、一致性、隔离性、持久性）特性的基础上，还需要保证高可用性和可扩展性，这是一个非常大的挑战。 想象一下您同时支付了两笔资金。 如果这两种资金的交易在分布式环境中互相影响，那么如果一笔交易的资金回滚，另一笔交易受到影响，这是不可接受的。

基于CAP和BASE原理，结合支付宝系统的特点，我们设计了一个基于服务级别的分布式交易框架。 它支持两阶段提交协议，但在保证事务ACID原则的同时做了很多优化。 ，保证交易的最终一致性。 我们称之为“软东西”策略。 原理如下：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

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

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

完成：

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

主业务服务负责启动和完成整个业务活动。

从商业服务中提供TCC类型的商业运作。

业务活动管理者控制业务活动的一致性。 它注册业务活动中的操作，在活动提交时确认所有两阶段事务操作，在业务活动取消时调用所有两阶段事务操作。 ”

与2PC协议比较：

没有单独的阶段，降低了协议成本

系统容错能力高，恢复简单

异步可靠消息传递策略的关键组成部分如下：

阿里巴巴P9高级架构师：支付宝、蚂蚁花呗的技术架构及双十一实践

一些关键设计点：

如果步骤2、3、4出现故障，业务系统将自行决定是否回滚或启动新的补偿机制； 如果第6、7步出现异常，消息中心需要向生产者回查； 如果步骤8出现异常，消息中心需要重试。 步骤6中的确认消息由消息中心组件封装，应用系统不需要感知。

这套机制保证了消息数据的完整性，从而保证了通过异步可靠消息传递的系统数据的最终一致性。

某些业务的预检查需要消息中心提供指定的条件审核机制。

以上技术我专门整理了一下。 有很多技术不是三言两语就能说清楚的。 很多问题的答案其实很简单，但背后的思维和逻辑并不简单。 要知道正在发生什么，您还必须知道为什么。 如果你想学习Java工程、高性能和分布式，就简单解释一下。 微服务、源码分析的朋友可以去软件测试网——中国软件测试人员的精神家园，这里有技术专家讲解，Java大规模互联网技术可以免费分享~

蚂蚁花呗

蚂蚁花呗是今年新增的支付工具。 “确认收货后下个月再付款”的支付体验已被越来越多的消费者信赖。 与余额宝、余额宝一样，蚂蚁花呗避免了银行间交易环节，最大程度避免了支付拥堵。 官方数据显示，今日双十一促销期间，蚂蚁花呗支付成功率达到99.99%，每次支付平均耗时0.035秒。 与各大银行渠道合作，保障支付顺畅。

蚂蚁花呗发展还不到一年，但发展速度非常快。 支付量从上线初期的10笔/秒增长到双十一峰值21万笔/秒。 支撑蚂蚁花呗业务发展的技术体系不断演进，目前完全依赖于蚂蚁金服的金融云架构。

2014年12月，蚂蚁花呗团队完成了业务系统的优化，并按照标准将系统架设在金融云上，依次连接渠道层、业务层、核心平台层、数据层，让用户了解蚂蚁花呗的营销，整个下单、支付过程是统一的体验。

2015年4月，蚂蚁花呗系统同步建设了单元化金融云LDC，使数据和应用异地迁移成为现实，并具有更好的扩展性和流量控制能力。 在可用性方面，与财务云会计系统深度融合，借用会计系统的能力，让蚂蚁花呗通过低成本改造，具备同城容灾、异地容灾等高可用能力。 如果任何单位的数据库出现问题，都可以快速进行容灾切换，不会影响该单位的用户进行蚂蚁花呗支付。 稳定性方面，借助云客户平台的高稳定性能力，将蚂蚁花呗客户签约形成的合同数据提前迁移写入云客户平台的缓存中。 销售高峰期缓存命中率达到100%。 同时，结合全链路压测平台，蚂蚁花呗进行了容量和持续稳定性测试，发现系统的性能点得到了反复优化，让系统在大促当天顺利运行。 在之前的架构中，无法有效衡量系统的秒级处理能力，无法通过简单的导流、压测获得更准确、可信的数据。 基于金融云，系统通过全链路压测，快速获得每秒4万笔支付的稳定处理能力。

蚂蚁花呗业务最关键的就是买家信用和支付风险的控制。 从买家下单的那一刻起，后端就开始对虚假交易、限价、套现、支出风险等风险模型进行并行计算。 这些模型最终将在20ms内完成仅数百亿数据的计算和判定。 ，能够在用户到达收银台之前判断交易是否存在潜在风险。

为保证双11期间蚂蚁花呗拥有充足的信贷资金，在金融云系统下搭建机构资产中心，对接支付清算平台，将桌上的信贷资产打包，形成资产池基本上是发行流通证券进行融资，即通过资产转让获得足够的资金。 这一创新保证了用户能够通过花呗服务顺利完成交易，并分流了银行渠道的压力。 通过资产证券化业务，不仅帮助超过100万家小微企业获得融资，还支持了蚂蚁花呗用户的消费信贷需求。 蚂蚁小贷资产证券化业务平台可实现每小时超亿笔交易、总规模数十亿元的资产转让。

总结

经过这么多年的高可用架构和大促销的准备，蚂蚁金服技术团队能够做到“先胜后战”，主要分为三个方面的技术积累：“策略”、“工具”和“一般的”。

“规划”是指总体建筑设计方案和策略；

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

“匠”是指在实践中成长起来的技术人员。

纵观目前各种架构的分享，大家都喜欢谈论“策略”方面，分享各种架构设计方案的优化策略。 然而，最终通常会出现两种情况：“所吹嘘的 X 根本没有被证明”（各种框架能力根本没有经过实践检验，只是一句空话）、“所吹嘘的 X实践一测就坏了”（设计理念很好，但是一遇到实际大业务的冲击系统就崩溃了），最后成功的很少。 这些说明，虽然技术人员对建筑学中的“心灵鸡汤”、“学有所成”早已耳熟能详，但一旦付诸实践却发现根本不是那么回事。 由此可见，其实最终起到决定性作用的并不是“策略”的理论分析和设计。 最重要的是“工具”和“通用”的水平。 最终胜利的关键在于各种具有卓越可靠性和稳定性的基础设施工具的支持，以及“被虐过千遍”的经验丰富的技术人员的支持。 这两个层面的问题是无法通过分享来学习的。 它们必须通过时间和无数的血与泪来学习。 没有捷径。

从目前业务和市场的发展情况来看，技术往往需要在特定的时间有质的提升和能力的飞跃，这并没有给你太多的时间来为技术架构的完善做准备。 在技​​术积累和人员储备不足的情况下，如何搭建平台能力，更加专注于业务相关的开发任务，是每个技术团队都希望获得的能力。

过去，我们使用开源或商业组件来实现技术共享并获得快速的解决方案和开发技术的能力。 但随着业务复杂度、专业性、规模逐渐增大，这种方式的缺点也明显： 1、很多组件根本无法满足大并发场景下的各项技术指标； 2、随着业务变得更加复杂和专业，没有开源组件可以直接使用； 3、“人”本身的经验和能力是不可转让的。

所以现在我们通过“云”来共享技术和业务能力的方式也发展得越来越快。 这也是为什么我们刚刚推出的“蚂蚁花呗”技术，在几个月的时间里，迅速成功地做到了“从上线到上线”。 最初的10笔/秒的支付量，在双十一当天增长到了210,000笔/秒的峰值，迅速完成了别人几年后可能无法达到的能力。 类似的例子还有著名的“余额宝”系统。

这些都是建立在蚂蚁金服10多年基础组件和技术人员经验磨练出来的原生云服务之上的。 基于这个能力，我们现在可以快速构建高效、合规的金融云服务架构下的高可用、安全的A系统。