。

最近的几次大会上#xff0c;也有不少关于全链路的议题。

之前有朋友在面试过程中也有被问到了什么是全链路压测#xff0c;如何有效的开展全链路压测。

今天我们就来聊聊全链路压测#xff0c;但本文不会涉…要说当下研发领域最热门的几个词全链路压测

肯定跑不了。

最近的几次大会上也有不少关于全链路的议题。

之前有朋友在面试过程中也有被问到了什么是全链路压测如何有效的开展全链路压测。

今天我们就来聊聊全链路压测但本文不会涉及到具体的技术栈文章最后会附相关的链接主要讲讲全链路实践的理论问题。

其实进行全链路压测对于整个公司技术要求还是很高的没有一定技术沉淀的公司最好不要贸然尝试全链路压测因为如果没做好可能会把生产环境搞宕机所以对于没有一定科技能力的公司还是尽量不要贸然追潮流实施全链路压测。

为什么需要全链路压测

先说说为什么需要全链路。

随着业务的发展技术架构从原来的单体架构发展到现在的微服务架构

应用越来越多给研发人员定位问题带来的困难也越来越大。

在单体架构时期只要查看一个应用的日志就能大体知道问题出在哪里。

但是在微服务架构下基于前端返回的错误信息你如何从那么长的应用链路中找到出错的应用找不到具体的应用你如何查看错误日志

也许你熟悉业务可以大概猜测出问题在哪里但这毕竟存在不确定性。

在这种场景下我们就需要一个服务治理平台来帮助我们展示业务的全链路调用关系并能通过某个ID查询出某个请求在业务平台中流转过程。

这里提到的服务治理平台至少要包含功能有服务的注册与发现服务状态的可观测以及流量管理。

目前主流的服务治框架有spring-cloud框架dubbo框架以及service

mesh框架。

基于服务治理我们就可以具体的观察到请求在不同应用之前的流转再结合统一日志平台我们就可以快速定位到是哪个微服务出了问题就能针对性的去做排查这就是全链路跟踪也是开展全链路压测的第一个基础。

在说清楚了为什么需要全链路后我们再谈谈不同架构下对于性能测试的要求有哪些不同。

在不同的架构阶段对性能测试的要求也不一样简单来说可以分成4个不同的阶段

我们通常说的全链路压测指的就是第4阶段业务发展到这个阶段时会面临以下几个棘手的问题

单体业务的性能已经得到基本的保证了但是在这么长链路上哪个环节会出问题并不清楚不同业务模块的流量并不完全相同如何保障核心链路的资源配置成为重点但是这个在测试环境是无法有效模拟的如何找出集群的性能短板避免因某个服务的配置问题、性能问题引起集群的性能雪崩成为重中之重

保障重大活动的系统稳定性引入全链路压测平台后我们就可以有效的保障公司重大活动的系统稳定性因为我们是以生产环境的配置为基础真实的模拟用户行为。

所以在解决完全链路压测中发现的问题后理论上我们是有信心能够保障活动期间的系统稳定性

精准的容量评估基于线上全链路的性能压测和监控我们会清晰的看到流量洪峰来临时每个业务的流量情况就可以有针对性的做出容量评估提高系统资源的利用率。

端到端的全链路巡检第一时间发现故障并快速定位问题基于全链路压测我们可以做到完全的端到端检测发现业务集群中的性能瓶颈及时定位并解决问题不产生遗留死角。

建立公司的性能运营体系将运动式的性能优化演化为自发的日常性能优化当全链路压测体系建立起来后就可以作为常规的测试手段来进行日常测试使性能测试常态化规范化。

哪些业务场景适合做

不知道大家注意到没现在落地了全链路压测的公司基本上都是电商公司都存在高强度的交易和支付高并发场景。

因为全链路平台的搭建是个高成本的活动所以我们要思考哪些场景合适引入全链路测试主要有以下几种场景

有强并发的支付交易场景包含各类大促场景目前全链路压测的落地实际多出于此类头部公司例如淘宝、有赞、滴滴、美团等。

需求正常迭代完成并测试通过上线后又出现各种各样的系统故障的情况可以适当引入全链路压测。

这种情况一般是由于线上线下的硬件资源配置相差较大在线下无法正确评估性能资源的使用情况引起的。

基础技术组件

既然全链路压测有这么多优点我们是不是可以大力的推广落地呢这也是很多面试官喜欢问这个问题的由来。

但我们清楚任何一种技术都不是银弹能解决所有问题。

在文章开头我们提到了全链路压测对于整个公司技术有较高的要求需要公司全体研发人员一起配合才能有效的落地否则就是空中楼阁。

团队在落地全链路压测时至少需要考虑以下几个问题:

全链路压测平台不单单是测试部门或者说测试中台的事它基本上会涉及到公司所有的核心业务如果不是那也没必要做这需要业务部门的技术配合和改造那么在KPI已经很紧张的情况下如何说服业务部门配合你做改造呢从某些方面来说这个并不会影响他们自己部门的KPI改造的不好反而还会影响业务风险较大。

如何做好数据隔离

在生产环境上做压测绝对不能对真实用户的数据造成影响那么就需要做好数据隔离业务侧的系统需要能够识别哪些是真实流量哪些是压测流量。

目前业内通用的做法有两种流量标识或者影子数据库这都需要对业务代码做改造。

流量如何分发

想要实现全链路压测那么压力的发起就不能照搬单体性能测试那样通过自己写脚本来发起压测。

需要通过研发并发能力更强可控性更高的方式来发起流量。

目前业内主流的方式是基于Netty框架做改造通过NIO的方式发起流量。

流量的来源一般是录制上线的真实请求并对数据加以清洗。

这需要通过改造中间件来实现。

Mock服务能否支持

在全链路的压测过程中必然会接触到第三方的服务短信、支付、第三方接口等等如何有效的拦截这些服务并返回正确的数据。

而且还不能让Mock服务成为压测中的性能瓶颈对Mock服务自身的性能要求也会很高。

在全链路压测的过程中是否能够建立起有效的、全方位的监控机制能够第一时间发现问题是否有分级、分层监控方案当发现TPS上不去后是否能够方便的定位到大致是哪里出了问题否则全链路压测开展起来就没太大的意义。

毕竟是在生产上做压测如果某个服务被压跨了是否有足够的应对方案如果发生不可逆的故障中间件很容易压出问题如数据库宕机、MQ数据堆积、Redis穿透等等运维团队是否能够有效支撑到位快速恢复业务呢

通过以上问题可以看出落地全链路测试涉及到研发的各个部门并不是测试人员单方面的事甚至于可以说和测试人员没什么直接的关系。

当我们想要落地全链路时我们需要考虑清楚团队是否有足够的底层技术来支持。

05小结

全链路压测是一项综合技术要求很高的实践场景需要整体IT团队在积累了各种前期的技术储备后共同协作完成并不是某个部门或者团队的事需要有人整体的协调和统筹才能真正落地。

作为测试人员我们要了解全链路压测是在做什么并且能大体知道是怎么做的需要用到哪些技术能力再结合团队的具体技术能力分步骤、有选择的去推动和落地。

而不是一味的追求直接就上全链路压测同时这是一项更依赖集体的活动哪怕你技能再强也不可能一个人完成这项工程需要分清个人能力和公司平台哪个更重要。

对于面试过程中的问题我们可以针对的讲讲实现全链路的前因后果理清楚技术栈和实现思路即可。

实战案例

光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。

如果对你有帮助的话点个赞收个藏给作者一个鼓励。

也方便你下次能够快速查找。

如有不懂还要咨询下方小卡片博主也希望和志同道合的测试人员一起学习进步

我的自动化测试开发之路一路走来都离不每个阶段的计划因为自己喜欢规划和总结

测试开发视频教程、学习笔记领取传送门