1.3　全链路压测的发展前景

全链路压测已经走过了10年的岁月，当前它正处于生命力最旺盛的时候，几乎每年都有新的实践方法迸发出来。笔者摘录了近几年互联网大型峰会上公开的部分与全链路压测相关的议题，由此可见其活跃程度比较高。

● 2017年QCon全球软件开发大会：全链路压测在滴滴的实践。

● 2017年GIAC全球互联网架构大会：饿了么全链路压测实践与体系建设。

● 2018年GOPS全球运维大会：京东全链路压测军演系统。

● 2019年TOP100全球软件案例研究峰会：京东618/“双11”全链路压测的实践之路。

● 2020年QECon全球软件质量&效能大会：百万级流量无人值守全链路压测实践。

● 2021年QECon全球软件质量&效能大会：大规模微服务体系容量保障提效实战。

● 2021年MTSC中国互联网测试开发大会：华为应用市场春晚百万级QPS全链路压测实践。

● 2022年GIAC全球互联网架构大会：网易云音乐全链路压测实践。

通过上述议题，我发现一个有趣的规律，早年人们更多关注如何实施全链路压测，即如何将全链路压测在企业内有效落地，并解决实际问题。而近几年，重点转变成了全链路压测的降本提效，即如何以更低的成本实施全链路压测。

这一改变为我们带来了一些启示，目前，行业对全链路压测已经不再陌生，对它的效果和价值也有了深刻的认识，因此全链路压测已经进入了成熟期。但相应地，全链路压测实施难度大、成本高、投入多的痛点并没有改变，这也制约了全链路压测在更多中小型企业的推广和落地，因此全链路压测的降本提效成了近几年的研究热点及方向。

降本提效的理念贯穿于全链路压测的整个生命周期，包含压测前期、压测中期、压测后期这3个阶段：

● 压测前期的主要工作是压测脚本和压测数据的准备，以及压测模型的构建，提效的重点在于如何自动化生成这些内容，减少人力投入；

● 压测中期指的是压测执行阶段，无人值守压测是该阶段目前的研究重点，涉及自适应压测策略、压测风险全自动管控等内容；

● 压测后期的重点是压测结果分析，需要进行“根因”分析，做到自动识别系统服务的容量隐患。

上述这些工作在行业内已经有了一定的实践成果，也是本书的重要组成部分，在后续章节中我们还将进行深入解读。

让我们将视野进一步扩展至互联网技术发展的趋势上，云原生是目前互联网行业最火爆的热点技术之一。那么，在“云原生时代”下，全链路压测又该何去何从呢？

云原生技术的发展确实改变了互联网服务容量保障的底层逻辑。其中，最典型的例子就是弹性伸缩，即根据业务需求和流量情况自动调整计算资源。如果弹性伸缩的速度足够快，我们就无须提前对系统进行容量规划，在流量峰值来临时直接对系统进行实时扩容就可以了。此外，主流的云服务商都支持按需付费，用户只需要为系统服务实际消耗的资源支付费用，所以，弹性伸缩还能为我们节省成本。

弹性伸缩还有一个好处是，它基于Serverless（无服务器）理念，将服务资源的管理工作下沉到基础设施中，这样，管控粒度更细、更具备实时性，而且业务方不需要关心服务资源的消耗，弹性伸缩能够将服务容量始终维持在安全水平。

用一句话总结，有了云原生技术的加持，系统的容量保障逐渐成为云基础设施能力的一部分，通过弹性伸缩结合一定的容量预测能力，我们能够更快速、更经济地保障服务容量维持在安全水平。这几乎颠覆了传统的容量保障工作，似乎我们不再需要全链路压测来提前评估服务的容量情况了，对于容量风险的容忍度也可以更高了，但真的是这样吗？

事实上，目前以弹性伸缩为代表的云原生容量预测技术并不具备太大的应用能力，这和云原生所宣传的效果还存在很大的距离。究其原因，笔者认为主要有以下几点：

● 容量预测技术尚未发展到非常成熟的阶段，对容量的预估不够精确，它的效果还无法与全链路压测的效果相提并论，自然也就无法支持大规模的自动化弹性伸缩；

● 弹性伸缩的风险较高，特别是缩容操作有引发线上服务异常的可能性，甚至会直接导致事故的发生；

● 扩缩容速度不够快，无法满足快速弹性伸缩的要求，尤其是像网店的“秒杀”活动这样的流量急速上升的场景，更是弹性伸缩的软肋。

在这些问题被彻底解决之前，全链路压测依然是容量保障最重要的“武器”之一，它的地位无可取代。同时，全链路压测也可以与弹性伸缩相结合，通过对全局容量进行评估并将评估结果反馈给基础设施，我们可以保证在较短的时间内提前完成伸缩操作，这同样节省了成本。

综上所述，全链路压测技术正处于高速发展的时期，它与如今主流的技术发展方向几乎都有交集。我们有理由相信，全链路压测将逐渐成为互联网公司的标配技术，其应用前景很广阔。