在之前的分享中，介绍了关于什么是全链路压测？介绍了为什么要在线上环境中实现全链路压测，如何对链路流量进行分离等内容。那么如何能够模拟出这样超大规模的流量来进行全链路压测，这是一个值得我们思考的问题。

试想在单链路压测的场景下，可以用到的工具有Apache JMeter、Apache AB等等一些工具，并且做测试的同学还会有自己开发的一些简易的小工具，当然这些工具都是在实际使用过程中进行单机部署的，使用的是多线程的方式来模拟用户操作。以Apache JMeter为例，能够瞬间提供的流量是有限的，根本无法模拟出线上环境中的那些流量。那么如何做才能模拟出线上的并发流量呢？

建设模拟数据的构造平台

在之前的分享中，我们提到了压测数据与真实数据的分离，其实如何能够模拟出这些压测数据是能否实现全链路压测的核心内容。因为提到了如何区分压测数据，如何标记压测数据，如何存储压测数据等等。

从图中可以看到，要想实现全链路压测，首先需要解决的就是数据构造问题，笔者经历过银行核心系统的压测，几乎都是自己准备测试数据，并且遇到一些主键ID不能重复的场景还需要去用压测工具进行调整，并且配置文件这些都是需要手动的进行调整，参数少的情况下还行，但是参数一多的话就容易给搞混了。

很显然，这种方式效率非常低下，并且极其消耗人力物力，基本上都是搞到凌晨四五点的事情。所以不要怪测试运维的同学，是确实这个事情比较麻烦。

既然这么麻烦，后来就有了一些自动化的测试脚本，然后笔者也开始学习Python语言，逐渐的一些小规模的测试就形成体系了，就能将很多的内容归类起来进行重复性的利用。也就逐渐单车变摩托了。

简单总结一下，在进行数据构造平台建设的时候需要考虑到如下的三个问题。

• 将线上的数据备份下来，进行脱敏、修正然后导入到一个测试环境的数据库中。
• 将流量进行标记，可以让测试数据准确的落库到测试数据存储的数据库中
• 将数据准备好之后，就是将对应的参数文件调整到每一个服务实例中，这个过程是自动化的

如何建设自己的全链路压测系统？

重复造轮子，这件事情，只有在现有的技术或者是能力不满足业务要求的时候，才需要进行自研，自己搞出一套属于自己的东西。一般情况下如果有现成的东西就不需要自己耗费精力去研究这些！因为在你建设过程中可能遇到的问题，别人在建设过程中一定会遇到，所以没有必要去自己再去采坑。

现在很多的技术都是开源的，所以在很多大厂中，所使用建设的压测系统也都是经过借鉴的。

一般来讲如果想要去建设一个自己的全链路压测系统，需要从如下的几个方面入手。

• 管理控制台
• 任务编排服务
• 流量压力模拟
• 系统性能监测
• 压测数据采集

压测任务编排

这里以Dubbo框架来举个例子，在很多公司业务系统中都是采用Dubbo来作为RPC框架，所以可以使用Dubbo的RPC调用来进行通信。例如我们要对一个真实场景进行压测，那么任务编排的作用就是为任务分配ID、分配操作内容、以及如何调用流量模拟器，任务编排结束之后，就会更改注册中心对应的配置，当配置的Agent监测到发生变化之后，就会拉取编排好的任务。然后进行数据预热进行压测。测试数据下发的数据都是从数据构造平台中进行获取的。

压测流量模拟

压测流量的模拟可能是一个压测系统中大家最为关心的内容，在上面，我们也提到了关于单机环境下的压测流量模拟，其实底层无非就是调用了一些HTTP的接口，发送了一些数据请求。并且我们也知道，一般的压测模拟都是通过多线程来进行模拟的。

其实在全链路压测过程中所模拟出来的流量与之类似，只不过就是多了几个Agent来模拟流量罢了。

并且在压测的同时，为了更好的演练出系统的动态扩容等操作，我们需要引入压测数据采集的Agent对于一些数据进行采集，通过实时的分析处理，来动态的调整一些参数，基本上可以做到于线上环境模拟出来的流量是一样。

压测预警

当压测数据出现异常的时候，监控系统一定是要报警的，例如会发送一些告警的短信、邮件等等、为了避免这种情况的出现，一般进行压测的时候，运维的同学会对这块内容进行手动的调整，以便能找到一个合适的点位，来配置参数。

总结

上面介绍了如何在线上环境进行全链路压测，当然在实际操作过程中，可能还会遇到其他的问题，就如笔者上面提到的那种，如果在现有开源平台能够满足的情况下，就用开源平台，如果没有的话，就需要适配自己的业务进行自研。