压测做的不对，等于白做

在软件领域，无论是开发、测试、运维都对一个词不会陌生，那就是：压测。在百度百科里是这么定义压测的：

压测，即压力测试，是确立系统稳定性的一种测试方法，通常在系统正常运作范围之外进行，以考察其功能极限和隐患。

本来是件很有意义的事，可是现实中往往尴尬的事就那么自然的发生了：明明几轮压测下来没啥问题，但是业务高峰一来系统还是扛不住。故事通常会这样继续——就在研发同事一筹莫展的时候，运维同事及时的请出了三大法宝：扩容、限流与降级，问题迎刃而解。

让人不得不感慨：姜还是老的辣，坑还是运维踩的多！

network02

感慨之余，我们不禁要问，与其这样是不是说压测就没有用了呢？其实不然。

很多压测都做对了么？

我们知道，对于压测这件事其实每个人或角色理解的都不见得完全准确，让我们先从压测的目的说起。

有一些人认为压测就是在测试系统或资源的极限，所以对应的压测方案也是有着鬼斧神工的亮点：

• 把这两台 F5 设备连接数打满

• 运营商有 4 个 G 的带宽，压测得能跑满

• 服务器集群每台机器 CPU、内存利用率都得能到 95%

• ……

以上只是举例，请各位无需对号入座。其实想表达的是，我们是不是该静下心来问下自己，到底为什么要做压测呢？这里找到一张图片，从用户角度和技术角度讲了我们做压测的目的是什么。

network03

（图片来自极客时间）

所以，到此还需要引入另外一个概念，我们的压测其实核心做的事叫：容量保障。它有两个最关键的点：

1. 以尽可能小的成本确保系统当前和未来的容量充足，即容量规划

2. 解决已知的容量问题，预防未知的容量问题，即容量治理

该怎么做好容量保障？

谈到这里有人可能会说是不是有点跑题了，并且这个问题貌似也有点多余，答案当然是做好容量测试也即压测呗。嗯，回答正确，但是问题就在于知易行难呀。

阿里前任 CTO 行癫在 2018 年双 11 启动会上说过一句话：“容量测试是验证手段，不是测试手段”。

换句话说，我们应该先努力设计和建造出满足容量要求的服务，再通过容量测试去验证它，而不是靠容量测试去反复探测服务容量瓶颈，再去不停地优化服务或扩容。我认为这才是对容量测试的现代化理解。

是不是有种醍醐灌顶的感觉，原来之前提到的压测方案从根本上就是有问题的。问题的尽头会是答案么？我们该如何设计一个好的压测方案呢？其实理论上并不复杂。

通常来讲，一次正确的压测需要我们得确认好压测范围、制定压测方案、实施压测、最后进行数据分析。我们一步步来讲，先确认测试范围，这里还是一张图来说清楚这件事：

network04

（图片来自极客时间）

总结一下，最重要的服务主要有以下四个：

• 关键路径上的核心服务

• 有明显流量峰值特征的服务

• 对响应时间敏感的服务

• 占用资源大的服务

服务有了，剩下的就是确认怎么来测了？幸好，基调听云在这块有着自己的见解。

你该做的是全链路压测方案

根据我们一些行业客户的经验来看，对未来可能产生的流量峰值而言，任何预防性的稳定性保障手段，都不如把实际峰值场景模拟出来“看一看” 来的有效。这就好比建造一座大坝，预计能抵挡千年一遇的洪水，但是否能达到这个目标，还是需要经历多次洪水考验才能证明的。全链路压测就是通过模拟这场千年一遇的洪水，来验证服务系统是否能承载预估的流量峰值。

为什么单链路压测无法排除系统整体容量风险呢，因为整体系统的容量不是由多条“单链路”的容量简单相加而得的。我们看一下下面这张图，它表达的含义是，应用服务的容量除了受自身影响，还受依赖服务的影响，而依赖服务又可能有其他调用方，甚至是一些外部服务，这些影响经过几层累积后，最终的影响面极难判断。

network05

（图片来自极客时间）

而全链路压测直接从全局视角出发，它的本质是基于线上真实环境和实际业务场景，通过模拟海量的用户请求，来对整个系统的容量进行评估的手段。

说白了，不能真实模拟业务场景有数据的压测，某种程度上都可以说成是“伪”压测。

没有可观测性会“差之毫厘，失之千里”

压测具有天然的结果不可预见性，再好的压测方案如果不能得到有效的数据来分析都会使效果大打折扣。尤其是在复杂的、深度的系统环境下，通过获取全链路的追踪数据及指标数据实现整个压测过程的可观测性显得尤为重要。

传统压测中，我们的监控手段比较有限，一般多集中在对基础资源层的监控上，最多也就是加上开源的 APM 监控，但对于真实用户端和真实网络情况是缺乏必要的监控手段的。

基调听云通过多年 APM 行业的积累，借助多维遥测技术及问题定位能力实现了具备可观测性的全链路混合压测方案。

network01

东西看着不少，我们来关注重点好了。

可观测性：通过端到端的遥测数据实现可观测性。

全链路：提供从真实用户体验操作，到应用、组件、基础资源的压力以及 Trace 可全量进行追踪的能力。

混合：JMeter 的接口压测+真实用户体验模拟浏览器的压力形成混合压力。

光说不练终是假把式

某省考试院重要考试报名前，使用基调听云压测服务对系统进行了多轮压测，其中最高模拟用户数达到了 11 万/分钟，基本上高度模拟了真实流量高峰场景。

在全栈监控下，问题基本上无处藏身：

network06

发现连接池问题，优化才是王道：

network07

让结果来说明一切吧：

network08

似乎该做个总结才好，就算不是老王面对这么好的瓜不自夸也挺难的。

如果您对基调听云的具备可观测性的全链路混合压测方案感兴趣，随时点击“联系我们”吧。