应用灰度发布方法及设备、应用访问方法及设备与流程

本申请涉及应用灰度管理
技术领域：
，更具体地，是应用灰度发布方法及相关设备、应用访问方法及相关设备。
背景技术：
：通常地，应用开发者对应用进行测试时，可以将已发布的应用作为主版本的应用，并发布测试版本的应用。不同版本的应用发布在不同的物理服务器上。管理员在配置数据库中配置应用灰度策略(可简称为应用灰度)，灰度策略用于对用户的访问请求进行分流，即将大部分用户的访问请求转发至主版本，并将一部分用户的访问请求分流至测试版本。从而，可以监测测试版本的运行情况，以作为对主版本改进及完善的依据。以上应用灰度策略的发布系统，应用灰度的发布效率较低，且较为耗费资源。技术实现要素：有鉴于此，本申请提供了一种应用灰度的发布系统，用以提高应用灰度发布的效率，并节省应用灰度发布系统所使用的资源。为实现所述目的，本申请提供的技术方案如下：一种应用灰度发布系统，包括：Redis存储系统、分流服务器、容器构建服务器及Docker应用容器；其中：所述Redis存储系统，用于以键值对形式存储灰度策略；所述容器构建服务器，用于监测所述Redis存储系统，若监测到所述Redis存储系统的灰度策略中新增某版本的应用，则在物理服务器上构建Docker应用容器；还用于向所述分流服务器发送触发指令；以及，还用于修改分流服务器中所述新增某版本的应用对应的分流参数，分流参数用于指示所述Docker应用容器的地址；所述Docker应用容器，用于发布所述某版本的应用；所述分流服务器，用于接收到触发指令后，从Redis存储系统中读取灰度策略；其中，所述分流参数及所述灰度策略用于将用户请求分流至所述Docker应用容器。在一个可能的设计中，在监测所述Redis存储系统的方面，所述容器构建服务器具体用于：以周期性轮询方式监测所述Redis存储系统。在一个可能的设计中，所述键值对中的键表示用户信息，所述键值对中的值表示应用版本信息，其中，所述用户信息包括位置信息、注册时间、登录时间或访问数据量。另一方面，本申请还提供了一种应用灰度发布方法，包括：所述容器构建服务器监测Redis存储系统，以监测Redis存储系统存储的灰度策略是否发生变化，其中，所述灰度策略存储为键值对形式；所述容器构建服务器若监测到所述Redis存储系统的灰度策略中新增某版本的应用，则在物理服务器上构建Docker应用容器，并修改分流服务器中所述新增某版本的应用对应的分流参数，分流参数用于指示所述Docker应用容器的地址；所述Docker应用容器发布所述某版本的应用；所述分流服务器从Redis存储系统中读取灰度策略；其中，所述分流参数及所述灰度策略用于将用户请求分流至所述Docker应用容器。在一个可能的设计中，所述容器构建服务器监测Redis存储系统，包括：所述以周期性轮询方式监测所述Redis存储系统。在一个可能的设计中，应用灰度发布方法还包括：所述容器构建服务器向分流服务器发送触发指令；所述分流服务器从Redis存储系统中读取灰度策略，包括：所述分流服务器接收到所述触发指令后，从Redis存储系统中读取灰度策略。在一个可能的设计中，应用灰度发布方法还包括：若容器构建服务器并未成功修改分流服务器中该灰度策略对应的分流参数，则注销所构建的Docker应用容器。在一个可能的设计中，所述键值对中的键表示用户信息，所述键值对中的值表示应用版本信息，其中，所述用户信息包括位置信息、注册时间、登录时间或访问数据量。又一方面，本申请还提供了一种应用访问方法，包括：接收到用户请求后，从所述用户请求中提取用户信息；根据灰度策略，确定所述用户信息所对应的目标版本应用；其中，所述灰度策略为键值对形式；根据分流参数，查找所述目标版本应用的地址，该地址表示目标版本应用发布在哪个Docker应用容器上；将所述用户请求转发到目标版本应用的地址指示的Docker应用容器上，以使所述用户请求访问所述目标版本应用。又一方面，本申请还提供了一种分流服务器，包括：处理器和存储器，所述处理器通过运行存储在所述存储器内的软件程序、调用存储在所述存储器内的数据，至少执行上述应用访问方法。与现有的应用灰度发布系统相比，本申请提供的应用灰度发布系统中，使用了Redis存储系统替代原有的配置数据库，将灰度策略保存为键值对形式，灰度策略发布更加快速，且基于该种形式灰度策略的分流流程更加高效。另外，本申请采用Docker技术来作为多版本的应用容器引擎，构建的Docker应用容器代替物理服务器，更加节省资源。当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。附图说明为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。图1为现有的应用灰度发布系统的结构图；图2为本申请提供的应用灰度发布系统的结构图；图3为本申请提供的应用灰度发布方法的流程图；图4为本申请提供的基于灰度策略的应用访问方法的一个流程图；图5为本申请提供的基于灰度策略的应用访问方法的另一示例图。具体实施方式下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。为了便于理解本申请，首先对应用灰度发布等概念及使用的相关技术进行说明。通常地，应用开发者会发布同一应用的多个版本，并测试用户对各个版本的使用情况，以完善应用功能及提升应用性能，并降低应用升级所影响的用户范围。灰度发布一般包括以下几个步骤。(1)选取灰度策略，比如用户规模、应用发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等；(2)筛选用户，比如用户的特征、用户数量、用户常用功能、用户范围等；(3)部署系统，比如部署新系统、行为分析、意见征集、产品功能改进等；(4)应用改进以及完整发布。如图1所示，现有的灰度发布是基于分流服务器+新老版本服务器集群来实施的。具体地，假设目前应用发布有两个版本，相应地，服务器集群中设置有两个服务器，分别为服务器1及服务器2，其中，服务器1上发布的是老版本，服务器2上发布的是新版本。策略发布管理员通过策略配置库，在分流服务器上部署灰度策略。从而，不同的用户访问应用时，分流服务器根据灰度策略，将不同用户的访问请求发送至不同的服务器上，以访问不同版本的应用。虽然图1中仅仅示出了两个用户，两个用户仅仅是示例说明，在实施中，访问应用的用户是大量的，灰度策略可以将一部分用户分流到某版本应用的服务器上，以收集此部分用户对该版本应用的使用情况，进而根据使用情况对应用进行改进及完善。当然，以上对应用测试仅仅是灰度发布的一种应用场景，但在实际应用中，灰度发布的应用场景并不局限于此，只要是使用灰度策略对用户访问请求分流的情况均在本申请的保护范围内。现有的灰度发布方式中，使用物理服务器存储不同版本的应用，若应用版本数量较多，则需要部署相应数量的物理服务器，耗费资源较多。另外，策略配置库中的灰度策略以数据表的形式进行存储，分流服务器需要读取配置策略库中的数据表以实现分流，分流效率较低。为了解决以上问题，本申请提供了以下应用灰度发布系统，该系统具体结构见图2。如图2所示，应用灰度发布系统可以包括：Redis存储系统、分流服务器、容器构建服务器及Docker应用容器。Redis存储系统，代替现有的策略配置数据库，用于以键值对的形式存储灰度策略。其中，键用于表示用户信息，值用于表示应用版本信息。Redis是一个键-值对(key-value)存储系统。Redis存储系统上的灰度策略可以是多种形式，例如，一种形式是以位置作为灰度策略中的“键”。该种形式中，灰度策略的键-值对中的“键”为位置信息，“值”为应用版本信息。举例说明如下：比如，使用某应用的用户所在的位置包括北京的海淀区、北京的朝阳区、河北的保定市、河北的石家庄、天津的滨海新区等。用户发送的应用访问请求可以包含相应的位置信息，如应用访问请求中的IP地址表示位置信息。该应用的主版本为Version_Quanguo，若想要在主版本的基础上发布一个测试版本Version_Haidian，该测试版本主要给北京海淀区的用户使用。待北京海淀区的用户使用成熟后，可以再发布新版本为Version_Beijing，给所有北京地区的用户使用，以此类推实现某国家或地区的全部用户使用。基于上述情况，应用首次发布的两个版本为：主版本Version_Quanguo及测试版本Version_Haidian，北京海淀区的用户访问测试版本Version_Haidian，其他地区的用户访问主版本Version_Quanguo。从而，Redis存储的灰度策略可以如下表1所示。表1Key(地理位置)Value(某版本的应用)HAIDIANVersion_HaidianOTHERVersion_Quanguo以上以用户的位置信息作为键值对中的“键”仅仅是一种示例，根据实际应用需求，“键”的内容还可以是其他用户信息，如用户的注册时间、用户的访问时间或用户的访问数据量等。容器构建服务器，用于周期性轮询Redis存储系统，以监测灰度策略是否发生变化，若监测到灰度策略发生变化，则在物理服务器上构建Docker应用容器。Docker应用容器，用于发布某版本的应用。以表1所示的应用版本为例，容器构建服务器在Redis存储系统查询到在主版本Version_Quanguo的基础上，新增测试版本Version_Haidian，则在Docker应用容器1的基础上，新增Docker应用容器2。其中，Docker应用容器1上发布的是主版本Version_Quanguo，Docker应用容器2上发布的是测试版本Version_Haidian。两个Docker应用容器均部署在物理服务器上，也就是说，是在物理服务器上构建Docker应用容器，以虚拟服务器代替现有的物理服务器。Docker应用容器的配置策略从Redis存储系统及容器构建服务器上获取。Docker应用容器构建完成后，容器构建服务器还可以用于修改Redis存储系统的内部参数及分流服务器的分流参数，并开放对新构建的Docker应用容器的访问。进一步地，容器构建服务器还可以用于，触发分流服务器读取Redis存储系统中的灰度策略。Docker是一个开源的应用容器引擎，让开发者可以打包应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。分流服务器，用于根据容器构建服务器的触发，从Redis存储系统中读取灰度策略。另外，分流服务器设置有分流参数，分流参数用于指示灰度策略中各个版本的应用所在的Docker应用容器的地址。仍以上述表1及图2为例，主版本Version_Quanguo发布在Docker应用容器1上，则主版本Version_Quanguo对应的分流参数1表示Docker应用容器1的地址；测试版本Version_Haidian发布在Docker应用容器2上，则测试版本Version_Haidian对应的分流参数2表示Docker应用容器2的地址。Docker应用容器是容器构建服务器构建的，容器构建服务器可以记录Docker应用容器的地址，因此，分流服务器上的分流参数可以是容器构建服务器修改的。可见，分流服务器依据灰度策略及分流参数实现对用户访问请求的分流。具体地分流流程可以参见下文的基于灰度策略的应用访问方法。与现有的应用灰度发布系统相比，本申请提供的应用灰度发布系统中，使用了Redis存储系统替代原有的配置数据库，将灰度策略保存为键值对形式，灰度发布更加快速，且基于该种形式灰度策略的分流流程更加高效。另外，本申请采用Docker技术来作为多版本的应用容器引擎，构建的Docker应用容器代替物理服务器，更加节省资源。另外，基于以上应用灰度发布系统，本申请还提供了一种应用灰度发布方法。见图3，其示出了该应用灰度发布方法的流程，具体包括以下步骤。S31：容器构建服务器轮询Redis存储系统，以监测灰度策略是否发生变化。其中，若应用发布新的版本，则策略管理员可以为该版本的应用配置相应的用户。例如，主版本Version_Quanguo为原有版本的应用，在主版本的基础上，若新增测试版本Version_Haidian，则策略管理员为测试版本Version_Haidian配置的是北京海淀区的用户，为主版本Version_Quanguo配置的是除海淀区之外的其他位置的用户。以上配置信息以键值对形式保存在Redis存储系统中，该键值对可以称为灰度策略。S32：若监测到灰度策略中新增某版本的应用，则容器构建服务器在物理服务器上构建Docker应用容器。S33：Docker应用容器发布该某版本的应用。S34：容器构建服务器向分流服务器发送触发指令。S35：分流服务器接收到触发指令后，从Redis存储系统中读取灰度策略。S36：容器构建服务器修改分流服务器中该灰度策略对应的分流参数，分流参数指示的是该Docker应用容器的地址。其中，若容器构建服务器并未成功修改分流服务器中该灰度策略对应的分流参数，则注销所构建的Docker应用容器。以上流程的其他说明可以参见关应用灰度发布系统的说明。应用灰度发布后，分流服务器可以根据分流参数及灰度策略，对用户发送的访问请求进行分流。参见图4，基于灰度策略的应用访问方法的流程包括以下步骤。S41：分流服务器接收到用户请求后，从用户请求中提取用户信息。其中，提取的用户信息是根据灰度策略中的“键”内容来决定的。例如，键内容为用户的位置信息，则可以提取用户请求中的IP地址，根据IP地址确定用户的位置信息。S42：分流服务器根据灰度策略，确定用户信息所对应的目标版本应用。其中，灰度策略表示为键值的对应关系，从各个键中，查找表示所述用户信息的键，进而确定该键对应的值，将该值表示的某版本的应用确定为目标版本应用。S43：分流服务器根据分流参数，查找目标版本应用的地址，该地址表示目标版本应用发布在哪个Docker应用容器上。S44：分流服务器将用户请求转发到目标版本应用的地址指示的Docker应用容器上，以使该用户请求访问该目标版本应用。假设分流服务器读取到的灰度策略如上述表1所示，北京海淀区的用户访问测试版本Version_Haidian，其他地区的用户访问主版本Version_Quanguo。并且，主版本Version_Quanguo发布在Docker应用容器1上，测试版本Version_Haidian发布在Docker应用容器2上。如图5所示，分流服务器接收到用户A的请求后，判断用户A的位置信息为OTHER，即海淀区以外，则分流服务器将用户A的请求转发至Docker应用容器1；若分流服务器接收到用户B的请求后，判断用户B的位置信息为HAIDIAN，则分流服务器将用户B的请求转发至Docker应用容器2。本申请还提供了一种分流服务器，包括处理器和存储器，所述处理器通过运行存储在所述存储器内的软件程序、调用存储在所述存储器内的数据，至少执行图4中的S41-S44部分。需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括上述要素的过程、方法、物品或者设备中还存在另外的相同要素。对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。当前第1页1 2 3