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

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

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

背景

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

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

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

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

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

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

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

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

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

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

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

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

明确度量需求

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

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

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

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

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

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

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

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

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

度量体系构建

度量方法调研

数据规范化

在做仿真度量之前，需要考虑要将数据先行进行规范化处理，目的是：

• 正向化（一致化处理）：指的是将评价指标的类型进行统一，使得属性值与度量准确度正相关

• 无量纲化 ：不同指标，不同单位

• 归一化：不同指标，数值大小不同

方法选型

评分公式自变量选择

对于接口流量达成度这个指标，从属性来看，它适合中间型的变换，我们期望总流量越接近目标流量，那么这个指标的完成度就越好，这个时候，我们有两种计算方式可以选择。

第一种，可以用总流量和目标流量的差值绝对值当自变量；第二种，用总流量和目标流量的比例当自变量。但通过流量数据的表现来看，使用差值的绝对值，样本点的差异太大，导致其使用规范化之后的数据会集中散布在一点，大部分都是100分，如下图：

因此我们改用了比例当自变量，该问题得以改善，如下图：

度量数据预处理                                          

压测流量预测

一般压测的发单峰值流量会在历史节假日峰值基础上上浮一定比例，但是由于线上从未出现过压测的峰值，如果能预测出线上业务系统在压测水位流量情况，能大大提升仿真度精度。

在滴滴内部有专门的估算，根据历史流量增长情况，引入天气、节气等因子，对未来一个月内流量做流量估算，我们基于这套供需预测模型，考虑节假日因素及增长波动，最小化目标函数与真实流量曲线的误差求得最有压测流量增长曲线及接口峰值。并在实际节假日做了多轮验证，核心业务指标误差在5%以下。

流量预测模型实现与效果验证结果

流量预测也是一个比较大的系统工程，篇幅问题，这里不再细讲，这里需要重点讲的是流量预测是对线上流量理想态的预测，但是线上实际情况要复杂的多，任何线上变更或者线上异常都会影响流量预测效果，比如：

• 节假日高峰期，流量过大，业务执行降级等操作，线上流量模型变化较大；

• 在订单撮合业务中，如果偏后面底层服务出现夯住/躺尸/雪崩，前面的链路会接受远大于估算流量的冲击。

数据降噪

使用比例当自变量以后，仍然发现得分分布不太均匀，大量的得分给到了95到100分，分析数据后发现，有个别比例太大的离群点，影响了整体的分布，把这些点去掉后，再观察一下分布情况。

去掉离群点之后，整体样本均匀分布在了百分制的评分规则上。因此，对于这些比例值比大部分数据高太多的离群点，我们不能把它纳入样本数据来进行计算，要根据具体的业务情况，去掉该数据，或者对该数据，加入白名单，进行单独的考虑。

一般这类我们把它当噪点，去噪点方式主要通过流量过滤、黑白名单、设置阈值或数据预处理。

流量过滤

对于一些流量太小的数据，就直接进行了过滤，这些数据因为流量过小，在正常的发压下，导致比例特别高，过高的比例，影响了公式的最差指标，会导致其他的指标达成的不那么好的，也给了一个较高的评分，从下图2可以看出大量的评分给到了95以上，这样给用户的感觉就不那么客观。

图1

图2

因此将router<100，inrouter<500进行了过滤，过滤之后就得到了图 4，目前这样的得分情况，比较符合预期。

图3

图4

黑白名单

对于一些场景的数据，无法拿到流量，或者因为某种原因，压测不到，比如非网约车业务场景或者一些离线任务调用等等。这些数据加入黑名单，不加入评分计算公式的计算；对于流量较低但是核心接口，这类通过加白处理，避免被识别成低频流量而被过滤掉。

数据阈值与预处理

对于最后的评分结果，我们希望是一个固定的分数，不会因为新样本的增加，而影响之前已经打过分项目的评分。所以，对于中间型变换公式的 max|x-k|这一项，设置了阈值，x=7,当x大于7以后，得分都是0分。

在对得分结果的观察中发现 当0

分析链路的覆盖情况数据，我们发现有些接口线上没有流量，或者流量很低，这些接口不应该纳入链路覆盖度这一模块的考量。因此我们设计了过滤规则，以主链路入口的流量大小为参照物，自定义过滤规则，比如小于主链路入口流量的1%或2%作为过滤条件，同时设定一个最大阈值，当主链路的流量比较大的情况下，流量过滤条件会被拉高，因此我们设定的过滤条件最大为100qps，当其超过100时，统一按100来处理。            

过滤前

过滤后

度量模型搭建

接口覆盖

接口覆盖定义为从router、inrouter维度看压测覆盖情况，主要分两部分内容：一是压测模型对接入层接口的覆盖范围；二是压测流量达没达到预期目标，反映压测模型或者场景配置是否合理。压测目标设定利用流量预测中的能力，接口覆盖计算公式为

其中代表流量达成度， 为计算接口达成情况的公式，为总流量（压测流量+线上流量）与目标流量的比值，k为x的最优期望，y为x的最差阈值，同时引入权重因子，根据接口不同级别设定不同权重， 代表权重计算。为接口覆盖，通用引入权重因子，最终两个维度叉乘计算出接口覆盖实际值  ，最终效果如下：

接口覆盖度效果

压测流量与预测流量曲线图

模块覆盖

对于模块覆盖，核心理念是分析高峰期或节假日高峰时，随着业务单量变化与机器硬件资源消耗、模块流量变化的相关性，并通过压测模型进行拟合。核心需要考量业务单量VS模块流量拟合度， 业务单量VS资源使用拟合度。

这里资源使用量主要考虑cpu使用， 其中模块流量拆分为两大维度，模块下压测接口覆盖率和模块压测总流量与线上流量拟合度。拟合度算法如下：

模块接口、模块流量与业务单量拟合度：

• 对线上高峰期(如周五晚高峰)对比时间发单量与各接口、链路、模块流量进行线性拟合,  生成方程式, 广泛方程式: y = w'x+e

• 利用模块高峰期对比时间的真实流量与上步方程式计算的预测流量进行R方值计算, 算法：  ，结果取值为[-∞,1], 映射为[0-100]，结果小于0的（效果比均差还差），直接默认为0。

模块CPU使用与业务单量拟合度：

• 对线上高峰期(如周五晚高峰)对比时间发单量与各模块CPU真实使用核数进行线性拟合,  生成方程式, 广泛方程式: y = w'x+e

• 利用各模块高峰期对比时间的CPU核数与上步方程式计算的预测流量进行R方值计算, 算法:，结果取值为[-∞,1], 映射为[0-100]，结果小于0的（效果比均差还差），直接默认为0。

拟合度越高，代表和业务单量关系越大，流量预测结果越准确，所有我们对模块覆盖核心分两类：

第一类：拟合度大于0.7

• 使用拟合方程(拟合度计算中的y = w'x+e)计算预测值

• 采用MSE的变种计算， MSE是目前业界公认的比较严苛的评价拟合度的算法r = 1- 1/n∑((Y-y)/y)²

第二类：拟合度小于0.7

• 计算线上高峰期均值与高峰流量及cpu, 得 FlowAver、FlowMax、CpuAver、CpuMax

• 计算压测时间端均值与高峰流量及cpu, 得 PreFlowAver、FlowMax等

• R = 0.5*abs(PreFlowAver - FlowAver) / FlowAver + 0.5*abs(PreFlowMax - FlowMax) / FlowMax

该维度仿真度计算方法

实际落地效果如下：

链路覆盖

链路覆盖度指的是链路压测流量走向与线上流量拟合度，核心目的是看清核心链路从入口接入层到最终存储层的覆盖率情况,  从而辅助压测同学发现链路覆盖薄弱点，下面列举了几种影响该分值的常见场景：

• 压测场景、用户特征等覆盖不全，部分逻辑没有走到；

• 链路异常、业务压测配置与线上配置不一致等因素导致与线上走的逻辑不一致；

• 对压测链路做了特殊处理。

链路覆盖度得分计算原理同模块接口覆盖，通过计算业务流量与每个接口的拟合度，最终计算该接口在压测水位流量值，判断该接口是否覆盖。在计算链路总分时，引入权重因子，计算出该条链路覆盖率：

链路维度存在多条链路，再根据链路权重，计算链路维度仿真度得分：

单条链路压测覆盖拓扑图

链路压测覆盖前端展示效果图

品类&场景覆盖

对于品类和场景，是压测前参考线上真实比例，包括预期压测水位值，有较强的明确性。只需要压测前提前调整压测模型，通过计算品类、场景压测覆盖度和目标达成度即可，权重因子由流量决定，流量越大，权重越大。

其中为流量，为权重，场景覆盖的权重因子主要由流量的大小来决定，因此把当前项的流量 （flow）占总流量的比值作为权重 （weight），流量越高，比重越大。

整体效果演示 

  仿真度量效果（测试版）

总结与展望

基于滴滴的业务场景以及全链路压测实施方式，仿真度的建设是压测闭环链路中不可或缺的一环。通过对接口、链路、模块、品类和场景五个维度量化评估仿真度，能一定程度上以客观数据解释压测覆盖情况，且对压测值守同学在压测模型校准、压测覆盖定向提升等方面提供较大助力。

但线上环境的复杂、多样多变，单靠这几个维度还远远不够，我们需要持续探索其他维度数据，打磨仿真精准度，并挖掘仿真度价值，将仿真度作为一套平台能力，赋能周边业务。

针对仿真度在精度提升、价值挖掘方面，我们将从以下几方面着手：

• 精度提升：扩展维度边界，接入idc机房总资源使用、网络使用(如专线带宽)、接入层整体流量等维度。

• 价值挖掘：压测模型智能调整，辅助智能化压测，降低压测成本；利用流量预测、容量规划能力实现辅助周边业务限流值校准以及容量风险前置评估；感知业务流量重大变化，及时预警等等。

仿真度的建设与滴滴内部各方共同合作密不可分，感谢集团压测平台、数据团队、业务团队以及基础服务团队提供的帮助与支持，期待在各方合作努力下，将仿真度建设更加完善，赋能业务。

 END 

部门介绍 

本篇文章来自网约车出行技术的质量中台团队，出行技术作为网约车业务研发团队，通过建设终端用户体验平台、C端用户产品生态、B端运力供给生态、出行安全生态、服务治理生态、核心保障体系，打造安全可靠、高效便捷、用户可信赖的出行平台。

招聘信息

团队后端、测试需求招聘中，欢迎有兴趣的小伙伴加入，可以扫描下方二维码简历直投，期待你的加入！

研发工程师

岗位描述：

1. 负责相关业务系统后台研发工作，包括业务的架构设计、开发，控制复杂度，提升系统性能和研发效率；

2. 有业务 sense，通过不断的技术研究和创新，与产品、运营一起快速迭代提升业务的核心数据。

测试开发工程师

岗位描述： 

1. 构建适用于网约车业务的质量保障体系，制定并推进相关质量技术方案落地，持续保障业务质量；

2. 深入了解业务，与业务中各角色建立沟通，总结业务问题与痛点，全方位为业务创造价值，工作不设固定边界；

3. 通过应用相关质量基础设施，提升业务代码质量和交付效率；

4. 沉淀高效测试解决方案，并能提供通用化方案，支持在其他业务线落地应用；

5. 解决业务质量保障中的难点问题、复杂技术难题；

6. 质量技术领域前瞻性探索。