书名：深入浅出全链路压测
ISBN：978-7-115-62414-7
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
编 著 吴骏龙
责任编辑 张 涛
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
网址 http://www.ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
全链路压测是互联网服务容量保障工作人员的重要工作，也是横跨多个领域的技术。本书采用“理论联系实际，再从实际回溯到理论”的方式，深入浅出地阐述全链路压测的知识。本书前4章聚焦于全链路压测的基础知识，先对全链路压测的基本知识和发展前景等进行深入介绍，再展开讲解全链路压测的技术实现、组织保障和工具建设，其间穿插一些实例代码和图表，帮助读者融会贯通。第5章和第6章介绍全链路压测的衍生实践，包括微服务架构下的容量治理，以及容量规划与容量预测，将全链路压测的应用价值扩大到更广的领域。第7章用4个案例讲解全链路压测在不同类型企业的落地实践，涵盖全链路压测在容量保障和混沌工程领域的应用。第8章从技术、管理和职业发展这3个方面，以问答形式阐述多个全链路压测问题，为读者带来更多的思考。
本书内容既包括全链路压测的理论知识，又包括丰富的实践案例，适合架构师、研发人员、性能测试人员、运维人员、网站可靠性工程师、团队管理者、项目经理等阅读。
优秀的互联网软件产品，不仅要具备良好的质量，还应具备充足的“容量”。然而，在很长一段时间内，行业对容量保障的关注度都不及质量保障，毕竟，我们更习惯用“缺陷（bug）少”而不是“性能好”来评价一款软件产品的优劣。但现实情况是，容量问题的负面影响丝毫不亚于质量问题。某大型订票网站在上线初期多次出现系统崩溃，某年春晚某“头部”企业的“摇一摇”红包活动短暂宕机等，都是容量方面出现问题的例子。
令人欣喜的是，自2013年阿里巴巴公开全链路压测的细节以来，各互联网企业对容量保障的关注度逐渐提升，甚至诞生了不少致力于容量保障的创业公司。全链路压测作为容量保障工作中最引人注目的一项实践，也从最初只有少数大公司才有能力建设的“皇冠上的明珠”式的项目，逐渐“走入寻常百姓家”。
我在2017年年初加入“饿了么”（后成为阿里巴巴本地生活）从事全链路压测的自动化和规范化工作，2020年我又在一家创业公司从0到1搭建了全链路压测的完整体系，另外我还在多家企业和多个行业峰会上进行过大量关于全链路压测及其衍生实践的分享。我能够深刻感受到，越来越多的企业开始认识到全链路压测的价值，也愿意投入资金去建设全链路压测。但是，全链路压测究竟该怎么做、需要哪些人去做，企业对此依然有着非常普遍的困惑。
作为一名一直从事全链路压测的实践者，我一直在思考，如何将全链路压测的各项工作系统地总结出来，既能让缺乏实践背景的从业人员快速掌握全链路压测的方法，又能为已经从事全链路压测工作的专业人士带来进一步的启发。使全链路压测真正“平民化”、实用化，是我编写这本书的最大初衷。本书采用“理论联系实际，再从实际回溯到理论”的讲解方式，将理论知识和实践案例串联起来，深入浅出地阐述全链路压测的知识。我希望达到的效果是，读者在阅读本书的过程中能时刻结合实际工作场景进行思考。
全链路压测并不难，希望本书能够帮到你。
2021年5月，我在极客时间平台上撰写的技术专栏“容量保障核心技术与实战”正式上线，这个专栏从互联网服务容量保障的视角切入，从基础到进阶再到实战，全面讲解容量保障的各项实践细节。
本书的部分内容源自该专栏，并将专栏中的口语化表达转换为正式的书面文字表达，同时采用全新的角度，以全链路压测为主线，包含容量保障的各项工作。本书整体内容较专栏增加了一倍有余，我期望能够为读者带来不一样的学习体会。
本书的编写思路是，先聚焦于剖析全链路压测的基础知识，再详细讲解全链路压测的衍生内容，并通过一系列的案例串联全链路压测要点，最后通过问答的形式查漏补缺。
建议读者按顺序阅读本书，如果你已经熟悉了某些章的内容，那么任意阅读其他章也不会有什么困扰，因为本书每章都是独立的。同时，为了体现本书的特色，我在每章的开头都总结了一个“金句”，读者可以“金句”为起点，在章节中寻找“金句”对应的内容。我相信，读者带着兴趣阅读，能提高学习效果。
第1章 认识全链路压测。本章对全链路压测的诞生背景、概念和特点等进行介绍。
第2章 全链路压测的技术实现。本章详细介绍全链路压测的技术实现知识，涵盖压测数据隔离、中间件改造和应用服务改造、压测模型构建、压测流量构造、容量指标监控等内容，并对一些流行的技术进行重点剖析。本章还介绍全链路压测的实施流程。
第3章 全链路压测的组织保障。本章讨论全链路压测的组织建设形式，并解读一些组织运营的最佳实践，同时，针对中小型公司，本章也给出一些实践建议。
第4章 全链路压测的工具建设。本章主要探讨全链路压测的工具建设，对常见的开源工具进行介绍，并提供分布式压测平台和全链路压测管理平台的详细实现方案。
第5章 微服务架构下的容量治理。本章系统性地介绍微服务架构下容量治理的手段，包括扩容、限流、降级、熔断、容灾这5个常用手段，并讲解容量指标分析和预案建设的相关内容。
第6章 容量规划与容量预测。本章全面介绍容量规划的本质和系统化方法、容量预测的智能化方法，以及排队论的概念和应用场景等。这些方法与全链路压测结合起来，能够更好地保障互联网服务的容量安全。
第7章 全链路压测实战案例。本章讲解4个实战案例，涵盖全链路压测在不同类型企业的落地实践，也涵盖全链路压测在容量保障和混沌工程领域的应用。通过这些案例，我希望帮助更多企业实现全链路压测的落地。
第8章 全链路压测快问快答。本章从技术、管理和职业发展这3个方面，以问答形式阐述多个全链路压测的精华知识。这些问答不仅给出非常具体的实践指导，也总结出一些解决问题的方法，能为读者带来更多的思考与感悟。
在从事全链路压测工作中，我得到过很多人的帮助，感谢我的启蒙老师郑卓君，她为我打开了全链路压测的大门，我的很多实践成果都建立在她卓有成效的工作之上；感谢我的老领导兰建刚，在工作中他给予了我非常大的自主权，让我能够带领一支庞大的团队不断探索前沿技术；我还要感谢所有在我的极客时间专栏上提出宝贵建议的读者，读者提出的很多建议都转化成了本书的精华；最后，我要感谢我的家人对我在编写本书期间的包容和支持，整个写作过程占用了我不少陪伴家人的时间，但他们没有任何怨言。
由于编者水平有限，书中难免存在疏漏之处，恳请广大读者批评指正。
本书编辑联系邮箱：zhangtao@ptpress.com.cn。
吴骏龙
对未来可能产生的流量峰值而言，任何预防性的容量保障手段，都不如把实际峰值场景模拟出来“看一看”更有效。
全链路压测是一种先进的容量保障技术，自诞生之日起就备受质量保障人员的关注，经常被冠以诸如“容量保障的珠穆朗玛峰”“大促活动备战的重要武器”“大促活动前的模拟考试”等称号，但事实上它并不是什么神秘的技术，它就在你我身边。
举一个例子，相信绝大多数读者都参与过“双11”大促活动，阿里巴巴的公开资料显示，2020年“双11”期间，网店的订单创建峰值达到了58.3万笔/秒，这是一个非常大的数字。我们要在如此巨大的流量峰值下保证系统的稳定运行，全链路压测是不可或缺的技术保障手段之一。换言之，我们每个人都在享受着全链路压测带来的成果。对于IT（Information Technology，信息技术）从业者来说，全链路压测也逐渐成为应知必会的知识点之一。
1.1 全链路压测概述全链路压测是容量保障的一个重要环节。本节，我们将介绍互联网服务容量保障的一些基础知识，并由此展开讲解全链路压测的概念、价值和特点等。
提及容量保障，人们很容易联想到质量保障，两者同为互联网服务的技术保障手段，既有联系又有区别。
● 质量保障：指的是保障系统服务功能正常，系统按照开发人员设计的功能运行。例如，用户可以通过订单系统正常下单并结算，系统显示的订单信息和金额正确。
● 容量保障：指的是保障系统服务在大量用户访问时依然可以正常工作。例如，在“双11”期间，在大量用户访问的情况下，用户仍可以流畅地在网店上浏览和购买商品。
容量是我们生活中很常见的概念，我们喝水的杯子有容量，我们每天上班乘坐的地铁也有容量。广义的容量可以定义为：容器能够容纳物质的量。杯子是容器，水是物质，杯子能够容纳多少水就是容量。
从互联网技术视角出发，我们可以将软件系统或服务视为容器，将访问量或业务量视为物质，得到互联网软件系统容量的概念，即“单位时间内软件系统能够承载的最大业务量”，如图1.1所示。而容量保障，就是用各种方法保障软件系统的容量充足，尽力排除容量隐患。
图1.1 互联网软件系统容量的概念示意
容量保障对于软件系统的稳定运行至关重要，如果一辆货车核载80kg，而我们给货车装载了100kg的货物，后果可想而知。互联网企业也曾发生过不少因容量问题引发的系统运行事故，例如，某年春晚某“头部”电商的“摇一摇”红包活动短暂宕机，某微博出现热门事件时的频繁宕机，这些系统的宕机事故都对用户造成了巨大影响。
在笔者的职业生涯中，我能够非常深刻地感受到，容量保障对于一家互联网公司的重要性和必要性，因为我时刻都在面对以下这些问题。
● 我负责的软件系统目前运行得很好，但是公司业务增长迅猛，如果用户的访问量增加两倍，系统还能支撑吗？
● 如果系统无法支撑两倍的访问量，系统中哪些服务会首先成为瓶颈？
● 如果对这些系统服务采取扩容措施，需要扩容多少？
● 在大规模促销活动场景下，如何识别和预防系统的容量风险？
与此同时，随着互联网应用复杂度和系统架构复杂度的不断提升，容量保障的难度逐渐增大，解决上述问题的成本也越来越高。我们迫切希望能有一项技术帮助我们解决根本问题。幸运的是，经过技术人员的不懈努力，全链路压测技术诞生了。
全链路压测背后的理念非常朴素：对未来可能产生的流量峰值而言，任何预防性的容量保障手段，都不如把实际峰值场景模拟出来“看一看”更有效。这就好比建造一座大坝，我们预计用它能抵挡千年一遇的洪水，但是否能达到这个目标，还需要让大坝经历多次洪水考验才能证明。全链路压测就是通过模拟这场“千年一遇的洪水”，来验证系统服务是否能承载预估的峰值流量。
全链路压测就是基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据流量，对整个系统业务链进行容量测试，并持续对系统进行调优的过程。
值得注意的是，全链路压测的实施并不是依靠单一技术完成的，它是一项综合性技术工程，涵盖技术、管理、人员保障等多个方面，同时需要多个角色参与其中，包括但不限于业务方、测试人员、运维人员、研发人员、DBA（Database Administrator，数据库管理员）、SRE等。由此可见，全链路压测的涉及面较广，它的成功实施需要多方通力协作。
全链路压测是一个通过技术手段助力业务发展的工程，它的价值体现在很多方面，如图1.2所示。
图1.2 全链路压测的价值
首先，全链路压测在技术上的价值是不言而喻的。通过全链路压测，我们不但能提升容量评估准确性、提升服务的SLA（Service Level Agreement，服务等级协议）、驱动服务性能优化和架构治理，还能借助它进行预案制定和演练等工作。
其次，全链路压测非常适合作为驱动容量保障建设乃至稳定性建设的桥梁和支点，我们通过它制定公共技术目标、协调技术改造项目、跟踪容量风险等，将企业的不同团队凝聚在一起，让系统达到最优的运行效果。
最后，全链路压测能够保障系统服务的容量安全和稳定运行，也就保障了公司业务活动的顺利开展，达到助力业务发展的效果，间接增强了企业的业务竞争力。如果一家企业举办的线上大促活动经常出现系统崩溃的问题，很难想象该企业的业务能获得用户的认可。
软件系统复杂度的日益提升和业务场景的多样化是全链路压测的诞生背景，因此，全链路压测具有鲜明的特点。我总结了以下6个全链路压测的特点。
第一，虽然全链路压测名称中有“压测”两字，但它本质上是一种容量测试技术或手段。压测和容量测试的区别在于，压测的目的是要找到系统服务性能的瓶颈，而容量测试则是根据预先制定的容量目标，通过对系统服务施压来观察和验证系统服务能否承载这一压力。从这个层面讲，全链路压测应当被视为一种验证手段，而非测试手段。换言之，我们应该先设计和建造出满足容量要求的系统服务，再通过全链路压测去验证它，而不是通过全链路压测去反复探测系统服务的容量瓶颈，然后不停地优化系统服务或扩容。
第二，全链路压测需要在生产环境中实施，这是为了尽可能避免环境差异对压测结果造成影响，环境差异包括资源配置、中间件部署方式、网络部署方式等。除非我们能够在线下搭建一套与生产环境完全相同的测试环境，否则无法保证全链路压测结果的可信度。
第三，全链路压测是主动发现服务容量隐患（风险）的手段，它通过模拟系统处于高负载状态的真实场景，提前暴露系统服务的容量风险，验证系统服务是否能够承载预期的峰值流量。这样，在真实流量峰值到来时，我们才能做到胸有成竹。
第四，全链路压测的业务涉及面广，“全链路”这3个字意味着我们至少要将核心业务流程所涉及的链路都纳入压测范围。在一些业务规模较大和系统复杂度较高的企业中，全链路压测甚至会涵盖成百上千个微服务。
第五，全链路压测的技术实现复杂，需要对基础设施和系统的业务进行改造，这意味着全链路压测经常作为企业的重点项目进行推动，且需要较长的实现周期，不可操之过急。全链路压测能否成功落地，很大程度上取决于企业是否具有过硬的组织管理能力和对应的技术架构。
第六，全链路压测对相关人员的技术素养要求较高，这些人员不仅要对服务系统的调用链路了解透彻，还要具备一定的性能分析和调优能力，这非常考验人员的技术功底。也正因为如此，全链路压测往往是多个团队合作使用的技术。
当然，随着技术的不断革新，以及优秀实践的迸发，上述这些特点也是会改变的。我们应当持续关注前沿技术，以动态的眼光审视全链路压测。
1.2 全链路压测的演进之路全链路压测的理念最早是由阿里巴巴提出的，它的效果在“双11”大促活动的容量保障工作中得到了充分的验证，自从2013年全面推行全链路压测以来，“双11”大促活动期间，电商系统的稳定性有了明显提升。不过，“罗马不是一日建成的”，全链路压测也是经历了多次探索和变革才发展到目前阶段的。让我们一起回顾过去，看一看全链路压测的演进之路，这些“历史”有助于我们更好地理解全链路压测。
全链路压测需要在生产环境中实施，才能避免环境差异造成的压测结果失真。但在生产环境中进行压测也会带来额外风险，因此，在实施全链路压测时，我们需要对系统进行数据隔离，并辅以各种技术改造工作和监控工作。在不具备这些能力之前，有一种方法可以让我们在测试环境中以较低的成本先“定性”地识别出系统可能存在的容量隐患，这种方法称为基线容量测试。
基线容量测试的具体做法是，按照与生产环境相同的部署方式搭建一套测试环境（以下简称基线环境），其中涵盖必需的中间件和网络设施，资源规模可以按生产环境的规模等比例减少。之后，将各服务的主干版本部署到基线环境上，通过压测的方式获取系统的容量指标并记录备案，这些指标称为“基线指标”。
首先，我们假定基线指标是符合系统的容量要求的，当系统服务准备发布新版本时，我们就可以在基线环境上部署这个新版本，以相同的标准进行压测。然后，将结果指标与基线指标进行对比，如果某些关键指标出现大幅异动，如响应时间大幅增加、CPU利用率大幅增加等，就需要技术人员介入以排查系统的风险。
基线容量测试可以在一定程度上提前发现系统潜在的容量隐患，但是由于基线环境与生产环境不完全对等，因此，我们既无法对服务容量进行定量评估，也无法为限流设置、超时设置等容量治理工作提供参考。
要更真实地评估系统服务的容量情况，我们还是要在生产环境上做压测。集群缩放压测是一种在生产环境中进行系统服务容量评估的早期实践，它的做法是逐步缩减集群内的服务器数量或实例数量，使得单台服务器或单个实例所承载的流量不断增加，从而评估出集群可承载的最大流量，并以此推算出单位流量增长所需扩容的服务器数量或实例数量。
集群缩放压测的优势是很明显的，它基于系统的线上真实流量，我们不需要编写任何压测脚本，也不需要准备任何压测数据，压测过程中也不会产生脏数据。但它的劣势同样明显，首先，系统线上操作的风险比较高，一旦集群规模被缩减至瓶颈点，容易引发系统的线上事故；其次，由于集群缩放压测基于系统的线上真实流量，因此对流量规模有一定要求，如果流量太小，当集群缩减到单服务器或单实例后依然没有达到容量瓶颈点，就无法推测容量情况。
集群缩放压测还存在一个“致命伤”，即无法对底层基础设施（如数据库、消息队列等中间件）的容量进行评估。虽然我们缩减了应用服务的集群规模，但这些基础设施的资源规模是不变的，在外部请求量恒定的情况下，依然无法评估它们的容量情况。
集群缩放压测只能作为技术人员简单用来摸底系统服务容量的手段，不能满足人们对系统整体容量评估的要求。于是，人们又提出了另一种手段—流量回放，它的做法是先将用户的真实请求记录下来，再将请求的TPS/QPS放大一定倍数后重新执行请求，达到压测的目的。注，TPC（Transaction Per Second，每秒处理的消息数），QPS（Queries Per Second，每秒查询率）。
与集群缩放压测类似，流量回放同样基于用户的真实请求，不需要准备压测脚本和压测数据。我们可以通过调整TPS/QPS倍数来灵活控制压测量，这是流量回放最大的优势。不过，与集群缩放压测不同，流量回放重新执行了一遍请求，我们需要确保请求是“无副作用的”，即不会修改或新增数据，否则会导致数据被污染。因此，流量回放通常只适用于系统部分无状态的“读请求”，无法应用在“写请求”上。
尽管如此，流量回放依然是一种进步很大的实践，在某些“读场景”较多的业务链路压测工作中，它的应用比较广泛。
随着微服务架构的日益盛行，系统中的服务调用关系错综复杂，一个服务可能会被多个服务所依赖，因此，需要以链路的视角来看待服务容量。服务之间的调用链路如图1.3所示。
图1.3 服务之间的调用链路示例
单链路压测的做法是根据业务场景和服务调用情况，划分出局部调用链路后，单独对其进行压测。单链路压测是全链路压测的雏形，用此方法时，我们也要对系统中的数据进行隔离和实施技术改造工作，但由于单链路压测在系统中实施的范围较小，一般都能够在少量业务域内闭环完成，因此单链路压测更容易实施和落地。
不过单链路压测仍然无法评估系统整体的容量情况，这是因为系统整体的容量不是由多条“单链路”的容量简单相加而得到的。服务的容量除了受自身影响，还受依赖服务的影响，而依赖服务又可能有其他调用方，甚至是一些外部服务，这些影响经过累积后，最终的影响范围极难判断。而单链路压测由于缺少外部干扰和资源竞争，容易得出“偏优”的压测结果，不能反映系统的真实承载能力。
因此，我们需要从系统全局视角出发，对整体业务链路和多种业务场景实施全链路压测，这样才能最真实地反映系统的容量情况。由此可见，全链路压测正是在人们的不断实践和探索的过程中逐渐演进出来的。图1.4对这一过程进行了总结，并展示了与全链路压测演进相关的周边技术。
图1.4 全链路压测的演进过程
1.3 全链路压测的发展前景全链路压测已经走过了10年的岁月，当前它正处于生命力最旺盛的时候，几乎每年都有新的实践方法迸发出来。笔者摘录了近几年互联网大型峰会上公开的部分与全链路压测相关的议题，由此可见其活跃程度比较高。
● 2017年QCon全球软件开发大会：全链路压测在滴滴的实践。
● 2017年GIAC全球互联网架构大会：饿了么全链路压测实践与体系建设。
● 2018年GOPS全球运维大会：京东全链路压测军演系统。
● 2019年TOP100全球软件案例研究峰会：京东618/“双11”全链路压测的实践之路。
● 2020年QECon全球软件质量&效能大会：百万级流量无人值守全链路压测实践。
● 2021年QECon全球软件质量&效能大会：大规模微服务体系容量保障提效实战。
● 2021年MTSC中国互联网测试开发大会：华为应用市场春晚百万级QPS全链路压测实践。
● 2022年GIAC全球互联网架构大会：网易云音乐全链路压测实践。
通过上述议题，我发现一个有趣的规律，早年人们更多关注如何实施全链路压测，即如何将全链路压测在企业内有效落地，并解决实际问题。而近几年，重点转变成了全链路压测的降本提效，即如何以更低的成本实施全链路压测。
这一改变为我们带来了一些启示，目前，行业对全链路压测已经不再陌生，对它的效果和价值也有了深刻的认识，因此全链路压测已经进入了成熟期。但相应地，全链路压测实施难度大、成本高、投入多的痛点并没有改变，这也制约了全链路压测在更多中小型企业的推广和落地，因此全链路压测的降本提效成了近几年的研究热点及方向。
降本提效的理念贯穿于全链路压测的整个生命周期，包含压测前期、压测中期、压测后期这3个阶段：
● 压测前期的主要工作是压测脚本和压测数据的准备，以及压测模型的构建，提效的重点在于如何自动化生成这些内容，减少人力投入；
● 压测中期指的是压测执行阶段，无人值守压测是该阶段目前的研究重点，涉及自适应压测策略、压测风险全自动管控等内容；
● 压测后期的重点是压测结果分析，需要进行“根因”分析，做到自动识别系统服务的容量隐患。
上述这些工作在行业内已经有了一定的实践成果，也是本书的重要组成部分，在后续章节中我们还将进行深入解读。
让我们将视野进一步扩展至互联网技术发展的趋势上，云原生是目前互联网行业最火爆的热点技术之一。那么，在“云原生时代”下，全链路压测又该何去何从呢？
云原生技术的发展确实改变了互联网服务容量保障的底层逻辑。其中，最典型的例子就是弹性伸缩，即根据业务需求和流量情况自动调整计算资源。如果弹性伸缩的速度足够快，我们就无须提前对系统进行容量规划，在流量峰值来临时直接对系统进行实时扩容就可以了。此外，主流的云服务商都支持按需付费，用户只需要为系统服务实际消耗的资源支付费用，所以，弹性伸缩还能为我们节省成本。
弹性伸缩还有一个好处是，它基于Serverless（无服务器）理念，将服务资源的管理工作下沉到基础设施中，这样，管控粒度更细、更具备实时性，而且业务方不需要关心服务资源的消耗，弹性伸缩能够将服务容量始终维持在安全水平。
用一句话总结，有了云原生技术的加持，系统的容量保障逐渐成为云基础设施能力的一部分，通过弹性伸缩结合一定的容量预测能力，我们能够更快速、更经济地保障服务容量维持在安全水平。这几乎颠覆了传统的容量保障工作，似乎我们不再需要全链路压测来提前评估服务的容量情况了，对于容量风险的容忍度也可以更高了，但真的是这样吗？
事实上，目前以弹性伸缩为代表的云原生容量预测技术并不具备太大的应用能力，这和云原生所宣传的效果还存在很大的距离。究其原因，笔者认为主要有以下几点：
● 容量预测技术尚未发展到非常成熟的阶段，对容量的预估不够精确，它的效果还无法与全链路压测的效果相提并论，自然也就无法支持大规模的自动化弹性伸缩；
● 弹性伸缩的风险较高，特别是缩容操作有引发线上服务异常的可能性，甚至会直接导致事故的发生；
● 扩缩容速度不够快，无法满足快速弹性伸缩的要求，尤其是像网店的“秒杀”活动这样的流量急速上升的场景，更是弹性伸缩的软肋。
在这些问题被彻底解决之前，全链路压测依然是容量保障最重要的“武器”之一，它的地位无可取代。同时，全链路压测也可以与弹性伸缩相结合，通过对全局容量进行评估并将评估结果反馈给基础设施，我们可以保证在较短的时间内提前完成伸缩操作，这同样节省了成本。
综上所述，全链路压测技术正处于高速发展的时期，它与如今主流的技术发展方向几乎都有交集。我们有理由相信，全链路压测将逐渐成为互联网公司的标配技术，其应用前景很广阔。
1.4 本章小结通过本章讲解的内容，我们逐步揭开了全链路压测的面纱，对全链路压测的诞生背景、概念、价值、特点和演进之路等有了深入的认识。同时，我们还介绍了全链路压测的发展前景，以与时俱进的视角看待全链路压测。主要内容总结如下。
● 互联网软件系统容量指单位时间内软件系统能够承载的最大业务量。
● 对未来可能产生的流量峰值而言，任何预防性的容量保障手段，都不如把实际峰值场景模拟出来“看一看”更有效。
● 全链路压测就是基于实际的生产业务场景和系统环境，模拟海量的用户请求和数据流量，对整个系统业务链进行容量测试，并持续对系统进行调优的过程。
● 全链路压测的实施并不是单一的技术应用，它是一项综合性技术工程。
● 单链路压测无法评估系统整体的容量情况，这是因为系统整体的容量不是由多条“单链路”的容量简单相加而得到的。
● 云原生时代下，全链路压测依然是容量保障最重要的“武器”之一。
