导读
作为国民级出行生活服务平台，高德服务的稳定性不论是平时还是节假日都是至关重要的，服务稳定性一旦出问题，可能影响千万级甚至上亿用户。春节、十一等节假日激增的用户使用量，给高德整体服务的稳定性带来了不小的挑战。每年在大型节假日前我们都会做整体服务的全链路压测。通过常态化全链路压测项目的推进，已具备了月度级别的常态化全链路压测能力，把战前演练提到日常，持续推进稳定性保障建设。
TestPG压测平台2018年9月启动，在2019年春节第一次支撑高德全链路压测任务，当时前后花了近2周的时间才完成3个机房的压测任务。后来成立了常态化全链路压测项目，通过对流程的优化以及压测平台技术能力的升级，现在已经具备了1天内完成全国3个机房全链路压测的能力。大型节假日的全链路压测周期缩短到了3天。
全链路压测的常态化不仅对高德整体服务的稳定性建设起到了推动作用，而且也推动了流程上的优化以及压测平台在技术能力上的改进提升。具体而言，我们主要从压测前的语料准备和压测过程中的压力调控两个方面入手，通过语料平台化生产，规范语料生成流程，对语料生产提效；通过压测过程中对发压能力的精准调控，使我们能够灵活调整压力模型，从而使其更加接近于线上真实情况，让全链路压测过程平滑流畅，效率提升。本文会重点介绍TestPG压测平台在发压能力精准调控方面的建设实践。
压力调控的两个主要问题
下图是现阶段高德全链路压测的一个大致流程
高德全链路压测涉及到接入层的上百个接口，每个压测接口的压测流量需要在链路梳理阶段由运维和相关同学事先预估给定。压测前会在压测场景里对每个接口的流量进行分配，通过流量占比事先配置好，这是我们全链路压测的压力模型。压测启动之后，会逐步加压，直到整体压测流量到达预估值，在整个过程中，可能会对事先配置的压力模型不断做出调整，最终使压测流量模型符合预期的线上流量模型。
高德全链路压测涉及的链路比较长，压测流量流经接入层，服务层最终到达引擎层，有可能出现实际到达引擎的流量与预估流量之间存在差异。这时候会先停止压测，更新压测场景里的接口压测流量占比配置，然后再启动压测。
在高峰期，压测集群中可能有百十台施压机同时施压，停止压测，更改压测场景里的接口流量占比配置，再启动压测，然后再一次逐步加压，这样一整套流程会非常耗时而且效率低下，有时只为了更新一两个接口的流量占比配置，不得不把前面的步骤再走一次，导致过多耗费时间精力。不断起停也使整个过程不连贯，无端拉长了全链路压测周期。
再者，在全链路压测过程中，整体压力是逐步增加的，多轮加压，每一轮加压后都会监控服务的各项指标来决定是否进一步增加压力。TestPG压测平台采用分布式集群施压模式，增压是通过往压测集群里调度新的施压机实现的，这样带来的问题就是，增加压测流量的时候，需要相关人员根据压测时候的单机施压能力大致估算出需要增加多少机器。由于增减的压力=单机施压能力*n台施压机，这样的压力调控粒度也是比较粗糙的。比如要加压1w qps，单机的施压能力是3k qps, 那么需要增加3台或4台施压机，那么实际增加的压力为9k或者1.2w。
最后，也是最重要的，高德业务系统对接口特征参数（对服务的功能/性能有重大影响的接口参数）尤为敏感，比如长短距离导航对后台服务的算力和资源消耗都是不同，这就提出了更高的要求，我们需要有能力在全链路压测中对接口的压力调控精确到特征参数级别。
简单总结一下，在压测过程中，针对压力调控，我们面临两个主要问题，一是压力调控效率低下，二是无法做到细粒度的精准调控。
实现路径
全链路压测是以真实流量提前对系统进行验证。只有以接近于线上真实流量的压力模型对系统进行压测，才更能发现可能隐藏的稳定性问题，压测才能更有价值。由于我们的压力模型是预估给出的，难免会与实际服务预期的流量存在差异。所以压测过程中通过对差异流量做调整，最终使压测流量模型符合预期的线上流量模型。
既然现阶段压测过程中，压力调整在所难免，并且由于其效率低下，已经影响到了全链路压测的顺利进行，那么就可以以此为抓手，在压力调控能力上做技术改进。首先是解决压力调整效率低下问题，保障全链路压测的流畅进行，提升效率。然后结合语料智能化项目，实现精准压测，使压测流量（压力模型+压测场景）更加接近于线上真实流量。未来可以进一步探索，提供丰富的压力模型以更好地支撑场景化压测的诉求。
接下来会介绍TestPG压测平台，在施压能力精准调控建设上的技术方案和落地成果。
技术方案
TestPG压测平台采用分布式集群施压模式，多台施压机构成一个压测集群。平台的整个架构是典型的master-slaver结构，压测的时候master调度slaver进行施压。这样的架构其实非常适合我们实现压力动态调控的一个自动控制系统。
上图是压力调控系统的一个抽象示意图。
压力调控中心是压力调控系统的大脑。其主要作用是根据压力调控策略向压测集群中的施压机下发压力调控指令，并且能够根据调控反馈数据，决定进一步的调控策略。
压测集群作为压力调控对象，接收压力调控中心下发的调控指令，并实施具体的压力调控动作。
压测集群与压力调控中心之间存在一个反馈渠道，这样压力调控中心就可以知道调控的效果，并根据反馈数据，对下一步的调控进行决策。
落地架构
以上是TestPG压测平台精准控压建设的一个落地架构示意图。
API Gateway模块承接用户压力调控指令，并把压力调控指令转发到Stress Contoller(压力调控中心)。
Stress Controller是压力调控的大脑，会根据压力调控策略向压测集群中的施压机下发调控指令，并根据反馈数据，决定下一步调控策略。
TestPG基于Redis实现了动态配置缓存。压力调控指令通过动态配置缓存下发到压测集群，更具体来说是下发到压测集群中的每台施压机上，目前TestPG采用两种方式实现动态配置的下发，分别是施压机主动拉取和通过发布订阅模式进行实时推送。
压力调控指令下达到施压机后，压测引擎运行实例会加载压力调控配置，实时调整压力。
每个压测引擎都会实时上报自己到压测指标（比如qps, rt等）和施压机的性能指标（比如cpu占用率，load率等）到TSDB时序数据库，TSDB建立了压测集群和压力调控中心之间的反馈渠道。Stress Controller定期查询TSDB，获取每台施压机以及整个压测集群的压测指标作为反馈数据，根据这些反馈数据判定单机压力调控成功与否，整个压测集群压力调控成功与否，并且会根据反馈数据决策是否进行进一步的调控。
基于以上架构，TestPG压测平台在精准控压建设上，已实现了集群和接口两个级别的精准调控。
集群压力调控
通过集群压力精准调控，在压测过程中，可以随时指定要压的预期qps，如果是下调压力，平台会非常快的把压测集群的输出流量，压到指定的预期qps。如果是上调压力，当前压测集群中的施压机整体输出压力上调后不能达到预期的qps，系统会从施压机公共资源池调配一定数量的施压机进入压测集群，确保在服务容量以内，压测流量能够上调到预期qps。通过这个功能，压测过程中增减压力，我们不再需要人工根据单机施压能力估算要增减多少施压机，整个压力调控过程完全是由系统自动进行的。集群的整体压力也实现了精准调控，达到平台在压力输出能力上指哪打哪的能力。
功能介绍
在压测过程进行中，可以对压测任务预期qps进行指定。
压测集群整体压力输出根据指定的预期qps实时调整。
接口压力调控
接口级别的压力调控，目前平台已经落地了接口流量占比动态调整能力，压测过程中可以随时对接口差异流量做调整，实现了在不停压测的情况下对接口流量占比的即时调整能力。该功能对保障全链路压测的顺利进行起到了关键作用，让我们可以方便高效地对压力模型做调整，使全链路压测得以平滑顺利进行，提升了全链路压测参与各方的幸福感。
今年十一全链路压测，由于业务增长较快，导致压力预估模型与实际预期有较大出入，通过接口比例动态调整功能，在不停压测的情况下我们对压力模型进行了近百次调整，保证了全链路压测的流畅度，保障了全链路压测的顺利进行。
针对于接口特征参数级别的精准调控，我们的解决方案是：通过语料智能化生产，对接口特征参数提取和统计，可以把压测接口按特征参数分布拆分为多个，结合接口调压能力，最终在接口级别压力调控上，可以进一步实现接口特征参数级别的更精细调控，这对于高德业务系统的全链路压测来说是非常重要，可以使我们实施更加精准的压测。
功能介绍
在压测过程中，对压测接口流量占比实时调整。
接口发压流量占比实时调整效果。
总结
通过发压能力精准调控的建设，目前TestPG压测平台具备了集群和接口两个级别的高效精准压力调控能力。提升了全链路压测效率，有效缩短了全链路压测的周期，在全链路压测过程中可以使我们方便高效地对压力模型做调整，使其更加接近于线上真实情况。
全链路压测的目的在于验证服务稳定性保障措施是否符合预期，提前发现服务稳定性问题。压测的真实性至关重要，这里的真实性是指压测的语料数据与线上用户场景相符合，压力模型也要与线上相符合。目前我们的压力模型是通过计算和预估的方式给出的，往往与线上压力模型存在出入；而压测数据虽然是基于线上流量生产的，但与春节、十一当天的场景还是有差异的。
在真实性保障上，目前TestPG压测平台也已经有了相应的解决方案，那就是语料智能化生产加上精准控压。未来，我们期望通过语料智能化项目的推进，借助机器学习等手段，通过对压力模型，以及用户场景的预测，并结合精准控压技术，让全链路压测的压测流量模型更加接近于春节、十一等节假日线上真实情况，实现真正意义上的精准压测。
未来思考
精准控压技术，赋予了平台对压力的精准调控能力，解决了全链路压测过程中，压力调控效率低下问题，保障了全链路压测的顺畅度；并且通过对压力模型的方便高效调整，也使得全链路压测的压力模型更加符合线上真实情况。但是精准控压技术的用武之地不应该局限于此。
未来我们可以在压测类型上做进一步探索。目前从TestPG压测平台的使用情况大致来看，日常压测上大家并没有有意识的区分压测类型。绝大多少情况下大家都是以固定qps持续对系统施压。但是，线上系统面临的真实流量有时候并不是固定，有可能出现极限尖峰脉冲等情况。平时系统如果没有压测过这种极限场景，那么线上系统遇到这种异常流量时就有可能被打挂。
基于精准控压技术，我们可以在压力模型上做进一步深挖，未来可以在平台上提供多种压测类型支持，比如负载测试、压力测试、系统容量预估测试等等。并为每种压测类型配备相应的压力模型，比如可以提供负载递增的压力模型，这样可以方便我们探查系统容量极限；又比如通过提供极限脉冲压力模型，可以有效测试系统在遭遇异常流量时候的表现。我们期望通过提供丰富的压测类型支持，把系统性能的各方面都测到，把系统压测做全做得更专业。
本文为阿里云原创内容，未经允许不得转载。
来源：oschina
链接：https://my.oschina.net/u/1464083/blog/4738834