自从双十一这个电商节之后，很多技术人的生活轨迹都发生了变化。人们提出了各种挑战。今天我们就来看看支付宝双11的发展历程，和过去10年一样，2019年的天猫双11再创新高。这个数字的背后，是一代又一代支付宝工程师为突破技术难关而努力奋斗的成果。今天，支付宝同学们为MacTalk提供了一部纪录片《一心一役》，这是11位技术同学经历双11的口述记录，讲述了支付宝科技发展一路走来的秘史。很多事情都是第一次公开。很喜欢，推荐给大家。对于技术人员来说，24小时保持双11的稳定流畅并不容易，但最具挑战性的时刻还是人们拿起手机，刷新已保存的购物车，点击支付的那一刻.2011年，在越来越顺畅的双十一背后，支付宝有哪些不为人知的技术探索，又是如何支撑起如此庞大的交易数据？查看第一个显示的文本版本。1.说到外部瓶颈，事情似乎从一开始就不是很顺利。2011年双十一期间，小部分用户高峰期无法支付。经查，这是少数银行网银系统受压故障所致。在早年的支付宝交易中，用户点击支付后需要通过支付宝和银行的接口进行支付。早年这个接口性能很差，每秒只能支持几十到几百笔交易，稳定性比较差。一旦流量上来，容易出现故障。如果这个问题不解决，以后每次大促都无法支付，会极大影响用户体验。但是，仅靠技术很难解决这个问题。银行对网上银行系统的演进有自己的规划，支付宝不能干涉他们的系统。然而，聪明的运营商想出了一个解决方法。2012年双十一，支付宝通过活动吸引用户先充值再支付，让用户先将钱充值到支付宝余额，然后在双十一当天直接从余额中扣款。这样，外部瓶颈也转化为内部瓶颈。这样做的效果非常显着，付款失败的问题得到了很大的缓解。然而，外部瓶颈始终存在。面对每年成倍增长的流量高峰，对外支付的依赖始终是一个隐患，不知何时爆发。解决这个问题最好的办法就是让资金在内部系统中流通，不经过网上银行。这就是先充值再付费的原则。那么，有没有办法吸引用户把钱存入支付宝呢？2013年6月，支付宝推出余额宝，一下子解决了这个问题。截至2014年底，余额宝拥有1.85亿用户。2013年和2014年的双十一，交易高峰分别是4次和3次。成倍增长。2018年5月，支付宝接入网联清算平台。同时，这些年银行也在大力提升系统能力。大中型银行网上银行系统支持的交易笔数已达到每秒2万笔以上。问题基本解决了。外部瓶颈解决后，支付峰值能达到多高，就看支付宝的系统如何解决逐年更加凶猛的流量峰值了。2.兵力规划：部队缺粮缺草。事实上，支持交易峰值的首要问题不是设计一个完美的支持横向扩展的架构，而是准确预估可能出现的流量峰值，然后安排相应的机器。和资源。如果不做预估，可能会出现两种情况：预留资源过多，架构设计过度，造成资源浪费；预留资源太少，无法完美支持大促，导致部分支付排队或失败。每年为了备战双十一，负责大促的决策团队会根据历史数据和大促目标，拟定一个成交值，然后将这个值拆解成各个系统需要处理的流量，所以规划系统容量。双11大促的场景指标一般包括创建交易数、收银展示数、交易支付数。总付费目标数已经有了，运维人员根据总tps/单机tps的算法，计算出每个指标下应用的单机容量，然后参考历史活动数据，可以计算出单机容量应用于不同场景下链路的tps。但是，这种方式涉及到大量的人工干预，并且对每个应用程序的容量估计的粒度也比较粗。后来，支付宝搭建了容量分析平台，可以进行自动化细粒度的容量分析。它的原理是，如果我们把一个链路理解为一个服务，那么这个链路的根节点可以理解为该服务的源流量请求，每条链路上的节点（这里的节点包括applications、DB、Tair等。)可以计算出本节点调用次数相对于根节点流量的系数。因此，当服务源的QPS确定后，可以根据链路数据计算出各节点的QPS。2018年双十一，支付宝还构建了智能容量模型，不仅可以根据业务流量预估容量，还可以智能生成应用资源部署方案，使得在该方案下，部署单元可以承载给定的业务流量当容量水平在目标范围内时。智能容量模型是支付宝对AIOps探索的一部分，也是数据技术和人工智能在系统中落地的一部分。这方面也是目前支付宝技术探索的方向之一。3.LDC和弹性架构：大促的最强武器在预估了流量，做出了合理的容量规划之后，接下来就是看我们的架构能否支撑流量高峰。首先需要说明的是，流量高峰涉及一个系统的方方面面。支付宝整个系统极其复杂，针对toC和toB都推出了很多业务。即使只关注核心支付系统，也包括支付结算、记账、核算等子系统。系统部分组件由通用中间件支持，如负载均衡中间件LVS/Spanner、阿里巴巴分布式缓存中间件Tair等，其他由支付宝自研SOFAStack金融级分布式中间件处理。支付高峰的本质是高并发问题。互联网公司解决高并发的思路是横向扩展和横向拆分，采用分布式的方式来应对流量高峰。支付宝也不例外。支付宝很早就完成了服务化架构和核心数据库的横向拆分，成功应对了往年的双十一。分布式系统示意图这种架构的问题是所有的子应用程序都需要访问所有的数据库子数据库，但是数据库连接是有限的。在当时主流的商业数据库中，连接是不共享的，也就是说一个事务必须独占一个连接。连接是数据库非常宝贵的资源，不能无限增加。当时支付宝面临着应用集群无法再扩展的问题，因为每增加一台机器，都需要为每个数据分库增加几个新的连接，而此时的连接数为几个核心数据库已经达到上限。应用不能扩展，意味着支付宝系统的容量是固定的，不能再增加业务量。别说大促了，很可能连日常的生意都撑不了一段时间了。这个问题迫在眉睫。2013年起，支付宝开启新一轮架构转型，实施单元化LDC逻辑数据中心。双十一的流量高峰终于顺利度过。一个单元是带有所有内部器官的整个站点的缩小版本。它无所不能，因为所有应用程序都已部署；但它并不完整，因为它只能操作部分数据。这样，只要在单元中加入数据分区，就可以提高整个系统处理性能的上限。单元化示意图然而，并不是所有的数据都可以拆分。比如一些底层数据是全局数据，需要所有单元应用访问。而且，支付宝经过近十年的建设，有些结构还不能很好的拆分成单元。在此前提下，支付宝设计了CRG的单元化架构，既能发挥单元化优势，又能支持现有架构。1.RZone(RegionZone)：最符合理论单位定义的区域。每个RZone都是独立的，有自己的数据，可以完成所有的服务。2.GZone（GlobalZone）：部署了不可分割的数据和服务，RZone可能依赖这些数据或服务。GZone全球只有一组，数据只有一份。3、CZone（CityZone）：也部署了密不可分的数据和服务，RZone也会依赖它。与GZone不同的是，CZone中的数据或服务会被RZone频繁访问，每笔交易至少会被访问一次；而RZone访问GZone的频率要低得多。CZone专为解决异地延迟问题而设计。CRG架构示意图。关于支付宝单元化和LDC的更多信息，请参考这篇文章。LDC实施后，系统容量得到了横向扩展，成功支撑了2013年及之后的双十一流量高峰，系统不再受限于单点故障。五中心金融级架构。理论上，只要无限扩展LDC的计算资源，就可以处理无限流量。但这样一来，大部分机器只能在大促期间使用，平时闲置，造成资源浪费。平时最好用少量资源支撑常规流量，大促时通过容量规划提前使用一些闲置或第三方资源来应对高峰流量。这就是弹性架构的由来。2016年，支付宝开始改造大顺的灵活架构。弹性架构是基于业务链路的，因为只有部分链路在大促期间流量激增，所以只需要对大促的关键链路进行弹性扩容即可。弹性架构涉及多个层次的转换。首先，弹性机房和弹性单元需要在LDC逻辑机房架构中按照业务纬度继续切片，保证单片机业务可以部署在一个独立的逻辑单元，并保持与LDC的连通性无弹性单元，可随时弹射回收。二是弹性存储，包括管道数据和状态数据的弹性。流式数据包括支付订单。为了支持这些数据的弹性，创建一个弹性位+弹性UID，然后路由根据弹性UID分配顺序给弹性单元处理。基于状态的存储，比如用户的账户余额，是整体弹出的。具体实现方式是通过DB层的主备切换，将主库的压力转移到备库上。然后是中间件层面的改造，包括路由、RPC、消息队列、流量管理等等。应用层也需要做相应的修改，因为每个弹性单元需要作为一个独立的逻辑单元进行部署，所以需要从服务到数据进行梳理和剥离，增加elasticid等弹性逻辑处理。除了这些，运维平台和压力测试工具也需要做相应的改造。2016年弹性架构上线后，成功支撑了当年的双十一，满足了大促的要求和规划目标，节省了机房的物理资源，成为应对流量的最有力武器大促巅峰。弹性架构中的弹性单元都是新的集群，但实际上可以进一步提高资源利用率。方法是离线混合技术，因为有些集群是用来做离线大数据分析的，但是并不是24小时满负荷工作的。没有任务时，集群资源利用率极低。如果线下应用和线上业务应用一起部署，在大促高峰期利用这些资源，可以减少大促采购的资源，进一步节约成本。混合技术需要运维分时调度协作，在不同的时间段将资源分配给不同的应用。从2017年开始，支付宝开始尝试离线混合和分时调度技术，在大促期间利用离线技术使用的集群资源，大大提高了集群资源的利用率。4、百万支付：解决数据库扩容瓶颈2016年双十一期间，交易量峰值达到了每秒12万笔，而这场高并发之战仍在继续。上面提到的应对大促的技术手段有很多，但其实漏掉了一个最重要的环节，那就是数据库。在流量高峰期，数据库承受的压力最大。这是因为，在前台，我们看到的是一个成功的事务，但是拆解后，一个事务平均可能会产生几百甚至上千个请求，数据库的压力远大于我们看到的数字。从一开始，数据库就一直是支付宝系统的瓶颈之一。事实上，之前结合结构改造，对数据库进行了很多升级。除了上面提到的灵活改造外，还包括：1、分库分表，将原来的交易账库分离成交易库和账户库，通过分布式事务解决数据一致性问题。2.数据库水平拆分，所有用户按照1%的粒度分成100份，单元化逻辑隔离。3、数据库读写分离，多点写入，数据复制。通过这些方法，可以大大提高性能。早年支付宝使用的商业数据库，可以改进到一个极限。出于成本考虑，一年只有几天的促销活动，不可能额外购买数据库系统和设备。早在2014年双十一，支付宝自研数据库OceanBase就开始承担了双十一核心交易流量的10%，之后逐渐承担了交易、支付、账户等核心系统流量的100%，并且经受住了极端条件。严峻的考验。OceanBase从一开始就规划为分布式关系型数据库，天然支持大规模高并发场景。但是，支付宝本身用户太多，双十一面临的系统压力太大。到2017年双十一的时候，即使使用额外的弹性库，数据库CPU压力也会接近上限。成为持续扩张的瓶颈。2018年双十一，支付宝内部提出了百万支付架构，也就是说这个架构可以支撑每秒百万笔交易量级的系统压力。该架构的核心是OceanBase2.0分布式分区方案。以往架构下的DB扩容，由于DB单机是有限制的，一个UID最多对应一台机器，这里的扩容能力是通过给DB增加一个新的集群，增加一个应用和一个数据来实现的来源。这会带来一系列的问题，比如应用的内存增长，多数据源导致的弹窗费时费力，多DB集群日常维护成本高等。为了解决这个问题，考虑到DB也可以像应用一样动态扩展，必须打破一个UID最多一台机器的限制，这样应用和DB可以同时扩展，并且新建无需增加新的数据库集群能力即可实现容量支持。因此，基于DB的分区功能，大大增强了DB的扩展性，避免了不得不增加集群扩容的尴尬。同时对应用进行了相关升级，如全站序号结构升级、一系列中间件改造、任务钓鱼场景改造等。OceanBase分区架构传统的数据库弹性架构将数据物理拆分到不同的机器上，业务在数据接入/开发/后期维护和数据配套设施方面非常繁琐；同时，拆分后资源难以快速恢复，数据拆分聚合无法实现无损业务。与传统数据库的弹性架构相比，OceanBase2.0架构完全不侵入业务。内部通过分区实现数据分片的自组织和负载均衡，通过生成列和分区规则实现自动路由，通过分区聚合（partition_group）消除分布式分区。提高性能的事务性能开销，从而实现无损线性扩展。另外，数据分片之间的share_nothing架构实现了分片故障隔离和单点故障消除的高可用架构。2018年双十一，OceanBase2.0成功上线，支持所有交易和支付流量。而且，这种基于OceanBase2.0分区方案的架构可以轻松扩展到支持百万级交易，应对流量洪流的战斗也暂时告一段落。5、技术支撑：技术标准化大促双十一是新技术的练兵场，如何保证这些技术能够有效支撑流量高峰？尤其是支付宝，涉及到人们的资金安全。一旦出现问题，后果将极其严重，必须慎之又慎。2014年，支付宝推出全链路压测，成为系统技术验证的神器；2017年起，支付宝开始构建自动化、智能化的技术风险防控体系；上线后，大促相关的技术开始标准化。大促中控示意图大促中控也是大促的一站式保障解决方案。其目的是积累之前大促的经验，形成套路和规范，最终向无人值守的方向发展，搞大促不需要技术人熬夜。通过大促的中控，可以进行自动化的无损压力测试。在线压力测试虽然可以取得预期的效果，但不会影响正在进行的业务。其核心技术能力是环境、机器、线程的隔离，压测异常时的智能熔断。压测不是万能的，有些问题在压测中可能很难暴露出来。2018年以来，支付宝还开展了红蓝攻防演练，检查大促高峰出现异常时的应急策略、组织保障、反应速度等是否正确。到位，并验证新技术的稳定性是否达标。为了大促期间的资金安全，支付宝开发了资金实时验证系统，实现峰值资金安全实时验证，验证每一笔资金准确无误。当所有技术都准备就绪时，这还不够。在每次大促之前，还有很多配置需要切换。执行数百次配置自动化检查，以确认所有系统都已进入促销状态，以确保万无一失。随着时钟逐渐指向零，大促即将开始。6、未来可期。我们一直在一起。总结一下，双十一流量高峰考验的是架构的可扩展性、数据库的承载能力、运维强大的调度能力、完善的技术支撑能力。为了保证大促的顺利完成，需要做的技术准备远不止文中提到的那么多。全链路压测等幕后英雄众多。限于篇幅，这里就不一一介绍了。支付宝也在不断更新技术装备库。今年双十一，支付宝还有几项新能力经过实战检验：OceanBase2.2上线，该版本在TPC-C基准测试中获得第一名，稳定支持新品推广；推广阶段现已100%覆盖支付宝核心支付链路，是业界最大的ServiceMesh集群。随着普惠金融的落地和万物互联的发展，支付平台面临的流量压力将进一步加大。我们现在看到的高峰，未来可能会很常见；未来的峰值可能会比今天高出几个数量级。支付高峰之战还将继续，技术将不断更新演进。未来的双11科技大战将更加精彩。双十一不仅仅是一个购物节，更是互联网技术发展的推动力。期待2020年。
