Amazon简介
每年我们在准备双11活动期间，容量规划最大的困难在于，评估从用户登录到完成购买的整个链条中，核心页面和交易支付的实际承载能力。全链路压测的出现改变了这一现状，通过应用系统改造使线上环境可以同时处理正常流量和测试流量，以支持线上不影响正常用户访问的集群读写压测，获得最真实的线上承载能力数据。全链路压测将大促稳定性保证提升到新的高度，是双11、双12等大促备战最重要的核武器，并且会持续发挥作用，为每一次大促的稳定性保驾护航。
全链路压测的价值
多年大促的考验
从13年全链路压测诞生，到现在全链路压测已经经历了6个年头，全链路压测从“贵族技术”逐渐成为喜闻乐见的方式。
线上单链路千万级流量输出
使用各种运营商（电信、移动、联通和教育网等）CDN输出压测流量，真实模拟用户从外网访问应用的使用场景，可以至少每秒千万级的压测流量。
线上DB读写能力
中间件HSF、notify、tddl、相关应用和数据库表进行全链路压测的改造，保证压测请求的写操作不会影响到正常表的数据，解决数据上的后顾之忧。
应用需要接入全链路压测平台，只需要将使用到的中间件升级到指定版本即可。
线上Tair读写能力
全链路压测的测试数据是从线上数据dump过来，虽然经过了清洗、过滤、脱敏的层层处理，还是会存在少量部分字段跟线上数据一样，当这个字段被用作tairkey的时候，会造成对线上tair数据的覆盖；应用当中使用其它方式来作为tair key的场景，一不小心也可能出现冲突的可能；我们每年都出现几起因为tair key覆盖相关的故障，甚至p1级故障，需要根治这个问题。tair-client支持逻辑隔离，主要是针对“走影子表”的压测流量的key统一加上全链路压测的前缀（_test）。今年已经常态化开启，彻底解决历史遗留的问题。
如果已经将tair-client的版本升级到指定版本（2016年的版本，向后兼容）之上，对业务不会有任何影响：
Tair-mc-client 2.0.21及以上Tair-client 2.4.106及以上（3.x版本不支持）Pandora sar 2_15_161221及之后版本
下面几种情况 有且仅对 压测流量产生影响：
① PUT和GET 有任何一方不在上述版本之上（PUT方和GET方同时满足，或者同时不满足 也不会受影响）；由于是2年前的版本，未升级的应用建议升级最新的sar包。
② PUT和GET 所带的流量属性不一样，比如PUT是“走影子表”的压测流量，而GET是正常流量；或者相反。这类情况是非常危险，强烈建议升级和改造！
监控：与Eagleeye完美结合
Eagleeye上压测大盘，在压测过程中，可是实时观测相关应用及其上下游应用的QPS、RT，tair和应用出错情况。
http://eagleeye.taobao.net:9999/RtChainDetail?chainId=4&time=&totalTime=3600000
贴合业务场景
自由控制压测模型，能够整合丰富多样的业务场景，众多链路并行压测，自由控制压测的量级。
支付宝对接
Amazon压测结构
Amazon包含了3个重要部分：压测控制台、压测控制器和压测引擎。
压测控制台：统一操作的WEB控制台，包括“链路管理”、“需求管理”、“压测控制”和“引擎管理”等模块。
压测控制器：管理和控制所有压测引擎实时状态的Master，接收来自压测控制台的操作，并对压测引擎发送指令，并接收压测引擎的状态反馈。
压测引擎：部署在CDN机器上，发送压测流量的实体，接收压测控制器的指令并执行相关的操作。
单链路压测流程
全链路压测的服务能力，完全开放给各个应用方自助使用，只针对单个应用或者某几个应用的线上压测，我们叫做“单链路压测”，由于压测的资源有限，需要针对压测的资源进行合理的分配，目前到的压测流程如下：
新增压测链路详情：包括链路的名称，所属应用，是否需要登录等基本信息；
新增压测需求：指定要压测的时间需求（起止时间），绑定vip，绑定压测链路，配置压测模型（链路和流量配比等）。另外，一个需求可以设置多个压测方案，应多多种压测场景。
提交压测需求：在提交需求之后，需求处于锁定状态，不可编辑，但是可以查看。
审批需求：系统管理员对提交到的需求审核，如有必要还会和需求提交人进行沟通之后，会作出“审批通过”和“审批不通过”的判断。审批不通过的需求解除锁定状态，需求提出人可以对需求进行变更，重复3；审批通过的需求就不能再变更。系统管理员会对各个需求的方案生成压测计划，并绑定压测机器资源。
压测控制：需求提出人或相关人员操作压测计划，执行压测。
说明：系统管理员对压测需求中的时间区间，需求中各个压测方案，分别评估压测的流量分配合适的CDN压测引擎。
衍生场景
如有任何问题、想法和合作，欢迎一起来探讨。
尖兵计划-常态化压测
基于灰度隔离环境，从线上腾挪少量机器到隔离环境（无线上流量，tair和DB复用线上）中进行小规模的“边压边弹”的全链路压测，产出各个应用的性能基线数据，以及最小单元应用容量配比。
在17年我们做了无人值守的尝试：
白加黑-白天单元隔离全链路压测
18年双11全链路压测，进行了13次，也就是通宵了13次，其中有一个星期连续通宵了3天，大家苦不堪言，幸福感极低。
整体方案：
全链路压测上云-PTS
性能测试服务（Performance Testing Service，简称 PTS）是卓越的 SaaS 性能测试平台，具备强大的分布式压测能力，可模拟海量用户的真实业务场景。2016 年 8 月正式发布的 PTS 全新版本，由阿里巴巴高可用团队倾心打造，核心能力基于服务阿里全生态多达 4 年以上的单链路/全链路压测平台。PTS 倡导零编码的业务场景式高仿真压测，目前也在快速迭代中。 通过 PTS，我们希望将性能压测本身的工作持续简化，将更多的精力回归到关注业务和性能问题本身，同时降低成本、提升稳定性、优化用户体验，最大程度地帮助企业提升商业价值。(https://help.aliyun.com/document_detail/29262.html)
网友评论