在开始全链路压力测试之前，还需要梳理核心链路，准备测试数据，改造系统，染色流量。改造一些旧系统并不容易，往往涉及到各种复杂的业务集成，改造成本相对较高。
1、整理核心链接
第一步是整理。梳理系统中的业务场景，找到支持和实现业务场景信息流的链接，有助于我们知道要测量什么。一般来说，业务系统中有很多场景，用户当然不会平均访问每一个场景。因此，在进行全链路压力测试时，用户集中使用的场景对应的服务之间调用的链接通常是我们需要整理的核心链接。这个整理过程并不难。从调用入口开始，我们可以找到其他需要调用的服务接口。只要确定了这些调用关系，我们就可以获得技术核心链接。通常需要通过程中的第二次分析。
第二步是记录。记录确定的核心链接中的服务调用关系，记录分支业务等信息，标记需要参与性能测试的场景，标记不需要参与测试的场景，方便后续工作的跟进。随着业务系统的不断进化和变化，需要及时更新与核心链接相关的文档。
第三步是隔离。隔离核心链接中不能参与性能测试的部分，如第三方支付接口、短信网关接口、物流运输系统等。这些系统的性能需要第三方自己保证。隔离时，可以考虑根据接口契约将第三方系统替换为Mock系统。
2、准备测试数据
在产品环境中，线上真实数据通常用于全链路压力测试。在线数据的多样性可以使测试覆盖系统中更多的被测场景和代码路径。当然，在使用真实数据时，有必要对它们进行脱敏处理。在线数据的获取方式主要如下。
提取系统日志，恢复用户的访问请求，并在系统中回放。高峰期日志更具代表性。
使用SQL脚本从产品环境中的数据库中提取数据并进行改造，改造后的数据可以作为压力测量数据。在线数据包含各种用户敏感信息，如身份证号码、手机号码、家庭地址等。在测试之前，这些数据应该脱敏(批量更换数据，增加随机数量等。).此外，在线数据还包含临时信息，如临时信息，需要用有效的信息替换，以便系统可以重复使用和执行。
在全链路压力测试中，基于性能的数据水平应与产品环境中的数据水平一致，并根据在线业务增长率提前准备半年或一年的数据。如果新业务上线，可能暂时没有线上数据作为参考，那么基于性能的数据水平需要人工预测。性能测试数据需要定期清理。一般来说，我们通过编写脚本来自动清理。如果长时间不清理，测试结果会受到影响。
3、改造系统并进行流量染色
在测试环境中进行性能测试时，自然不需要担心测试过程对产品环境用户的影响，也不需要考虑测试数据的隔离。在产品环境中，测试数据必须隔离，否则会污染在线数据，我们已经反复提到过很多次了。如何在不影响产品环境的情况下实现测试数据？测试请求和真实请求需要通过增加性能测试请求的染色标志来区分。
对常用的HTTP调用接口微服务系统而言，在HTTP请求的Header中加入特殊标记，以提示HTTP服务器这是一个测试请求，这是一个不错的选择，不影响请求数据，侵入性也很小。这个想法也可以在使用其它协议向微服务系统发送请求时使用。
在接收到包含染色标志的请求后，HTTP服务器会立即将请求转发给业务处理模块。这些模块涉及缓存层、线程池、数据库、日志等环节。为了保证带有测试标志的请求和产品环境数据的分离，有必要对这些模块进行相应的更改。在处理过程中，要防止测试标志丢失，因为一旦标志丢失，后续处理模块就无法区分数据的实际身份是测试数据还是真实用户数据，这将直接影响产品环境下的用户体验。
全链路压力测试改造系统涉及HTTP服务器、应用程序代码、消息队列、缓存层、数据库等环节，最终将测试数据写入影子表、影子日志目录。在改造过程中，首先要识别阅读界面和写入界面。阅读界面不涉及测试数据的隔离操作，隔离主要针对写入界面。改造的内容主要包括以下几个方面。
线程池。以Java语言为例。当测试请求进入线程池时，应将测试标记写入线程的ThreadLocal变量中，以便测试标记随线程传递到下一个处理环节。
缓存层。缓存层存储了大量用户经常访问的数据，可以加快用户访问速度。测试过程中产生的数据可能会冲走用户正在使用的缓存数据。因此，有必要将缓存服务器隔离出来，并将测试数据写入其中，从物理上将测试数据与实际业务数据分开。
影子库和影子表。改造数据库有两种方案——影子表和影子库，具体选择哪一种应根据实际情况而定。
影子表创建在产品数据库中，复制产品数据库对应表的结构，保证相同数量级的初始数据。一般来说，我们在影子表的名称后面添加一个特殊的后缀来区分它。创建影子表不仅成本低，而且不需要单独购买数据库的使用授权。但由于影子表和业务表共享内存等资源，在测试过程中可能会对产品环境产生一定的影响。
影子库是我们创建的一个与产品环境相同的独立数据库。由于它是独立的，在测试过程中对产品环境数据库的影响很小。由于它是独立的，它需要购买数据库的使用权，并建立相应的硬件基础设施，这导致投资成本更高。
消息队列。当测试数据进入消息队列时，有两种可能:一种是根据业务情况丢弃；第二，将测试标记传输到其他模块进行处理。
日志模块。当测试日志与真实用户日志混合时，分析和调查非常麻烦。我们通过建立影子日志目录来改造日志模块，以便于区分测试日志数据和真实日志数据。
模块，如搜索引擎。搜索引擎或BI（BusinessIntelligence，商业智能)分析系统，可以读取产品数据库，扫描和提取数据。防止影子表、影子库的数据在此过程中被扫描。
在系统改造过程中，任何环节的遗漏都可能导致测试标记的丢失。为了避免测试过程中标记的遗漏，还应验证测试数据的隔离效果。在正式开始全链路测试之前，应在测试环境中进行全面的演练测试，以确保性能测试过程符合设计预期。验证过程分为四个步骤。
测试环境验证的单一要求:在测试环境中部署改造后的系统，发送单一要求验证测试标记的流通是否符合预期，数据是否写入影子表和影子日志目录。
在测试环境中验证多线程要求:从产品环境中提取数据并进行脱敏处理，在测试环境中使用这些数据，并使用多线程并发测试。在线数据的多样性可以使测试覆盖更多的代码路径。
产品环境验证的单一要求:由于线上环境和测试环境的配置不同，在测试产品环境时，还需要发送单一要求进行验证，以确保测试数据在线各个环节的准确隔离。
多线程请求在产品环境中验证:利用线上脱敏后的数据在产品环境中进行性能测试。所有数据应在测试前备份，以确保测试中出现问题时数据能够及时恢复。
4、测试过程和测试监控
在产品环境下进行全链路压力测试时，虽然我们选择了业务的低峰期，但在整个压力测试过程中，我们仍然需要随时关注系统的所有指标，以避免影响在线用户的正常使用。在实施过程中，我们通常选择光滑的压力测试方法，而不是从一开始就发送所有的测试请求，以避免系统被压垮。在接下来的测试过程中，一旦系统出现异常行为，如果响应过慢或错误率超过预期标准，应及时停止增加访问流量，消除异常问题。
在全链路压力测试过程中，需要对系统服务器、数据库、接口业务处理等信息进行实时收集，作为测试系统是否正常的依据。除了常见的服务器资源使用，监控内容还包括系统中各微服务接口响应结果的正确率、响应时间、每秒请求数等信息。系统的处理能力也可以从业务处理维度进行监控，包括每秒创建订单数量、每秒交易次数、订单失败率等监控指标。监控内容还包括系统日志中的异常信息和消息队列中间件的实时处理。
5、验证异常处理方案
全链路压力测试可以检查系统的流量限制和降级措施是否正常。微服务系统通常会对超出预期的流量进行特殊处理，如限制流量或按顺序分别处理，以确保大多数用户的正常使用。另一种方法是降级，这意味着当流量达到峰值时，系统会根据设置自动停止一些不重要的服务，以确保核心业务的正常运行。当系统流量恢复正常时，重新启动其他业务。
事实上，测试环境中的性能测试在整个测试工作中占有很大的比重，因为在测试环境中，我们有足够的权限使用和部署机器，以便于定位一些性能缺陷。越早发现缺陷，修复缺陷的成本越低。因此，测试环境中的性能测试是必不可少的。测试环境中的性能测试可以无风险地发现程序级问题，而产品环境中的性能测试是对生产系统容量的低风险准确评估，两者相辅相成。如果不在测试环境中进行性能测试，系统可能会在产品环境中频繁出现性能故障。