成都建设网站价格,企业网站管理系统登录,购物网站建设成本,公司网站建设作用和过去10年一样#xff0c;2019年天猫双11又创造了一个全新的纪录。 这个数字背后#xff0c;是数代支付宝工程师们殚精竭虑、不断突破技术难关。
今年双11之前#xff0c;小编邀请到11位经历双11的技术同学口述实录#xff0c;特别筹备了纪录片《一心一役》#xff0c…和过去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 探索的一部分也是对数据技术和人工智能在系统中落地实践的一部分这方面也是当前支付宝技术探索的方向之一。
LDC与弹性架构大促最强武器
对流量进行预估并进行合理的容量规划之后接下来就看我们的架构是否能支持流量峰值了。
首先需要说明的是流量高峰涉及到一个系统的方方面面支付宝的整个系统极其复杂而且面向toC和toB都推出了很多业务即使只关注核心支付系统也包括支付清算、账务、核算等子系统。
系统部分组件由通用型的中间件提供支撑如负载均衡中间件LVS/Spanner、阿里巴巴的分布式缓存中间件Tair等其它则由支付宝自研的SOFAStack金融级分布式中间件负责。
支付峰值的本质是一个高并发问题互联网公司解决高并发的思路是横向扩展水平拆分用分布式的方式来应对流量洪峰支付宝也不例外。支付宝很早完成了服务化架构和核心数据库的水平拆分成功应对了前几年的双十一。 分布式系统示意图
这个架构的问题是所有子应用都需要访问所有数据库分库但是数据库连接是有限的。当时主流的商业数据库连接都不是共享的就是说一个事务必须独占一个连接。而连接却又是数据库非常宝贵的资源不能无限增加。当时的支付宝面临的问题是不能再对应用集群扩容因为每加一台机器就需要在每个数据分库上新增若干连接而此时几个核心数据库的连接数已经到达上限。应用不能扩容意味着支付宝系统的容量定格了不能再有任何业务量增长别说大促很可能再过一段时间连日常业务也支撑不了了。
这个问题迫在眉睫从2013年开始支付宝开始新一轮的架构改造实施单元化的LDC逻辑数据中心双十一的流量峰值终于还是成功的扛下来了。
一个单元是一个五脏俱全的缩小版整站它是全能的因为部署了所有应用但它不是全量的因为只能操作一部分数据。这样只要将数据分区增加单元就可以提升整个系统的处理性能上限。 单元化示意图
但是并不是所有的数据都能拆分比如部分底层数据是全局数据所有单元的应用都需要访问。并且支付宝经过近十年建设有些架构也并不能很好的拆分成单元。在这个前提下支付宝设计了CRG的单元化架构既能利用单元化的优点也能支持现有的架构。
RZoneRegion Zone最符合理论上单元定义的 zone每个 RZone 都是自包含的拥有自己的数据能完成所有业务。GZoneGlobal Zone部署了不可拆分的数据和服务这些数据或服务可能会被 RZone 依赖。GZone 在全局只有一组数据仅有一份。CZoneCity Zone同样部署了不可拆分的数据和服务也会被 RZone 依赖。跟 GZone 不同的是CZone 中的数据或服务会被 RZone 频繁访问每一笔业务至少会访问一次而 GZone 被 RZone 访问的频率则低的多。CZone 是为了解决异地延迟问题而特别设计的。CRG架构示意图
关于支付宝单元化和LDC的更多信息可查看这篇文章。
实施了LDC之后系统容量实现水平扩展顺利支持了2013年及之后的双十一流量洪峰并且系统不再受到单点故障限制经过完善之后还做到异地多活最终形成了三地五中心的金融级架构。
理论上只要无限扩展LDC的计算资源就可以应对无限大的流量但是这样做的话大部分机器只有在大促时才能派上用场平时就是闲置的造成资源浪费。最好能做到平时用少量资源支持常规流量大促时经过容量规划提前启用部分空闲或第三方资源应对高峰流量这就是弹性架构的由来。
2016年支付宝开始为大促进行弹性架构的改造。弹性架构基于业务链路因为大促时只有部分链路的流量激增因此只需要针对大促关键链路进行弹性扩容即可。
弹性架构涉及到多个层面的改造首先是弹性机房和弹性单元需要在LDC逻辑机房架构上按照业务纬度继续切片保证单片业务可以独立逻辑单元部署并保持与非弹性单元的联通性并且可随时弹出和回收。 其次是弹性存储包括流水型数据和状态型数据的弹性。流水型数据包括支付订单为了支持这些数据的弹性创建了弹性位弹性UID然后路由根据弹性UID将订单分配至弹性单元中进行处理。状态型存储比如用户的账户余额进行整体弹出具体实现方式是通过DB层的主备切换将主库压力分流至备库。
然后是中间件层面的改造包括路由、RPC、消息队列、流量管理等等。应用层面也需要进行相应的改造因为每个弹性单元需要做到独立逻辑单元部署因此需要从服务到数据进行梳理并剥离同时添加弹性id等弹性逻辑处理。
除了这些之外还需要对运维平台、压测工具进行相应的改造。
2016年弹性架构上线后成功支撑了当年双十一满足大促要求和预定目标节省了机房物理资源成为应对大促类流量洪峰最有力的武器。
弹性架构里的弹性单元都是新增的集群但其实还可以进一步的提高资源利用率。方法就是离在线混部技术因为有些集群是用作离线的大数据分析但并不是全天24小时都满负荷工作当没有任务时集群资源利用率极低。如果将离线的应用和在线的业务应用部署在一起让大促高峰时段能够利用这些资源就可以减少大促期间采购的资源进一步节省成本。混部技术需要运维的分时调度配合在不同的时段将资源分配给不同的应用。
从2017年起支付宝开始尝试离在线混部和分时调度技术在大促时利用离线技术所使用的集群资源大大提升了集群资源利用率。
百万支付解决数据库扩展瓶颈
2016年的双十一交易笔数峰值达到12万笔每秒这场高并发之战仍在继续。 前面提到了很多应对大促的技术手段但其实漏掉了一个最重要的部分那就是数据库。在流量洪峰时受到压力最大的就是数据库。这是因为在前台我们看到是一个成功交易但拆解之后一个交易可能平均要产生数百甚至上千个请求数据库的压力要远远大于我们所能看到的数字。
从最开始数据库就一直是支付宝系统的瓶颈之一在之前其实已经配合架构改造对数据库做了诸多升级除了上面提过的弹性化的改造还包括
分库分表将原有的交易账户库分离为交易库和账户库并通过分布式事务解决数据一致性问题。数据库水平拆分将所有的用户按照1%粒度分为100份配合单元化的逻辑隔离。数据库读写分离、多点写入、数据复制通过这些方式可以大大提升性能。
早年支付宝采用的商业数据库能进行的改进是有极限的为了成本考虑不可能为了一年仅仅几天的大促活动去采购额外的数据库系统和设备。
早在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分区方案的这套架构可以轻松扩展到支持百万级交易关于应对流量洪峰的战役暂时告一段落。
技术保障大促技术标准化
双十一是新技术的演练场那么怎么确定这些技术能有效支撑流量高峰呢特别在支付宝涉及到人们的资金安全一旦发生问题后果极其严重更是要慎之又慎。
2014年支付宝上线了全链路压测成为系统化技术验证的神器从2017年起支付宝开始打造自动化和智能化的技术风险防控体系2018年的双十一大促中控上线大促相关的技术开始走向标准化。 大促中控示意图
大促中控也就是一站式的大促保障解决方案它的目的就是将之前大促的经验沉淀下来形成套路和规范最终向无人值守方向发展搞大促不需要技术人再熬夜了。
有了大促中控可以进行自动化的无损压测线上压测能得到想要的结果的同时不影响正在进行的业务。它的核心技术能力是对环境、机器、线程的隔离以及在压测异常时的智能熔断。
压测并不是万能的有些问题可能在压测中难以暴露从2018年起支付宝还展开了红蓝攻防演练为了在大促峰值出现异常时检查应急策略、组织保障、响应速度是否到位以及验证新技术的稳定性是否达标。
对于大促中的资金安全支付宝自研了实时的资金核对系统实现峰值的资金安全实时验证验证每一笔资金准确无误。
当所有技术准备就绪并不是就可以了每次大促之前还有很多配置需要切换一旦出错就会造成严重影响因此支付宝打造了面向终态的技术风险巡检能力在大促前一天进行成百上千的配置自动化检查确认所有系统进入大促状态确保万无一失。
随着时钟渐渐指向零点大促一触即发。
未来可期我们一路同行
总结起来双十一流量峰值考验的是架构的可伸缩性、数据库的承载能力、运维的强大调度能力以及完善的技术保障能力。为了确保大促顺利完成需要做的技术准备也远远不只文中提到的诸如全链路压测这样的幕后功臣还有很多由于篇幅所限这里就不再一一介绍了。
支付宝也在持续更新着自己的技术装备库。今年的双十一支付宝也有几项新能力得到实战检验OceanBase 2.2上线该版本在TPC-C基准测试中取得第一名平稳支撑了新大促自研的Service Mesh 首次登上大促舞台目前已经 100% 覆盖支付宝核心支付链路是业界最大的 Service Mesh 集群。
随着普惠金融的落地以及万物互联的发展支付平台面临的流量压力会进一步提升。现在我们看到的峰值未来也许稀松平常未来的峰值也许比今天还要高几个量级。支付峰值这场战役仍会继续下去其中的技术也将不断的更新进化未来双十一的技术之战将更加精彩。 原文链接 本文为云栖社区原创内容未经允许不得转载。
