共计 5896 个字符，预计需要花费 15 分钟才能阅读完成。
中通快递作为国内出名综合物流服务企业，已间断 5 年稳坐行业市场份额榜首。受双 11、618 等大促流动影响，井喷式的业务流量对中通的零碎稳定性提出了更高的要求，过来的压测计划曾经无奈满足业务倒退的需要。测试环境等比缩放导致压测失真、宏大且简单的零碎链路梳理等都是辣手的问题，让咱们一起看看中通是如何利用大促零碎稳定性保障利器 Takin 来实现这项艰巨的工作的。
背景
目前在中通性能测试次要分为线上和线下压测两种计划，在重复实际过程中咱们慢慢发现这两种计划都有着各自不足之处，且为压测工作带来了很多不便。以下就线上和线下压测的有余剖析，谈谈中通是如何一步步改良压测计划并解决问题。
- 线下压测计划中的有余
在线下压测试过程中，为了缩小与实在环境物理资源上的差别，公司采取的是针对 CPU 与内存进行等比缩放的策略，如果是计算密集型利用，线上环境总的 CPU 核数为 80，线下压测环境总 CPU 核数为 8 核，则为 10:1 的线上线下等比缩放策略，如果是 IO（目前只看内存）密集型利用，线上内存总量如果为 80G，线下压测环境内存总量为 8G，也同样是 10:1 的线上线下等比缩放策略。
很显著这种等比缩放策略在高 TPS 指标的压测场景下会失真，TPS 指标越高，则失真越重大，因为咱们并不能对网络、中间件、数据库等一系列的因子也同样做出等比缩放。
- 线上压测计划中的有余
在线上压测时，多以读接口为主，只有相当大量的写接口会做线上压测，这大量的写接口通常也须要被压利用的开发人员进行代码革新，以防止大量的压测数据对业务数据造成净化。
所以这种线上压测形式无奈大范畴利用，同时这种对代码硬革新的形式，也减少了压测老本与危险，导致大家通常不违心面对线上压测，更不必提联结上下游一起进行线上全链路压测了，而这种不敢在线上大量压测的思维，也导致更多压测被放在线下以等比缩放的形式进行，其结果则是压测后果的失真，在 2012 年，某厂正是因为测试环境等比缩放压测，导致网络流量数据失真，引发了线上故障，才促使其下决心走上了线上全链路压测的路线。
- 引入技术解决方案
因为有上述问题，公司引入了线上全链路压测产品，其特点是应用压测 JavaAgent 探针以字节码形式植入利用，这样业务利用则毋庸硬编码，就能够自动识别和兼容压测流量，并进行分流，将缓存和存储数据存储到影子区域，实现物理隔离压测数据，防止造成生产数据净化，就技术计划上看，线上全链路压测产品最外围的性能其实就是两点：流量染色与保障数据安全，示意图如下：
全链路压测部署 & 外围配置
线上全链路压测 agent 装置部署
- 将 pradar-agent.zip 包上传到须要接入利用所对应的服务器 /home/admin 目录下，并间接解压.
- 批改对应利用的启动脚本(通常在公布平台中批改)，将批改后的前面这个命令增加到 java -jar xxx.jar 的 -jar 之前（-javaagent:/home/admin/pradar-agent/agent/pradar-core-ext-bootstrap-1.0.0.jar -Dpradar.project.name= 该利用利用名）
- 重新启动利用
在 pradar-web 操作页面的利用治理页，查看是否胜利上报：
agent 装置齐全成后，在具体实施时，如果压测入口是 http 接口，则在申请头中带上“User-Agent：PerfomanceTest”，如果入口是 dubbo 接口，则在 AttachementArgs 中带上“p-pradar-cluster-test：true”，agent 会将这类申请自动识别为压测流量，它会将压测标识向上游利用传递，并将数据分流到利用所配置的影子资源中，例如 redis 的影子 key、影子数据库（表）、rocketmq 上配置的影子 TOPIC 及生产组等等，由此将压测数据与正式数据进行隔离，防止了压测数据对正式业务数据的净化。
- 次要影子资源的配置
缓存 redis 的影子资源，在探针辨认为压测流量时，会主动对要写入或者查问的 key 前加上 ”PT_” 前缀来进行数据隔离，而 MQ 的 TOPIC 与生产组影子资源，须要在公司的 ZMS 配置核心，按业务 TOPIC 与生产组名称，去新增出带 ”PT_” 前缀的 TOPIC 与生产组名即可。数据库资源的配置会简单一些，上面独自阐明。
影子库配置如下图所示：
影子表配置如下图所示，都是把业务表名前加上“PT_”来示意为影子表，多个表应用逗号分隔：
- 挡板的配置
在线上压测时，有可能会触发到资金扣款或者短信发送等敏感办法，如果大量的压测触发了这类办法，轻则造成骚扰，重则产生重大的资损，相似这样的办法，咱们则须要在梳理压测链路时进行辨认，并为此类办法加上挡板（Mock)，如下图示例，如此当压测探针辨认到压测申请 (有压测标) 时，则会执行咱们针对此办法所配置的 Mock 代码，如果是正式的业务流量（无压测标），则依然会执行原来的短信发送办法而不受影响。
链路接入与压测流程
做线上全链路压测，很多人放心的一个问题就是，线上生产环境就这么间接压，不怕出问题么，那么除了进行错峰压测以外，中通压测团队为了平安有序的进行线上全链路压测，通过两期接入我的项目的摸索，曾经造成了一整套保障平安压测的施行流程，流程图如下:
全链路压测能够大抵分为三个阶段：
1. 需要定义与链路梳理阶段；
2. 测试环境部署及测试阶段；
3. 线上压测及后果产出阶段。
- 需要定义与链路梳理
需要定义
- 明确压测的具体业务链路与范畴边界
- 明确压测的目标，是达到指定性能指标，还是摸高进行容量布局
- 具体的性能指标，tps(每秒申请数)/rt(响应工夫)/ 成功率 /SA(以 99% 为例，指 99% 的申请响应工夫都在设置的 rt 范畴之类, 也就是 RT 的达标率)
链路梳理
链路梳理是全链路压测最为重要也是最外围的环节，通常这个环节的品质，将影响全链路压测的整体施行效率。接下来具体说一下，链路梳理的目标步骤与须要拿到的要害信息
链路大图
首先须要梳理出链路调用大图，刚开始不须要太细，但须要对入口 / 进口 / 利用名 / 数据库 / 缓存 / 中间件 / 资金影响 / 邮件 / 短信等，相似这样的一些要害信息能梳理到，因为窃密手册的起因，具体的链路图，这里就不放出了，能够用本文最下面的《压测流量链路示意图》进行脑补。
详细信息收集操作手册
依据下面梳理的梳路大图，进一步明确具体细节，须要收集如下信息：
- 利用根底信息与部署信息
- 链路模块 - 指的是这次需要所确定的压测链路
- 利用名 - 利用名称，在 jvm 中设置时 -Dpradar.project.name 的 value 内容
- 利用负责人 - 个别为利用的主开发人员
- 运维 - 能够进行 agent 安装包上传与装置，并查看 agent 相干日志的零碎运维人员
- 测试负责人 - 此利用的测试人员
- DBA- 能够进行数据铺底，影子库表创立，数据库性能监控的 DBA 人员
- 性能指标 - 本次压测的指标
- 利用的调用链类型与接口 - 指的是在全链路压测中，本利用在整个链路调用中所通过的接口办法名，以及对应的接口类型，在理解这个信息时，应该要理解分明这些接口办法的作用与逻辑，以此判断出是否须要对其加挡板(mock)，是否须要进行一些测试数据初始化的筹备工作。
- 启动容器 - 例如 tomcat 或者 jar 形式间接启动
- 实例数量 - 次要是对测试环境与线上环境的实例实进行统计，须要所有实例全副装置 agent，不然可能导致压测数据流入到正式的数据库表中。
- 利用入口信息与相干依赖信息
- 入口 - 压测的入口
- 数据库 jdbc 连贯信息 - 次要是数据库的类型，连贯的域名（或者 IP），端口，数据库名称，用户名与明码等相干的信息。
- 用到的表 - 发动压测后，调用流经到该数据库时，会读哪些表，会写哪些表，数据逻辑是什么，都须要搞清楚，以不便判断怎么造出测试数据，是用影子库形式还是用影子表形式。
- 文件门路 - 是否会在读写文件的相干信息.
- redis 预设值 - 发动压测后，调用流经 redis 的业务与数据逻辑，比方面单的单号是从 redis 中读取的，则咱们能够依据压测量，在单号寄存的 redis 中预设（铺底）一批测试单号数据，留神对于 redis 中预设测试数据，须要思考过期工夫，另外测试数据的 key 键是在正式的 key 值前加上 PT_来作为影子 key。
- mq 的 topic- 如果波及到 mq，则须要建设影子 topic 与影子生产组，办法都是在正式的 topic 与生产组前减少 PT_来作为影子 topic 与影子生产组，须要特地留神的是，影子 topic/ 影子生产组与正式的 topic/ 生产组都须要在同一个集群。
- es 索引 - 在正式的 es 索引前，加上 PT_作为影子索引.
- hbase- 正式表前加上 PT_作为影子表.
- 不良影响 - 在明细信息收集过程中，须要梳理出此利用是否会有产生理论的资金 / 电话短信邮件 / 网安数据上报等一系列，有可能因压测而造成的不良影响，针对这些不良影响的调用办法，则须要以加挡板 mock 的形式绕开。
至此，整个链路的业务，技术，数据信息都曾经理解得根本分明了，那么在这个根底上，则能够参考上一节中《全链路压测部署 & 配置》相干的内容，在测试环境将整个全链路压测环境给部署与配置得当。
- 测试环境调试
全链路压测，向上追述，个别总是能找到一个页面或者 APP 入口，那么必然对应着一个 http 的接口，所以为了示意这个申请是全链路压测的影子申请，须要在 http 头中减少 User-Agent:PerfomanceTest，如果入口就间接是一个 dubbo 入口的话，则在 dubbo 的 Attachment Args 里减少 key:value 为: p-pradar-cluster-test:true
当咱们在测试环境察看到压测流量都按咱们的预期，落入了相干的影子资源，而没有产生数据落入正式资源的状况后，咱们能够在测试环境进行大量数据的压测，如果一切正常，咱们就能够开始着手进入线上环境的压测流程了。
- 线上压测及后果产出阶段
筹备阶段
- 提前准备线上必须的影子库表，铺底数据，影子 topic/ 影子生产组建设等须要 DBA 与运维部门撑持的后期事项。
- 提前在 pradar-web 操作页面的利用治理页对利用的相干配置进行配置操作。
- 依照《中通 - 全链路压测上线打算模板.xlsx》编写上线打算，并招集相干人员 (运维，DBA，开发，测试，我的项目 PM) 评审，提前约定灰度上线，全量上线，试跑压测用例，正式压测的相干工夫节点。
灰度验证
将 agent 安装包上传到相干利用的其中一台机器上，如果有预发机，最好是上传到预发机器，而后由开发在公布平台中批改 jvm 配置，配置好 agent 相干的参数，重新启动灰度机器，察看 12 小时以上日志，是否失常。
全量上线与试跑
如果灰度没有问题，则告诉运维，将 agent 装置在利用的所有机器，全量重启指标机器。
如果一切正常，则能够应用压测脚本进行线上试跑了，试跑计划应在上线打算中提前布局好：
正式压测
- 压测场景配置
注：压测试场景配置最好在灰度公布后，就开始进行
在 pradar-web 操作页面的零碎流程中创立一个流程（一个入口只须要创立一次）：
在操作页面的“业务流动”中创立一个业务流动，并与下面的“零碎流程”进行关联
在“压测治理”->“压测场景”中，创立一个压测场景，在业务流动中，将上一步中创立的业务流动减少进去，能够减少多个业务流动，以表明同时压测多个流动的场景，如果有数据文件且数据不能够重复使用的状况，能够抉择多个 IP 后，对此 csv 数据文件勾选“拆分”操作，最初还须要关注的是正式压测，须要应用“阶梯递增”模式，则您的 Jmeter 脚本中须要以 ”bzm-Concurrency Thread Group” 形式创立线程组。
- 压测执行
确认了压测工夫与相干人员后，编写压测打算，并告诉到相干人员按计划执行，同时要特地留神压测入口域名是否受到 CDN 与防火墙的流量限度，如果有，须要提前找运维与网络的撑持人员将压力机 IP 退出白名单。
所有准备就绪，则按计划执行压测即可，在“压测场景”中点“启动”，正式发动压测。
压测后果
以某场景为例失去如下压测报告：
漏数检测
除了个别性能测试都要进行的监控以外，进行全链路线上压测试时，最大的区别是咱们大量应用了影子数据库表，影子数据库表用于与正式数据库表进行测试数据的隔离，且压测数据咱们都会加上辨认标识，比方 PT 结尾的订单号都是压测数据，但因为各种起因，大量的压测数据可能会导致部份或者全副压测数据被谬误的写入了正式数据库表，从而净化了实在环境的数据，导致各种生产故障，因而有必要实时的检测是否有测试数据被谬误的写入了正式数据库表，以便及时的进行压测行为，并疾速对进入正式库的谬误数据进行荡涤纠正，将损失降到最低。为此，咱们本人基于对数据库 binlog 的监听，设计了一套能实时监控压测数据对生产数据造成影响的工具，原理图如下：
全链路压测实际的思考
应用压测探针形式进行线上压测以来，咱们曾经在订单，运单，面单等多个业务共 62 个利用中进行了接入，胜利反对了双 11&618 大促与淘宝 & 拼多多等大流量联结线上压测的场景，尽管初步能解决原来压测中存在的问题，但也引入了一些新的问题。
- 组织与工作模式问题
先看看某大厂 BU 进行全链路线上压测的简化版组织及工作模式架构图：
中通全链路线上压测组织与工作模式图：
全链路压测系统接入简直牵扯到整个产研团队的各个方面，须要开发、测试、运维及供应商等团队充沛配合协同工作。
图一中某大厂因为订单全链路压测属于公司级重点项目，由上至下的推动相干零碎革新和对立协调资源，各我的项目由开发负责人挂帅，开发、测试、运维相互配合，性能团队属于撑持团队，负责压测计划评审、工具反对、压测问题记录与答疑。
图二中咱们的模式，全链路压测属于部门级我的项目，由性能测试团队负责主导，对接各方推动接入工作，其余相干方属于配合工作人员，性能测试团队须要协调各方资源，工作难度较高。
- 其它问题
手工操作过多，自动化水平太低，比方探针的版本控制与部署，施压机的主动创立与调配等。
流程推动线下化，没有造成对立治理的配置项、查看项、评审等流程在线化推动。
测试脚本与测试数据在线化对立治理及可复用水平底。根本靠压测人员自行保护。
压测所积攒的后果数据，无奈在线造成压测基线自动化比照，无奈达成压测后果在工夫线上的可视化统计与剖析。
最初
中通通过引入全链路压测，确实解决了原来压测环境等比缩放压测的失真问题，然而，在面对整个在订单，运单，面单等多个业务共 62 个利用的压测，单从上下游数据层面交互就是一项简单的工作，另外还须要各个环节的人员合作等、工作量及复杂度是可想而知的。因而，此项工程并非一天两天能全副解决的，路漫漫其修远兮，前面咱们还将通过发动性能专项翻新流动，将公司性能测试总体价值推向更高阶的档次。
