全链路压测方案梳理-转载

 全链路压测的概念挺火的，想做成却没有机会（毕竟不是互联网巨头类的公司），所以在这里也不想纸上谈兵，可能过段时间它就会被更新更高大上的概念给替换了，但是我们可以收集一下相关资料（目前可以开展全链路压测的公司真的很少，所以资料有限），将来对自己的性能测试项目可能也会有帮助：

相关链接：

阿里全链路压测    全链路压测3.0    智能全链路压测

有赞全链路压测实战    全链路压测方案设计与实施详解     全链路压测引擎的设计与实现

京东全链路压测

饿了么全链路压测

滴滴全链路压测解决之道

美团全链路压测自动化实践

全链路压测平台（Quake）在美团中的实践

逻辑思维在全链路压测方面的实践

全链路压测的大概思路

全链路压测定义
全链路压测平台主要有两个核心的也是最顶级的要求：

全业务
全链路
这导致了，必须线上搞压测，必须用线上的真实数据搞压测。
那么线上搞就容易搞出事情，所以技术含量还是要有的，还是很高的。

压测关键前提
1、业务模型梳理

首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，

针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。

2、数据模型构建

数据构建和准备，应该考虑这几点问题：

①、数据的真实性和可用性

可以从线上环境（生产环境）完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量；

据说美团的做法是：

http服务的，通过nginx日志把请求内容导出来，处理一下，放到数据库池子里。
rpc服务的，通过美团内部已有的rpc框架录制功能，把请求数据导出来，处理一下，放到数据库池子里。
然后压测流量从数据库池子里来。

②、数据脱敏

基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏。

③、数据隔离

同样，为了避免造成脏数据写入，可以考虑通过压测数据隔离处理（根据测试标识区分），落入影子库，mock对象等手段，来防止数据污染；另外比如http请求，可以直接将测试标识加在header里（不污染代码，仅测试引擎添加即可），这样可以把隔离出来的（带测试标识的）流量，只访问隔离出来的服务器，这样就不会污染整个线上服务器集群。

压测核心
全链路压测基本上和原生Jmeter没关系，因为Jmeter用的是BIO（基于Jmeter的云平台化，足够规模的分布式压测也是可选的一个方向），美团用的是NIO，阿里的PTS也用到NIO，好处不解释了。
采用的方式有：

使用一些脚本语言如：Python、Ruby 等，读取线上日志构建请求，用多线程模拟用户请求进行压测
类似Netty NIO 框架 + apache ab 组合模式
采用Twitter/iago、 Gatling、Grinder、Locust等开源压测工具
大厂都会自主研发压测平台，避开了开源工具的一些问题
压测监控
一般会采用 InfluxDB 来完成数据的聚合工作，所有聚合指标都是一行 SQL 搞定，非常快速。或基于开源二次开发的监控，比如CAT，Falcon，Skywalking等。

关于监控这块，美团的开源精神值得肯定（虽然内部的好东西未必能开源出来），而像饿了么监控系统 EMonitor 说是比CAT好，但目前为止也没见开源，阿里的云监控更别提了，天天推销让你花钱买服务。

什么公司要搞全链路压测
至少目前来看，得是有追求，有余力的公司吧。
阿里，滴滴，饿了么，云集微店，美团，这些公司有一个共性，都是支付场景比较高并发的公司，就是对钱非常敏感的公司。
支付场景，也就是支付相关的各个服务（订单，派送，入库出库等很多），相连密切，这样的场景比较复杂，还是高并发，自然对性能测试有高要求。
同时支付场景，是会改变库的数据的，这也要求线上测试必须做数据隔离，这也是全链路压测的核心。

什么阶段的公司搞全链路压测
微服务的架构。
需要架构组，得有Mtrace的这种微服务RPC消息跟踪体系架构，能改中间件。
各部门能配合全链路压测调试及部署，运维的机器资源部署。
简单性能测试要通过，即单点的性能测试要没问题。
有更高的技术追求。
什么时间搞全链路压测
压力小的白天就行，要错过高峰期，这也是得益于数据隔离，服务器隔离。
压力大的一般凌晨进行，要错过高峰期。
谁来搞
肯定不是测试，也不是一般的性能测试工程师和测试开发工程师，基本上是一个研发团队在搞。

据说美团的压测平台前身也是测试开发工程师搞的，推广的也不错，在美团趟出了一条压测的路，但是存在了不少有待改进的地方。后来种种原因，平台移交给了开发团队，现在看起来，平台的压测性能、可用性等各方面有了很大的提升。不是说测试开发的同学做不了，而是效率和速度确实还是有差距的。开发同学的效率和速度就是特别大的优势，能加班，可以快速的让产品成型并且快速迭代。

以上内容部分参考自 https://testerhome.com/topics/16498

原文链接：https://blog.csdn.net/smooth00/article/details/91373705