“双11”核武器——全链路压测详解

以下是精彩视频内容整理： 

“双11”对于阿里而言是一场保障系统稳定性的实战。用有限的成本实现最大化的集群整体吞吐能力，带给用户畅爽的极致购物体验，这依靠阿里多年技术沉淀下来的一套高可用架构基础设施，也就是阿里系统稳定性保障的“核武器”——全链路压测。它的重要作用不仅体现在“双11”购物狂欢节，而且横向拓展到高德，优酷，钉钉等非电商的应用形态。 

全链路压测平台由阿里巴巴中间件技术部高可用架构团队提供，该团队同时负责包括容量规划、准入控制、限流降级、流量调度、弹性伸缩等高可用架构的基础设施，主导的同城容灾、异地多活、单元化体系建设支撑阿里巴巴电商链路的分钟级故障切换和业务稳定运行。

 全链路压测在阿里

企业高可用架构涉及线上管控，故障演练，异地多活，全链路压测。与全链路压测相关的有容量规划，弹性伸缩和线上压测。

阿里的运维体系横向分了规模化、稳定性、监控、变更和资源五部分，全链路压测所处位置在稳定性部分。

分布式服务化复杂的线上环境包括CDN、网关、负载均衡、分布式页面系统等，技术生态十分丰富，在这样的环境下任意节点都可能成为瓶颈、出现短板、暴露问题。以阿里“双11”活动为例，从2009年到2017年业务增长呈指数型增长趋势，这使得系统的可用性面临更加严峻的挑战。

一些小而美的中小企业面临的挑战会更加夸张。像系统容量、基础技术设施瓶颈、中间件瓶颈、业务性能以及系统之间依赖的影响等众多因素都缺乏有效的验证手段。

 2013年以前没有全链路压测，重大活动保障时对业务目标进行拆分，在做单个系统的容量规划时，所有的依赖环节能力是无限的；然而实际发生流量洪峰的时候，很多后端系统流量过不去，带来了零点秒杀时候被限流这种不好的用户体验。

全链路压测平台，作为大促稳定性最重要的“核武器”，经过2013年到现在5年的沉淀，已经承载了阿里生态里几乎所有业务线，而且用来重点保障“618”、“双11”、“双12”等重大活动的高稳定性。全链路压测平台每年承载整个阿里生态内全/单链路的压测数在10000次以上，每年“双11”单个项目上通过全链路压测识别到的全局各种性能瓶颈问题均在400个以上。

 全链路压测的价值不止于满足业务带来的挑战，更在成本方面带来极大的收益。一方面是节约机器成本，另一方面是人力成本：

1.机器成本，不同业务形态需要的容量配比不同，业务行为对不同模块的挑战不一样，通过全链路压测找到短板，把系统水位拉平，用最少的机器承载业务模型。

2.人力成本，全链路压测之前，几百个系统从夏季甚至春节过后就开始准备“双11”的技术优化，全链路压测之后，通过压测动态调整资源，做到“变压边弹”，既省时省力，又更加精准。

 全链路压测和PTS

上图是全链路压测整体方案架构图。压测数据，压测场景，压测执行是给施压人员提供的交互页面，通过场景编排，流量构造去做压测前期准备。通过任务下发，部署于全球各地的CDN节点可以最大程度模拟用户场景真实性。通过EDAS 、ARMS 监控，快速帮客户识别到性能问题，找出调用链路问题所在，生成压测数据性能报告。

全链路压测是一个模拟线上环境的完整闭环，由5大核心要素组成：

1.压测环境：对应用户真实的线上环境，具备数据与流量隔离能力的生产环境；

2.压测基础数据：构造满足大促场景的核心基础相关数据（如买家，卖家，商品信息），影子库里构造相同量级的数据；

3.压测流量（模型、数据）：成百上千的接口组合，到复杂的接口之间的参数传递，复杂的条件判断来构造精准的全局流量模型，和真实业务情况保持一致；

4.流量发起：模拟全国各地真实的用户请求访问，探测站点能力；

5.问题定位：多维度的监控和报表，服务端可通过其他生态产品协助定位。

全链路压测闭环中主要体现三种能力，分别是：

1.翻译构造能力：便捷的构造全局业务场景和流量数据的能力。不需要编码，直接通过页面拖拽操作就可以完成场景构造。

2.模拟掌控能力：最大程度还原真实用户发起流量的能力，压测过程流量发起节点是全国CDN。压测过程中的问题无法预知，目标量级内随便调节每条链路并发或TPS能力，且极低误差，上千万TPS情况下做到1QPS误差。

3.展现定位能力：客户侧的体验级监控，报表提供能力，服务端快捷的定位能力。

上图为典型电商场景测试实景图，纯界面化卡片拖拽编排业务模型。抽象出链路的最小单位，应对于大家理解的API，接口，URL……进而抽象出一批指令（比如思考时间、集合点、条件跳转、cookie存取、全局准备、并发用户限制等），链路配合指令就能模拟全局用户行为。后续会做更业务化的封装/数据工厂，降低理解成本，未来运维同学自己就可以完成产品编排。

 全链路压测面临的新挑战

随着全链路压测在阿里生态体系内和业界其它公司的实践，有一些问题开始凸显：

1.对内对外对架构有不同要求。

2.并发还是PTS。金融、保险、传统制造类、互联网公司与阿里对并发的理解不同。阿里衡量系统性能时倾向于TPS，也就是1秒处理多少笔。

3.理解成本是否可以继续降低。更好的将行业里的固定形态业务进行封装。

4.计费问题。当深度封装使应用性提高到一定程度的时候计费就变成了偏底层的指标，中间的转化对产品和账单体系、监控报表上提出了很大的挑战。

阅读原文