全链路压测
全链路压测是一种基于线上真实环境的，模拟海量的用户请求和数据，对整个业务链路进行各种场景的测试验证，持续发现并进行调优，保障系统稳定性的的一个技术工程。
为什么要使用全链路压测
1. 全链路压测被称为系统整体容量保障的核武器。
2.全链路压测可以实现生产环境的压测服务，模拟真实的生产峰值场景，以发现真实的线
上瓶颈并实现监控分析
3.全链路压测可以实现精准的容量规划，确保线上系统的正常运行。
4. 全链路压测可以实现海量的并发请求，以模拟真实的用户峰值场景。
5. 全链路压测可以实现压测流量和生产流量的隔离，避免对生产流量产生影响。
6. 全链路压测可以自动化压测，减少人工成本，并提高压测频率，快速发现问题。
全链路压测 VS 线下传统压测
全链路压测不是银弹
上面列举了很多个全链路压测的优点，看起来对我们有百益而无一害，但实际上目前很多企业都把全链路压测给整偏了。不管企业是大是小、系统是大是小，也不管成本高低，很多人都只是想实现全链路压测，摸到技术的风向标。
全链路压测的难点
管理协调
实际上，从整个全链路项目来看，企业里从老板到最底层的工程师，都会需要参与进来。也就是说，全链路涉及老
板、产品经理、架构师、开发工程师、测试工程师、运维工程师等各个角色。
不同岗位的关注点
老板关注的是，全链路压测带来的业务容量提升和企业利润增长；
产品经理要关注的是，业务容量的增长和后续功能的设计；
架构师要关注的是，全局架构设计对全链路压测的宏观支撑；
开发工程师要关注的是，业务细节和技术细节的改造；
测试工程师要关注的是，覆盖住这些改造；
运维工程师要关注的是，全链路改
造和线上的压测过程对系统整体状态的影响。
四个问题
在决定进行全链路压测的落地之前，我们要思考很多方面的问题:
1.企业有没有那么大的流量需求？
交易量级能否达到几十万、上百万、上千万 / 每秒的交易量
2.系统要不要做全链路线上压测？
线下压测是否已经可以满足需求？
3.系统能不能做全链路线上压测？
首先系统要有进行全链路压测的可行性，其次也需要进行多轮验证，也可能会多次压缩测试范围
4.组织支持不支持你做真正的全链路线上压测？
在决定进行全链路压测之前，我们需要理性分析它的实施成本和上层的支持力度。切忌在没有必要的航线上不断试错。如果企业确实需要做全链路压测，那就要把改造的细节列清楚，并计算出成本。
适合使用全链路压测的企业
如果企业需要解决以下问题，则可以考虑落地全链路压测：
1. 直接使用生产环境，避免了环境的差异性。
2. 实现高并发广域网压测平台，模拟了真实的用户场景。
3. 不用进行线下线上容量的推算。
全链路压测的两个改动
压力工具改造
这涉及到流量问题。如果压力场景需要超过万级每秒的请求量级，就得对压力工具进行改造了。
1. 压力发起部分：主要是多节点分布式的改造。
2.参数化部分：主要是数据量大引起的改造需求。在传统的压测工具中，基本上都是使用 Master-Slave 的方式，master 负责拆分参数化数据，但当数据量过大的时候，显然这是个问题点。
业务流量的改造和隔离
1.实现全链路的压测流量识别，从而实现隔离。
业务标识改造的目的是实现业务流量的隔离，业务流量隔离的目的是不让压测流量影响真实的线上用户。贯穿业务改造的关键是整个业务流的识别跟踪，最后还可以方便地进行数据的清理。
脚本改造
加上流量tag，以实现后续的流量隔离。这一点任何一个压力工具都只需要加个参数即可，没有复杂度。
应用服务改造
这是改造工作量最大的部分。改造要实现的是对流量标识的识别，再把请求旁路到相应的存储组件中去。
应用的改造主要是对现有的业务代码进行入侵式的改造，增加业务开发的工作量。
实现的手段就是跨线程透传，将压测流量写入 ThreadLocal 对象中。
中间件的改造
对于一些跨服务调用使用的中间件，由于需要对压测流量进行标识，所以也是需要改造的。
存储的改造
不管是缓存还是数据库、队列，都要对压测流量进行识别，以便隔离。目的就是不影响生产数据。
对缓存（比如 Redis)，我们可以实现不同的 key 值；对于数据库，我们可以实现影子表或影子库。
日志改造
将压测流量的日志和生产日志隔离开。
2.只在入口做压测流量的识别，直接旁路到另一套独立的链路中去（这里的硬件可以共用，但是会增加部署的复杂度）。
只要在网关做压测流量的识别即可，后面交给Devops。
全链路对监控的影响
我们知道线上生产系统是必须有监控的，因而全链路压测不涉及太多对监控系统的改造，它更多的是工作量的增加，例如增加影子库这样的监控点。
对于一些改造后并没有增加节点的技术组件和模块来说，在监控上则没有影响。
