全链路压测改造

全链路压测是基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

全链路压测针对是线上真实环境，主要的目的是针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。简单来说就是为了快速准确找出系统的优化点。

全链路压测听起来很好，各个大厂都可以找到相关的博客或者分享文章，但是要实施全链路压测需要很大的工作量，对于系统需要进行改造。

由于全链路压测涉及整个技术生态，不同的公司使用的技术和基础设施各不相同，所以改造内容也不同，但是大致的改造是类似的，主要在以下几个方面：

流量标记

流量标记的作用是让所有服务或者说是代码在任何一个时刻都能知道当前是否为压测。因为实际业务中链路一般都比较长，从头开发这样的一个功能还是比较复杂。

目前大部分系统为了全链路追踪一般都是用了OpenTracing标准的某种实现，那么在OpenTracing中的Span中的Context就是一个绝好的信息载体。

对于对外暴露的HTTP API请求，需要从URL中获取到压测信息，然后将其传递到RPC或者其他调用层，RPC层依次传递对应的标志就行了。

RPC框架

RPC上的改动比较上，主要是需要用上下文传递压测标记。这里可以用RPC框架自带的上下文，当然用OpenTracing的比较方便，这一步改动不大。

数据库中间件

既然要做全链路压测，那么肯定不能只测试读接口，对于写接口，需要考虑到数据隔离的问题。

这个时候影子表是比较合适的选项，影子表是与真实表对应的一个概念，与真实表同构，只是名称不同。在 MySQL 的innodb引擎中，影子表与真实表存储的文件不同，但是共用buffer pool。总体而言，影子表的使用是安全，能够有效模拟真实表，同时又能起到逻辑隔离的效果：

数据库中间件需要支持的是影子表偏移的，而且还需要支持配置，因为根据业务和系统情况，并不是所有表都需要影子表，而且影子表的偏移各不相同。

其次就是和影子表有关的其他改造，比如初始化，预热，buffer pool恢复，数据构造和数据清理等都是需要考虑的。

MQ中间件

MQ中间件主要是两个问题，一个是压侧标识传递，另外一个是队列隔离。

日志组件

日志组件上主要是压测流量日志是否需要打印特定标识，是否需要单独的降级开关。

线程池

业务系统或多或少用到了线程池，而线程池一般都需要改造用于支持压测标识的传递。

Mock

一个完整的业务流程很难只和自己的系统打交道，外部系统一般不纳入压测中，比如第三方保险/语音电话服务/短信等等，有时候也会遇到下游系统并没有准备好加入压测链路，所以需要Mock。

具体的Mock返回数据要根据情况创造。

降级

降级并不是全链路压测必须的，但是提供降级开关可以在压测出现问题的时候中断部分接口，依然执行全链路压测，以免压测失败。