CN108536570B - 数据直播间灰度压测的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种数据直播间灰度压测的方法及装置、灰度压测生成压测数据文件的方法及装置、基于灰度发布的持续压测方法及装置和一种基于数据直播间灰度发布的持续压测系统。所述一种数据直播间灰度压测的方法包括：根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；判断压测是否成功；若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；将所述请求数据同步到数据处理平台。通过压测平台的控制，循环压测当前正在进行灰度发布的数据直播间，并重复采集待测试请求场景灰度发布过程中的数据，实现压测数据的日常循环更新。并且灰度用户是真实数据，压测的仿真性较高。

Description

数据直播间灰度压测的方法、装置及系统

技术领域

本申请涉及数据直播间压测领域，具体涉及一种数据直播间灰度压测的方法及装置。本申请同时涉及一种灰度压测生成压测数据文件的方法及装置。本申请同时涉及一种基于灰度发布的持续压测方法及装置。本申请同时涉及一种基于数据直播间灰度发布的持续压测系统。

背景技术

数据直播间，承担着各种数据口径的露出，根据用户的查询请求可以查询数据直播间相关的数据。在双十二项目中，在当天查询的需求会暴增，因此需要对数据直播间的功能作压力测试。并且本次数据直播间使用了新的数据库，新数据库对查询场景集合非常敏感，非常容易因为一个查询请求有问题而导致集群宕机的情况，由于无法估计新数据库的能力，需要对新数据库的能力进行测试。所以如何构建重要场景集合以及分布，是非常重要的。另外，查询随着数据量的增大，单次压测已经不能满足压测的需求。

以往的数据直播间压测方案为影子数据压测方案，多采用影子数据，包括影子账户、影子表等。

影子数据压测方案的缺点为：影子账户非真实用户，由于使用的影子账户并非真实账户，附带的整个账户体系、数据都是不存在的，仿真性是有所欠缺的；在数据成分的构建上，主要通过线上数据统计后做评估，无法构建重要场景集合以及分布，无法测试新数据库的能力；影子数据多是经验评估值，通常需要一个长期过程，无法做到及时的更新，如果要做日常的压测回归，必须人工介入。

发明内容

本申请提供一种数据直播间灰度压测的方法、灰度压测生成压测数据文件的方法和基于灰度发布的持续压测方法，以解决现有数据直播间压测方案仿真性有所欠缺、无法测试新数据库的能力、无法做自动循环测试的问题。本申请另外提供一种数据直播间灰度压测的装置、灰度压测查询生成压测数据文件的装置、基于灰度发布的持续压测方法以及基于数据直播间灰度发布的持续压测系统。

本申请提供一种数据直播间灰度压测的方法，包括：

根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

判断压测是否成功；

若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；

将所述请求数据同步到数据处理平台。

可选的，所述启动当前进行灰度发布的数据直播间的压测步骤之前还包括：

若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，对所述数据直播间进行灰度发布，并采集所述待测试请求场景初始的请求数据。

可选的，所述对所述数据直播间进行灰度发布，并采集初始的请求数据步骤之前还包括：

判断所述数据直播间是否有新的场景上线；

若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布。

可选的，所述判断压测是否成功步骤之后还包括：

若压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

可选的，所述请求数据包括如下数据的至少一种：提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为。

可选的，所述采集所述数据直播间待测试请求场景灰度发布过程中的请求数据的步骤之前还包括：

预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

可选的，所述预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点步骤的实现方式包括：

预先在所述待测试请求场景的关键部位注入统计代码，监听所述待测试请求场景中运行过程中的查询事件。

可选的，所述采集所述数据直播间待测试请求场景灰度发布过程中的请求数据步骤的实现方式包括：

当所述灰度用户查询所述待测试请求场景时，判断监听所述待测试请求场景运行过程中的查询事件发生，通过采集埋点采集所述灰度用户查询所述待测试请求场景的请求数据。

本申请另外提供一种数据直播间灰度压测的装置，包括：

压测模块，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

第一判断模块，用于判断压测是否成功；

请求数据采集模块，若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；

请求数据同步模块，用于将所述请求数据同步到数据处理平台。

可选的，所述装置还包括：

初始设置模块，用于若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，对所述数据直播间进行灰度发布，并采集所述待测试请求场景初始的请求数据。

可选的，所述装置还包括：

第二判断模块，用于判断所述数据直播间是否有新的场景上线；

若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布。

可选的，所述装置还包括：

请求数据停止采集模块，若所述反馈信息为上一轮压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

可选的，所述装置还包括：

预先埋点模块，用于预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

本申请另外提供一种灰度压测生成压测数据文件的方法，包括：

接收所述数据直播间同步的所述请求数据；

通过对所述请求数据进行统计，获取所述请求数据的请求成分列表；

对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件；

将所述压测数据文件推送至压测平台。

可选的，所述请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为。

可选的，所述对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级步骤的实现方式包括以下至少一种：

通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

可选的，所述通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述请求成分列表提供的数据以及数据直播间的历史访问数据，提前预估采取扩散措施后所增加的查询所述待测试请求场景的用户的请求频次，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

可选的，所述通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述数据直播间的不同时间段的历史访问数据，选择合适的平移时间段，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

可选的，所述增加查询所述待测试请求场景的用户的实现方式包括以下至少一种：

将查询所述待测试请求场景频次少的用户替换为查询所述待测试请求场景频次多的用户；

增加查询所述待测试请求场景的灰度用户以外的用户。

可选的，同步到所述数据处理平台的所述请求数据可用于重复回放、分析。

本申请另外提供一种灰度压测生成压测数据文件的装置，包括：

请求数据接收模块，用于接收所述数据直播间同步的所述请求数据；

请求成分列表获取模块，用于通过对所述请求数据进行统计，获取所述请求数据的请求成分列表；

请求频次扩散模块，用于对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件；

压测数据文件推送模块，用于将所述压测数据文件推送至压测平台。

本申请另外提供一种基于灰度发布的持续压测方法，包括：

接收所述数据处理平台推送的所述压测数据文件；

对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

可选的，所述压测数据文件包含最新的压测扩散数据。

本申请另外提供一种基于灰度发布的持续压测装置，包括：

压测数据文件接收模块，用于接收所述数据处理平台推送的所述压测数据文件；

最新适用的灰度用户数据筛选模块，用于对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

本申请另外提供一种基于数据直播间灰度发布的持续压测系统，包括数据直播间、数据处理平台、压测平台；

数据直播间，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；判断压测是否成功；若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；将所述请求数据同步到数据处理平台。

数据处理平台，用于接收所述数据直播间同步的所述请求数据；通过对所述请求数据进行统计，获取所述请求数据的请求成分列表；对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件；将所述压测数据文件推送至压测平台。

压测平台，用于接收所述数据处理平台推送的所述压测数据文件；对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

与现有技术相比，本申请具有以下优点：灰度用户是真实数据，在数据处理平台数据的扩散也都是在真实数据中进行扩散，最大程度模拟线上的真实情况，使压测的仿真性较高；在重要场景集合的构建上，通过对数据直播间不同的场景进行测试，并通过扩散数据构建不同用户不同时间段等多种查询场景集合来测试新数据库的能力；可自动生成数据并推送至压测平台，压测平台控制数据直播间进行压测，压测成功则重新采集访问数据直播间待测试请求场景的数据，实现日常自动化的循环压测。

附图说明

图1是本申请第一实施例提供的数据直播间灰度压测的方法的流程图；

图2是本申请第一实施例提供的数据直播间灰度压测的方法的另一流程图；

图3是本申请第二实施例提供的数据直播间灰度压测的装置的结构框图；

图4是本申请第二实施例提供的数据直播间灰度压测的装置的另一结构框图；

图5是本申请第三实施例提供的灰度压测生成压测数据文件的方法的流程图；

图6是本申请第四实施例提供的灰度压测生成压测数据文件的装置的结构框图；

图7是本申请第五实施例提供的基于灰度发布的持续压测方法的流程图；

图8是本申请第六实施例提供的基于灰度发布的持续压测装置的结构框图；

图9是本申请第七实施例提供的基于数据直播间灰度发布的持续压测系统的平台框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本发明。但是本发明能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施的限制。

本申请是在多个平台配合下共同完成，本申请第一实施例提供一种数据直播间灰度压测的方法。请参看图1，该图为本申请第一实施例的流程图。本申请的第一组权利要求的执行主体是数据直播间，以下结合图1对本申请第一实施例提供的数据直播间灰度发布的方法进行详细说明。

如图1所示，示出了本申请第一实施例提供的数据直播间灰度压测的方法的流程图，包括以下步骤。

步骤S101，根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

本步骤用于启动当前进行灰度发布的数据直播间的压测。根据压测平台预先选择的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。根据压测平台的控制，了解新版本的数据直播间一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能，新数据库的能力，大商户能否正常访问新版数据直播间等功能。

压测平台，软件压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压测平台通过控制数据直播间进行压测，了解被测应用程序一般能够承受的压力，同时能够承受的用户访问量(容量)，最多支持有多少用户同时访问某个功能。

灰度用户数据，进行灰度发布的新版数据直播间新一轮压测时，压测平台推广的适用最新版数据直播间的群体。

最新适用的灰度用户数据，进行灰度发布的新版数据直播间新一轮压测时，压测平台推广的适用最新版数据直播间的最新的群体。数据直播间，承担着各种数据口径的露出，根据用户的查询请求可以查询数据直播间相关的数据，相当于数据看板。

灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。就是在某项产品或应用正式发布前，选择特定人群试用，逐步扩大其试用者数量，以便及时发现和纠正其中的问题。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

简而言之，灰度指不饱和的黑色。使用黑色调表示物体，即用黑色为基准色，不同的饱和度的黑色来显示图像。每个灰度对象都具有从0％(白色)到100％(黑色)的亮度值(注意这个百分比是以纯黑为基准的百分比，百分比越高颜色越偏黑，百分比越低颜色越偏白)。一般情况下在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是互联网产品的定义是由用户投票决定的，在一开始，不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。即容忍失败，允许适度浪费，鼓励内部竞争内部试错。

具体的，压测平台预先选择的最新适用的灰度用户数据，是对数据直播间新一轮压测能达到需要的数量级的适用群体的预估。即选择最新适用的灰度用户数据，是选择那些预估请求频次能达到新一轮压测需要的数量级的灰度用户，向这些最新适用的灰度用户推广最新版的数据直播间。具体怎么做选择，下文的实施例三以及实施例五会作具体解释，此处不作分析。

基于压测平台预先选择的最新适用的灰度用户数据，进行数据直播间的新一轮压测，压测是通过数据直播间的接口进行。向数据直播间的相应压测接口推送最新适用的灰度用户数据，通过判断向相应压测接口推送数据是否成功，进而判断数据直播间的压测是否成功。通过向数据直播间推送最新适用的最新灰度用户数据，进行数据直播间的压测，进而测试该新版数据直播间能够承受相应的压力，是否能够承受所有时间段的用户访问量，新数据库能否正常运行，大商户能否正常访问新版数据直播间等功能。

需要说明的是，压测可以在一个时间段来进行，也可以不规定在哪个时间段进行压测，具体看压测需要测试的内容而定，此处不作限定。当压测规定在某一个时间段来进行，意味着要测试这个时间段访问待测试请求场景的请求频次是否能达到需要的数量级。若访问数据直播间的灰度用户大体上没有改变，只是时间段发生了改变，并且压测成功，则说明原有访问数据直播间的灰度用户的访问量即是数据直播间最大的访问量，数据直播间可以承受原有访问数据直播间的灰度用户该时间段的用户访问量。若访问数据直播间的灰度用户也发生了改变，时间段也发生了改变，并且压测成功，则说明新的访问数据直播间的灰度用户的访问量是数据直播间最大的访问量，数据直播间可以承受新的访问数据直播间的灰度用户该时间段的用户访问量。

优选地，请参看图2，步骤S101之前还包括步骤S106：若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，对所述数据直播间进行灰度发布，并采集所述待测试请求场景初始的请求数据。

本步骤用于对数据直播间进行灰度发布，并采集待测试请求场景初始的请求数据。

初始适用的灰度用户数据，进行灰度发布的新版数据直播间第一轮压测时，压测平台推广的适用最新版数据直播间的初始的群体。

请求数据，数据直播间进行灰度发布过程中灰度用户访问数据直播间待测试请求场景的数据。请求数据包括如下数据的至少一种：提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为。

初始的请求数据，进行灰度发布的新版数据直播间第一轮压测时，在数据直播间待测试请求场景采集的请求数据。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。与现有国内一般的公司发布的作法相比，灰度发布的过程是一个渐近的过程，其实这才是一种正确、规范、安全的发布过程。正常一个产品开发过程中，会对其进行功能测试，用户体验测试，交互评估等。功能测试可以让产品尽量少的BUG；用户体验测试与交互评估等可以在开发过程中，使产品尽可能的满足于用户的使用习惯，以及对功能的可接受程度。但这些都是少部分人的感觉与习惯所产生的结果，只是公司内部的测试+小范围外部测试。

将数据直播间进行灰度发布，即使数据直播间的功能可以平滑上线，在数据直播间正式发布前，选择特定的用户试用，逐步扩大其使用者数量，以及时发现和纠正数据直播间中的问题。由特定的用户决定该数据直播间成功与否，如果成功则扩大数据直播间的使用人数，如果失败则进行相应问题的纠正。通过将数据直播间的功能进行灰度发布的方式，使数据直播间平滑上线，为之后采集用户的请求数据作准备，并且在之后数据扩散的过程中也会用到之前灰度发布中请求访问数据直播间的相关数据。

将所数据直播间进行灰度发布的实现方式是指，保持两份数据直播间不同的版本，让一部分用户先在新版数据直播间进行试用，如果这部分用户能够稳定使用，则把绝大部分的用户迁移到新版数据直播间，如果在新版数据直播间试用出现问题，则退回到数据直播间的原有版本。

在标准的软件产品的发布过程中，这充其量只是一个Alpha版本，而一般互联网产品的发布大多都是做到这里就直接上线，替换了原有的版本，这种跳跃式的发布是非常危险的，如果产品影响面大，对项目成员的压力是非常大的。

灰度发布可以在原有的Alpha版本之后增加了更大范围的外部测试，是一个不断的放量过程，通过这样的发布过程可以使产品的问题暴露出来，而不会影响到全部的用户，最终可以让产品最大程度稳定、适合用户。即保持两份数据直播间不同的版本，让一部分用户先在新版数据直播间进行试用，如果这部分用户能够稳定使用，则把绝大部分的用户迁移到新版数据直播间；如果在新版数据直播间试用出现问题，则退回到数据直播间的原有版本，并及时纠正新版数据直播间的问题。在新版数据直播间重新调整和修改之后再次平滑上线，重复上述放量、发现问题、纠正问题、回滚到原有版本的步骤，直到该新版数据直播间能够最大程度的稳定和适合绝大部分的用户。灰度测试环境就是生产环境，使用的是生产数据，所影响的也是生产环境，只是范围比测试环境更广，更真实。其实就是小范围的生产环境，类似于游戏内测。

灰度发布的步骤一般包括：

1)定义目标；

2)选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等；

3)筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等；

4)部署系统：部署新系统、部署用户行为分析系统(web analytics)、设定分流规则、运营数据分析、分流规则微调；

5)发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表；

6)产品完善；

7)新一轮灰度发布或完整发布。

如果数据直播间要使用灰度发布，与往常的项目过程不同的是，需要做好提升点的预准备，通过数据分析，日志分析找到改进点；也要考虑在出问题时可以快速的定位到问题，并切换到数据直播间的原有版本；当然放量也是可以有多种多样的，可以通过选取最能让产品改进的用户参与新版本的试用，在此处不再赘述。数据直播间的灰度发布可以从业务、功能、性能、用户体验很多方面使产品得以提升，并平滑上线。

数据直播间的灰度发布机制可以通过以下几个维度进行考量：1、需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；2、速度：角度、锐度尤其是速度，是产品在生态中存在发展的根本；3、灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；4、冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错；5、开放协作度：最大程度地扩展协作；6、进化度：让企业组织本身在无控过程中拥有自进化、自组织能力；7、创新度：构建充满可能性、多样性的生物型组织。

例如，ABtest属于灰度发布方式当中的一个小小的分支，让一部分用户继续用版本A，一部分用户开始用版本B，如果用户对版本B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。相对于普通的灰度发布方式，ABtest有两个新的版本，不同的用户试用的版本不同，而普通的灰度发布方式只有一个新的版本。

若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，进行数据直播间的灰度发布。并不是所有的灰度用户都会对数据直播间进行访问，将数据直播间推广到初始适用的灰度用户数据中，灰度用户中的部分用户对数据直播间进行访问，通过扩散每次访问数据直播间的部分灰度用户的数量来实现灰度发布。在数据直播间进行初始的灰度发布时，基于初始试用的灰度用户数据进行推广，并接受其中部分灰度用户进行试用。然后采集数据直播间待测试请求场景的初始的请求数据，即采集待测试请求场景的提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为。

优选地，请查看图2，步骤S106之前还包括步骤S107：判断所述数据直播间是否有新的场景上线；步骤S108，若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布。

上述步骤用于对数据直播间进行新一轮的灰度发布。

所谓场景，是指数据直播间中待用户访问的功能或者页面。

数据直播间会有不同的场景上线，每当数据直播间有新的场景上线时，都会进行新一轮的灰度发布，以测试增加了新的场景的数据直播间能否正常运行。不同于数据直播间最初始进行灰度发布时，测试的请求场景由测试人员任意选择。增加了新的场景的数据直播间进行灰度发布时，一般情况下，测试的请求场景都是新上线的场景。

步骤S102，判断压测是否成功。

本步骤用于判断压测是否成功。

向数据直播间的相应压测接口推送最新适用的灰度用户数据，通过判断向相应压测接口推送数据是否成功，进而判断数据直播间的压测是否成功。若向数据直播间相应压测接口推送数据成功，则判断压测成功；若向数据直播间相应压测接口推送数据不成功，则判断压测不成功。若压测成功，则说明该新版数据直播间能够承受相应的压力达到预估的数量级，能够承受测试时间段的用户访问量，新数据库能够正常运行，大商户能够正常访问新版数据直播间等。若压测不成功，则说明该新版数据直播间不能承受相应的压力达到预估的数量级，不能够承受测试时间段的用户访问量，新数据库不能正常运行，大商户不能够正常访问新版数据直播间等。

步骤S103，若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

本步骤用于采集所述数据直播间的灰度发布过程中灰度用户查询所述数据直播间待测试请求场景的请求数据。

待测试请求场景，进行灰度发布的数据直播间基于一个请求场景进行压测，该请求场景即为待测试请求场景。

若压测成功，则说明该新版数据直播间能够承受相应的压力达到预估的数量级，能够承受测试时间段的用户访问量，新数据库能够正常运行，大商户能够正常访问新版数据直播间等。则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据，从而得以实现日常的循环自动化压测。

并不是所有的灰度用户都会对数据直播间进行访问，将数据直播间推广到适用的灰度用户数据中，灰度用户中的部分用户对数据直播间进行访问，通过扩散每次访问数据直播间的部分灰度用户的数量来实现灰度发布。部分灰度用户数量的方法根据测试人员自行选择，可以依据上一次压测时的人数进行等比例扩散，或者是依据其他方法进行扩散。例如，上一次压测时的试用人数为50个，本次压测的试用人数为100个，下一次的试用人数是150个。灰度用户人数的确定也可以根据测试人员自行选择，本申请不作具体的限定，只要保证每一次压测时访问数据直播间的人数都有所增加即可。

真实采集数据直播间的灰度发布过程中灰度用户查询待测试请求场景的的请求参数，请求比例以及请求时间段等，包含了访问页面(例如，DScode1)、用户、请求比例、请求时间段、请求次数、请求频次、请求行为等其他参数。每一轮灰度发布是基于一个请求场景来采集相关的请求数据，每一轮压测也是基于一个请求场景来进行测试。数据直播间每次一个场景上线，都会进行功能的灰度发布，这样就会采集到很多灰度用户查询所述数据直播间待测试请求场景的的请求数据。例如，用户A、用户B、用户C经常查询时间段的请求数据，如下：

DScodel：用户A访问3次，查询时间段为9点到10点。

DScode2：用户B访问4次，查询时间段为10点到11点。

DScode3：用户C访问5次，查询时间段为15点到16点。

优选地，请参看图2，所述步骤S103之前还包括步骤S110：预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

本步骤用于预先在进行灰度发布的所述新版数据直播间进行埋点。

埋点，所谓“埋点”，是数据采集领域(尤其是用户行为数据采集领域)的术语，指的是针对特定用户行为或事件进行捕获、处理和发送的相关技术及其实施过程。

通过在进行灰度发布的数据直播间预先埋点，判断在监听的事件发生时，通过采集相应的埋点，进而采集灰度用户访问数据直播间的请求数据。

优选地，所述步骤S110的实现方式包括：预先在所述待测试请求场景的关键部位注入统计代码，监听所述待测试请求场景中运行过程中的查询事件。

埋点技术通过在数据直播间待测试请求场景的关键部位植入统计代码，追踪用户的点击行为；或者植入多段代码，追踪用户的连续行为；并通过建立模型等方法，得出用户操作行为；最终作为建立产品数据系统的一个环节准确的收集数据。做数据埋点的方法有很多，第一类是预先设定好想要获取的目标数据，让程序员撰写代码把“采集器”埋到相应的页面上，用于追踪和记录的用户的行为，并把实时数据传送到后台数据库或者客户端。第二类方法是利用第三方统计工具插件(例如，友盟、talking data、百度魔方等)收集想要获得的数据，但是这样的数据就可能会被第三方掌握了。

埋点的业务意义显而易见，即帮助定义和获取分析人员真正需要的业务数据及其附带信息。在不同场景下，业务人员关注的信息和角度可能不同。典型的应用场景有面向数字营销领域的分析，以及面向产品运营领域的分析。前者注重来源渠道和广告效果，后者更在意产品本身流程和体验的优化。两者各有侧重，也可以有一些交叉。本申请主要是面向数据直播间产品运营领域的分析，对于不同的项目和分析目的，应当设计不同的埋点方案，本申请针对待测试请求场景设计不同的埋点方案。

埋点的技术实质，是先监听数据直播间运行过程中的事件，当需要关注的事件发生时进行判断和捕获，然后获取必要的上下文信息，最后将信息整理后发送至服务器端。所监听的事件，通常由操作系统、浏览器、APP框架等平台提供，也可以在基础事件之上进行触发条件的自定义(如点击某一个特定按钮)。本申请监听的是数据直播间运行过程中的查询事件。

优选地，所述步骤S103的实现方式包括：当所述灰度用户查询所述待测试请求场景时，判断监听所述待测试请求场景运行过程中的查询事件发生，通过采集埋点采集所述灰度用户查询所述待测试请求场景的请求数据。

本申请预先在数据直播间的关键部位注入统计代码，监听数据直播间运行过程中的查询事件，通过采集数据直播问埋点的方式进而采集相应的请求数据。当灰度用户查询数据直播间时，判断监听所述新版数据直播间运行过程中的查询事件发生，采集所述灰度用户请求查询数据直播间的埋点，并获取所述请求数据。当灰度用户每次查询一个数据直播间待测试请求场景的功能时，都会在系统里留下请求的埋点，判断监听数据直播间运行过程中的查询事件发生，通过采集数据直播间埋点的方式进而采集相应的请求数据。

优选地，请参看图2，步骤S102之后还包括步骤S109，若压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

本步骤用于停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

若压测失败，则说明该新版数据直播间不能承受相应的压力达到预估的数量级，不能承受测试时间段的用户访问量，新数据库不能正常运行，大商户不能正常访问新版数据直播间等。则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据，不会再进行下一轮压测。

步骤S105，将所述请求数据同步到数据处理平台。

数据处理平台，是离线数据处理平台，可以对数据进行分析计算，即ODPS。ODPS(Open Data Processing Service)，是阿里巴巴通用计算平台提供的一种快速、完全托管的GB/TB/PB级数据仓库解决方案。

通过将所述请求数据同步到数据处理平台，进而对请求数据进行分析计算，得到需要的数据。

本申请第二实施例提供一种数据直播间灰度压测的装置。请参看图3、图4，为本申请第二实施例的结构框图。以下结合图3、图4对本申请第二实施例提供的一种数据直播间灰度压测的装置进行详细说明。

如图3所示，示出了本申请第二实施例提供的数据直播间灰度压测的装置的结构框图，所述装置包括：

压测模块301，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

第一判断模块302，用于判断压测是否成功；

请求数据采集模块303，用于若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；

请求数据同步模块304，用于将所述请求数据同步到数据处理平台。

如图4所示，示出了本申请第二实施例提供的数据直播间灰度压测的装置的另一结构框图，所述装置还包括：

初始设置模块305，用于若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，选择待灰度发布数据直播间的使用比例，按照该比例对所述数据直播间进行灰度发布，并采集初始的请求数据。

第二判断模块306，用于判断所述数据直播间是否有新的场景上线；

若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布；

请求数据采集模块307，用于若压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

预先埋点模块308，用于预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

本申请第三实施例还提供一种灰度压测生成压测数据文件的方法。请参看图5，该图为本申请第三实施例的流程图。以下结合图5对本申请第三实施例提供的灰度压测生成压测数据文件的方法进行详细说明。

如图5所示，示出了本申请第三实施例提供的灰度压测生成压测数据文件的方法，包括以下步骤。

步骤S501，接收所述数据直播间同步的所述请求数据。

本步骤用于ODPS接收所述数据直播间进行灰度发布时采集的灰度用户查询所述待测试请求场景的请求数据。

ODPS(Open Data Processing Service)，是阿里巴巴通用计算平台提供的一种快速、完全托管的GB/TB/PB级数据仓库解决方案，现在已更名为MaxCompute，MaxCompute向用户提供了完善的数据导入方案以及多种经典的分布式计算模型，能够更快速的解决用户海量数据计算问题，有效降低企业成本，并保障数据安全。

MaxCompute主要服务于批量结构化数据的存储和计算，可以提供海量数据仓库的解决方案以及针对大数据的分析建模服务。随着社会数据收集手段的不断丰富及完善，数据规模已经增长到了传统软件行业无法承载的海量数据(百GB、TB乃至PB)级别。在分析海量数据场景下，由于单台服务器的处理能力限制，数据分析者通常采用分布式计算模式。但分布式的计算模型对数据分析人员提出了较高的要求，且不易维护。MaxCompute的目的是为用户提供一种便捷的分析处理海量数据的手段，用户可以不必关心分布式计算细节，从而达到分析大数据的目的。

通过采集数据直播间进行灰度发布时灰度用户查询所述待测试请求场景的埋点，采集灰度用户查询所述待测试请求场景的请求数据，并同步至ODPS，进而通过ODPS中的分布式计算模型快速的分析计算请求数据。

优选地，同步到所述数据处理平台的所述请求数据可用于重复回放、分析；在将来的产品规划中可以起到指导作用，不仅仅应用于本次基于灰度发布的压力测试中。

步骤S502，通过对所述请求数据进行统计，获取所述请求数据的请求成分列表。

本步骤用于获取所述请求数据的请求成分列表。

请求成分列表，包括所述数据直播间日常使用中包含的用户，查询场景，以及行为等，是需要的数据的集合。请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为。

在ODPS接收所述数据直播间进行灰度发布时采集的灰度用户查询所述待测试请求场景的请求数据之后，需对请求数据进行简单的过滤和统计，筛选出符合预定条件的请求成分列表。请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为。

在离线的服务上面对请求数据的统计分析可以通过以下多个维度进行分析：1、非法过滤，对请求数据中非法访问数据直播间的用户的过滤；2、访问页面，灰度用户访问数据直播间的页面，例如DScode1；3、用户，不同的用户访问数据直播间带来的影响不同；4、访问的频次，不同的用户访问数据直播间中功能的频次不同。根据以上维度的分析，得到请求数据的请求成分列表，根据请求成分列表可以得到不同类型的用户在不同的请求时间段访问同一个请求场景的请求次数、请求频次以及请求行为。例如，用户A、用户B、用户C经常查询时间段的请求数据，如下：

DScode1：用户A访问3次，查询时间段为9点到10点。

DScode2：用户B访问4次，查询时间段为10点到11点。

DScode3：用户C访问5次，查询时间段为15点到16点。

DScode1、DScode2、DScode3为查询的同一个查询场景下的不同的页面，用户A、用户B、用户C为不同的用户，9点到10点、10点到11点、15点到16点为不同的请求时间段，3次、4次、5次为不同的请求次数，不同时间段的请求频次可以根据不同时间段的请求次数和时间段时长进行推算，请求行为可以是浏览、上传、下载等。

步骤S503，对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件。

本步骤用于扩散待测试请求场景的请求频次，从而获取相应的压测数据文件。

压测数据文件，将待测试请求场景的请求频次进行扩散，得到待测试请求场景相应的压测数据文件。

压侧数据文件用于对压测平台预先筛选新一轮压测最新适用的灰度用户数据时作策略引导，根据压测数据文件中的数据进而选择新一轮压测时应推广的灰度用户数据，以使新一轮压测的请求频次能够达到需要的数量级。因此压测平台在压测数据文件扩散的数据中筛选新一轮压测最新适用的灰度用户数据，具体选择哪一部分数据进行压测根据不同的压测计划而定，在下文中会作具体解释。

将所述请求成分列表中统计的待测试请求场景的的请求频次扩散到下一轮压测需要的数量级，并获取对应待测试请求场景的压测数据文件。在待测试请求场景的的请求频次可能只有几个，而压测的请求频次则需要几万，因此需要将数据直播间灰度发布时待测试请求场景的的请求频次进行扩散。压测并不是所有的功能都开放给用户，主要是用于测试待测试请求场景短时间内请求次数过大时，数据直播间平台能否承受暴增的数据量压力。并且本申请数据直播间采用的是新数据库，新数据库对查询场景非常敏感，由于无法估计新数据库的能力，因此需要做压测来检验新数据库的能力。

例如，数据直播间每次一个场景上线，都会进行功能的灰度发布，这样就会采集到很多灰度用户访问数据直播间待测试请求场景的请求数据。比如：

DScodel：用户A访问3次，查询时间段为9点到10点；

DScode2：用户B访问4次，查询时间段为10点到11点；

DScode3：用户C访问5次，查询时间段为15点到16点。

其中，DScode1、DScode2、DScode3为查询的同一个查询场景下的不同的页面，用户A、用户B、用户C为不同的用户，9点到10点、10点到11点、15点到16点为不同的请求时间段，3次、4次、5次为不同的请求次数，不同时间段的请求频次可以根据不同时间段的请求次数和时间段时长进行推算，请求行为可以是浏览、上传、下载等。新一轮需要的TPS是1W/S，那么根据上述数据统计的待测试请求场景的查询请求的请求频次，通过各种方式预估扩散到总计为1W/S，进而获取相应的压测数据文件，以备后续将压测数据文件推送到压测平台控制压测。

优选地，所述对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级步骤的实现方式包括以下至少一种：

通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

可以通过增加查询待测试请求场景的用户的方式，将待测试请求场景的请求频次扩散到下一轮压测需要的数量级。增加查询待测试请求场景的用户，进而测试新增的用户访问量能否达到压测的数量级，能否正常访问数据直播间。例如，增加上海某地区的商户，使请求频次达到下一轮压测测试上海某地区的商户能否正常访问数据直播间时需要的数量级。

可以通过时间平移的方式，将待测试请求场景的请求频次扩散到下一轮压测需要的数量级。将现有查询待测时请求场景的用户之前查询的请求数据平移到该用户当前需要的时间段的数据中，进而测试现有查询待测时请求场景的用户该时间段能否正常访问数据直播间。例如将现有查询待测试请求场景用户昨天或者三年前上午10：00-11：00查询的数据，平移到该用户今天上午9：00-10：00的数据中，使请求频次达到下一轮压测测试上午9：00-10：00的访问情况时需要的数量级。

可以通过等比例扩散的方式，根据所述请求成分列表中各个请求成分所对应的不同类型的比例，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。根据对维度统计的请求成分列表中的各个成分进行分析，每个成分都对应不同的类型，例如，用户可以分为不同地区的用户、运营产品不同的用户等，访问页面可以分为Dscode1、Dscode2，请求行为可以分为浏览、下载、上传等。根据每个成分不同类型对应的比例，将待测试请求场景的请求频次等比例扩散。例如，访问待测试请求场景中女装商户和男装商户的比例是2∶1，所对应的请求频次比例是4∶1，则当扩散之后，访问待测试请求场景中女装商户和男装商户的比例为2∶1时，所对应的请求频次比例仍然为4∶1。

上述三种是扩散待测试直播间的请求频次的方法，可以通过以上任意一种方式实现待测试直播间的请求频次的扩散，也可以通过结合任意两种方式实现，也可以结合三种方式实现。压测数据文件只是对压测平台筛选新一轮压测最新适用的灰度用户数据时起引导作用，具体怎么进行筛选依据具体的压测计划而定。可以依照上文中一种方式扩散的数据进行筛选，也可以依照两种或三种方式结合的方式扩散的数据进行筛选。

优选地，所述通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述请求成分列表提供的数据以及数据直播间的历史访问数据，提前预估采取扩散措施后所增加的查询所述待测试请求场景的用户的请求频次，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。需要增加的查询待测试请求场景的用户预先并不知道该用户查询待测试请求场景的请求频次，需要对其进行预估。根据对数据成分列表的数据进行分析，得到要增加哪些用户才可以将请求频次达到下一次压测需要的数量级，将预估可以达到下一次压测需要的数量级的用户添加进来，进而生成相应的待测试请求场景的压测数据文件。

优选地，所述通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述数据直播间的不同时间段的历史访问数据，选择合适的平移时间段，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。需要平移的时间段预先并不知道该用时间段查询待测试请求场景的请求频次，需要对其进行预估。根据对数据成分列表的数据进行分析，得到平移哪些时间段才可以将请求频次达到下一次压测需要的数量级，将时间段平移至预估可以达到下一次压测需要的数量级的时间段，进而生成相应的待测试请求场景的压测数据文件。

优选地，所述增加查询所述待测试请求场景的用户的实现方式包括以下至少一种：

将查询所述待测试请求场景频次少的用户替换为查询所述待测试请求场景频次多的用户；

增加查询所述待测试请求场景的灰度用户以外的用户。

可以通过将查询待测试请求场景频次少的用户替换为查询所述待测试请求场景频次多的用户，扩散查询待测试请求场景的用户。在数据直播间的功能进行灰度发布的时候，选择特定的用户试用，逐步扩大其使用者数量，一般情况都是选择普通的小商户进行试用，不会选择热点的大商户，因为大商户查询数据直播间时，请求频次高，数据直播间承受压力较大，有可能会发生宕机。之后做请求频次扩散的时候再将小商户替换为大商户，获取相应的压测数据文件推送到压测平台，从而达到测试大商户的目的。

具体的步骤是，有些小商户交易量比较小，但是查询场景比较丰富，针对此类小商户替换成交易量比较大的大商户，使查询页面、查询频次、查询时间段等不变。这里查询的时间时间段不变是指，查询请求发起时间、查询时间的长度都相同。例如，上海大区的经理D要查询数据直播间，上海大区交易量很高，请求频次高，上海大区的经理在数据直播间一查就会发生宕机。则先让东北地区经理E去查询数据直播间，两者的查询时间、查询频次、查询页面差不多，通过替换小商户ID为大商户ID将小商户的查询行为替换成大商户的查询行为，从而测试大商户ID能否能否正常访问数据直播间。

需要说明的是，查询数据直播间的用户包含多种，包括内部高管、经营小二、外部商户、地区经理、小商户等。本申请主要用于内部压测，因此查询数据直播间的用户主要是商家和平台相关工作人员，商家和平台相关工作人员通过内部的数据直播间查看活动的销售数据，进而执行相应的操作。

可以通过增加查询待测试请求场景的灰度用户以外的用户的方式，来扩散查询待测试请求场景的用户。所述灰度用户以及灰度用户以外的用户都是真实数据，针对某一些真实的用户作灰度发布，并且在真实数据里作扩散，进而生成相应的压测数据文件推送至压测平台，实现测试灰度用户以外的用户的目的。

步骤S504，将所述压测数据文件推送至压测平台。

本步骤用于自动推送所述压测数据文件到压测平台。

将之前扩散好的所述压测数据文件自动推送到压测平台，与对应的压测计划关联，可实现自动化的压测。压测平台是以文件来推动的，现有技术的压测一般是人为操作的，本申请将压测数据文件自动推送到压测平台，压测平台进而根据压测数据文件筛选数据直播间新一轮压测最新适用的灰度用户数据，实现自动化的压测。需要说明的是，压测平台区别于之前进行数据扩散的数据处理平台ODPS，也区别于进行灰度发布的数据直播间，是控制数据直播间进行压力测试的另一个平台。

本申请第四实施例还提供一种灰度压测生成压测数据文件的装置。请参看图6，该图为本申请第四实施例的结构框图。以下结合图6对本申请第四实施例提供的灰度压测生成压测数据文件的装置进行详细说明。

如图6所示，示出了本申请第四实施例提供的灰度压测生成压测数据文件的装置，包括以下模块。

请求数据接收模块601，用于接收所述数据直播间同步的所述请求数据；

请求成分列表获取模块602，用于通过对所述请求数据进行统计，获取所述请求数据的请求成分列表；

请求频次扩散模块603，用于对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件；

压测数据文件推送模块604，用于将所述压测数据文件推送至压测平台。

本申请第五实施例还提供一种基于灰度发布的持续压测方法。请参看图7，该图为本申请第五实施例的流程图。以下结合图7对本申请第五实施例提供的基于灰度发布的持续压测方法进行详细说明。

如图7所示，示出了本申请第五实施例提供的基于灰度发布的持续压测方法，包括以下步骤。

步骤S701，接收所述数据处理平台推送的所述压测数据文件。

本步骤用于接收数据处理平台推送的压测数据文件。压测平台接收数据处理平台自动推送的压测数据文件，来推动压测平台根据压测数据文件筛选数据直播间新一轮压测最新适用的灰度用户数据。

步骤S702，对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，进行当前进行灰度发布的数据直播间的压测。

具体的，压测平台在压测数据文件扩散的数据中筛选新一轮压测最新适用的灰度用户数据，具体选择哪一部分数据进行压测根据不同的压测计划而定。若新一轮压测是测试压测数据文件中新增的查询待测试请求场景的用户能否正常访问数据直播间，则将数据直播间推广到压测数据文件中增加的查询所述待测试请求场景的用户中去。例如，需要测试压测数据文件中增加的上海某地区的大商户能否正常访问数据直播间，则将数据直播间推广到该上海某地区的大商户中去。若新一轮压测是测试某一个时间段的用户访问量数据直播间能够访问，并且访问数据直播间的用户没有改变，则将数据直播间基于平移的时间段，仍然推广到原有的访问数据直播间的用户中去。例如，需要测试原有的江苏某地区的商户晚上18：00-19：00访问数据直播间的访问量数据直播间能否承受，则将数据直播间在晚上18：00-19：00推广到原有的江苏某地区的商户中去。若新一轮压测是测试某一个时间段的用户访问量数据直播间能够访问，并且访问数据直播间的用户发生改变，则将数据直播间基于平移的时间段，推广新增的访问数据直播间的用户中去。例如，需要测试新增的上海某地区的商户晚上18：00-19：00访问数据直播间的访问量数据直播间能否承受，则将数据直播间在晚上18：00-19：00推广到新增的上海某地区的商户中去。

若压测数据文件是根据请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将待测试请求场景的请求频次扩散到下一轮压测需要的数量级。则根据对请求成分列表中各个请求成分所对应的不同类型的比例的等比例扩散进行分析，筛选数据直播间新一轮压测时最新适用的灰度用户数据。控制进行等比例扩散的请求成分所对应的不同类型的比例保持不变，进行数据直播间的推送，推送的方式同样按照上述或者控制用户或者控制时间段进行，进而达到相应目的的测试。例如，访问待测试请求场景中女装商户和男装商户的比例是2∶1，所对应的请求频次比例是4∶1，则当扩散之后，访问待测试请求场景中女装商户和男装商户的比例为2∶1时，所对应的请求频次比例仍然为4∶1。

对压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于最新适用的灰度用户数据，进行当前进行灰度发布的数据直播间的压测。通过压测测试新版数据直播间能否承受相应的压力达到预估的数量级，能否承受测试时间段的用户访问量，新数据库能否正常运行，大商户能否正常访问新版数据直播间等等。

优选地，所述压测数据文件包含最新的压测扩散数据。

压测数据文件包含最新的压测扩散数据，压测平台基于最新的压测扩散数据筛选数据直播间最新适用的灰度用户数据，并控制数据直播间基于最新适用的灰度用户数据进行压测。在数据直播间压测成功之后，数据直播间会采集最新的请求数据，用于新一轮的请求数据的分析以及相关数据的扩散，从而得以实现日常的循环自动化压测。

本申请第六实施例还提供一种基于灰度发布的持续压测装置。请参看图8，该图为本申请第六实施例的结构框图。以下结合图8对本申请第六实施例提供的基于灰度发布的持续压测装置进行详细说明。

如图8所示，示出了本申请第六实施例提供的基于灰度发布的持续压测装置，包括以下模块。

压测数据文件接收模块801，用于接收所述数据处理平台推送的所述压测数据文件；

最新适用的灰度用户数据筛选模块802，用于对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，进行当前进行灰度发布的数据直播间的压测。

本申请第七实施例还提供一种基于数据直播间灰度发布的持续压测系统。请参看图9，该图为本申请第七实施例的平台框图。以下结合图9对本申请第七实施例提供的基于数据直播间灰度发布的持续压测系统进行详细说明。

如图9所示，示出了本申请第七实施例提供的基于数据直播间灰度发布的持续压测系统的平台框图，所述系统包括数据直播间901、数据处理平台902、压测平台903。

数据直播间901，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；判断压测是否成功；若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据；将所述请求数据同步到数据处理平台。

数据处理平台902，用于接收所述数据直播间同步的所述请求数据；通过对所述请求数据进行统计，获取所述请求数据的请求成分列表；对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件；将所述压测数据文件推送至压测平台。

压测平台903，用于接收所述数据处理平台推送的所述压测数据文件；对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

与现有技术相比，本申请具有以下优点：灰度用户是真实数据，在数据处理平台数据的扩散也都是在真实数据中进行扩散，最大程度模拟线上的真实情况，使压测的仿真性较高；在重要场景集合的构建上，通过对数据直播间不同的场景进行测试，并通过扩散数据构建不同用户不同时间段等多种查询场景集合来测试新数据库的能力；可自动生成数据并推送至压测平台，压测平台控制数据直播间进行压测，压测成功则重新采集访问数据直播间待测试请求场景的数据，实现日常自动化的循环压测。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

1、计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

2、本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

Claims (22)

1.一种数据直播间灰度压测的方法，其特征在于，所述方法包括：

根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

判断压测是否成功；

若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据，所述请求数据包括如下数据的至少一种：提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为；

将所述请求数据同步到数据处理平台，所述数据处理平台用于通过所述请求数据获取所述请求数据的请求成分列表，对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

2.根据权利要求1所述的数据直播间灰度压测的方法，其特征在于，所述启动当前进行灰度发布的数据直播间的压测步骤之前还包括：

若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，对所述数据直播间进行灰度发布，并采集所述待测试请求场景初始的请求数据。

3.根据权利要求2所述的数据直播间灰度压测的方法，其特征在于，所述对所述数据直播间进行灰度发布，并采集初始的请求数据步骤之前还包括：

判断所述数据直播间是否有新的场景上线；

若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布。

4.根据权利要求1所述的数据直播间灰度压测的方法，其特征在于，所述判断压测是否成功步骤之后还包括：

若压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

5.根据权利要求1所述的数据直播间灰度压测的方法，其特征在于，所述采集所述数据直播间待测试请求场景灰度发布过程中的请求数据的步骤之前还包括：

预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

6.根据权利要求5所述的数据直播间灰度压测的方法，其特征在于，所述预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点步骤的实现方式包括：

预先在所述待测试请求场景的关键部位注入统计代码，监听所述待测试请求场景中运行过程中的查询事件。

7.根据权利要求5所述的数据直播间灰度压测的方法，其特征在于，所述采集所述数据直播间待测试请求场景灰度发布过程中的请求数据步骤的实现方式包括：

当所述灰度用户查询所述待测试请求场景时，判断监听所述待测试请求场景运行过程中的查询事件发生，通过采集埋点采集所述灰度用户查询所述待测试请求场景的请求数据。

8.一种数据直播间灰度压测的装置，其特征在于，所述装置包括：

压测模块，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

第一判断模块，用于判断压测是否成功；

请求数据采集模块，若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据，所述请求数据包括如下数据的至少一种：提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为；

请求数据同步模块，用于将所述请求数据同步到数据处理平台，所述数据处理平台用于通过所述请求数据获取所述请求数据的请求成分列表，对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

9.根据权利要求8所述的数据直播间灰度压测的装置，其特征在于，所述装置还包括：

初始设置模块，用于若所述灰度发布为新一轮的灰度发布，则基于初始适用的灰度用户数据，对所述数据直播间进行灰度发布，并采集所述待测试请求场景初始的请求数据。

10.根据权利要求9所述的数据直播间灰度压测的装置，其特征在于，所述装置还包括：

第二判断模块，用于判断所述数据直播间是否有新的场景上线；

若所述数据直播间有新的场景上线，则对所述数据直播间进行新一轮的灰度发布。

11.根据权利要求8所述的数据直播间灰度压测的装置，其特征在于，所述装置还包括：

请求数据停止采集模块，若反馈信息为上一轮压测失败，则停止采集所述数据直播间待测试请求场景灰度发布过程中的请求数据。

12.根据权利要求8所述的数据直播间灰度压测的装置，其特征在于，所述装置还包括：

预先埋点模块，用于预先在进行灰度发布的所述数据直播间的待测试请求场景中进行埋点。

13.一种灰度压测生成压测数据文件的方法，其特征在于，所述方法包括：

接收数据直播间同步的请求数据；

通过对所述请求数据进行统计，获取所述请求数据的请求成分列表，所述请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为；

对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

将所述压测数据文件推送至压测平台。

14.根据权利要求13所述的灰度压测生成压测数据文件的方法，其特征在于，所述通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述请求成分列表提供的数据以及数据直播间的历史访问数据，提前预估采取扩散措施后所增加的查询所述待测试请求场景的用户的请求频次，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

15.根据权利要求13所述的灰度压测生成压测数据文件的方法，其特征在于，所述通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级的步骤中，基于如下方式实现：

根据所述数据直播间的不同时间段的历史访问数据，选择合适的平移时间段，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

16.根据权利要求13所述的灰度压测生成压测数据文件的方法，其特征在于，所述增加查询所述待测试请求场景的用户的实现方式包括以下至少一种：

将查询所述待测试请求场景频次少的用户替换为查询所述待测试请求场景频次多的用户；

增加查询所述待测试请求场景的灰度用户以外的用户。

17.根据权利要求13所述的灰度压测生成压测数据文件的方法，其特征在于，同步到数据处理平台的所述请求数据可用于重复回放、分析。

18.一种灰度压测生成压测数据文件的装置，其特征在于，所述装置包括：

请求数据接收模块，用于接收数据直播间同步的所述请求数据；

请求成分列表获取模块，用于通过对所述请求数据进行统计，获取所述请求数据的请求成分列表，所述请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为；

请求频次扩散模块，用于对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；

压测数据文件推送模块，用于将所述压测数据文件推送至压测平台。

19.一种基于灰度发布的持续压测方法，其特征在于，所述方法包括：

接收数据处理平台推送的压测数据文件；

对所述压测数据文件进行分析，筛选数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

其中，所述压测数据文件为所述数据处理平台对请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

20.根据权利要求19所述的基于灰度发布的持续压测方法，其特征在于，所述压测数据文件包含最新的压测扩散数据。

21.一种基于灰度发布的持续压测装置，其特征在于，所述装置包括：

压测数据文件接收模块，用于接收数据处理平台推送的所述压测数据文件；

最新适用的灰度用户数据筛选模块，用于对所述压测数据文件进行分析，筛选数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；

其中，所述压测数据文件为所述数据处理平台对请求成分列表中的数据进行分析，将所述请求成分列表中统计的待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级。

22.一种基于数据直播间灰度发布的持续压测系统，其特征在于，所述系统包括数据直播间、数据处理平台、压测平台；

数据直播间，用于根据压测平台的控制，基于预先选择的最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测；判断压测是否成功；若压测成功，则采集所述数据直播间待测试请求场景灰度发布过程中的请求数据，所述请求数据包括如下数据的至少一种：提出数据请求的灰度用户的身份相关数据以及访问页面、请求次数、请求时间段、请求频次、请求行为；将所述请求数据同步到数据处理平台；

数据处理平台，用于接收所述数据直播间同步的所述请求数据；通过对所述请求数据进行统计，获取所述请求数据的请求成分列表，所述请求成分列表所统计的请求成分至少包括如下内容之一：对所述数据直播间发出查询请求的用户、访问页面、请求时间段、一个请求时间段的请求次数、请求频次、请求行为；对所述请求成分列表中的数据进行分析，将所述请求成分列表中统计的所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级，从而获取对应所述待测试请求场景的压测数据文件，包括以下至少一种方式：通过增加查询所述待测试请求场景的用户，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；通过时间平移的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；根据所述请求成分列表中各个请求成分所对应的不同类型的比例，通过等比例扩散的方式，将所述待测试请求场景的请求频次扩散到下一轮压测需要的数量级；将所述压测数据文件推送至压测平台；

压测平台，用于接收所述数据处理平台推送的所述压测数据文件；对所述压测数据文件进行分析，筛选所述数据直播间最新适用的灰度用户数据，并控制所述数据直播间基于所述最新适用的灰度用户数据，启动当前进行灰度发布的数据直播间的压测。

Images