压多少抗多少，滴滴全链路压测仿真度量体系建设

滴滴在重大节假日、活动前为保障线上系统稳定，需要通过全链路压测做多轮风险排查以及容量验收，我们经常听到这样的声音"你们全链路压测和线上业务场景有多大差异"、"是不是压测达到目标线上真的能抗这么大量"、"我的某某个模块感觉在压测期间压力比线上大很多呢" 等等。我们缺少一套能看清压测覆盖与真实系统下流量差异的手段，而主观验证存在很大误差和不合理性，所以我们通过构建一套压测仿真度量体系，科学评估压测覆盖和真实系统的差异性。

从2020年开始网约车压测团队开始重点建设压测仿真度量体系，并实现工程化落地应用，本文将系统化介绍滴滴网约车全链路压测仿真度量体系建设过程。

背景

随着滴滴网约车线上业务场景越发复杂化以及网约车业务的潮汐特性、节假日突增流量冲击，稳定性保障挑战巨大，全链路压测是应对当前复杂分布式环境下，系统面临的诸多不确定性可能导致系统可用性问题的核心手段，全链路压测是通过技术手段模拟海量用户的真实请求和数据，对整个业务链路进行各种场景测试验证，持续发现线上系统潜在的稳定性风险，协助验证系统是否能承受已制定的重大活动、事项的流量预估，辅助各服务方开展风险排查和解决。下图为网约车全链路压测建设图：

对于网约车全链路压测来讲，最大的挑战是在模拟真实场景时存在大量不确定性因素：

• 时间和空间不确定性， 乘客发单后要求固定时间内接单，司乘匹配条件依赖司乘距离，司机投放地是按线上司机出车地零散分布；

• 订单距离以及司机接送驾时间不确定性，压测司机接送驾无法完全模拟线上真实道路场景，比如堵车等，压测司机接送驾速度过快会导致运力过于充足，过慢则会导致运力不足，导致压测和线上真实场景存在偏差；

• 成单不确定性，司机接单完全依赖分单匹配策略，同一司机同一地点，接到的订单都可能不一样；

• 还有诸如场景不确定、品类不确定以及其他业务线流量对于公共模块的资源抢占等等。

如此多不确定因素加持下，我们需要保障全链路压测足够仿真，才能实现“压多少抗多少”的目标。仿真度量体系就是为了衡量全链路压测可信度的关键途径，它有两方面意义：一是看清全链路压测覆盖现状，让稳定性相关同学了解自己对应的系统、服务、链路等压测覆盖真实情况，提升大家对全链路压测的信任度。二是发现压测覆盖脆弱点，指导压测维护同学定向提升，形成正向闭环，保障压测效果。

滴滴建设仿真度量体系的过程主要有四个阶段，如下图所示：

• 度量需求是指对仿真体系进行度量时所采用的度量范围和度量程度，度量范围用于明确度量系统界限；

• 度量体系构建是分解度量要求，对界定的度量范围进行系统化计算，包括度量数据获取、评分模型构建以及权重因子选择等；

• 度量效果验证是对度量体系的明确，通过多轮的度量实验已公式校准，最终寻求一个与预期结果最相符的模型；

• 度量架构搭建是度量体系的工程化落地，包括架构选项、架构搭建以及业务逻辑实现等等。

明确度量需求

全链路压测仿真度提升过程，总结来看可以划分为三个大的节点：

1. 覆盖度提升，早期全链路压测覆盖聚焦在8个维度，衡量标准依赖和线上真实高峰期流量对比两者gap值，业务需求驱动，人为主观验证偏多，目标多以接口、品类数量覆盖为主。

2. 看清问题，在不同维度覆盖度提升到一定程度以后，开始关注压测效果以及分析压测薄弱点，定向提升，期间我们基于8个维度数据做了一系列可视化产品，辅助我们看清压测问题。

3. 目标导向，只是看清问题还不够，我们还需要一套指标衡量体系量化当前仿真度，并且基于现状设定合理年度目标值，形成牵引。也就引申出仿真度的度量体系，我们在原来提升维度标准范围内，基于当前基建情况以及技术实现成本考虑，最终确定5大可衡量维度，并做了二次拆解，拆解如下：

• 接口覆盖(压测接口覆盖率、流量达成仿真度[router、inrouter])

• 场景覆盖(场景定义、场景流量、流量对比)

• 品类覆盖(品类全集、品类流量、流量对比)

• 链路覆盖度(接口维度、流量维度) 

• 模块覆盖度(模块流量覆盖、模块接口覆盖度、资源维度(cpu\内存)） 

度量体系构建

度量方法调研