【前言】

我们团队保障了很多KA项目（第七次人口普查项目，广交会等）的后台稳定性，覆盖14亿中国人口，后台接口的并发量达到11万的QPS。在生产环境进行全链路压测的过程中，我们踩了很多坑，但也因此积累了丰富的实战经验，希望分享出来，让大家少走弯路。

【什么是全链路压测】

在网络上对全链路的名词解释，可以看到相关词条里有很多延伸：全链路监控， 全链路设计，全链路追踪系，全链路运营，全链路日志分析...

全链路：分为两层意思；一个请求在系统中经过的完整路径。二是一系列动作的集合，比如从用户登录，到录入数据，到提交后台等整个环节。

基于以上的分析，我们给全链路压测的定义：基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。

遵循业界通用的USE原则和RED原则，我们提炼出主要从如下两个方面排查：

• 查看机器负载
• 查看错误日志

【排障为什么难】

【排障实战经验】

1. 首先要有大局观：全链路分析问题的意识。开发一般只会发现程序代码的问题，很少思考链路上的配置问题。
2. 根据错误信息和QPS曲线进行初步分析。
3. 尽可能的收集整个链路上的所有信息(日志，CPU，内存，带宽等），并把相关的相关人员拉到一个讨论组里面，进行信息同步。
4. 结合压测的可复现性，控制单一变量，逐步缩小排查链路，更快定位问题。
5. 终极大法，抓包分析。

一般而言，通过日志来定位问题，算是比较简单的方式。但大部分时候并没有报错，QPS曲线波动却波动很大。

下面分享几个有趣的曲线：

• QPS（Req/s）随着并发数（Active Threads）的增加不升反降，这说明，一定是某个环节出现了瓶颈，并不能一味的通过增加并发数来提高QPS值。

• QPS曲线周期性的掉坑又爬上来，就是比较典型的资源耗尽问题。

• QPS曲线被一刀切下来后平稳的运行，这种就是典型的限频问题。

上面这个曲线只是定性分析，至于是什么资源耗尽，又是那个链路触发了限频，我们梳理了腾讯云上各个组件的最佳实践，大家可以先订阅【云原生压测团队】，后面再慢慢欣赏。

经典案例后续会陆续补充到【云原生压测团队】，请先【订阅】哦。