背景

去年双十一，为了应对零点的峰值流量冲击，我们在八月下旬启动了全链路压测第一次实践。由于从零开始，因此单独搭建了一套和生产1:1的环境，2个月的时间，光环境成本就高达几百万。经过双十一，压测团队从中汲取了不少的经验和教训。双十一之后，在CTO的指导下和支持下，由基架和性能测试团队快速的投入了全链路压测平台的研发当中。并且趁着核心系统重构，快速的接入落地，对后续的系统稳定性保障工作，迈出了坚定地一步。

流程导图

梳理阶段

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集群限流功能，并对单机、集群限流功能进行了演练，确保功能的可用性。

总结回顾

关键词：对技术&业务保持敬畏！