聊聊传统压测和全链路压测的区别

前言

记得刚开始学习性能测试相关知识的时候，我一直有个疑问：性能测试能对测试工程师本人和企业带来什么价值？

随着不断的学习成长和工作中的应用实践以及和很多业内同行沟通交流，我总结了如下几点性能测试的优点和价值：

提升测试工程师的技术能力；
提升对系统架构和业务逻辑的了解；
提升测试工程师在职场和求职市场的竞争力；
提前发现系统潜在的不稳定因素，提高线上系统稳定性；
更精准的流量评估和容量规划，降低系统的硬件成本和维护成本；
保障系统在大促秒杀等场景和峰值流量冲击下的稳定性，助力业务目标达成；

全链路压测的衍生和挑战

随着互联网行业不断发展，系统架构越发复杂，业务场景越发多样化，对性能测试的要求也越来越高。

传统压测方式已经无法满足业务和技术的发展需要，全链路压测，就是在这样的背景下应运而生的。

作为性能测试领域新阶段的最佳实践，全链路压测在更多公司被探索和应用的过程中，也遇到了种种挑战。

传统压测和全链路压测的区别

相比于传统的压测方式，全链路压测在性能测试领域，有其独到的特殊性：

压测类型	传统压测	全链路压测
压测工具	Jmeter、Locust、Loadrunner	压测集群、流量引擎、录制回放
承接方式	需求响应式，被动	发现系统所有链路存在的瓶颈点，主动
压测环境	测试环境/性能环境	生产环境
环境特点	环境不稳定/配置低/压测结果参考性不高	环境稳定/完全真实环境/压测结果真实可靠
压测场景	单机单接口、单机单链路、单机混合链路	包含覆盖范围内的所有核心链路及场景
压测过程	可观测性较低，延时较高	实时可视化观测
测试结果	数据维度小，无法提供太多数据便于分析	提供多维度细粒度的数据，便于快速定位问题优化
投入成本	需要搭建单独的压测环境	完全线上生产环境进行，无须单独搭建环境

以我之前工作过的某银行信用卡中心为例，当时也是传统压测占大多数。要完成一次完整的压测，需要经历下述多个环节才可以完成：

业务研发部门提出压测需求，压测团队和业务方沟通后确认是否执行；
业务部门提供压测范围、涉及链路接口、数据并且准备相关的铺底数据和参数化数据；
压测团队和运维DBA沟通，准备相关的压测环境，开通防火墙及临时访问权限；
压测团队调试脚本，有问题需要业务研发协助定位解决；
开展压测，通过nmon、JDK自带工具获得压测数据，然后导出进行图表绘制，进行性能问题初步分析；
和业务研发、运维以及DBA沟通，一起排查定位问题；
优化发布后，再次验证（这个环节要持续多轮）；
压测完成，统计压测结果，手动编写压测报告；

上述过程还只是在测试环境进行压测，不仅耗时费力，还无法对生产环境的性能评估有足够的建议参考。每次上线特别是大促阶段，还是提心吊胆的怕出问题。

全链路压测落地过程中的挑战

虽然全链路压测解决了传统压测过程中的种种痛点，可以为线上性能评估提供更多详实的参考建议。但在落地过程中，全链路压测依然要解决很多问题，主要有如下几点挑战：

链路梳理：现在大多数企业都是采用微服务架构来设计系统，且业务场景多样化，导致了系统架构异常复杂。要覆盖所有压测范围内的场景，就需要对涉及的所有应用及其调用关系进行梳理。目前业内还没有较好的链路梳理工具，导致这个过程需要人肉来梳理，耗时且费力。
流量评估：不同企业在监控体系方面的建设都不一样，要进行全面详细的流量评估，需要有完善的监控平台来进行各维度的数据采集和展示。
数据隔离：生产全链路压测最重要的一点是避免对生产数据造成污染。业内常见的做法有如下两点：
全链路监控：在全链路压测实施过程中，实时的可视化监控监控是很重要的一点。在整个压测链路中，能实时的观察到每个调用链路的具体信息，对问题的快速发现和定位有重大的帮助。
- 压测数据写入正式库表，然后通过特殊的字段进行清理（业务改造成本大，清理风险高，耗时久）
- 采用影子库表，压测流量数据进行影子库表，在不对生产数据造成污染的情况下进行压测；
服务保护机制：全链路压测是在生产环境进行，压测过程中，除了要防止数据污染，还要考虑到不把生产服务压垮。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。

我在上家公司推动落地生产全链路压测的过程中，就遇到了上述的几点挑战，且这个过程也踩了不少坑。

当时我就在想，能不能有这么一个产品：既可以不对现有业务进行改动，又可以方便快捷的完成链路梳理、流量评估、数据隔离，同时还要能做到全链路监控和压测过程的服务保护？

一次偶然的机会，我了解到了开源全链路压测平台Takin。

开源全链路压测产品:Takin

最开始了解到Takin，还是因为全链路压测相关的事情。大概20年初，我正忙于前司的全链路压测落地的事情，网上找了很多方案和实践，但大多都是空泛的概念。

后来接触到数列科技，看了他们的产品功能介绍，和他们技术负责人也聊过几次，给了我很多启发。

恰好今年，他们的全链路压测产品Takin开源了，下载试用了一番，体验不错，是从实际的生产实践角度出发来解决实际的问题。

Takin是什么？

Takin是国内知名的系统高可用专家数列科技的核心产品，是基于Java语言开发的一套生产全链路压测系统。

可以在无业务代码侵入的情况下，嵌入到各个应用程序节点，实现生产环境的全链路性能测试，适用于复杂的微服务架构系统。它的实现原理如下：

Takin有什么优势？

业务代码0侵入：在接入、采集和实现逻辑控制时，不需要修改任何业务代码；
链路自动梳理：仅需部署客户端，无需对应用进行任何改造，就可以看到所有的服务调用关系，快速理解系统架构，并且通过链路架构图可以详细了解链路经过的应用、缓存、中间件、DB，甚至第三方的API，每条链路的所有走向都一目了然；
数据安全隔离：在不污染生产环境业务数据情况下进行全链路压测，可以对写类型接口进行直接的性能测试；
安全性能压测：在生产环境进行性能压测，对业务不会造成影响；
性能瓶颈快速定位：性能测试结果直接展现业务链路中性能瓶颈的节点；

Takin的接入难度大么？

从我个人的使用体验来说，6月25日开源的版本，从下载安装配置，到正常的run起来，大概用了1天左右。

相比于复杂的全链路压测实践来说，这点时间已经很短了，但对于没有太多生产全链路压测实践或者技术比较薄弱的测试同学来说，难度稍微有点高。

前两天和他们技术负责人聊了会儿，了解到他们已经在做了一次重大更新，不仅优化了安装部署的步骤，修复了老版本的一些问题。

这次还开源了链路自动梳理和多环境模式压测支持的功能。下面是他们本次更新做的一些优化点：

一键安装部署，有效降低接入成本；
链路自动梳理，快速理解系统架构；
多环境模式压测支持，满足不同使用需求；

相比于之前，这次的更新，对很多测试同学来说，差不多几个小时就能安装部署好，run起来。

Takin能否应用在测试环境？

生产环境进行全链路压测，实际上对于大部分企业来说，是很难落地的，一方面是业务量级是否真的需要，另一方面是投入产出比。

不过测试环境做全链路压测，对于很多测试同学来说，反而是很好的选择。数列科技这次开源的更新内容里，针对不同环境开展压测，做了专门的优化更新，大概原理如下：

主要特点如下：

通过链路自动梳理架构图，帮助测试同学理解业务架构，不依赖开发也能搞清系统架构；

高效收集压测过程的全部机器信息，无须跨多个系统获取；
压测报告可定位出异常服务节点，辅助测试同学定位性能问题；

老_张

君子藏器于身，待时而动。