对大多数人而言，今年的双十一可谓是无感而过。然而，这个「无感」正是今年支付宝技术团队的一个重要目标。
随着「双十一」进入第 14 个年头，这一现象级的标志性活动在很大程度上已经融入国人的日常生活，因而显得不再那么特殊——打折促销天天有，满减秒杀是基操，消费者已经习惯了随时随地都能下单，同城快递隔天就到。
但是，在这些看似寻常的体验背后，是整个零售电商和物流系统能力的规模化提升，而数字支付作为其中最关键的一环，和往年一样，也面临着一系列新的复杂的技术优化挑战。
自诞生时起，「双十一」便是一个极具挑战和实际价值的技术命题。高质高效地保障双十一大促工作的进行，涉及基础设施、存储、中间件、业务架构、交互技术与安全等多个技术领域，需要多部门紧密配合，能够集中体现一个团队的资源统筹、技术积累、工程实力和创新能力。
2022 年双十一期间，在多类日常业务以外，支付宝要为淘宝/天猫、抖音、快手、拼多多等客户提供线上交易服务（包括海外支付），支持合作的银行、购物中心等机构的线上线下支付业务，这些交易请求来自 POS 机、网银、浏览器、小程序、各商户 App 等不同平台，覆盖了直播秒杀、跨店满减、小额免密、先享后付等多个支付场景，较长的促销周期和多商户线上线下叠加不仅意味着多个流量洪峰，也进一步提升了峰值的不确定性。
面对今年「多平台、多场景、多峰值」的压力，如何保障系统稳定，如何在控制成本的同时确保系统容量可伸缩？本文将从超大规模分布式系统稳定性和高可用建设角度出发，尝试理解支付宝技术架构演进中的一些关键技术和思路。
由点到面，应对多平台、多场景、多峰值
为了应对新形势下的双十一，今年 3 月份开始，支付宝团队启动了「川流计划」，取川流不息之意，喻支付体验顺畅，将沉淀了多年的电商服务能力原子化，形成了一套面向全行业的产品解决方案，目标是随时随地、快速支撑任何一家商户的大促。
技术团队重点聚焦大促服务的常态化能力构建，以业务和需求为导向，确保做到稳定如常、体验如常、成本如常、效率如常。
今年以淘宝/天猫为首的各商家将大促时间提前到了 11 号的晚 8 点，与线下购物的高峰期重合，再加上其他常规业务，需要确保不同业务之间有充分的隔离性，能够同时达到稳定的状态。支付宝团队通过自适应泄洪、多商户动态异步化技术，在更加随机化的大促场景下持续保持支付的可用性及高性能，同时通过分时复用，在线离线混合部署，无感化弹云等技术，大幅提升效率和降低成本。
尽管用户侧感知不强，往年双十一为保证峰值平稳会做部分不紧急任务降级、暂缓处理，例如无法查询花呗账单等，今年通过读时提交等新的技术，保障退款、提现等业务服务不受损，交易收单功能也做了升级，让消费者在订金、现货、尾款等各阶段都具备相同的支付能力。
其中，为了满足如今商家在直播时代的秒杀诉求，团队重点构建了秒级高可用技术，动态维持秒杀性能，将支持秒杀的能力提升了一个量级，包括通过近端计数和异常感知，自动降级弱依赖业务，进一步提高并发，构建无感化弹云等创新技术，实现更快的容量伸缩，从而确保每个商家都能在自己的平台发起秒杀活动。
双十一流量洪峰和随之而来的峰值时刻高并发的处理效果，向来是双十一技术保障工作的一大看点。但不同于过往双十一的流量洪峰，秒杀服务本质上是一种营销服务，如果把这个秒级交易分摊到日常，对服务器成本的要求其实并不高。但随着直播秒杀成为一种常规化的营销手段，为了满足众多商家在较长的促销周期内随机性发起的千千万万的秒级峰值，需要有大量的机器成本的投入。
「这也是今年我们的底气，能够保障那么多商家在双十一期间的秒杀。」支付宝产品技术负责人善攻说，「从 0 点到 8 点，用户不用再熬夜了，对支付宝来说，面临的情况就是各个平台不同模式和玩法的峰值叠加，再碰到线下支付的高峰。我们并没有把成本转嫁到客户身上，而是通过技术迭代、资源协调等来实现更智能、更绿色、更高效的服务。我们也认为，只有具备普适性才可以对全社会提供可持续的服务。」
支付宝高并发、高性能、高可用架构演进
这些年来，随着业务特点和规模的发展变化，尤其在历届双十一的极端需求倒逼之下，例如从应对 0 点的单一流量洪峰到满足多平台支付需求和效率，支付宝完成了数次大的架构演进，逐渐形成了一套包括金融级分布式交易、分布式大数据分析与决策、智能化风险防控等在内的完整架构与技术体系。
第一阶段：转型分布式 SOA 架构，成为互联网电商支付工具
支付宝最初服务于淘宝网，用担保交易和支付这一项功能打开了用户网购的习惯，从 2005 年起开始服务整个互联网的电商支付。在这个阶段，其应用架构开始向分布式 SOA 架构转型，对交易、支付、账务、收银台等核心系统做服务化改造。
为解决引入分布式体系而带来的业务和系统复杂性等问题，团队重点聚焦实现集群的一致性，主要包括确保分布式数据一致性和在分布式环境下进行系统监控的问题。对此，支付宝基于两阶段事务原理自研了相应的分布式事务框架和微服务框架，同时构建了第一代监控系统，摆脱了黑屏命令行监控，从稳定的分布式事务体系应用架构和系统化的监控报警平台，奠定了后续高可用架构的基础。
第二阶段：去 IOE，解决存储单点扩展和稳定性问题，流量从百万到千万
随着支付宝从单一支付工具逐渐成为一个互联网金融平台，系统支撑的流量激增，使用大量服务器支撑双十一流量洪峰构成了巨大的成本压力，以及其他很多不确定性因素。2011 年开启去 IOE 战略（不再使用 IBM 小型机、Oracle 数据库、EMC 高端存储，转向自主掌控的技术）。在此背景下，团队从应对大流量带来的高并发和稳定性风险角度出发，解决核心系统级别的稳定性和可扩展性问题，奠定了这一代高可用架构的基石。
第三阶段：异地多活架构，流量弹性伸缩
金融级产品对稳定性有极高的要求，需要加速实现金融级异地多活的高可用架构。作为蚂蚁代表性技术的逻辑单元 LDC（Logical Data Center）在这一阶段被提出，相对于传统的 IDC（Internet Data Center-IDC），确保分布式系统在逻辑上的协调与统一。与 OceanBase 数据库相结合，支付宝团队实现了两地三中心和三地五中心的城市级异地多活高可用架构，主要解决机房扩展性、数据容灾，以及大促期间机房快速弹性问题。
也是从这一时期开始，双十一的峰值和日常业务峰值差别越来越大，因此基于 LDC 架构灵活的流量调度能力，实现了机房级别弹性扩展能力，在大促前将流量弹回到新的机房，在大促结束后快速回收该机房。2016 年的双十一，支付宝全天完成交易笔数为 10.5 亿笔，支付峰值 12 万笔/秒，大促中 50% 流量基于云计算资源弹性伸缩。
第四阶段：原生混合云部署，提供全球性的互联网金融服务
随着蚂蚁集团对云原生理念的投入，坚信未来的金融级应用场景都会往极致的弹性和混合云方向发展，2017 年开始云原生架构启动实施，蚂蚁全站应用上云，支付宝开始尝试离在线混部和分时调度技术，在大促时利用离线技术所使用的集群资源，大大提升了集群资源利用率。
向云原生转型的过程中，不同场景的应用很难一步到位，为了满足不同的业务需求，在云原生的改造中，新老业务并存过渡，通过统一的研发平台，同时支持基于虚拟机和容器的双模持续交付，助力于整个架构的稳妥的演进和迁移。考虑到商家服务全面开放、大促活动常态化，生活服务、保险、理财、公益等各项业务的发展和形态趋于多样化，支付宝团队意识到需要把高可用做成一项常规能力，并且从风险视角构建一套架构体系从根源上确保稳定性。
针对外部环境的剧烈变化（如活动带来的流量突增、机房故障等）、内部节点异常（如数据库宕机，服务器宕机等）和人为变更的风险（如代码发布，配置推送等）这三类主要风险，支付宝建设了如变更防控体系、容量风险体系、应急定位体系等风险防控体系，实现系统化的三板斧（可监控、可灰度、可回滚）要求，并引入数据智能化手段进行精细的风险识别，构建仿真环境以模拟故障及验证问题。
从业务中来，到业务中去
从容应对多峰高并发
从最初淘宝平台上的一种担保交易和支付功能，到如今提供支付、生活服务、政务服务、理财、保险等众多能力的数字生活开放平台，支付宝在没有先例可循的情况下，构建起一个中国乃至世界范围内互联网三高（高并发、高性能、高可用）架构的代表。
2017 年，支付宝处理支付峰值 25.6 万笔/秒，已经成为全球最大的一家 OLTP 处理实体，但同时却继承了互联网公司特有的超大规模用户量（截止 2020 年，支付宝在全球拥有超过 12 亿用户），支付宝的技术架构发展历程，也可以说一个持续不断地在性能与成本、业务需求与用户体验之间取舍平衡的三高架构演进史。
脱离实际业务需求的技术往往于业务产生不了最大实用性价值，只有在服务业务、保障业务持续可用过程中沉淀下来的技术，才是最有价值的技术。正是因为一次次双十一的倒逼创新，支付宝的实践证明在金融级中间件、数据库和云计算平台的支持下，分布式架构完全能够胜任复杂、高要求的金融级交易。
在如今这个时代，一家公司要走得更远，只有提供更好的服务，满足用户更加苛刻的需求。构建常态化的双十一技术服务能力只是开始，随着业务发展和服务类型变得更加复杂多样，多峰高并发将不仅仅是支付宝的日常。在万物互联的智能时代，什么样的技术和架构可以应对无处不在的计算，将不仅仅是支付宝团队需要解决的重大命题。
