随着哈啰用户体量的不断增大，业务场景越发复杂化，尤其在目前已变成群众出行必不可少的基础设施的背景下，如何识别线上系统瓶颈、风险，保证系统的高可用已经变得尤为重要，让技术更好的服务业务，创造更多的价值。        

聊到全链路压测，对很多同学来说更关注它的技术实现细节，这没错。但全链路压测想要成功的在生产环境实施、落地，其实也需要很好的组织和流程机制。本文也会着重从技术细节和流程机制两个方面来给大家介绍如何通过生产全链路压测来识别系统风险，保证高可用的。

首先，如果在线下做全链路压测，我们需要部署和维护一套线下的全链路系统，加上线下环境的不稳定性等特性，我们会疲于保证线下系统可用性上，投入成本极高；并且线下的服务器和存储以及其他基础设施资源规格和线上不一致，产出的压测结果并一定能够真正指导我们进行线上合理的容量预估和基准线设定的稳定性相关工作。

其次，很多同学可能都针对单接口、单链路或者单服务做压测，不管是线上还是线下，我们会发现，其实等到线上全网流量真正起来之后还是会存在很多问题。由于线上流量和业务的复杂性，做这样的压测，我们会遗漏掉很多流量对系统的影响，最终得出的压测接口也不能真正合理的指导维护线上系统的稳定性。

再有，我们的功能从一个月迭代一次到现在一周迭代一次，留给测试的时间越来越短。功能测试时间从之前的一周、两周缩短到现在三四天、两三天的时间，那性能测试就没有办法按时上线，很有可能会出现各种各样的性能问题，这会直接影响到公司的品牌影响力。

总之，我们希望通过生产全链路压测，使得生产系统有足够的冗余和合理的预案来应对线上的复杂度和不确定性。

1、精准的容量评估和系统基准线设定；

2、端到端的全链路巡检，主动发现线上问题和风险；

3、验证相关预案的合理性和时效性。

1、正常迭代测试完成，上线后出现各种系统故障；

2、对线上系统容量和资源预估只能根据"重点服务、核心链路，资源多给点"的经验之谈；

3、性能团队在尽力完成相关的性能测试，但是线上还是会有相关的系统故障出现；

4、根据业务场景，比如B端业务可能全链路压测的诉求不是很大，C端业务的大概率是需要做全链路的压测。

参与人员：非功能测试、业务开发(单人)、DBA

这个阶段，主要针对核心开关锁链路进行压测，由于还没有整个链路详细的上下游依赖，以及业务影响，我们只能通过不断压测来调整用户模型和流量模型，业务改造，来保证链路能够压通并达到目前压力，在此过程中，事前准备到压测值班，再到压测问题定位和复盘，都只单人参与，其他同学对压测整个项目的进程以及本质并没有很清楚，甚至是完全不知道。

参与人员：非功能测试、业务开发(多人)、中间件、DBA、大数据

在我们核心链路能够正常进行压测后，我们开始考虑和扩大压测业务的范围，使我们能够真正的了解线上服务的容量、瓶颈以及风险。在这个阶段，我们选取了占网关前95%的流量，也动员了更多的业务开发参与其中，通过全链路压测人让更多的人提升风险意识。中间件同学的接入，让我也开始开始考虑数据、日志隔离的问题，不断完善压测的技术方案。

参与人员：非功能测试、技术风险、业务开发

通过以上两个阶段，全链路压测在线上的实施流程已经全部跑通，这个时候我们更多的关注是如何让全链路压测变得更加规范和更加有效率，常规化，并且做出更加精准的线上容量预估和基准线的设定。我们增加了很多规范和机制，不断的演习和完善，从以前的每次压测（数据预埋、压测、数据清理、复盘）4天的时间周期，缩减至2两天，并且建立起每月2次全链路压测（月中单独全链路压测，月底跟随全业务线进行全链路压测）的常规机制。

下面我们通过“技术细节”和“流程机制细节”两个方面来详细展开讲述全链路压测在的落地历程

整体：

某业务线：

从2018年开始，我们开始进行生产全链路压测，出于之前并没有太多在生产使用jmeter进行分布式加压的实操经验，当时压测流量主要是通过Jmeter发起，以手动执行脚本为主。

从2019开始，通过线下对Jmeter工具的不断使用和一些特性的掌握，性能测试同学逐步开始全部用Jmeter来进行生产全链路压测，自研压测平台也在研发和调试中。

从2021开始，开始使用自研压测平台pt-test正式进行生产全链路压测。

首先，我们来看下业务场景。如上图，该业务线主要的业务有三个要素构成：运营区、用户、车辆，所以我们主要需要构造的压测流量就是压测城市、压测用户、压测车辆，下面我们来具体聊一下，这个三个数据是如何构造的。

压测城市选定

选取一块目前在业务上实际未使用的区域，划定为了运营区，并且按照产品模型，划定了相应的站点、规范停车区、禁停区等，还原线上的运营实情。

压测车辆

关于压测车辆，我们本应该走车辆投放流程，造一批虚拟车辆，但是由于考虑到走正式投放流程，事件流较长，涉及到的业务部门的人较多，不易推进，而且会产生很多无用的压测相关数据，故我们最后选择直接操作储存介质，将相关需要的压测单车信息直接写入到数据库和redis中，造出一批虚拟压测单车。

压测用户

压测虚拟用户和压测虚拟车辆做法相同，也是通过直接操作储存介质，来造一批虚拟用户，通过对线上用户的特征分析，得出了用户模型。我们的用户有持卡类型，非持卡类型，开通免密未开通免密等，通过相关对用户的骑行卡，免密签约token等数据提前预埋，来还原线上各类用户的占比，尽量使我们的压测用户流量和真实流量靠近。

业务改造+压测用户特征识别

针对一些业务场景需要对压测数据进行过滤，比如：投保，数据回流、超时订单结束等，我们前期通过识别压测用户标识，硬编码来过滤压测用户流量和数据，不让这些数据走到后面的业务逻辑中去。

中间件改造+压测流量标透传

为了彻底消除压测前业务开发和数仓信息不对等的情况发生，以及由于压测数据流入数仓，导致数仓模型的数据准确性受到严重影响，以及兼容后续其他方需对压测数据无感知的情况。故中间件针对压测进行了升级，支持了压测流量标识透传，保证在压测链路的每一环和每一个参与方在需要的时候都可以识别压测流量。具体实现如下图：

正如前言部分提到的，想要将全链路压测在生产上高效率、可控的执行，并且压测常态化，我们除了关注压测的一些技术实现外，我们还需要一个完善且可执行的流程机制，以及模板化的文档。如下图，这边将整个压测生命周期分成了压测前、压测开始、压测结束，在各对应的节点也明确了操作流程规范和一些标准化、模板化文档，使整个压测过程落地变得执行可控和高效率。

如下图，在压测的整个执行落地的各个环节，我们明确各位参与同学的职责，提升参与人员的专注度和压测的效率、成功率。

在公司微服务架构的技术背景下，一个服务从开发、构建、测试、集成到部署再到升级，都变得更加灵活、敏捷了，以及可扩展性的提高等。但微服务架构并非银弹，也存在很多缺点。比如，系统网络拓扑的复杂度变高，会引起一系列的高可靠相关的问题和风险。如何提前发现这些问题和风险？这个也是我们一定要在生产进行全链路压测的理由，建立起常态化的压测机制。

目前公司为大小发布周，故这边按照每月两次（月中单独进行全链路压测，月底跟随全业务线进行压测）的节奏进行常态化的生产压测。来提前发现生产问题和风险，以及验证线上预案。

系统基准线设定

现在目前已经达成历史峰值2倍压力的目标，后续准备拉出一份，压测目标下，各个接口的tps的，用于推进各接口基准线设定，给限流以及压测终止的相关提供参考。

数据、指标隔离

目前压测数据隔离方便我们还有很大欠缺，我们的相关压测数据都落到了生产真实数据所在的储存介质中，大量压测数据的堆积，占用了可用空间，影响了储存介质的性能，同时针对某些数据我们不得不进行压测后的清理，大大增加了压测操作的生命周期，降低了压测效率。后续会对影子表相关解决方案的落地进行推进。

业务指标这块也还没有进行隔离，压测期间会影响会导致真实指标的波动，会造成我们指标波动的误判，从而放过了当时由线上真实业务、流量引起的波动，给系统稳定性埋下隐患。后续准备推进针对压测指标和非压测指标进行重新配置。

完善压测模型。

我们现在的压测流量模型的完善基本是靠每次的压测问题中分析得出，没有提前得出十分贴近线上流量的模型，这样会导致我们有相关线上真实场景是覆盖不到的，而且也有可能因流量模型和线上系统容量不一致导致此次压测不能顺利完成。我们目前也在与测试效能组探讨，流量录制接入压测的可能性，通过流量录制，录制反映链路流量的热力图，将非压测期间的热力图与压测期间的热力图对比，得出没有被压测流量覆盖的场景，通过调整压测入参，使得压测模型更加趋近生产。

压测生命周期平台化、自动化

这一块主要期望压测平台在自动化方便更加完善，从压测接口模型、压力发起，到根因分析，再到压测报告改进优化跟踪等方面，做得更加的自动化和平台化。