关于全链路压测的几个问题

1 什么是全链路压测?

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

2 全链路压测解决什么问题?

验证峰值流量下服务的稳定性和伸缩性

验证新上线功能的稳定性

进行降级、报警等故障演练

对线上服务进行更准确的容量评估

机房故障，流量突增的支撑能力评估

3 什么时机下需要?

业务发展速度（业务的不断发展，依赖的模块不断增多。需要找出短板来进行解决）

在可以预期的一段时间（最好是半年，一个季度有点晚）内，业务会有较快速的发展，线上机器必须要大幅度扩容

扩容有的时候并不是线性的，从两台扩展到四台，你得服务能力或者能提高两倍

继续扩容服务能力就有可能提高不上去了，因为要受限于其他的模块，比如 DB、公共组建、中间件等

对单机压测结果越来越没有自信

3.1 一个很好的指标，一般而言，我们都会压一下我们自己的模块

3.2 单机的压测不代表真实的线上场景，内心会越来越虚，这个时候，就要考虑全链路了

4 压力测试方式分为几个阶段？

对线上的单机或集群发起服务调用

将线上流量进行录制，然后在单台机器上进行回放

通过修改权重的方式进行引流压测

全链路压测（难点在于梳理清楚链路的边界）

全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。

5 全链路压测核心功能有哪些？

数据构造

压测隔离

服务隔离

数据隔离

6 压测需要做哪些工作？

数据模型构建

压测平台搭建

6.1 压测机中的机器数据能够实时的收集查看到、可以随时停止压测、一定时间内实时错误率达到阈值自动熔断

系统代码改造（压测标记，mock，业务逻辑）

6.2 写请求写到影子区域(比如header头中做标记，存储、缓存、消息、日志等一系列的状态数据)、依赖的外部服务做 mock 处理(短信、邮件、push 等等)，多线程改造

真实流量蓄水池，分批释放（回放业务高峰期产生的流量）

逐步压测

7 为什么需要容量规划？

什么时候增减机器、保障系统稳定性、节约成本

8 压测关注哪些指标？

应用层面

服务器资源

基础服务：中间件和数据库

核心指标：（响应时间不要用平均响应时间，关注95线；吞吐量和响应时间挂钩；吞吐量和成功率挂钩）

系统：

系统容量

业务性能

基础设施瓶颈

中间件瓶颈

系统直接的依赖影响

9 如何获取单台机器的服务能力

模拟请求 通过对生产环境的一台机器发起模拟请求调用来达到压力测试的目的

请求转发 将分布式环境中多台机器的请求转发到一台机器

调整负载均衡 修改负载均衡设备的权重，让压测的机器分配更多的请求

  9.1 在进行压测的同时，实时探测压测机器的系统负载，一旦系统负载达到预设的阈值即立刻停止压测，同时输出一份压测报告 通过单机压测获取的单机服务能力值也是容量规划一个非常重要的参考依据

最小机器数 ＝ 预估的业务访问量 ／ 单机能力

  9.2 在做单个系统的容量规划时，所有的依赖环节能力是无限的，进而使得我们获取的单机能力值是偏乐观的；  9.3 采用单系统规划时，无法保证所有系统均一步到位，大多数精力都集中核心少数核心系统；  9.4 部分问题只有在真正大流量下才会暴露，比如网络带宽等等。

全链路压测改造关注点：https://www.codercto.com/a/55270.html

美团quake压测：https://tech.meituan.com/2018/09/27/quake-introduction.html

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

阿里全链路压测

有赞全链路压测

京东全链路压测

饿了么全链路压测

滴滴全链路压测解决之道

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