背景
去年双十一，为了应对零点的峰值流量冲击，咱们在八月下旬启动了全链路压测第一次实践。因为从零开始，所以单独搭建了一套和生产1:1的环境，2个月的时间，光环境成本就高达几百万。html
通过双十一，压测团队从中汲取了很多的经验和教训。双十一以后，在CTO的指导下和支持下，由基架和性能测试团队快速的投入了全链路压测平台的研发当中。mysql
而且趁着核心系统重构，快速的接入落地，对后续的系统稳定性保障工做，迈出了坚决地一步。redis
流程导图
梳理阶段
一、系统服务梳理sql
全链路压测是一个很复杂的工程，其中涉及到多个服务。对整个业务系统进行梳理，确认流量传递的上下游和范围，是首先要作的事情。mongodb
二、核心链路梳理安全
什么是核心链路？如今来看，依然是一个艰难的选择。压测团队在梳理核心链路时，主要从以下几方面来评估：网络
1）是不是高频访问业务；框架
2）是不是强依赖的核心环节；elasticsearch
3）是否直接影响生产的交易业务；分布式
4）参考生产实际的QPS指标为维度；
三、外部依赖梳理
肯定核心链路后，要对其外部依赖进行进行梳理（好比第三方支付）。因为全链路压测在生产环境进行，所以须要对外部依赖进行mock处理，避免对生产服务形成影响。
四、中间件梳理
为了不压测流量对生产形成影响，产生脏数据，须要对整个流量传递过程当中涉及的中间件进行梳理，让压测流量透传落影子库。
压测流量模拟在请求网关接口时候在header中带上:x-infr-flowtype=PT，各个中间件路由逻辑以下：
mysql：影子库；
redis：影子key，前缀ptshadow_；
mongodb：影子collection,前缀ptshadow_；
kafka：不分topic，下游路由会进行相应路由；
rocketmq：不分topic，下游路由会进行相应路由；
hbase：影子namespace,前缀ptshadow_；
elasticsearch：影子索引，前缀ptshadow_；
分布式锁fusion-distributed-locks：影子key，前缀ptshadow；
准备阶段
一、接入fusion框架
全链路压测基于fusion，全部中间件和规范必须按fusion统一规范使用。
二、流量模型梳理
流量模型，也能够称之为流量漏斗。即外部流量从网关入口开始，在每一个调用链路上的变化比例。
三、mock模块配置
对于外部依赖调用的链路，经过mock手段，进行对应的处理。
四、影子中间件创建
在梳理阶段对全部的中间件梳理完成后，便可根据规范进行对应的中间件创建。
五、测试环境验证
完成上述步骤，须要在测试环境验证mock配置、流量标数据落影子库的正确性。
六、仿真环境验证
测试环境验证经过后，接入仿真环境，进行联调验证，确保没问题，才能开始进入压测阶段。
预热阶段
一、测试用户生成
因为全链路压测的特殊性，所以须要造一批专门用来压测的user数据。
二、测试数据准备
测试数据包含基础数据和参数化数据（压测请求传参所用），咱们的解决方案是经过定时的job来迁移生产数据并进行脱敏。
三、外部服务关闭
因为全链路压测的特殊性，所以在压测开始前，都会对外部服务进行服务注册下线，保证压测的流量不会影响生产业务。
四、分支代码发布
全链路压测是须要进行多轮的，这个过程当中每次优化均可能涉及到代码变动，所以在压测开始前，须要确认最新的优化代码分支发布到了仿真环境。
五、网络隔离检查
一样，因为环境的特殊性，压测前须要对各服务的隔离状况进行确认，避免影响生产业务。
实施阶段
一、单机单接口基准
单机单接口的基准压测是必不可少的环节。经过单机单接口压测，能够快速排查出被测链路自己的性能问题，这样有助于后续全链路压测的开展和性能瓶颈定位排查。
二、单机混合链路
混合链路压测的目的，在于验证被测服务自己的最大容量和安全水位，为全链路压测以及上线容量评估，提供参考依据。
三、全链路压测演练
全链路压测，是互联网企业系统稳定性的重要保障手段。
四、脉冲摸高测试
摸高压测，目的是为了验证当前系统的最高性能表现，便于评估线上扩容，留有冗余空间。
五、限流功能演练
限流熔断，是服务可用性的重要保障手段。咱们采用的技术框架是sentinel集群限流功能，并对单机、集群限流功能进行了演练，确保功能的可用性。
总结回顾
关键词：对技术&业务保持敬畏！
原文出处：https://www.cnblogs.com/imyalost/p/12524078.html