前言

之前断断续续写过一些全链路压测相关的技术文章，很多同学评价还不错。朋友建议我写个系列，基于自己的落地实践经验，对全链路压测做个系统性的梳理总结。

今年跳槽后我的工作重心也偏向了全链路压测和稳定性保障方面的研究，这个时间点写这个系列，也算是对自己过去工作的最好总结。

整体写作规划里，这个系列大概有14篇内容，不排除后期有新的理解和沉淀，会加更。目前草稿写差不多了，大体的更新节奏，应该是一周2篇左右的样子，静等更新吧。

 

目录大纲

背景：天猫2012双11的痛

全链路压测这个Topic，最初是阿里提出的，背景缘由也很简单，双十一大促嘛。

13年之前，阿里每次为了准备双十一大促系统能平稳支撑，都要花4-6个月准备，然后大促结束后花2个月时间打扫战场。

整个过程，参与的各个团队的同学加起来有将近200人，其中最耗时的点主要集中在机器容量评估和预案梳理以及压测优化方面。

结果2012年双11零点时刻，由于访问量过高，还是出了问题：商品超卖无法发货。这个问题当时还上了央视新闻，可见其影响力。

后来他们内部复盘，一番讨论后，为了避免后续的大促再次出现类似的问题，决定在生产搞压测，这就是现在被很多测试同学所熟知的生产全链路压测的背景由来。

 

定义：如何理解全链路压测

PS：这里的定义，是我自己基于自己对生产全链路压测的了解和实践总结得来的，仅代表个人观点。

1、什么是全链路压测？

基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行瓶颈调优，保障系统稳定性的一个技术工程。

2、全链路压测解决了什么问题？

针对业务场景越发复杂化、海量数据冲击，发现并解决整个业务系统的可用性、扩展性以及容错性的过程。

3、全链路压测创造了什么价值？

技术角度：降低成本、提高服务可用性、技术练兵&团队协作&快速响应；
业务角度：提升用户体验、技术更好的服务业务、创造更多业务价值。

 

差异：传统压测和全链路压测

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

随着不断学习成和工作中的实践以及和很多测试同学交流，我总结出了如下几点优点和潜在价值：

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

---

随着互联网行业不断发展，系统架构越发复杂，业务场景越发多样化，对性能测试的要求也越来越高，传统压测方式已经无法满足业务和技术的发展需要。

相比于传统的压测方式，全链路压测作为性能测试领域新阶段的最佳实践，它们的差异如下：

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

思考：解决差异带来的不稳定

传统压测和生产全链路压测的主要区别，概括来说可以分为如下四个点：

环境问题：主要是机器配置、节点数量以及一些参数配置方面（线程池、JVM）；
成本问题：单独的性能测试环境，机器成本和维护成本较高，生产在这方面几乎是0成本；
真实性问题：硬件配置差异、数据差异、中间件配置差异等，都可能导致流量预估和压测结果偏移；
数据流向问题：测试环境大多都是单接口单链路压测，数据流转性无法保证，数据多样性也存在部分问题；

---

那么，要解决差异带来的不稳定因素，最终的选择就是生产全链路压测：

 

挑战：如何落地生产全链路压测

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

1、链路梳理

现在大多数企业都是采用微服务架构来设计系统，且业务场景多样化，导致了系统架构异常复杂。

要覆盖所有压测范围内的场景，就需要对涉及的所有应用及其调用关系进行梳理。目前业内还没有较好的链路梳理工具，导致这个过程需要人肉来梳理，耗时且费力。

2、数据隔离

生产全链路压测最重要的一点是避免对生产数据造成污染。业内常见的做法有如下两点：

压测数据写入正式库表，然后通过特殊的字段进行清理（业务改造成本大，清理风险高，耗时久）；
采用影子库表，压测流量数据进行影子库表，在不对生产数据造成污染的情况下进行压测；

3、避免业务侵入

在全链路压测落地过程中，有一点必须考虑到的是业务部门的接受能力。如果要通过技术框架改造或者采用数据标记的方式来实现，势必会对生产业务造成一定影响（要改造是需要大量资源和时间的）。

4、性能定位分析

全链路压测是在生产环境进行，压测过程中，除了要防止数据污染，完善的监控体系和实时的可视化链路追踪也是很重要的一点。

不同企业在监控体系方面的建设都不一样，要进行全面详细的流量评估，需要有完善的监控平台来进行各维度的数据采集和展示。

在整个压测链路中，实时的可视化链路追踪能实时的观察到每个调用链路的具体信息，对问题的快速发现和定位有重大的帮助。

还要考虑到不把生产服务压挂。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。

5、更多挑战

全链路压测是在生产环境进行，压测过程中，要考虑不对生产服务造成影响。因此需要一套完整的机制来保证，压测在正常实施的同时，不对生产服务应用造成影响。

 

流程：生产全链路压测落地实践

生产全链路压测的整个流程，大致可分为三个环节，每个环节的主要事项如下：

能力建设：生产压测能力演变历程

生产全链路压测的本质，是个能力建设的技术工程，不是一蹴而就的。整体的演变历程大致如下：

1、需求驱动压测

这个阶段的主要特点是被动式响应压测需求，效率低，无法快速定位性能问题，结果对线上没太多参考价值。

2、性能体系建设

这个阶段主要是性能测试体系的建设过程，比如日常版本压测和性能基线性能回归等。

3、线上风险识别与熔断

到了这个阶段，就需要线上有一定的监控报警体系和风险熔断能力。

4、生产只读业务链路压测

只读场景相对来说技术难度没那么大，可以通过这个阶段来做到技术练兵。

5、生产流量数据隔离能力

上面提到了数据安全隔离，这也是生产全链路压测最大的一个技术挑战。

6、生产部分业务链路压测

全链路的覆盖场景根据业务不同要覆盖的范围和难度也不一样，建议先从非核心业务开始落地做试点验证。

7、生产全链路压测

通过上面几个步骤，从基础的能力建设、体系建设，到线上的监控能力、只读场景练兵以及数据隔离到试点验证，最终才能达到生产核心链路全链路压测的过程。

 

最后

以上内容主要是对全链路压测的背景及落地实践和演变过程做个介绍，后续的系列文章会针对每个环节进行讨论和说明，敬请期待。

建了一个全链路压测沟通交流群，目前群人数已超过100，想加群的同学请公众号回复关键字：全链路压测。

添加我好友，我邀请进群，加群请备注说明来意。

转载请注明出处，商用请征得作者本人同意，谢谢！！！