之前有和认识的同⾏聊过他们全链路压测的⼀些技术实现⽅案，⾃⼰也看了很多相关的资料，这篇博客，说说⾃⼰对全链路压测的理解，以及整理的⼀些知识点。。。
PS：主要罗列的是问题点，以及对应的⼀些解决⽅案，仅供参考。。。
相关链接：
⼀、什么是全链路压测
基于实际的⽣产业务场景、系统环境，模拟海量的⽤户请求和数据对整个业务链进⾏压⼒测试，并持续调优的过程。 ⼆、全链路压测解决什么问题
针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可⽤性、服务能⼒的瓶颈，让技术更好的服务业务，创造更多的价值。 三、⾯对的问题点以及解决⽅案
1、业务模型梳理
央视网评星巴克事件
⾸先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以⾸先应该将核⼼业务和⾮核⼼业务进⾏拆分，确认流量⾼峰针对的是哪些业务场景和模块，
针对性的进⾏扩容准备，⽽不是为了解决海量流量冲击⽽所有的系统服务集扩容⼏⼗倍，这样会造成不必要的成本投⼊。
2、数据模型构建
环境与可持续发展
数据构建和准备，应该考虑这⼏点问题：
①、数据的真实性和可⽤性
可以从⽣产环境完全移植⼀份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量；
②、数据脱敏
基于⽣产环境的全链路压测，必须考虑的⼀点是不能产⽣脏数据，以免对⽣产造成影响，影响⽤户体验等，因此在数据准备时需要进⾏数据脱敏；前言讲座
③、数据隔离
同样，为了避免造成脏数据写⼊，可以考虑通过压测数据隔离处理，落⼊影⼦库，mock对象等⼿段，来防⽌数据污染；
3、压测⼯具选型
全链路压测应对的都是海量的⽤户请求冲击，可以使⽤分布式压测的⼿段来进⾏⽤户请求模拟，⽬前有很多的开源⼯具可以提供分布式压测的⽅式，⽐如jmeter、Ngrinder、locust等。
可以基于这些压测⼯具进⾏⼆次开发，由Contorller机器负责请求分发，agent机器进⾏压测，然后测试结果上传Contorller机器。
食品安全在行动
考虑到压测量较⼤的情况下回传测试结果会对agent本⾝造成⼀定资源占⽤，可以考虑异步上传，甚⾄事务补偿机制。
4、压测环境搭建
全链路压测都是基于⽣产环境，解决了业务模型和数据以及压测⼯具选型开发，就要考虑系统扩容和风险规避了，⽐如压测不能影响实际的⽣产业务运⾏，还有资源申请等。
重新搭建⼀套完全匹配⽣产环境的压测环境，成本太⾼，且需求频次较低，投⼊成本太⼤。
5、系统容量规划
前⾯提到了业务拆分和流量预估，在系统容量规划阶段，⾸先应该对单个接⼝单个服务进⾏基准测试，调整配置参数，得到⼀个基准线，然后进⾏分布式集部署，通过nginx负载均衡。
⾄于扩容，要考虑到服务扩容和DB资源扩容，以及服务扩容带来的递减效应。
⾄于⼤流量冲击情况下，可以考虑队列等待、容器锁、长连接回调、事务降级等⽅式来解决。
6、测试集部署
能做全链路压测的业务系统，基本都是分布式系统架构，服务集部署和负载均衡，就是需要实现和考虑的技术点。
需要解决的问题有：
①、服务间通信问题
⼀般通信⽅式有两种：同步和异步。
同步调⽤：
REST（JAX-RS，Spring Boot）
内肋管RPC（Thrift, Dubbo）
异步调⽤：
(Kafka, Notify, MetaQ)
同步调⽤⼀致性强，但是要考虑性能和调⽤失败的事务处理。
异步调⽤的话，可以降低服务间的耦合，提升性能体验，但是⼀致性是需要解决的（分布式架构有个CAP理论，感兴趣的可以查询相关资料看看）。
中文译音②、负载均衡问题
需要将⼤流量冲击均匀的分发给集上的每台机器，⽬前⽐较优秀的负载均衡服务器是nginx，但nginx的部署貌似也存在⼀些问题，我们公司之前就遇到过订单重复问题。
③、容灾问题
需要确保的⼀点是：当服务中的某台或者某部分服务宕机，可以及时的进⾏服务转发，⽽不⾄于连锁反应下整个系统链路的服务挂掉（可以参考我之前的博客：）。
7、数据收集监控
压测数据收集，需要由agent机回送给Contorller机器，但数据量过⼤会占⽤⼀定的资源，可以考虑异步实现测试结果回送。
⾄于监控，现在有很多优秀的专业监控⼯具，⽐如Nmon、Zabbix，全链路监控⼯具Zipkin、PinPoint以及携程开源的全链路监控⼯具CAT。
或者可以针对需要，⼆次开发JVM⾃带的⼀些监控⼯具，做到实时全⽅位监控。
上⾯的内容，主要还是⼀些知识点整理和个⼈的⼀些思考，权当参考，如有错误或者更好的建议，可以在评论区指正，不胜感激！
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议