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