CN103176790A - 应用发布方法和*** - Google Patents

Abstract

本发明提供了一种应用发布方法，包括以下步骤：接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符；基于用户请求信息和从配置服务器中获取的应用配置信息，对用户请求信息进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件，则重写当前用户请求中的统一资源定位符；将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本。本发明还提供一种实现前述方法的应用发布***。本发明的应用发布方法及***，能够对应用灰度发布实现统一控制管理、节省应用灰度发布时间以及成本。

Description

应用发布方法和***

技术领域

本申请涉及计算机数据处理技术领域，特别是涉及一种应用发布方法及***。

背景技术

互联网产品通常需要不停的升级更新以更好的实现其功能和满足用户需求。但在产品升级过程中，通常会出现新旧版本兼容、升级版本的产品不稳定，或者大量用户同时升级造成的***崩溃，以及用户不习惯等问题。为了解决这些问题，很多互联网产品会采用灰度发布的策略，即选取一小部分用户作为新版本的发布对象，通过对这些用户使用过程中的问题进行搜集和检测，若发现问题，则及时更新、修改等调整，若没有问题，则进一步扩大新版本的发布范围。

一般情况下，在一种新产品的灰度发布过程中，开发者通常会预先选取测试用户、测试环境和测试服务器，并将这些测试用户放入新产品的白名单中。在接收用户使用请求时，通过判断该用户是否在白名单中来确定是否进入测试服务器中的灰度发布版本。此种方法中，为了避免影响正常运转，灰度发布版本的服务器通常都是少量几台，当需要扩大测试范围时，则需要重新调整配置其他服务器，而且灰度发布的环境与线上环境不同，每次都需要对灰度发布环境进行配置调整，这需要耗费较多的时间和精力。另外，灰度发布的范围通过产品开发者的设定来控制，当有多个产品发布时，则存在多种灰度发布范围的控制，由于发布范围不同，无法实现统一控制，这增加了管理难度和成本。

发明内容

本申请提供一种应用发布方法及***，以解决应用灰度发布时存在费时且无法统一控制管理的问题。

为了解决上述问题，本申请公开了一种应用发布方法，包括以下步骤：

接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符；

基于用户请求信息和从配置服务器中获取的应用配置信息，对用户请求信息进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件，则重写当前用户请求中的统一资源定位符；

将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本。

进一步地，所述方法还包括更新应用配置信息，所述更新应用配置信息包括：

监听配置服务器中的应用配置信息的修改操作；

从预存的配置表中查询所述修改的应用配置信息所对应的应用服务器；

将所述修改后的应用配置信息同步到所述应用服务器。

进一步地，所述应用配置信息包括：

应用的统一资源定位符和分流策略。

进一步地，所述判断当前用户是否符合进入灰度发布版本的条件包括：判断当前用户的统一资源定位符与应用配置信息中的统一资源定位符是否匹配，若匹配，则根据分流策略来判断当前用户是否符合进入灰度发布版本的条件。

进一步地，所述重写当前用户请求中的统一资源定位符包括：在当前用户请求中的统一资源定位符添加标识；所述处理还包括：若当前用户符合进入灰度发布版本的条件符合，则不做处理；

所述应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本包括：若处理后的当前用户请求中的统一资源定位符包含标识，则表示能够进入灰度发布版本，反之，则表示不能够进入灰度发布版本。

进一步地，所述重写当前用户请求中的统一资源定位符包括：添加符合标识在当前用户请求的统一资源定位符中；所述处理还包括：若当前用户不符合进入灰度发布版本的条件，则添加不符合标识在当前用户请求的统一资源定位符中；

所述应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本包括：若处理后的当前用户请求中的统一资源定位符包含符合标识，则表示能够进入灰度发布版本，若包含不符合标识，则表示不能够进入灰度发布版本。

进一步地，所述标识为graypub参数，graypub参数的不同取值分别表示符合标识和不符合标识。

为了解决上述问题，本申请还公开了一种应用发布***，包括：

用户请求接收模块，用于接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符；

配置信息获取模块，用于获取配置服务器中的应用配置信息；

处理模块，用于基于用户请求信息和从配置服务器中获取的应用配置信息，对当前用户请求进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件符合，则重写当前用户请求中的统一资源定位符；

请求传递模块，用于将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符以及应用配置信息，确定当前用户进入的版本。

进一步地，所述***还包括：

监听模块，用于监听配置服务器中的应用配置信息的修改操作；查询所述修改的应用配置信息所对应的应用服务器；将所述修改后的应用配置信息同步到所述应用服务器。

进一步地，所述应用配置信息包括统一资源定位符和分流策略，所述处理模块包括：

判断单元，用于判断所述当前用户的统一资源定位符与应用配置信息中的统一资源定位符是否匹配，若匹配，则根据分流策略来判断当前用户是否符合进入灰度发布版本的条件。

进一步地，所述处理模块还包括：

标识添加单元，若当前用户符合进入灰度发布的条件，则添加符合标识在当前用户请求的统一资源定位符中，反之，则添加不符合标识在当前用户请求的统一资源定位符中；或者

若当前用户符合进入灰度发布的条件，则添加标识在当前用户请求的统一资源定位符中，反之，则不做处理。

与现有技术相比，本申请包括以下优点：

本申请的应用发布方法和***对客户端通过服务器发送给应用的访问请求进行拦截，先对访问请求进行过滤，根据预定的条件来判断当前用户所能访问的应用版本，并根据判断结果对访问请求中的统一资源定位符进行重写，从而对访问用户实现分流，达到应用灰度发布的目的。通过在服务器和应用之间建立***实现分流，通过控制该***中的分流策略和配置信息便可以控制灰度发布的范围，在应用所对应的任何服务器中都可以应用，无需专门采用灰度测试服务器，也无需重新建立灰度测试环境，从而可以节省时间和精力。另外，因为该***为独立的***，可以应用于该服务器的所有应用中，只需要在***中添加应用对应的配置信息即可实现灰度发布的控制，从而便于管理，特别是对于包含有大量应用的大型服务器来说，此种方法无需再逐一管理其中的各应用，可以实现统一控制，降低了管理难度和成本。

另外，当灰度发布测试到某一阶段，需要扩大一定的测试范围时或者完全发布时，可以通过逐渐放量的方式，只需要更改配置信息中的相关信息，例如分流阈值等等便可以实现，无需更改测试环境和服务器，从而减低了灰度发布的复杂度，并提高了灰度发布的通用性。

当然，实施本申请的任一产品不一定需要同时达到以上所述的所有优点。

附图说明

图1是本申请的本申请的应用发布方法和***实现的架构图；

图2是本申请的应用发布方法实施例一的流程图；

图3是本申请的应用发布方法和***中同步过程的架构图；

图4是本申请的应用发布方法和***实例的***架构图；

图5是本申请的应用发布***实施例一的结构示意图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

参照图1，其示出本申请的应用发布方法和***实现的架构图，需要进行灰度发布的应用的新旧版本代码可同时存储在应用服务器中，灰度发布的策略等应用配置信息由配置服务器统一存储管理，应用服务器通过与配置服务器之间的信息交互来获取和同步应用配置信息。当用户通过客户端向应用服务器发送访问请求时，应用服务器基于用户请求信息和从配置服务器中获取到的应用配置信息来对用户进行实时判断，并确定其所进入的灰度发布版本，从而实现应用的灰度发布。

参照图2，其示出本申请的一种应用发布方法实施例一，包括以下步骤：

步骤101，接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符(URL，Uniform Resource Locator)。

服务器端在接收客户端发送的用户请求后，会将用户请求传递给应用发布***。用户请求除了包含应用的URL之外，还可以包含用户标识(ID)等信息，应用发布***可以根据实际需求来读取用户请求中的相关信息。

步骤102，基于用户请求信息和从配置服务器中获取的应用配置信息，对用户请求信息进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件符合，则重写当前用户请求中的URL。

应用配置信息由配置服务器统一管理，配置服务器中可以存储多个应用的配置信息，且维护有配置表，以保证应用与各自的配置信息一一对应。应用服务器通过与配置服务器的交互来实时获取应用配置信息。应用配置信息可包括该应用所对应的统一资源定位符、重写统一资源定位符的规则以及分流策略等等。

当前用户是否符合进入灰度发布版本的条件可以是：首先判断当前用户请求的URL是否与预存的URL匹配，若匹配，则分流策略来判断当前用户是否符合进入灰度发布版本的条件。可以理解，通过分流策略来判断时，根据分流策略的不同，还可以获取当前用户的其他信息来帮助实现判断。

例如，分流策略可以包括通用的分流策略，也可以包括特定的分流策略。通用的分流策略一般包括随机分流或者根据用户ID分流等等。随机分流策略为随机选取设定比例范围内的用户作为进入灰度发布版本的用户，此时，可以仅通过用户请求中的URL就可以实现判断。用户ID分流策略为从用户请求中获取用户ID，根据预定规则对ID进入处理后，根据处理后的值对用户进行分组，例如，对ID求余(mod)等方式，则通过设定余数的取值区间来选取进入灰度发布版本的用户。特定的分流策略则可以根据实际情况来确定。例如，根据会员业务分组。假设有普通会员、黄金会员和钻石会员，可分别设定这三种会员进入灰度发布版本的比例等分流策略信息，此时，可通过获取用户请求中的用户身份标识来识别用户所在的分组，以确定该用户请求是否进入灰度发布版本。

可以理解，本申请还可包括更新应用配置信息。当有新应用发布时，发布者可以选取灰度发布所需要的通用的分流策略或者特定的分流策略，并将新应用的统一资源定位符等信息作为新的应用配置信息添加到配置服务器中，然后更新配置表，并与新应用对应的应用服务器建立数据通信即可实现新应用的灰度发布。

另外，更新应用配置信息还包括原有应用配置信息的修改，当应用发布者对应用配置信息进行修改，例如需要扩大灰度发布范围时，可以在配置服务器中修改对应的分流策略。此时设置在配置服务器中的监听单元可以监听到修改操作，并会查询配置表获取修改的应用配置信息所对应的应用服务器，然后将修改后的应用配置信息同步到所述应用服务器中，从而实现应用服务器中的应用配置信息的实时更新，进而保证应用发布时分流数据的准确性。可以理解，所有应用的配置信息都可以存储在配置服务器中，通过配置服务器来实现数据的同步。参照图3，当后台管理在配置服务器中修改应用配置信息后，置于配置服务器中的监听装置首先能够监听该修改操作，并查找到修改后的应用配置信息，然后同步给对应的应用服务器。

重写当前用户请求中的统一资源定位符根据应用配置信息中的重写统一资源定位符的规则来实现，例如，在当前用户请求中的统一资源定位符中添加标识。可以理解，若当前用户不符合进入灰度发布版本的条件，可以不做处理，也可以重写其请求中的统一资源定位符。此时可以通过在符合与不符合的统一资源定位符中添加不同的标识符来区别。例如，在符合条件的统一资源定位符中添加符合标识、在不符合条件的统一资源定位符中添加不符合标识。以graypub参数作为标识为例，当graypub参数取不同的值时，分别表示是否符合。例如，如果附加graypub＝0或者没有这个参数，则表示不能进入灰度发布版本；如果附加graypub＝1，则表示能够进入灰度发布版本。另外，如果还有其他的分流策略，例如，根据具体业务分组，则可以通过附加graypub＝x(x为一个大于2的数字)来表示具体业务分组。如，设定2表示普通会员，3表示黄金会员，4表示钻石会员等等。当URL中附加graypub＝2，则说明能够进入普通会员的灰度发布版本。

步骤103，将处理后的URL传递给应用，应用根据处理后的URL以及应用配置信息来确定当前用户进入的版本。

应用配置信息中包含有重写URL的规则，URL被重写后，则可以根据此重写规则对URL进行解析。置于应用服务器中的处理模块在重写URL之后，则会将用户访问请求传递给应用。应用会设定特定的逻辑判断模块，并包含不同版本的运行代码，应用在接收请求后，根据URL中的标识以及结合应用配置信息中的重写规则来确定当前用户所进入的版本代码。例如，以前述应用配置信息的重写规则为例，如果URL中有graypub＝1这个参数，则认为需要进入灰度发布版本，如果URL中有graypub＝0或者没有这个参数，则认为不需要进入灰度发布版本。又如，如果URL中有graypub＝2这个参数，则认为需要进入普通会员所对应的灰度发布版本。

参照图4，其示出本申请实施过程中的用户请求走向图。在一具体场景中，所述应用发布***判断用户请求是否应该进入灰度发布和对URL的重写可通过置于应用服务器中的apache或者nginx来实现。

首先，用户请求经过负载均衡路由到一台应用服务器，置于应用服务器中的apache/nginx，通过从配置服务器中所获取的应用配置信息来判断当前用户是否需要进行灰度发布版本，并根据判断结果重写当前用户请求中的URL，即在URL中添加对应的灰度发布重写标记。本实例中，灰度发布重写标记是graypub参数，如果graypub＝0或者没有这个参数，认为没有进入灰度发布版本；如果graypub＝1表示进入灰度发布版本；如果graypub＝x(x是一个大于2的数字)，则表示根据具体业务分组。

应用服务器中，Web应用方在接收请求时，首选读取用户请求的URL，并基于应用配置信息进行判断。如果有graypub＝1这个参数，则认为需要进入灰度发布版本，控制进入灰度发布的新代码；如果没有graypub参数或者graypub参数为0，则认为不需要进入，则控制进入原代码执行；如果graypub为其他参数，则表示根据业务情况处理，分别控制其进入对应的代码。

本申请通过需要进行灰度发布的各种应用的应用配置信息置于配置服务器中，各应用服务器只需要与配置服务器进行通信便可以获取到与之对应的应用配置信息。当应用服务器接收到访问请求时，可以基于配置信息和用户请求信息进行实时判断，从而确定用户所进入的版本。通过后台的配置服务器可以实时对各应用的应用配置信息进行修改，如分流策略中的阈值等等，可以准确的控制灰度发布的范围和精度。例如，当某一应用的灰度发布的范围需要从20％扩大到50％时，无需重新修改应用服务器的发布环境，也无需增减应用服务器，可以直接在配置服务器中修改该应用配置信息中的分流策略数据，然后通过配置服务器与应用服务器之间的数据通信，将修改后的应用配置信息同步到对应的应用服务器中。此种方式无需更改测试环境和应用服务器，这降低了灰度发布的复杂度，提高了灰度发布的通用性。另外，配置服务器中可以存储多个应用的应用配置信息，并分别与多个应用服务器建立数据通信，各应用的配置信息可以得到统一管理和维护，降低灰度发布的成本。

参照图5，其示出本申请的应用发布***实施例一，包括用户请求接收模块10、配置信息获取模块50、处理模块20和请求传递模块30。

用户请求接收模块10，用于接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符。

配置信息获取模块50，用于获取配置服务器中的应用配置信息。

处理模块20，用于基于用户请求信息和从配置服务器中获取的应用配置信息，对当前用户请求进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件符合，则重写当前用户请求中的统一资源定位符。优选地，处理模块20还包括判断单元，用于判断所述当前用户的统一资源定位符与应用配置信息中的统一资源定位符是否匹配，若匹配，则根据分流策略来判断当前用户是否符合进入灰度发布版本的条件。

优选地，处理模块20还包括标识添加单元，若当前用户符合进入灰度发布的条件，则添加符合标识在当前用户请求的统一资源定位符中，反之，则添加不符合标识在当前用户请求的统一资源定位符中；或者若当前用户符合进入灰度发布的条件，则添加标识在当前用户请求的统一资源定位符中，反之，则不做处理。

具体的，处理模块可以根据预定的应用配置信息中的重写统一资源定位符的规则写入对应的参数到统一资源定位符中，例如，附加graypub＝0或者不附加这个参数，则表示不能进入灰度发布版本；如果附加graypub＝1，则表示能够进入灰度发布版本。另外如果还有其他的分流策略，例如，根据具体业务分组，则可以通过附加graypub＝x(x为一个大于2的数字)来表示具体业务分组。

请求传递模块30，用于将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符中以及应用配置信息，确定当前用户进入的版本。

优选地，应用发布***还包括监听模块，用于监听配置服务器中的应用配置信息的修改操作，并查询修改的应用配置信息所对应的应用服务器，然后将修改后的应用配置信息同步到所述应用服务器。其中，配置服务器中可以维护一个配置表，记录其中所存储的所有应用以及各应用对应的配置信息、以及应用对应的应用服务器。在监听到应用配置信息有更新时，则查询该应用对应的应用服务器，并将更新的应用配置信息同步给应用服务器。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于***实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上对本申请所提供的应用发布方法及***进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (11)

1.一种应用发布方法，其特征在于，包括以下步骤：

接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符；

基于用户请求信息和从配置服务器中获取的应用配置信息，对用户请求信息进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件，则重写当前用户请求中的统一资源定位符；

将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本。

2.如权利要求1所述的应用发布方法，其特征在于，所述方法还包括更新应用配置信息，所述更新应用配置信息包括：

监听配置服务器中的应用配置信息的修改操作；

从预存的配置表中查询所述修改的应用配置信息所对应的应用服务器；

将所述修改后的应用配置信息同步到所述应用服务器。

3.如权利要求1所述的应用发布方法，其特征在于，所述应用配置信息包括：

应用的统一资源定位符和分流策略。

4.如权利要求3所述的应用发布方法，其特征在于，所述判断当前用户是否符合进入灰度发布版本的条件包括：

判断当前用户的统一资源定位符与应用配置信息中的统一资源定位符是否匹配，若匹配，则根据分流策略来判断当前用户是否符合进入灰度发布版本的条件。

5.如权利要求1所述的应用发布方法，其特征在于，所述重写当前用户请求中的统一资源定位符包括：在当前用户请求中的统一资源定位符添加标识；所述处理还包括：若当前用户符合进入灰度发布版本的条件符合，则不做处理；

所述应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本包括：若处理后的当前用户请求中的统一资源定位符包含标识，则表示能够进入灰度发布版本，反之，则表示不能够进入灰度发布版本。

6.如权利要求1所述的应用发布方法，其特征在于，所述重写当前用户请求中的统一资源定位符包括：添加符合标识在当前用户请求的统一资源定位符中；所述处理还包括：若当前用户不符合进入灰度发布版本的条件，则添加不符合标识在当前用户请求的统一资源定位符中；

所述应用根据处理后的统一资源定位符以及应用配置信息来确定当前用户进入的版本包括：若处理后的当前用户请求中的统一资源定位符包含符合标识，则表示能够进入灰度发布版本，若包含不符合标识，则表示不能够进入灰度发布版本。

7.如权利要求6所述的应用发布方法，其特征在于，所述标识为graypub参数，graypub参数的不同取值分别表示符合标识和不符合标识。

8.一种应用发布***，其特征在于，包括：

用户请求接收模块，用于接收客户端发送的用户请求，所述用户请求中包含请求访问的统一资源定位符；

配置信息获取模块，用于获取配置服务器中的应用配置信息；

处理模块，用于基于用户请求信息和从配置服务器中获取的应用配置信息，对当前用户请求进行处理，所述处理包括：若当前用户符合进入灰度发布版本的条件符合，则重写当前用户请求中的统一资源定位符；

请求传递模块，用于将处理后的统一资源定位符传递给应用，应用根据处理后的统一资源定位符以及应用配置信息，确定当前用户进入的版本。

9.如权利要求8所述的应用发布***，其特征在于，所述***还包括：

监听模块，用于监听配置服务器中的应用配置信息的修改操作；查询所述修改的应用配置信息所对应的应用服务器；将所述修改后的应用配置信息同步到所述应用服务器。

10.如权利要求8或9所述的应用发布***，其特征在于，所述应用配置信息包括统一资源定位符和分流策略，所述处理模块包括：

判断单元，用于判断所述当前用户的统一资源定位符与应用配置信息中的统一资源定位符是否匹配，若匹配，则根据分流策略来判断当前用户是否符合进入灰度发布版本的条件。

11.如权利要求8所述的应用发布***，其特征在于，所述处理模块还包括：

标识添加单元，若当前用户符合进入灰度发布的条件，则添加符合标识在当前用户请求的统一资源定位符中，反之，则添加不符合标识在当前用户请求的统一资源定位符中；或者

若当前用户符合进入灰度发布的条件，则添加标识在当前用户请求的统一资源定位符中，反之，则不做处理。

Images