全链路压测如何排障调优 — 先导篇

【前言】

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

【什么是全链路压测】

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

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

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

全链路压测定义

生产业务场景：包括真实的环境和实际业务场景。真实环境指的是压测需要在真实的生产环境中进行；实际业务场景，指的是实际业务中使用到的测试场景，如登陆场景、注册场景等。

模拟海量的用户请求和数据：海量的目的是让服务器能够达到较大的负荷，从而达到压测的目的。海量数据一般来源于线上数据引流或者真实数据模拟。

整个业务链：要求压测需要覆盖整个业务链路，诸如CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路等。如果压测的请求只能覆盖部分链路的，不称为全链路压测。

持续排障与调优：全链路压测需要持续进行，这要求在测试过后持续进行排障调优，以便达到持续优化的目的。

【为什么讲排障】

1.排障是压测过程中最最重要的一环，它直接了决定了压测的量能否达到容量评估的要求。（容量评估请参考：如何去做接口容量预估）

2.排障能力非常重要，时间就是金钱。一个团队的排障能力直接决定了项目的故障恢复时间，而故障恢复时间是与钱强相关。以阿里为例，如果在双十一的凌晨12点发生故障，分分钟就损失了好几亿。

阿里2020年演练的故障恢复时间是1分28秒

3.排障非常难，我们之前遇到一个问题，排查了八九个通宵才有进展。

压测时的真实发声

【怎么进行排障】

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

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

【排障为什么难】

【排障实战经验】

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

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

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

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

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

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

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

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