CN110990039B - 应用程序更新方法、装置、系统及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种应用程序更新方法、装置、系统及计算机可读存储介质，涉及计算机技术领域，包括应用于Nginx服务器，该方法包括：将待更新的API服务器进行批次划分，待更新的API服务器为运行待更新应用程序的API服务器；对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。该方法应用程序更新可以在线操作，对用户提供不间断服务，提高用户体验。同时，通过分批次的摘除API服务器的流量，实现无损更新，在使用最小的资源情况下，确保服务正常可用。

Description

应用程序更新方法、装置、系统及计算机可读存储介质

技术领域

本申请涉及通信及计算机技术领域，尤其是涉及一种应用程序更新方法、装置、系统及计算机可读存储介质。

背景技术

目前，现有技术中，针对应用程序的更新方法，主要有是通过在更新前提前向用户发布公告，停服更新，更新时选取在业务流量低峰期，停止线上服务，更新应用程序，最后再对用户开放服务；然而该现有技术方案主要出现在传统软件服务领域，由于互联网领域对服务可用性要求非常高，要求7*24小时不间断对用户提供服务，该方案停服更新，显然不能为用户提供不间断的服务，降低了用户的体验度。

发明内容

有鉴于此，本申请提供了一种应用程序更新方法、装置、系统及计算机可读存储介质。

第一方面，本申请实施例提供了一种应用程序更新方法，应用于Nginx服务器，所述方法包括：

将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

对每个批次的API服务器，

变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。

结合第一方面，本申请实施例提供了第一方面的第一种可能的实施方式，其中，所述方法还包括：

当所述当前批次的API服务器更新完成应用程序时，变更已更新的API服务器的IP地址列表的配置，以恢复当前批次的API服务器的流量。

结合第一方面，本申请实施例提供了第一方面的第二种可能的实施方式，其中，在将待更新的API服务器进行批次划分的步骤之前，还包括：

确定待更新的API服务器需划分的批次的数量。

结合第一方面的第二种可能的实施方式，本申请实施例提供了第一方面的第三种可能的实施方式，其中，确定待更新的API服务器需划分的批次的数量的步骤，包括：

获取所述应用程序在预设时间内的请求量峰值；

获取待更新的API服务器总数以及每台所述API服务器能承载的最大请求量；

根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量。

结合第一方面的第三种可能的实施方式，本申请实施例提供了第一方面的第四种可能的实施方式，其中，所述根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量的步骤，包括：

根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量，应用批次运算算式确定待更新的API服务器需划分的批次的数量。

结合第一方面的第四种可能的实施方式，本申请实施例提供了第一方面的第五种可能的实施方式，其中，所述批次运算算式为：

P＝[N/(N-F/Q)]

其中，P为待更新的API服务器需划分的批次的数量，F为所述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台所述API服务器能承载的最大请求量。

第二方面，本申请实施例还提供一种应用程序更新方法，应用于API服务器，所述方法包括：

接受Nginx服务器对IP地址列表的配置的变更，以摘除流量；

对待更新的应用程序进行更新；

所述应用程序更新完毕后，向所述Nginx服务器发送更新完毕的信息，使所述Nginx服务器对IP地址列表的配置进行变更，以恢复API服务器的流量。

第三方面，本申请实施例提供了一种应用程序更新装置，所述装置包括：

划分单元，用于将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

配置单元，用于对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。

第四方面，本申请实施例还提供了一种应用程序更新装置，所述装置包括：

摘除单元，用于接受Nginx服务器对IP地址列表的配置的变更，摘除API服务器的流量；

更新单元，用于对待更新的应用程序进行更新；

发送单元，用于所述应用程序更新完毕后，向所述Nginx服务器发送更新完毕的信息，使所述Nginx服务器对IP地址列表的配置进行变更，以恢复API服务器的流量。

第五方面，本申请实施例提供了一种应用程序更新系统，包括多个Nginx服务器和多个API服务器，所述Nginx服务器包括上述第三方面的应用程序更新装置，所述API服务器包括上述第四方面所述的应用程序更新装置。

第六方面，本申请实施例又提供了一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行上述的第一方面或第二方面所述的方法。

本申请实施例带来了以下有益效果：本申请实施例提供的应用程序更新方法，应用于Nginx服务器，该方法包括：将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。因此，本申请实施例提供的技术方案，应用更新可以在线操作，对用户提供不间断服务，提高用户体验度。同时，通过分批次的摘除API服务器的流量，实现无损更新，在使用最小的资源情况下，确保服务正常可用。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的应用场景示意图；

图2为本申请实施例提供的一种应用程序更新方法流程示意图；

图3为本申请实施例提供的一种应用程序更新方法的具体流程图；

图4为图3中步骤S310的详细流程图；

图5为本申请实施例提供的另一种应用程序更新方法流程示意图；

图6为本申请实施例提供的一种应用程序更新装置结构示意图；

图7为本申请实施例提供的另一种应用程序更新装置结构示意图；

图8为本申请实施例提供的一种Nginx服务器的示意图；

图9为本申请实施例提供的一种API服务器的示意图；

图10为本申请实施例提供的一种应用程序更新系统的应用原理图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例的条目中所提到的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括其他没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前，现有技术中，针对应用程序的更新方法，主要有以下两种方案：

方案(1)停服更新，提前向用户发布公告，更新时选取在业务流量低峰期，停止线上服务，更新应用程序，最后再对用户开放服务；

方案(2)并行运行新旧两版应用程序，更新其中一版程序后，将流量引入新版程序，最后再停止旧版本应用程序。

上述现有技术方案主要存在以下问题：方案(1)主要出现在传统软件服务领域，由于互联网领域对服务可用性要求非常高，要求7*24小时不间断对用户提供服务，而方案(1)停服，显然不能满足为用户提供不间断的服务，降低了用户的体验度。方案(2)对机器资源要求高，更新过程中需要同时运行2个版本的应用程序，资源占用消耗大，CPU、内存等资源将会是运行一个版本程序的2倍；另外，服务(例如云存储的服务)都对外提供端口访问，同一台机器无法启动两个相同端口，这就要求新旧两版应用程序的端口不能相同，这就导致每次更新需要切换端口，运维的复杂度高。基于此，本申请实施例提供的一种应用程序更新方法、装置、系统及计算机可读存储介质，可以云存储系统中的应用程序变更时，实现在线更新，对用户提供不间断服务，提高用户体验度。同时，通过分批次的摘除API服务器的流量，实现无损更新，在使用最小的资源情况下，确保服务正常可用，此外，无需端口切换，降低了运维的复杂度。

为便于对本实施例进行理解，首先对本申请实施例所公开的一种应用程序更新方法，结合附图进行详细介绍。

本申请提供的应用程序更新方法，可以应用于如图1所示的云存储业务应用场景中。

云存储系统可以包括接入层和业务层，接入层和业务层可以作为云存储业务的架构的主要组成部分，接入层和业务层分别完成流量接入和处理，接入层和接收层的机器数量量级很高。云存储业务应用场景可以包括接入层的多个Nginx服务器101(图1中示出了)和业务层的多个API服务器102，其中，接入层的Nginx服务器完成均衡用户流量、https证书认证等工作；业务层的API服务器完成请求鉴权、限流、数据的读取和写入等工作，是云存储业务中的核心服务器。

图1中示出了Nginx服务器1，Nginx服务器2，……，Nginx服务器M共M个Nginx服务器，以及API服务器1，API服务器2，……，API服务器N共N个Nginx服务器101，M个Nginx服务器和N个API服务器组成M×N网段拓扑结构，每台Nginx服务器将用户请求平均发送给所有API服务器上。

上述的应用程序指为完成某项或多项特定工作的计算机程序，包括但不限于服务器(例如API服务器)、移动设备(如智能手机、平板电脑等)中的APP。

图2为本申请实施例提供的一种应用程序更新方法流程示意图。该方法应用于Nginx服务器(例如图1所示的Nginx服务器101)。

参照图2，该方法包括：

步骤S210，将待更新的API服务器进行批次划分，上述待更新的API服务器为运行待更新应用程序的API服务器；

对每个批次的API服务器，

步骤S220，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。

本申请实施例提供的应用程序更新方法，应用于Nginx服务器，首先通过将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；然后对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。该方法通过分批次对API服务器的应用程序更新，确保应用程序更新可以在线操作，对用户提供不间断服务，提高用户体验。

图3示出了本申请实施例提供的一种应用程序更新方法的具体流程图，该方法应用于Nginx服务器。参照图3，该方法包括：

步骤S310，确定待更新的API服务器需划分的批次的数量；

步骤S320，将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

对每个批次的API服务器：

步骤S330，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序；

步骤S340，当当前批次的API服务器更新完成应用程序时，变更已更新的API服务器的IP地址列表的配置，以恢复当前批次的API服务器的流量。

在本实施例中，云存储系统包括Nginx服务器和API服务器，每台Nginx服务器均配置有所有API服务器(机器)的IP地址。通过变更Nginx服务器的配置中的IP地址列表，可以摘除部分(第一批次)API服务器的流量，使该第一批次摘除了流量的API服务器的应用程序更新，未摘除流量的其他API服务器可以为用户提供服务；当第一批次的API服务器更新完毕之后，变更IP地址列表的配置，以恢复当前批次的API服务器的流量，此时恢复的API服务器可以对用户请求进行处理；再对下一批次的API服务器重复上述对第一批次的API服务器执行的操作，实现对下一批次的API服务器的应用程序更新，重复此操作，直至完成所有API服务器的应用程序更新。由于更新过程中，仅有在应用程序更新的API服务器不接收任何请求，其他API服务器接收请求，从而使得整个变更过程对用户无损，用户也无感知，能够满足为用户不间断提供服务的需求。

考虑到如何确定每次摘除API机器的数目(即每批次API服务器的更新数量)，如果每次摘除机器过少，上线的批次增加，从而增加了上线耗时；反之，如果每次摘除的机器数目过大，余下的机器可能无法承担业务量，会丢失部分用户请求，严重时甚至会压垮系统。

为了解决上述问题，在可选的实施方式中，如图4所示，该步骤S310可以通过以下步骤实现：

步骤S410，获取应用程序在预设时间内的请求量峰值；

这里的预设时间可以根据需求设置，可选的，本实施例中，预设时间设置为5-10天。

步骤S420，获取待更新的API服务器总数以及每台上述API服务器能承载的最大请求量；

步骤S430，根据上述请求量峰值、待更新的API服务器总数以及每台上述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量。

通过历史业务量和机器规模计算得出待更新的API服务器需划分的批次的数量，缩短上线时间，提高上线效率，同时又可以避免请求丢失的问题，降低了对系统的影响。

在可选的实施方式中，该步骤S430可以通过以下步骤执行：

1、根据请求量峰值、待更新的API服务器总数以及每台API服务器能承载的最大请求量，应用批次运算算式确定待更新的API服务器需划分的批次的数量。

在可选的实施方式中，上述批次运算算式为：

P＝[N/(N-F/Q)]；

其中，P为待更新的API服务器需划分的批次的数量，F为上述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台上述API服务器能承载的最大请求量。

其中，[]可以代表向下取整，也可以代表向上取整。

上述批次运算算式的原理为：先将请求量峰值F除以Q，得到最少需要的API服务器的数量；N-F/Q得出每次可以摘除的API服务器的机器数；N/(N-F/Q)，并对结果取整，得到批次P。

具体的，在本实施例中，上述批次运算算式为：

P＝[N/(N-F/Q)]；

其中，P为待更新的API服务器需划分的批次的数量，F为上述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台上述API服务器能承载的最大请求量，[]代表向下取整。

需要说明的是，如果计算得到的P<2时，此时P取2，即至少要分2批上线，P要大于1，避免一次摘除所有API服务器机器的流量所导致的停服问题。

需要指出的是，在其他实施方式中，上述批次运算算式为：P＝[N/(N-F/Q)]；其中，P为待更新的API服务器需划分的批次的数量，F为上述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台上述API服务器能承载的最大请求量，[]代表向上取整。

本申请实施例提供的应用程序更新方法，通过确定分批更新API服务器应用程序的批次，然后根据确定的批次分批对API服务器的应用程序进行更新，使得API服务器的应用程序更新可以在线操作，对用户提供不间断服务，提高用户体验度。同时，通过分批次的摘除API服务器的流量，实现无损更新，在使用最小的资源情况下，确保服务正常可用。

图5为本申请实施例提供了另一种应用程序更新方法流程示意图。该方法应用于API服务器(例如图1所示的API服务器102)，如图5所示，该方法包括：

步骤S510，接受Nginx服务器对IP地址列表的配置的变更，摘除API服务器的流量；

步骤S520，更新API服务器的应用程序；

步骤S530，应用程序更新完毕后，向Nginx服务器发送更新完毕的信息，使Nginx服务器对IP地址列表的配置进行变更，以恢复API服务器的流量。

图6为本申请实施例提供了一种应用程序更新装置结构示意图。如图6所示，该装置包括划分单元601和配置单元602。

划分单元601用于将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

配置单元602用于对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序。

在一些实施方式中，配置单元602还用于当所述当前批次的API服务器更新完成应用程序时，变更已更新的API服务器的IP地址列表的配置，以恢复当前批次的API服务器的流量。

在一些实施方式中，该装置还包括：

确定单元603，用于确定待更新的API服务器需划分的批次的数量。

在一些实施方式中，确定单元603在确定待更新的API服务器需划分的批次的数量时，用于获取所述应用程序在预设时间内的请求量峰值；获取待更新的API服务器总数以及每台所述API服务器能承载的最大请求量；根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量。

在一些实施方式中，确定单元603在根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量时，用于根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量，应用批次运算算式确定待更新的API服务器需划分的批次的数量。

在一些实施方式中，上述批次运算算式为：P＝[N/(N-F/Q)]；

其中，P为待更新的API服务器需划分的批次的数量，F为所述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台所述API服务器能承载的最大请求量。

需要说明的是，式中[]可以代表向下取整，也可以代表向上取整。

具体的，本实施例中，所述批次运算算式为：P＝[N/(N-F/Q)]；

其中，P为待更新的API服务器需划分的批次的数量，F为所述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台所述API服务器能承载的最大请求量，[]代表向下取整。

图7为本申请实施例提供的另一种应用程序更新装置结构示意图。

如图7所示，该装置包括：摘除单元701、更新单元702和发送单元703。

摘除单元701用于接受Nginx服务器对IP地址列表的配置的变更，摘除API服务器的流量；

更新单元702用于更新API服务器的应用程序；

发送单元703用于所述应用程序更新完毕后，向所述Nginx服务器发送更新完毕的信息，使所述Nginx服务器对IP地址列表的配置进行变更，以恢复API服务器的流量。

参见图8，本申请实施例还提供一种Nginx服务器101，包括：处理器80，存储器81，总线82和通信接口83，所述处理器80、通信接口83和存储器81通过总线82连接；处理器80用于运行存储器81中存储的可运行模块，例如计算机程序。

参见图9，本申请实施例还提供一种API服务器102，包括：处理器90，存储器91，总线92和通信接口93，所述处理器90、通信接口93和存储器91通过总线92连接；处理器90用于运行存储器91中存储的可运行模块，例如计算机程序。

其中，上述存储器可能包含高速随机存取存储器(RandomAccessMemory，RAM)，也可能还包括非易失性存储器(non-volatilememory，NVM)，例如至少一个磁盘存储器。通过至少一个通信接口(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

上述总线可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8或图9中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器用于存储程序，所述处理器在接收到运行指令后，运行所述程序，前述本申请实施例任一实施例揭示的流过程定义的装置所运行的方法可以应用于处理器中，或者由处理器实现。

处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(CentralProcessingUnit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者运行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器运行完成，或者用译码处理器中的硬件及软件模块组合运行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本申请实施例还提供了一种应用程序更新系统，包括多个Nginx服务器和多个API服务器，所述Nginx服务器包括上述图6所示的应用程序更新装置，所述API服务器包括上述图7所示的应用程序更新装置。

为了便于理解，下面结合图10对该应用程序更新系统的实际执行过程进行简要说明：

1.计算分批上线的批次P；

其中计算得到的P使得系统既能满足业务需求，又能减少变更批次，实现上线效率最大化。以预设时间为7天，P的计算过程如下：

设过去7天应用程序的请求量峰值F＝700000，API服务器数量N＝1020，每台API服务器可以承载的最大请求量Q＝7000，则根据批次运算算式P＝[N/(N-F/Q)]，其中中括号[]代表向下取整，计算出来的结果是P＝[3.4]，向下取整，即P取3。

2.更改Nginx配置，并重新加载(reload)Nginx服务器，摘除第1批次的API服务器的流量，待第1批次机器应用接收不到流量后，变更第1批次的API服务器的应用程序；

3.更改Nginx配置，reload Nginx，摘除第2批次的API服务器的流量，待第2批次机器应用接收不到流量后，变更第2批次的API服务器的应用程序；

4.重复以上操作，直至完成所有批次API服务器的应用程序更新。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行本申请实施例提供的上述的应用程序更新方法和/或应用程序更新方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可运行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地运行，它们有时也可以按相反的顺序运行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用运行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

Claims (5)

1.一种应用程序更新方法，其特征在于，应用于Nginx服务器，所述方法包括：

将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

对每个批次的API服务器，

变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序；

在将待更新的API服务器进行批次划分的步骤之前，还包括：

确定待更新的API服务器需划分的批次的数量；

确定待更新的API服务器需划分的批次的数量的步骤，包括：

获取所述应用程序在预设时间内的请求量峰值；

获取待更新的API服务器总数以及每台所述API服务器能承载的最大请求量；

根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量；

所述根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量的步骤，包括：

根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量，应用批次运算算式确定待更新的API服务器需划分的批次的数量；

所述批次运算算式为

P=[N/(N-F/Q)]

其中，P为待更新的API服务器需划分的批次的数量，F为所述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台所述API服务器能承载的最大请求量。

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

当所述当前批次的API服务器更新完成应用程序时，变更已更新的API服务器的IP地址列表的配置，以恢复当前批次的API服务器的流量。

3.一种应用程序更新装置，其特征在于，所述装置包括：

划分单元，用于将待更新的API服务器进行批次划分，所述待更新的API服务器为运行待更新应用程序的API服务器；

配置单元，用于对每个批次的API服务器，变更待更新的API服务器的IP地址列表的配置，以摘除当前批次的API服务器的流量，使当前批次的API服务器更新应用程序；

确定单元，用于确定待更新的API服务器需划分的批次的数量；

所述确定单元在确定待更新的API服务器需划分的批次的数量时，用于获取所述应用程序在预设时间内的请求量峰值；获取待更新的API服务器总数以及每台所述API服务器能承载的最大请求量；根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量；

所述确定单元在根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量确定待更新的API服务器需划分的批次的数量时，用于根据所述请求量峰值、待更新的API服务器总数以及每台所述API服务器能承载的最大请求量，应用批次运算算式确定待更新的API服务器需划分的批次的数量；

所述批次运算算式为

P=[N/(N-F/Q)]

其中，P为待更新的API服务器需划分的批次的数量，F为所述应用程序在预设时间内的请求量峰值，N为待更新的API服务器总数，Q为每台所述API服务器能承载的最大请求量。

4.一种应用程序更新系统，其特征在于，包括多个Nginx服务器和多个API服务器，所述Nginx服务器包括权利要求3所述的应用程序更新装置。

5.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有机器可运行指令，所述计算机可运行指令在被处理器调用和运行时，所述计算机可运行指令促使所述处理器运行所述权利要求1或2所述的方法。