CN105450461A - 一种分流方法及网络设备 - Google Patents

Abstract

本申请公开了一种分流方法，分流模块基于应用请求确定需要进行分流处理之后，判断所获取到的与该应用请求对应的cookie信息中是否具有用户标识，并在结果为是的情况下进一步提取cookie信息，调用通用服务化接口利用应用的分流配置文件获取与该cookie信息对应的应用版本信息，从而将应用请求转发至与应用版本信息对应的服务器，以使应用请求的发送端访问与应用版本信息对应的应用。该方案效率高、适用范围广，且无需对分流目标进行额外设置，极大地提高了分流工作的便捷性。本申请同时还公开了一种包含分流模块的网络设备以及一种包含通用化服务接口的网络设备。

Description

一种分流方法及网络设备

技术领域

本申请涉及通信技术领域，特别涉及一种分流方法。本申请同时还涉及一种包含分流模块的网络设备以及一种包含通用化服务接口的网络设备。

背景技术

随着互联网技术的不断发展，越来越多的人们已经习惯在网上进行各类活动，包括娱乐、购物等等。当然目前面临着一个很大的问题，就是信息量过大，网站同质化较多。若非具有一定的壁垒，用户的留存率相对较低。面对上述的诸多问题，如何来进行网站的升级优化是必须要考虑的因素。

针对网站的升级优化，现有技术主要采用ABTest来做线上多版本测试及验证，按照一定的分流规则将线上的部分用户进行新产品功能的验证，根据反馈统计的结果来决断哪个版本更适合用户行为习惯。目前，互联网业界已经有成型的ABTest系统，基本分为动态和静态两种。动态测试主要是由各应用系统实现，按照一定的分流规则进行多版本验证。静态测试则是由前端页面中去加载一段js脚本实现分流。

针对业界通用的ABTest系统进行分析，主要存在着“通用的ABTest系统主要完成的是静态测试，不支持动态测试”、“静态测试更多采用的是简单的随机分流规则，无法实现满足复杂应用场景”以及“动态测试系统由各个应用自实现分流规则，相对较为繁琐，而且不能共享”等问题。而作为一个专业的ABTest工具，其具体的实施方案如下：

步骤1：提出本次测试的目标及内容，是对页面结构调整还是某块区域的内容进行更新；

步骤2：通过步骤1确定方案后，创建一个测试实例，需要提供测试时间及基准测试的URL(UniformResoureLocator，统一资源定位器)；

步骤3：对基准版本中的元素进行调整，生成一个新的对照版本，生成一个新的URL；

步骤4：完成步骤3后，在基准版本对应的页面上嵌入生成的分流及统计脚本，在测试版本及landingpage页嵌入统计脚本。

步骤5：步骤4完成后在线上部署基准及对照版本，进行代码嵌入的验证。当有用户访问基准版本时，能够按等比例分配至各测试版本并统计页面的相关指标。

步骤6：根据统计到的用户反馈结果，对比基准版本与对照版本哪个更符合用户的体验。根据步骤1的所定的目标来验证本次改版是否能达到预期并进一步扩大用户量。

通过以上流程可以看出，现有的通用ABTest工具的设计思路均是创建基准版本及对照版本，生成测试实例后，动态生成分流JS脚本及统计脚本，将分流脚本嵌入至基准版本，统计脚本嵌入至对照版本中，进而达到分流及统计的目的。采用上述方式处理简单的页面内容替换完全没有问题，然而对于象电子商务购物或登录流程的验证等，此类工具就显得力不从心。

由此可见，现有技术中的分流方案仅支持前端页面的测试，且需要对分流的目标进行额外的人工设置操作，其步骤非常繁琐，极大地降低了工作效率。

发明内容

有鉴于现有技术中分流方案所存在的适用范围小、设置繁琐等问题，本申请提出了一种分流方法，该方法应用于设置有分流模块的应用服务器，包括：

所述分流模块接收应用请求，确定与所述应用请求对应的应用；

所述分流模块根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述分流模块从设置有通用服务化接口的服务器集群获取；

若需要进行分流处理，所述分流模块获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识；

若所述cookie信息中具有所述用户标识，所述分流模块提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成；

所述分流模块将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

相应地，本申请还提出了一种包含分流模块的网络设备，包括：

处理模块，用于接收应用请求，确定与所述应用请求对应的应用；

判断模块，用于根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述判断模块从设置有通用服务化接口的服务器集群获取；

辨识模块，用于在所述判断模块判断需要进行分流处理时，获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识；

分流模块，用于在所述辨识模块确定所述cookie信息中具有所述用户标识时，提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成；

反馈模块，用于将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

相应地，本申请还提出了一种包含通用服务化接口的网络设备，包括：

获取模块，用于在所述通用服务化接口被分流模块调用以获取与所述cookie信息对应的应用版本信息时，根据从后台配置管理端获取的与所述应用对应的分流配置文件确定分流规则；

分流模块，用于根据所述分流规则进行分流处理，从所述应用的测试组中确定分流后的测试桶；

确定模块，用于根据所述测试桶的配置信息确定所述应用版本信息。

由此可见，通过应用以上技术方案，分流模块基于应用请求确定需要进行分流处理之后，判断所获取到的与该应用请求对应的cookie信息中是否具有用户标识，并在结果为是的情况下进一步提取cookie信息，调用通用服务化接口利用应用的分流配置文件获取与该cookie信息对应的应用版本信息，从而将应用请求转发至与应用版本信息对应的服务器，以使应用请求的发送端访问与应用版本信息对应的应用。该方案效率高、适用范围广，且无需对分流目标进行额外设置，极大地提高了分流工作的便捷性。

附图说明

图1为本申请提出的一种分流方法的流程示意图；

图2为本申请提出的一种分桶式多版本测试模型示意图；

图3为本申请具体实施例中Apache处理http请求钩子的示意图；

图4为本申请具体实施例提出的一种无侵入式ABTest分流模型示意图；

图5为本申请具体实施例所提出的后台测试配置管理示意图；

图6为本申请具体实施例所提出的通用分流服务化应用内部实现示意图；

图7为本申请具体实施例所提出的Apache实现分流模块逻辑示意图；

图8为本申请具体实施例中程序的框架结构代码示例图；

图9为本申请具体实施例中分流处理器的流程示意图；

图10为本申请提出的一种包括分流模块的网络设备的结构示意图；

图11为本申请提出的一种包括通用服务化接口的网络设备的结构示意图。

具体实施方式

有鉴于背景技术中所提出的技术问题，本申请提出了一种分流方法，基于分桶式多版本测试框架及Apache模块的hook机制的原理设计ABTest分流系统：后台管理模块完成测试实例的配置，其中可以选择动态的调整测试时间、使用的分流规则及动态配置参数等；通用服务化应用将完成真正的分流，并将分流结果以接口的形式暴露给三方应用调用；Apache分流模块则完成请求的处理，调用分流服务化接口，获取分流状态及动态参数，处理完成后将结果响应给用户。

如图1所示，为本申请提出的一种分流方法的流程示意图，该方法应用于设置有分流模块的应用服务器，包括如下步骤：

S101，所述分流模块接收应用请求，确定与所述应用请求对应的应用。

S102，所述分流模块根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述分流模块从设置有通用服务化接口的服务器集群获取。

S103，若需要进行分流处理，所述分流模块获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识。

S104，若所述cookie信息中具有所述用户标识，所述分流模块提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成。

具体地，在当通用服务化接口被所述分流模块调用以获取与所述cookie信息对应的应用版本信息时，所述通用服务化接口首先根据从后台配置管理端获取的与所述应用对应的分流配置文件确定分流规则。随后，通用服务化接口根据所述分流规则进行分流处理，从所述应用的测试组中确定分流后的测试桶。最终，通用服务化接口根据所述测试桶的配置信息确定所述应用版本信息。

为了能及时进行更新，通用服务化接口根据所述应用的名称，定期与所述后台配置管理端同步所述分流配置文件。同时，通用服务化接口设置外部调用接口，以在进行分流处理并获取所述应用版本信息后向外提供所述应用版本信息、所述测试桶的参数以及当前测试状态信息。

基于以上设置，当技术人员需要对应用的各个版本进行分流处理时，即可在通用服务化接口根据所述应用的名称定期与所述后台配置管理端同步所述分流配置文件之前向后台配置管理端输入测试参数，由后台配置管理端据此生成分流配置文件。

S105，所述分流模块将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

上述S104-S105均以cookie信息中具有用户标识为前提进行处理，然而当所述cookie信息中不具有所述用户标识时，所述分流模块将所述应用请求转发至与默认应用版本信息相对应的服务器，以使所述应用请求的发送端访问默认版本的应用。

为了进一步阐述本申请的技术思想，现结合具体的应用场景，对本申请的技术方案进行说明。以下首先为本申请具体实施例中分桶式的多版本测试框架原理：

针对目前的多版本测试方案，可以有不同的实现方式。考虑到Web环境的特殊性及用户体验，多版本测试最基本要保证用户群体能按比例均等的分配至不同的测试版本中，同时在环境不变的情况下同一个用户能始终保持在一个版本中。因此本申请具体实施例首先提出了一种分桶式的模型框架，如图2所示，其模型主要涉及到如下几个的概念：

应用场景：表示本次测试的一个整体概述，一般对应业务人员对本次测试的需求。

测试组：对应应用场景的一个唯一实体描述，可以包括页面元素、排序算法的调整及中间业务逻辑层的变化等，测试组与应用场景一一对应；

分流选择器：即分流规则，它是一种分配算法，如轮询(RoundRobin)、cookie分流、IP_hash分流等。根据该规则将用户分配至不同的测试桶。

多版本测试桶：将用户分配至对应的测试桶时，需要动态替换的一些个性化的参变量。

应用UI层：对外供用户访问的界面或接口。

为了实现以上模型，本申请具体实施例中采用Apache服务器模块运行机制，Apache是一个开放源代码的web服务器，因其跨平台和安全性而被广泛使用，是目前最流行的web服务器之一。由于功能可通过模块扩展而实现，它目前支持非常多的特性，如mod_auth(权限验证)、mod_rewrite(url重写)等。当服务器需要加载某模块时，需要在服务器启动前在其配置文件中配置对应模块，服务器启动后，会load该模块，用于处理服务器特定的请求。

Apache模块通过动态或静态机制可以加载至服务器中，同时ApacheHook机制允许模块将自定义的函数注入到请求处理循环中，从而达到扩展Apache服务器默认处理的机制。一般应用级的模块定义均是对http请求处理部分进行扩展，即在接收到httprequest请求及返回response响应间进行应用的处理，将自定义的函数注入至合适的钩子上。具体地，Apache处理http请求部分的钩子示意图如图3所示，其中各钩子的含义及具体的作用如下所示：

post_read_request:读取客户端发过来的request信息，并交由下一阶段进行处理；

quick_handler:请求处理前被触发，一些缓存的工作可以在此进行处理；

translate_name:将请求的URL映射到本地文件系统或资源；

map_to_storage:确定所请求的资源配置，通常会考虑“目录”和“文件”部分。

header_parser:主要用于检查请求的头部信息；

access_checker:根据配置文件检查文件是否允许访问请求的资源；

auth_checker:按照配置文件设定的策略对用户进行谁，并设定用户名区域；

type_checker:根据请求资源的MIME类型规则，判定将要使用的内容处理函数；

fixups:这是一个通用阶段，允许模块在内容生成器之前，运行任何必要的处理流程；

insert_filter:允许模块在当前请求的输出中插入自定义的filter。

结合上述多版本测试分桶的模型及Apache模块运行机制，本申请具体实施例提出了一种基于服务化无侵入的ABTest分流装置，该装置的整体概况如图4所示。主要由后台配置管理、通用服务化应用及应用服务器模块几部分组成。主要流程的各步骤及完成的功能如下所示：

后台配置管理：管理员在其中配置分流场景及本次测试的分流所需的详细参数；

通用服务化应用：完成配置信息的同步、对外提供获取测试状态及版本的服务化接口；

同步分流配置：定时从后台配置管理中同步分流参数及变量信息；

服务化接口：服务提供者，对外提供应用访问时的调用及分流契约依据。

web服务器：完成用户请求处理，并用于配置公共模块、分流模块及服务器配置。

公共模块：对应web服务的通用模块，如：core模块、mod_alias模块等。

服务器配置：服务器启动及运行需要加载的文件，其中包括如跳转规则、虚拟主机及目录的配置等。

分流模块：调用服务化接口获取测试状态及版本信息；

应用部署：将应用部署发布至对应的服务器。

基于上述说明，以下将从“后台配置管理”、“通用分流服务化应用”以及“Apache分流模块设计”三方面详细阐述实现本申请方案：

(1)后台配置管理

为了达到参数的可视化配置、选择器的重用及修改参数后实时生效，不需要业务方每次改动重新发布应用程序，可以通过后台配置管理的方式来完成参数的配置。如测试的开始结束时间、使用的分流选择器的类型及参数等。同时对外提供文件同步接口，通用外部服务调用，即可获取配置文件信息。根据多版本测试的应用场景及需求，其后端配置的功能模块设计如图5所示，包括：

应用测试集：应用接入时，系统会对应为该应用分配一个名称。在做应用升级或文件同步时，能够单独对该应用进行操作，从而做到应用级的隔离性；

测试场景：对应用升级时，每个场景都会对应一次测试，各个测试间需要具有独立性。可以根据测试需求制定相应的测试计划，其中包括测试时间、测试选择器(随机、IP、地域、cookie等)、测试组等。

数据存储：应用管理、测试管理及测试对应的时间、选择器、测试组及参数的配置信息的存储。

文件同步服务：测试在创建后，管理端只是提供一份配置文件的契约，需要将该份配置文件同步至通用服务化应用中，再根据该契约文件进行相应的分流。该模块提供的即是配置文件的输出服务。

(2)通用分流服务化应用

后台配置管理完成了测试的创建，而它只是生成了一份契约式的配置文件。真正的分流逻辑的实现是由该通用分流服务化应用模块完成的。该模块对应的内部结构实现如图6所示，包括：

同步分流配置：根据配置的应用名从后台配置管理端获取配置文件，并将取到的文件存放至本地内存；

选择器：选择器的具体实现，根据配置文件中的选择器描述通过反射机制实例化对应的选择器，并根据配置文件中配置的分流规则进行分流；

测试组桶：通过分流规则完成分流后，会对应到测试组中的某一个测试桶中，根据配置文件中测试桶的配置信息获取对应的参数值；

对外服务化接口：提供给外部调用的http接口，通过该接口能获取对应的版本信息、某个测试桶的参数及当前测试的状态等信息。

(3)Apache分流模块设计

对于web服务器，目前业界流行的有apache、nginx等。这些服务器的架构均采用的是模块式开发，当有新功能需要加入时，可以自定义实现一个模块，将其挂载并load至服务器中，服务器在启动或运行时即可装载该模块的功能。本文正是基于这种可扩展式的开发模式，针对该分流模块提出并设计了一个多版本分流方案。该分流方案对业务使用方是完全透明的，只需一次在服务器环境搭建时，将该模块载入进来并编译。后期做多版本测试时，只需要创建测试场景即可。服务器则会根据用户请求信息调用服务化接口获取相应版本，并将请求转发至对应的服务器，以完成分流的功能。同时为了对本次测试的效果进行验证，可以在响应结果返回时插入一段js脚本用于收集用户的分流结果，进行效果统计分析。

基于Apache服务器模块的运行机制原理，模块的开发可以根据具体的需求hook至apache对应的钩子上。分流模块即可基于post_read_request与fixup是两个钩子进行开发，且分流效果的统计即可在response响应结果时在filter阶段插入自定义的filter，从而将分流脚本返回至客户端。基于上述各勾子设计的分流方案逻辑示意图如图7所示。包括：

ap_hook_post_config：在apache初始化阶段，将该分流模块load至apache服务器。

fixup：它是最后一个hook点，选择在这里进行分流逻辑的判断，同时将btFilter插入至filter链中。分流逻辑会调用通用服务化应用接口，根据用户请求完成相应的分流，获取到对应的版本及参数信息；

BtFilter：根据datahandler中获取到的配置，将所需要的打点脚本插入至response结果中，并调用其它filter，返回给客户端。

由此所生成的程序的框架结构代码示例如图8所示，从该模块的框架结构分析可以看出，分流处理器是整个模块的设计核心。其功能主要是调用通用服务化接口根据用户请求进行分流并将获取到的测试版本参数传入至应用服务器中。因此分流处理器的流程设计如图9所示，其步骤如下：

S901：从服务器端获取模块的配置信息，当前是否需要进行测试，以及测试所需要的服务器地址等信息；

S902：根据应用名从服务化接口获取当前应用的测试状态，如果状态不生效，则直接跳过分流场景；否则转入S903执行；

S903：获取用户访问的cookie信息，若没有任何用户标识，转入结束并访问默认应用；否则转入S904执行；

S904：提取用户cookie信息，并调用服务化接口获取对应的版本信息；

S905：将版本信息写入用户cookie中，以供下次访问时能够直接进行版本判断。

需要指出的是，分流逻辑作为分流模块的逻辑实现，由abSplit_handler函数来实现，该函数会hook在fixup钩子上。同时分流模块在服务器的配置文件中进行配置，并在服务器启动时将其装载进来。当有用户请求时，即可完成相应的分流逻辑，达到多版本测试的目的。将该分流模块进行编译、发布会生成so文件并装载至apache服务器中，服务器在启动时会自动加载该模块。

综上所述，本申请具体实施例中的设计方案分为三部分进行部署，后端配置管理作为一个管理端部署到一台服务器上，对外提供测试配置查询服务；通用服务化接口则实现了多版本测试框架，用于获取测试契约脚本，并根据分流规则对某应用进行分流，需要部署到一个集群上对外提供分流功能；Apache分流模块则需要部署到各应用服务器上，同时需要在配置文件httpd.conf中设置相应的初始化参数，根据应用名从通用服务化接口中获取对应的分流版本及参数。

同时，对于测试场景的创建、修改、删除等操作能够做到实时同步，不需要重启web服务器。由于测试场景是在后端配置并进行管理，同时由通用服务化接口对外提供服务。因此当测试场景有所修改，如(修改测试时间、分流比例、分流参数)，可以实时通过服务化接口暴露出来，而不需要重启web服务器，从而可以做到实时同步。采用该方案线上可以用来做灰度发布及紧急故障的修复等逻辑验证。

由此可见，以上技术方案具有以下几个明显的有益效果：

(1)分流规则上可以更加多样化，根据各个应用可以定制个性化选择器。如随机，IP，会员、白名单、地域等均可以实现，而且这些均可以由业务方自己去扩展实现；

(2)方案不单单适用于web界面的改版及优化，而且适合于后端引擎、流程优化及移动App应用的测试；

(3)完全通过后台管理来控制测试时间、分流比例，且无须在业务代码中嵌入脚本，只需在apache服务器启动时加载该分流模块即可。

为达到以上技术目的，本申请还提出了一种包括分流模块的网络设备，如图10所示，包括：

处理模块101，用于接收应用请求，确定与所述应用请求对应的应用；

判断模块102，用于根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述判断模块102从设置有通用服务化接口的服务器集群获取；

辨识模块103，用于在所述判断模块102判断需要进行分流处理时，获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识；

分流模块104，用于在所述辨识模块103确定所述cookie信息中具有所述用户标识时，提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成；

反馈模块105，用于将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

在具体的应用场景中，若所述cookie信息中不具有所述用户标识，所述反馈模块将所述应用请求转发至与默认应用版本信息相对应的服务器，以使所述应用请求的发送端访问默认版本的应用。

本申请还提出了一种包含通用服务化接口的网络设备，如图11所示，包括：

获取模块111，用于在所述通用服务化接口被分流模块调用以获取与所述cookie信息对应的应用版本信息时，根据从后台配置管理端获取的与所述应用对应的分流配置文件确定分流规则；

分流模块112，用于根据所述分流规则进行分流处理，从所述应用的测试组中确定分流后的测试桶；

确定模块113，用于根据所述测试桶的配置信息确定所述应用版本信息。

在具体的应用场景中，还包括：

同步模块，用于根据所述应用的名称，定期与所述后台配置管理端同步所述分流配置文件；

设置模块，用于设置外部调用接口，以在进行分流处理并获取所述应用版本信息后向外提供所述应用版本信息、所述测试桶的参数以及当前测试状态信息。

在具体的应用场景中，所述分流配置文件由所述后台配置管理端根据输入的测试参数生成。

通过应用以上技术方案，分流模块基于应用请求确定需要进行分流处理之后，判断所获取到的与该应用请求对应的cookie信息中是否具有用户标识，并在结果为是的情况下进一步提取cookie信息，调用通用服务化接口利用应用的分流配置文件获取与该cookie信息对应的应用版本信息，从而将应用请求转发至与应用版本信息对应的服务器，以使应用请求的发送端访问与应用版本信息对应的应用。该方案效率高、适用范围广，且无需对分流目标进行额外设置，极大地提高了分流工作的便捷性。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种分流方法，其特征在于，所述方法应用于设置有分流模块的应用服务器，所述方法包括：

所述分流模块接收应用请求，确定与所述应用请求对应的应用；

所述分流模块根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述分流模块从设置有通用服务化接口的服务器集群获取；

若需要进行分流处理，所述分流模块获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识；

若所述cookie信息中具有所述用户标识，所述分流模块提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成；

所述分流模块将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

2.如权利要求1所述的方法，其特征在于，还包括：

若所述cookie信息中不具有所述用户标识，所述分流模块将所述应用请求转发至与默认应用版本信息相对应的服务器，以使所述应用请求的发送端访问默认版本的应用。

3.如权利要求1所述的方法，其特征在于，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成，具体为：

当所述通用服务化接口被所述分流模块调用以获取与所述cookie信息对应的应用版本信息时，所述通用服务化接口根据从后台配置管理端获取的与所述应用对应的分流配置文件确定分流规则；

所述通用服务化接口根据所述分流规则进行分流处理，从所述应用的测试组中确定分流后的测试桶；

所述通用服务化接口根据所述测试桶的配置信息确定所述应用版本信息。

4.如权利要求3所述的方法，其特征在于，在所述分流模块接收应用请求之前，还包括：

所述通用服务化接口根据所述应用的名称，定期与所述后台配置管理端同步所述分流配置文件；

所述通用服务化接口设置外部调用接口，以在进行分流处理并获取所述应用版本信息后向外提供所述应用版本信息、所述测试桶的参数以及当前测试状态信息。

5.如权利要求1所述的方法，其特征在于，还包括，

在所述通用服务化接口根据所述应用的名称定期与所述后台配置管理端同步所述分流配置文件之前，所述分流配置文件由所述后台配置管理端根据输入的测试参数生成。

6.一种包含分流模块的网络设备，其特征在于，包括：

处理模块，用于接收应用请求，确定与所述应用请求对应的应用；

判断模块，用于根据所述应用的测试状态，确定是否需要进行分流处理，所述测试状态由所述判断模块从设置有通用服务化接口的服务器集群获取；

辨识模块，用于在所述判断模块判断需要进行分流处理时，获取与所述应用请求相对应的cookie信息，并判断所述cookie信息中是否具有用户标识；

分流模块，用于在所述辨识模块确定所述cookie信息中具有所述用户标识时，提取所述cookie信息，并调用所述通用服务化接口获取与所述cookie信息对应的应用版本信息，所述应用版本信息由所述通用服务化接口根据所述应用的分流配置文件生成；

反馈模块，用于将所述应用请求转发至与所述应用版本信息对应的服务器，以使所述应用请求的发送端访问与所述应用版本信息对应的应用。

7.如权利要求6所述的网络设备，其特征在于，还包括：

若所述cookie信息中不具有所述用户标识，所述反馈模块将所述应用请求转发至与默认应用版本信息相对应的服务器，以使所述应用请求的发送端访问默认版本的应用。

8.一种包含通用服务化接口的网络设备，其特征在于，包括：

获取模块，用于在所述通用服务化接口被分流模块调用以获取与所述cookie信息对应的应用版本信息时，根据从后台配置管理端获取的与所述应用对应的分流配置文件确定分流规则；

分流模块，用于根据所述分流规则进行分流处理，从所述应用的测试组中确定分流后的测试桶；

确定模块，用于根据所述测试桶的配置信息确定所述应用版本信息。

9.如权利要求8所述的网络设备，其特征在于，还包括：

同步模块，用于根据所述应用的名称，定期与所述后台配置管理端同步所述分流配置文件；

设置模块，用于设置外部调用接口，以在进行分流处理并获取所述应用版本信息后向外提供所述应用版本信息、所述测试桶的参数以及当前测试状态信息。

10.如权利要求8所述的网络设备，其特征在于，

所述分流配置文件由所述后台配置管理端根据输入的测试参数生成。