全链路压测探索实践之路

背景

去年双十一,为了应对零点的峰值流量冲击,我们在八月下旬启动了全链路压测第一次实践。由于从零开始,因此单独搭建了一套和生产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集群限流功能,并对单机、集群限流功能进行了演练,确保功能的可用性。

总结回顾

关键词:对技术&业务保持敬畏!

本文来自投稿,不代表TakinTalks稳定性技术交流平台立场,如若转载,请联系原作者。

(0)
上一篇 2021年4月19日 下午4:05
下一篇 2021年4月19日 下午6:01

相关推荐

发表评论

登录后才能评论