以前有和认识的同行聊过他们全链路压测的一些技术实现方案，本身也看了不少相关的资料，这篇博客，说说本身对全链路压测的理解，以及整理的一些知识点。。。html
PS：主要罗列的是问题点，以及对应的一些解决方案，仅供参考。。。ios
相关连接：nginx
阿里全链路压测服务器
有赞全链路压测架构
京东全链路压测app
饿了么全链路压测负载均衡
美团全链路压测自动化实践分布式
1、什么是全链路压测
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。
2、全链路压测解决什么问题
针对业务场景愈加复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。
3、面对的问题点以及解决方案
一、业务模型梳理
首先应该明确的是：全链路压测针对的是现代愈来愈复杂的业务场景和全链路的系统依赖。因此首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，
针对性的进行扩容准备，而不是为了解决海量流量冲击而全部的系统服务集群扩容几十倍，这样会形成没必要要的成本投入。
二、数据模型构建
数据构建和准备，应该考虑这几点问题：
①、数据的真实性和可用性
能够从生产环境彻底移植一份当量的数据包，做为压测的基础数据，而后基于基础数据，经过分析历史数据增加趋势，预估当前可能的数据量；
②、数据脱敏
基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以避免对生产形成影响，影响用户体验等，所以在数据准备时须要进行数据脱敏；
③、数据隔离
一样，为了不形成脏数据写入，能够考虑经过压测数据隔离处理，落入影子库，mock对象等手段，来防止数据污染；
三、压测工具选型
全链路压测应对的都是海量的用户请求冲击，可使用分布式压测的手段来进行用户请求模拟，目前有不少的开源工具能够提供分布式压测的方式，好比jmeter、Ngrinder、locust等。
能够基于这些压测工具进行二次开发，由Contorller机器负责请求分发，agent机器进行压测，而后测试结果上传Contorller机器。
考虑到压测量较大的状况下回传测试结果会对agent自己形成必定资源占用，能够考虑异步上传，甚至事务补偿机制。
四、压测环境搭建
全链路压测都是基于生产环境，解决了业务模型和数据以及压测工具选型开发，就要考虑系统扩容和风险规避了，好比压测不能影响实际的生产业务运行，还有资源申请等。
从新搭建一套彻底匹配生产环境的压测环境，成本过高，且需求频次较低，投入成本太大。
五、系统容量规划
前面提到了业务拆分和流量预估，在系统容量规划阶段，首先应该对单个接口单个服务进行基准测试，调整配置参数，获得一个基准线，而后进行分布式集群部署，经过nginx负载均衡。
至于扩容，要考虑到服务扩容和DB资源扩容，以及服务扩容带来的递减效应。
至于大流量冲击状况下，能够考虑队列等待、容器锁、长链接回调、事务降级等方式来解决。
六、测试集群部署
能作全链路压测的业务系统，基本都是分布式系统架构，服务集群部署和负载均衡，就是须要实现和考虑的技术点。
须要解决的问题有：
①、服务间通讯问题
通常通讯方式有两种：同步和异步。
同步调用：
REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）
异步调用：
(Kafka, Notify, MetaQ)
同步调用一致性强，可是要考虑性能和调用失败的事务处理。
异步调用的话，能够下降服务间的耦合，提高性能体验，可是一致性是须要解决的（分布式架构有个CAP理论，感兴趣的能够查询相关资料看看）。
②、负载均衡问题
须要将大流量冲击均匀的分发给集群上的每台机器，目前比较优秀的负载均衡服务器是nginx，但nginx的部署貌似也存在一些问题，咱们公司以前就遇到过订单重复问题。
③、容灾问题
须要确保的一点是：当服务中的某台或者某部分服务宕机，能够及时的进行服务转发，而不至于连锁反应下整个系统链路的服务挂掉（能够参考我以前的博客：容灾测试）。
七、数据收集监控
压测数据收集，须要由agent机回送给Contorller机器，但数据量过大会占用必定的资源，能够考虑异步实现测试结果回送。
至于监控，如今有不少优秀的专业监控工具，好比Nmon、Zabbix，全链路监控工具Zipkin、PinPoint以及携程开源的全链路监控工具CAT。
或者能够针对须要，二次开发JVM自带的一些监控工具，作到实时全方位监控。
上面的内容，主要仍是一些知识点整理和我的的一些思考，权当参考，若有错误或者更好的建议，能够在评论区指正，不胜感激！