刚刚过去的双十一全天交易额 2684 亿，再创新高，支付宝自研分布式数据库 OceanBase 每秒处理峰值达到 6100 万次，再次展示世界级数字金融运算能力。

今年是支付宝参加双十一的第十一年，也是一个新的起点，我们将支付宝历年重要技术制作成一张大图，但图所包含的信息毕竟有限，本文将这些技术分为三个阶段，为你详细解读。

2019-2013：被大促拽着前进

2009 年光棍节，第一次双十一来的很突然，谁也没有想到在网民自创的“节日”搞的促销活动会成为中国最大的购物狂欢节，当天淘宝商城的成交额激增 10 倍。

支付宝第一年参加双十一，第一代对账系统完成大促全量资金核对，同时整体完成面向服务的架构 SOA 改造，虽然手忙脚乱，不过还是扛了下来。

在 2008 年以前，支付宝用的是阿里的 WebX 框架，采用 IOE 商业系统 + 开源软件的方式搭建后台，但这套架构是烟囱式架构，难以维护和扩展。2007 年开始，支付宝自研 SOFA 框架，并于 2008 年 1 月上线。

SOFA 分布式中间件早期架构

SOFA 最开始的目标是对后端架构进行分布式服务化改造，而双十一大促将这个进程大大加快，刚完成这项改造，团队又马不停蹄的投入下一项任务中。

2010 年第二次双十一，大家虽然有了准备，但实际的流量和成交额仍然远超估计，据当年的参与者表示，虽然准备了比平时多 3 倍的容量，但最后的流量是平时的 20 倍，在最后关头，运维人员将会计系统降级，避免核心系统崩溃。

在这一年里，支付宝数据库团队完成数据库的垂直拆分和水平扩展，将交易账户库分为交易库和账户库，奠定了弹性扩容的基础。但是，拆分带来了数据一致性问题，中间件团队研发并上线了基于两阶段提交的分布式事务中间件 XTS，解决了这个问题。XTS 经过不断完善，现在已经进化为阿里巴巴和支付宝共建的 Seata 项目，并已经在 GitHub 上开源。

也正是在这一年，分布式关系数据库 OceanBase 开始立项，开始了技术长跑。

2011 年，支付宝运维监控系统 xflush 上线，实时秒级监控大促的峰值，业务健康度不再是黑盒，后来，升级为全功能监控平台 AntMonitor。

2012 年双十一单日交易一亿笔，在这背后，是支付宝紧急通过数据、网络、机房的改造，将单日的支付能力从百万级提升到了亿级。

当时，支付宝系统伸缩的瓶颈在基础设施和应用层面，首先是负责流量接入和调拨的负载均衡，支付宝自研了负载均衡中间件 Spanner，2012 年上线并成功支持大促，在不断升级改造后，到今天也仍在支撑日渐高涨的巨大流量。

其次的瓶颈在交易系统和账务系统，支付宝通过多 IDC 的改造，将交易系统和账务系统进一步拆分，扩展了系统承载能力，并通过 FailOver 机制，避免单点故障。

多 IDC 架构

2013 年，支付宝 All-In 无线，移动端首次在双十一大促中承担重要职责。

但实际上这一年最重要的变化是，支付宝开始实施单元化的 LDC 逻辑数据中心，并在此基础上实现了交易支付系统的异地双活，有效提升了核心系统的持续服务能力。

单元化改造示意图

这里的单元是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。单元化架构就是把单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用，数据则是全量数据按照某种维度划分后的一部分。

支付宝单元化改造并不是一蹴而就，过程十分艰辛，不过带来的好处也非常多，包括理论上无限可伸缩微服务架构、异地多活部署、全站蓝绿发布和线上灰度仿真、异构机房上的弹性混合云架构等。

从 2009 年到 2013 年的双十一，支付峰值从数百笔增长到 1.3 万笔每秒，每年的增长速度都是数倍甚至十几倍的提升。为了支撑疯涨的流量，这些年里，支付宝技术的最重要目标是扩展系统的承载能力，可以说是被大促拽着前进。到 2013 年，LDC 架构实现了理论上无限伸缩的能力，技术团队终于可以稍作喘息，开始追求精细化，大促相关技术也开始走到新的阶段。

2014-2018：从去 IOE 到大促技术标准化

2014 年对于支付宝来说，是一个全新阶段的开始：去 IOE 开始落地，大促神器全链路压测正式启用，最后大促中控平台上线，标志着支付宝双十一大促相关技术走向标准化。

首先是去 IOE，OceanBase 在 TPC- C 数据库基准测试取得第一名，这个蚂蚁自研的分布式关系数据库一下子为世人所知，这里我们看一下这些年来它在幕后一路走过的里程碑：

2014.11 OceanBase 承担支付宝交易 10% 流量；
2015.11 OceanBase 承担支付宝交易 100%、支付 50% 流量；
2016.11 OceanBase 承担支付宝交易 100%、支付 100%、花呗账务 30% 流量；
2017.11 OceanBase 承担支付宝交易 100%、支付 100%、账务 100% 流量，“去 O”大功告成！并第一次走出阿里，应用到南京银行互联网核心系统；
2018.11 基于 OceanBase2.0 分区的百万支付架构上线，正式兼容 Oracle；
2019.11 OceanBase 取得 TPC- C 测试第一名，双十一每秒处理峰值 6100 万次；
……

在 2014 年时，支付宝决定将核心交易系统的 10% 流量放到 OceanBase 上，在今天看来是非常冒险的举动，不过当时之所以这么做，是因为之前所采用的 Oracle 数据库已经无法支撑下一次大促了。OceanBase 也经历了非常多的优化，在 2018 年的双十一中，OceanBase 2.0 上线，并确立了以 OceanBase 2.0 分区为主的架构，彻底解决了数据库层面的瓶颈，实现百万支付架构。

OceanBase 分区架构

2014 年双十一首次采用全链路压测，这可以说是大促保障的核武器。全链路压测解决了之前的大促规划靠拍脑袋、成功看运气的问题，通过模拟用户在大促时的行为和流量，将涉及到的每个系统、每项技术都测试到位，大大减少了大促出事故的概率。

2016 年，支付宝还在 LDC 逻辑数据中心的基础上，在支付核心链路成功实现弹性架构，100% 按照运营需求弹性扩充资源，极大节省了成本。弹性架构可以让系统随流量自动化的伸缩，可以降低成本，提升运维效率。

从多 IDC 架构到弹性架构的演变

2017 年，支付宝首次实现离在线混合部署，80% 在线资源，20% 离线资源。随着大数据和机器学习的落地，支付宝平时有一些离线计算集群，通过调整工作时间，可以实现和大促高峰流量错峰，再和弹性架构结合，就实现了分时调度，同一批资源在不同的时间运行不同的应用，最大程度提升资源利用率。

离在线混部示意图

2018 年双十一，支付宝推出系列活动，“码上双十一”联动手淘拉新促活用户，相当于开启了双大促，如果按以前的做法，需要采购双倍的服务器，有了混部和分时调度之后，才得以在新增少量服务器的情况下支撑，极大的节省了成本。

2017 年其它的新技术还包括：

• 首次启用智能客服系统，单日服务总量超过 500 万人次。
• 智能风控 AlphaRisk 多模式切换落地，确保账户资损率低于千万分之五，遥遥领先于全球平均水平。
• 首个在国内自主研发的图数据库 GeaBase 及自研图查询语言第一次参加双十一，实现了对百亿级关系网络毫秒级的查询和变更。

2018 年双十一的时候，关于大促保障的相关技术基本已经成熟，但都比较零散，如果想更好的利用这些技术，需要把它们整合到一起，大促中控平台也正是在这个背景下出现的，它标志着支付宝将之前的大促经验沉淀，大促保障相关的技术实现标准化。

2018 年双十一的新技术还有：

• 首次在大促中进行红蓝攻防演练，在全链路压测的基础上进一步提升整个系统的可靠性。
• 大促巡检平台上线，实现大促相关的配置的全面检查，防止配置失误。
• 区块链技术第一次全面参战，百余个国家和地区、1.5 亿跨境上牌的原产地溯源不再是难题。
• 生物支付首次成为天猫双十一主流支付方式，每 10 笔支付就有 6 笔采用生物支付，标志着中国的生物支付时代来临。

2017 年双十一支付峰值 25.6 万笔 / 秒，2018 年支付宝内部实现可扩展的百万支付架构，再加上大促中控平台上线，我们可以看到，支付宝大促相关的技术已经成熟，并在不断打磨中追求可靠性、资源利用率、自动化、灵活性，把大促相关技术做到极致。

2019+：面向未来的金融科技

从 2018 年起，支付宝开始尝试和探索云原生架构的落地，同时数据智能相关技术也在公司内广泛使用。2019 年，相关的技术开始亮相大促舞台，以支付宝自研产品 SOFAMesh 搭建的金融级云原生基础设施首次登上双十一，打造了业界最大的 Service Mesh 集群。

OceanBase 2.2 上线大促核心支付链路，每秒处理峰值 6100 万次，这是 OceanBase 数据库同时兼容 MySQL 以及 Oracle 两种模式的一个里程碑的版本，性能和稳定性上也相对 2.0 版本有大幅提升。

最重要的是，支付宝技术开始走向无人区，未来的道路只能靠自己开拓，没有别人可以参考。支付宝开始自己描述面向未来的金融技术架构，推出了金融级云原生、开放计算架构等技术和理念，打造面向未来的金融科技。

金融级云原生是指在 CNCF 所定义的云原生基础上，发展出适合金融机构使用的一套技术栈，其中包括全面对外开放的 SOFAStack 金融级云原生分布式平台，以及通过安全容器、TEE、Service Mesh 等构建的全栈云原生安全架构。

SOFAStack 不仅采用 Kubernetes、容器等社区化的云原生基础技术，同时考虑金融行业的特殊性，支持之前的传统架构，形成双模技术，包括：

• 双模 PaaS：包括传统 PaaS 和基于 Kubernetes 的 PaaS，在 PaaS 中用容器来模拟 VM 的运行模式，同时支持容器和虚拟机；
• 双模微服务：通过 Mesh 来统一基于 Kubernetes 的微服务和老的服务注册中心式微服务；
• 双模 Serverless：同时支持基于云原生的 Nodejs Serverless 模式、基于 JVM 的 Serverless 模式，以及基于云原生的 Java Serverless 模式。

在开放计算架构方面，支付宝通过设计一套符合当下计算体系，同时又能应对未来计算趋势的技术框架，来解决计算引擎更新、统一研发体系、数据共享互通、数据风险防控等几方面问题。

首先在计算引擎方面，针对不同的计算作业状态进行统一管理，达到兼容任何一种计算引擎，并且实现插件化能力；在研发层面，推出了 SmartSQL，在标准 SQL 规范之上扩展了部分功能及语法，希望用最简单通用的语言，描述绝大部分的计算及机器学习作业；在存储层面，支付宝自主研发了统一存储系统，支持多种类型的数据存储格式，同时支持一份数据不同格式之间的自动转换及迁移，极大地简化了引擎层对存储的使用，同时节约了大量成本。

另外，开放计算架构之所以叫开放，就是它能包容不同的计算模式和引擎。在开放计算架构之中，包含了离 / 在线一体的图计算引擎及存储，从使用场景，可以覆盖在线、实时、离线各个场景，用于支持不同时效性的业务。从功能上，具备金融级图数据库，超大规模图计算，流图混合的动态图计算以及超快内存图等计算能力，覆盖了不同量级的数据计算能力。在机器学习方面，开放计算架构还包含了之前已经开源的 SQLFlow 以及前段推出的 ElasticDL 弹性深度学习框架。

这一整套体系将 BigData 和 DataBase 的理念揉合在一起，又称为 Big Data Base，是支付宝摸索出来的金融数据智能的最佳实践，下一代大数据的基石。

2019 年，开放计算架构在支付宝不同场景中落地。随着图计算在花呗，蚂蚁森林等场景中大规模上线，图数据库 Geabase 突破万亿边，在线图分析百亿关系特征计算秒级响应。同时，通过融合计算引擎，协同流、图、并行计算、机器学习等不同计算模式，在支付过程中提供秒级智能决策能力。

结语

互联网技术的更新迭代永无止境。

对支付宝人来说，虽然已经经历了这么多的大促，但每一年的双十一仍然是全新的挑战。这个挑战不仅来自于不断推陈出新的业务和运营，也来自于技术人对自己的严格要求，就像那句话所说的，今天的最好表现，是明天的最低要求。

正是这样的驱动力，驱使着支付宝的技术人不断的超越自我，突破舒适区，寻找下一场技术革命。也许，这也正是双十一的意义所在。

推荐阅读

万字长文丨 1 分 36 秒，100 亿，支付宝技术双 11 答卷：没有不可能
超燃！支付宝技术双 11 纪录片《一心一役》全球独家首发