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