CN111301789A - 应用软件打包方法和装置 - Google Patents

Abstract

本申请公开了应用软件打包方法和装置。该方法包括：接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求，第一HTTP请求至少包括待打包对象的存储地址和脚本数据，本地服务器预先配置路由，路由用于指向预先创建的路由函数；在预先创建的服务器队列中查找是否存在第二本地服务器，第二本地服务器是服务器队列中处于空闲状态的任意一个；若存在，则向第二本地服务器发送第二HTTP请求，以使得第二本地服务器响应于第二HTTP请求，对待打包对象进行打包处理得到第一打包结果；从第二本地服务器接收第一打包结果。根据本申请实施例，利用本地服务器对应用程序进行打包，有效地减小远程服务器的打包压力，从而提高打包效率。

Description

应用软件打包方法和装置

技术领域

本申请一般涉及软件工程技术领域，尤其涉及应用软件打包方法和装置。

背景技术

应用程序开发过程中，需要编译打包输出软件包，然后才执行部署。常见的打包工具，通常是将一些分散的小模块，按照一定的规则整合成一个大模块的工具。打包工具也会处理好模块之间的依赖关系，最终这个大模块将可以被运行在合适的平台中。

常见的打包方式，例如在本地服务器编译打包或者利用远程服务器编译打包。对于本地编译打包，存在打包结果不能有效地实现同步的问题，而远程服务器编译打包又因打包任务的数据量难以控制，导致配置服务器资源浪费。

因此，亟待提出一种解决方案来解决上述问题。

发明内容

鉴于现有技术中的上述缺陷或不足，期望提供一种应用程序打包方法和装置，其通过本地服务器执行打包，有效地减小远程服务器的打包压力，提高了打包效率。

第一方面，本申请实施例提供了一种应用程序打包方法，该方法包括：

接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求，第一HTTP请求至少包括待打包对象的存储地址和脚本数据，该本地服务器预先配置路由，该路由用于指向预先创建的路由函数；

在预先创建的服务器队列中查找是否存在第二本地服务器，第二本地服务器是服务器队列中处于空闲状态的任意一个；

若存在，则向第二本地服务器发送第二HTTP请求，第二HTTP请求至少包括待打包对象的存储地址和脚本数据，以使得第二本地服务器响应于第二HTTP请求，在根据存储地址按照路由函数获取待打包对象之后，执行脚本数据以对待打包对象进行打包处理，得到第一打包结果；

从第二本地服务器接收第一打包结果；

若不存在，则响应于第一HTTP请求，对待打包对象执行打包，以生成第二打包结果；或者，

等待查找得到的第二本地服务器，指示第二本地服务器来完成打包。

第二方面，本申请实施例提供了一种应用程序打包方法，该方法在至少一个本地服务器中处于空闲状态的本地服务器上执行，该本地服务器预先配置路由，该路由用于指向预先创建的路由函数，该方法包括：

接收第二HTTP请求，该第二HTTP请求包括待打包对象的存储地址和脚本数据；

解析第二HTTP请求，得到存储地址和脚本数据；

根据存储地址按照路由函数获取待打包对象；

执行脚本数据以对待打包对象进行打包，得到第一打包结果；

向远程服务器发送第一打包结果。

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

第一接收单元，用于接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求，该第一HTTP请求至少包括待打包对象的存储地址和脚本数据，该本地服务器预先配置路由，该路由用于指向预先创建的路由函数；

查找单元，用于在预先创建的服务器队列中查找是否存在第二本地服务器，该第二本地服务器是所述服务器队列中处于空闲状态的任意一个；

第一发送单元，用于若存在，则向第二本地服务器发送第二HTTP请求，该第二HTTP请求包括待打包对象的存储地址和脚本数据，以使得第二本地服务器响应于第二HTTP请求，在根据存储地址按照路由函数获取待打包对象之后，执行脚本数据以对待打包对象进行打包处理，得到第一打包结果；

第二接收单元，用于从第二本地服务器接收第一打包结果。

第四方面，本申请实施例提供了一种应用程序打包装置，该装置在至少一个本地服务器中处于空闲状态的本地服务器上执行，该本地服务器预先配置路由，该路由用于指向预先创建的路由函数，该装置包括：

第四接收单元，用于接收第二HTTP请求，该第二HTTP请求包括所述本地服务器的IP地址和待打包对象的存储地址和脚本数据；

解析单元，用于解析第二HTTP请求，得到存储地址和脚本数据；

获取单元，用于根据存储地址按照路由函数获取待打包对象；

第二打包单元，用于执行脚本数据以对待打包对象进行打包，得到第一打包结果；

第三发送单元，用于向远程服务器发送所述第一打包结果。

本申请实施例中远程服务器通过在预先创建的服务器队列中查找处于空闲状态的本地服务器来执行打包处理，从而减轻远程服务器的打包压力，远程服务器在接收第一HTTP请求后，查找预先创建的的服务器队列，如果查找到处于空闲状态的本地服务器，即第二本地服务器，向第二本地服务器发送第二HTTP请求，以请求由第二本地服务器完成打包任务，第二本地服务器从第二HTTP请求中解析得到待打包对象的存储地址，根据该存储地址按照预先创建的路由函数来获取待打包对象，然后，执行打包的脚本数据来实现打包处理。处于空闲状态的本地服务器有效地分担了远程服务器的打包处理压力，并提升了打包处理效率。

进一步地，在未查找到空闲状态的本地服务器时，由远程服务器完成打包任务，或继续等待直到查到到空闲状态的本地服务器，从而提高打包处理效率。

进一步地，远程服务器通过预先创建的服务器队列提高了编译打包的效率，节省资源。

进一步地，还可以通过监测心跳报文的方式对服务器队列进行维护，以提高打包处理效率。

进一步地，远程服务器在一定时间未接收到打包结果，则通过在服务器队列中查找新的第二服务器来执行打包处理，进一步提升了打包处理的效率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了本申请实施例提供的应用程序打包方法的流程示意图；

图2示出了本申请又一实施例提供的远程服务器监测本地服务器的方法的流程示意图；

图3示出了本申请又一实施例提供的应用程序打包方法的流程示意图；

图4示出了本申请实施例提供的应用程序打包方法的流程示意图；

图5示出了根据本申请一个实施例的应用程序打包装置500的示例性结构框图；

图6示出了本申请又一实施例提供的远程服务器监测本地服务器的装置600的示例性结构框图；

图7示出了本申请又一实施例提供的应用程序打包装置700的示例性结构框图；

图8示出了本申请实施例提供的应用程序打包系统的示例性结构框图；

图9示出了适于用来实现本申请实施例的服务器的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

请参考图1，图1示出了本申请实施例提供的应用程序打包方法的流程示意图。该方法在远程服务器侧执行。

如图1所示，该方法包括：

步骤110，接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求。

远程服务器可以接收至少一个本地服务器中任一个本地服务器发送的打包请求(即第一HTTP请求)。第一HTTP请求至少包括待打包对象的存储地址和脚本数据。

本地服务器启动后，接收前端客户端发送的打包请求，本地服务器将打包请求发送给远程服务器。其中，打包请求携带待打包对象的存储地址和脚本数据。存储地址，例如可以是仓库地址和分支名。如，Git仓库的地址，分支名称等。存储地址还可以进一步包括标签号。可以通过Git分支管理可以有效地获取操作代码。

待打包对象是指需要打包处理的应用程序代码。

脚本数据是用于执行对待打包对象执行打包的程序代码。

本申请实施例中，本地服务器都需预先配置路由，该路由用于指向预先创建的路由函数。通过调用预先创建的路由函数，将存储地址赋值给该路由函数，从而可以获取待打包对象。

步骤120，在预先创建的服务器队列中查找是否存在第二本地服务器。

本申请实施例中，通过在预先创建的服务器队列中查找处于空闲状态的本地服务器(即第二本地服务器)来执行打包。第二本地服务器可以是服务器队列中处于空闲状态的任意一个。

在远程服务器侧预先形成在线的本地服务器集合(即服务器队列)。预先创建服务器队列可以接收至少一个本地服务器中每一个本地服务器发送的第三HTTP请求。其中，第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态。远程服务器将IP地址和工作状态存储至服务器队列。

本申请实施例中，远程服务器还可以通过监听服务器队列中每个本地服务器的心跳报文来维护服务器队列。通过心跳报文来判断本地服务器是否在线。例如，接收本地服务器定时发送的心跳报文，或心跳报文请求。通过心跳报文的监听，远程服务器可以判断本地服务器是否在线。如果在规定的时间范围内，未接收到本地服务器发送的心跳报文，则判断本地服务器不在线，远程服务器则会从在线的本地服务器集合中移除未收到心跳报文的本地服务器。其中，心跳报文还可以携带本地服务器的工作状态标识符。工作状态标识符例如可以本地服务器处于空闲状态或者忙碌状态的标识符。

本申请实施例，还可以根据工作状态标识符更新服务器队列中发送心跳报文的本地服务器的工作状态。

本地服务器是基于koa框架启动的，在本地服务器内预先配置路由，该路由用于指向预先创建的路由函数。预先配置路由，例如可以是bulid路由，该bulid路由可以指向已编写完成的bulid函数。bulid函数可以预先定义如下参数，例如仓库地址、分支名称和/或标签号等。

查找方式，例如可以在服务器队列中轮询地或随机地查找是否存在第二本地服务器。

步骤130，若存在，则向第二本地服务器发送第二HTTP请求。

本申请实施例中，远程服务器在接收到打包请求后，将打包请求对应的待打包对象添加到任务队列中。然后，在服务器队列中查找第二本地服务器，该第二本地服务器可以是发送打包请求的本地服务器，也可以是在线的本地服务器集合(服务器队列)中其他的处于空闲状态的任意一个本地服务器。

在找到空闲状态的本地服务器之后，远程服务器向该空闲状态的本地服务器发送第二HTTP请求。第二HTTP请求用于请求本地服务器对待打包对象执行打包处理。第二HTTP请求至少包括待打包对象的存储地址和脚本数据。第二HTTP请求自带发送对象的IP地址。

空闲状态的本地服务器接收到该第二HTTP请求后，响应于第二HTTP请求，在根据存储地址按照路由函数获取待打包对象之后，按照打包的脚本数据对待打包对象执行打包，得到第一打包结果。

步骤140，从第二本地服务器接收第一打包结果。

本地服务器完成打包后，将第一打包结果发送给远程服务器，从而实现打包结果的同步。

步骤150，如果不存在，则响应于第一HTTP请求，对待打包对象执行打包，以生成第二打包结果。或者，等待查找得到的第二本地服务器，指示第二本地服务器来完成打包。

远程服务器查找至少一个本地服务器中处于空闲状态的本地服务器，例如可以通过轮询查找的方式来实现。如将待打包对象添加到任务轮询队列中以查找处于空闲状态的本地服务器。

如果在所有在线的本地服务器中都未找到空闲状态的本地服务器，或者说所有在线的本地服务器都处于工作状态，则远程服务器自身响应于打包请求，对待打包对象执行打包，得到第二打包结果。请注意，这里的第一打包结果和第二打包结果只是为了区别其执行打包的主体不同。或者，还可以一直等待，直到查找到第二本地服务器，由第二本地服务器来完成打包。

可选地，该方法还包括：

步骤160，如果超过第一时间阈值未接收到第一打包结果，则从服务器队列中查找新的第二本地服务器，并向该新的第二本地服务器发送第二HTTP请求。

本申请实施例，远程服务器还可以设置第一时间阈值来处理处于空闲状态的本地服务器由于自身或线路原因导致发送第一打包结果失败的问题。当超过第一时间阈值未接收到第一打包结果，则向处于空闲状态的其他本地服务器发送第二HTTP请求，以请求其他本地服务器执行打包处理，从而有效地提高打包效率。

从服务器队列中查找新的第二本地服务器，例如可以在服务器队列中剩余的本地服务器中查找，或者重新在整个服务器队列中查找。

本申请实施例，通过远程服务器调度空闲状态的本地服务器，来实现应用程序的打包处理，从而有效地减轻了远程服务器的负担，提高了打包处理的效率。

请参考图2，图2示出了本申请又一实施例提供的远程服务器监测本地服务器的方法的流程示意图。该方法在远程服务器侧执行。

如图2所示，该方法包括：

步骤210，接收至少一个本地服务器中每一个本地服务器发送的第三HTTP请求。其中，第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态。

本申请实施例中，不同的前端用户在进行软件开发时，只要对应用程序的相关代码进行调试，则会触发一个与之关联的本地服务器的启动。本地服务器可以基于koa框架启动。Koa框架是基于nodejs平台的下一代web开发框架。

在本地服务器启动后，本地服务器向远程服务器发送一个HTTP请求，该HTTP请求中包括该本地服务器的IP地址和当前时刻的工作状态。该工作状态，例如可以是空闲状态或忙碌状态。

步骤220，将IP地址和工作状态存储至服务器队列。

远程服务器将本地服务器的IP地址和当前的工作状态存储到某个存储区域，例如服务器队列。例如，与本地服务器的IP地址建立映射关系的存储装置，或存储位置上。

步骤230，定时监测服务器队列中每一个本地服务器发送的心跳报文。其中，心跳报文携带该本地服务器的工作状态标识符。

步骤240，根据工作状态标识符更新服务器队列中与之对应的工作状态。

远程服务器监听并接收本地服务器定时发送的心跳报文。心跳报文用于向远程服务器通知本地服务器与其连接的状态。心跳报文还可以包括本地服务器的工作状态，从而提高远程服务器监听效率。

步骤250，若在第二时间阈值内未接收到心跳报文，则从服务器队列中删除与未收到心跳报文相对应的IP地址。

远程服务器设置第二时间阈值，并判断超过第二时间阈值未接收到本地服务器定时发送的心跳报文，则判断该本地服务器不在线或者掉线，远程服务器则移除该本地服务器，从而节省资源，提高处理效率。

本申请实施例，在启动本地服务器时向远程服务器存储其IP地址和当前时刻的状态，远程服务器通过心跳监测与本地服务器保持连接，提升了远程服务器调度本地服务器的处理效率。

请参考图3，图3示出了本申请又一实施例提供的应用程序打包方法的流程示意图。该方法在至少一个本地服务器中的一个本地服务器上执行，该本地服务器处于空闲状态。

如图3所示，该方法包括：

步骤310，接收第二HTTP请求。

本申请实施例中，远程服务器查找处于空闲状态的本地服务器，当查找到处于空闲状态的本地服务器时，远程服务器向该本地服务器发送第二HTTP请求，该第一HTTP请求包括待打包对象的存储地址和脚本数据。存储地址，例如是仓库地址、分支名称等。存储地址还可以包括标签名。

步骤320，解析第二HTTP请求，得到存储地址和脚本数据。

步骤330，根据存储地址按照路由函数获取待打包对象。

步骤340，执行脚本数据以对待打包对象进行打包，得到第一打包结果；

步骤350，向远程服务器发送第一打包结果。

本申请实施例，本地服务器在接收到第二HTTP请求时，响应于第二HTTP请求，从第二HTTP请求中确定处于空闲状态的本地服务器，调用预先配置路由所需的存储地址，例如bulid路由。执行解析得到的脚本数据对待打包对象进行打包，以生成第一打包结果。本地服务器和其他的本地服务器是基于koa框架启动的，第二本地服务器是远程服务器从在线的本地服务器集合中查找到的，且处于空闲状态。

本申请实施例中，本地服务器执行完成打包后，会把打包结果发送给远程服务器，并通知远程服务器该本地服务器处于空闲状态，则远程服务器接收到第一打包结果后，将本地服务器的状态修改为空闲状态。

请参考图4，图4示出了本申请实施例提供的应用程序打包方法的流程示意图。该方法由远程服务器和至少一个本地服务器交互执行。

步骤410，远程服务器接收至少一个本地服务器中每一个本地服务器发送的第三HTTP请求。其中，第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态。

步骤420，远程服务器将IP地址和工作状态存储至服务器队列。

步骤430，远程服务器定时监测服务器队列中每一个本地服务器发送的心跳报文。心跳报文携带该本地服务器的工作状态标识符。

步骤440，远程服务器根据工作状态标识符更新服务器队列中与之对应的工作状态。

步骤450，远程服务器若在第二时间阈值内未接收到心跳报文，则从服务器队列中删除与未收到心跳报文相对应的IP地址。

步骤450a，任意一个本地服务器(第一本地服务器)发送第一HTTP请求至远程服务器。

步骤450b，远程服务器接收第一HTTP请求。

步骤460，远程服务器在预先创建的服务器队列中查找是否存在第二本地服务器。

步骤470，若存在，则远程服务器向第二本地服务器发送第二HTTP请求。

步骤470a，第二本地服务器接收第二HTTP请求，解析第二HTTP请求，根据存储地址按照路由函数获取待打包对象，执行脚本数据以对待打包对象进行打包，得到第一打包结果。

步骤470b，第二本地服务器向远程服务器发送第一打包结果。

步骤470c，远程服务器从第二本地服务器接收第一打包结果。

步骤480，如果不存在，则响应于第一HTTP请求，对待打包对象执行打包，以生成第二打包结果；或者，

步骤490，远程服务器等待查找得到的第二本地服务器，指示第二本地服务器来完成打包。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

参考图5，图5示出了根据本申请一个实施例的应用程序打包装置500的示例性结构框图。该装置在远程服务器侧执行。

如图5所示，该装置包括：

第一接收单元510，用于接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求。

远程服务器可以接收至少一个本地服务器中任一个本地服务器发送的打包请求(即第一HTTP请求)。第一HTTP请求至少包括待打包对象的存储地址和脚本数据。

本地服务器启动后，接收前端客户端发送的打包请求，本地服务器将打包请求发送给远程服务器。其中，打包请求携带待打包对象的存储地址和脚本数据。存储地址，例如可以是仓库地址和分支名。如，Git仓库的地址，分支名称等。存储地址还可以进一步包括标签号。可以通过Git分支管理可以有效地获取操作代码。

待打包对象是指需要打包处理的应用程序代码。

脚本数据是用于执行对待打包对象执行打包的程序代码。

本申请实施例中，本地服务器都需预先配置路由，该路由用于指向预先创建的路由函数。通过调用预先创建的路由函数，将存储地址赋值给该路由函数，从而可以获取待打包对象。

查找单元520，用于在预先创建的服务器队列中查找是否存在第二本地服务器。

本申请实施例中，通过在预先创建的服务器队列中查找处于空闲状态的本地服务器(即第二本地服务器)来执行打包。第二本地服务器可以是服务器队列中处于空闲状态的任意一个。

在远程服务器侧预先形成在线的本地服务器集合(即服务器队列)。预先创建服务器队列可以接收至少一个本地服务器中每一个本地服务器发送的第三HTTP请求。其中，第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态。远程服务器将IP地址和工作状态存储至服务器队列。

本申请实施例中，远程服务器还可以通过监听服务器队列中每个本地服务器的心跳报文来维护服务器队列。通过心跳报文来判断本地服务器是否在线。例如，接收本地服务器定时发送的心跳报文，或心跳报文请求。通过心跳报文的监听，远程服务器可以判断本地服务器是否在线。如果在规定的时间范围内，未接收到本地服务器发送的心跳报文，则判断本地服务器不在线，远程服务器则会从在线的本地服务器集合中移除未收到心跳报文的本地服务器。其中，心跳报文还可以携带本地服务器的工作状态标识符。工作状态标识符例如可以本地服务器处于空闲状态或者忙碌状态的标识符。

本申请实施例，还可以根据工作状态标识符更新服务器队列中发送心跳报文的本地服务器的工作状态。

本地服务器是基于koa框架启动的，在本地服务器内预先配置路由，该路由用于指向预先创建的路由函数。预先配置路由，例如可以是bulid路由，该bulid路由可以指向已编写完成的bulid函数。bulid函数可以预先定义如下参数，例如仓库地址、分支名称和/或标签号等。

查找方式，例如可以在服务器队列中轮询地或随机地查找是否存在第二本地服务器。

第一发送单元530，用于若存在，则向第二本地服务器发送第二HTTP请求。

本申请实施例中，远程服务器在接收到打包请求后，将打包请求对应的待打包对象添加到任务队列中。然后，在服务器队列中查找第二本地服务器，该第二本地服务器可以是发送打包请求的本地服务器，也可以是在线的本地服务器集合(服务器队列)中其他的处于空闲状态的任意一个本地服务器。

在找到空闲状态的本地服务器之后，远程服务器向该空闲状态的本地服务器发送第二HTTP请求。第二HTTP请求用于请求本地服务器对待打包对象执行打包处理。第二HTTP请求至少包括待打包对象的存储地址和脚本数据。第二HTTP请求自带发送对象的IP地址。

空闲状态的本地服务器接收到该第二HTTP请求后，响应于第二HTTP请求，在根据存储地址按照路由函数获取待打包对象之后，按照打包的脚本数据对待打包对象执行打包，得到第一打包结果。

第二接收单元540，用于从第二本地服务器接收第一打包结果。

本地服务器完成打包后，将第一打包结果发送给远程服务器，从而实现打包结果的同步。

第一打包单元550，用于如果不存在，则响应于第一HTTP请求，对待打包对象执行打包，以生成第二打包结果。

该装置还可以包括：

延迟单元560，用于等待查找得到的第二本地服务器，指示第二本地服务器来完成打包。

远程服务器查找至少一个本地服务器中处于空闲状态的本地服务器，例如可以通过轮询查找的方式来实现。如将待打包对象添加到任务轮询队列中以查找处于空闲状态的本地服务器。

如果在所有在线的本地服务器中都未找到空闲状态的本地服务器，或者说所有在线的本地服务器都处于工作状态，则远程服务器自身响应于打包请求，对待打包对象执行打包，得到第二打包结果。请注意，这里的第一打包结果和第二打包结果只是为了区别其执行打包的主体不同。或者，还可以一直等待，直到查找到第二本地服务器，由第二本地服务器来完成打包。

可选地，该装置还包括：

第二发送单元570，用于如果超过第一时间阈值未接收到第一打包结果，则从服务器队列中查找新的第二本地服务器，并向该新的第二本地服务器发送第二HTTP请求。

本申请实施例，远程服务器还可以设置第一时间阈值来处理处于空闲状态的本地服务器由于自身或线路原因导致发送第一打包结果失败的问题。当超过第一时间阈值未接收到第一打包结果，则向处于空闲状态的其他本地服务器发送第二HTTP请求，以请求其他本地服务器执行打包处理，从而有效地提高打包效率。

本申请实施例，通过远程服务器调度空闲状态的本地服务器，来实现应用程序的打包处理，从而有效地减轻了远程服务器的负担，提高了打包处理的效率。

请参考图6，图6示出了本申请又一实施例提供的远程服务器监测本地服务器的装置的示例性结构框图。该装置可以在远程服务器侧执行。

如图6所示，该装置包括：

第三接收单元610，用于接收至少一个本地服务器中每一个本地服务器发送的第三HTTP请求。其中，第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态。

本申请实施例中，不同的前端用户在进行软件开发时，只要对应用程序的相关代码进行调试，则会触发一个与之关联的本地服务器的启动。本地服务器可以基于koa框架启动。Koa框架是基于nodejs平台的下一代web开发框架。

在本地服务器启动后，本地服务器向远程服务器发送一个HTTP请求，该HTTP请求中包括该本地服务器的IP地址和当前时刻的工作状态。该工作状态，例如可以是空闲状态或忙碌状态。

存储单元620，用于将IP地址和工作状态存储至服务器队列。

远程服务器将本地服务器的IP地址和当前的工作状态存储到某个存储区域，例如服务器队列。例如，与本地服务器的IP地址建立映射关系的存储装置，或存储位置上。

定时监测单元630，用于定时监测服务器队列中每一个本地服务器发送的心跳报文。其中，心跳报文携带该本地服务器的工作状态标识符。

状态更新单元640，用于根据工作状态标识符更新服务器队列中与之对应的工作状态。

远程服务器监听并接收本地服务器定时发送的心跳报文。心跳报文用于向远程服务器通知本地服务器与其连接的状态。心跳报文还可以包括本地服务器的工作状态，从而提高远程服务器监听效率。

地址删除单元650，用于若在第二时间阈值内未接收到心跳报文，则从服务器队列中删除与未收到心跳报文相对应的IP地址。

远程服务器设置第二时间阈值，并判断超过第二时间阈值未接收到本地服务器定时发送的心跳报文，则判断该本地服务器不在线或者掉线，远程服务器则移除该本地服务器，从而节省资源，提高处理效率。

本申请实施例，在启动本地服务器时向远程服务器存储其IP地址和当前时刻的状态，远程服务器通过心跳监测与本地服务器保持连接，提升了远程服务器调度本地服务器的处理效率。

请参考图7，图7示出了本申请又一实施例提供的应用程序打包装置700的示例性结构框图。该装置在至少一个本地服务器中的一个本地服务器上执行，该本地服务器处于空闲状态。

如图7所示，该装置700包括：

第四接收单元710，用于接收第二HTTP请求。

本申请实施例中，远程服务器查找处于空闲状态的本地服务器，当查找到处于空闲状态的本地服务器时，远程服务器向该本地服务器发送第二HTTP请求，该第一HTTP请求包括待打包对象的存储地址和脚本数据。存储地址，例如是仓库地址、分支名称等。存储地址还可以包括标签名。

解析单元720，用于解析第二HTTP请求，得到存储地址和脚本数据。

获取单元730，用于根据存储地址按照路由函数获取待打包对象。

第二打包单元740，用于执行脚本数据以对待打包对象进行打包，得到第一打包结果；

第三发送单元750，用于向远程服务器发送第一打包结果。

本申请实施例，本地服务器在接收到第二HTTP请求时，响应于第二HTTP请求，从第二HTTP请求中确定处于空闲状态的本地服务器，调用预先配置路由所需的存储地址，例如bulid路由。执行解析得到的脚本数据对待打包对象进行打包，以生成第一打包结果。本地服务器和其他的本地服务器是基于koa框架启动的，第二本地服务器是远程服务器从在线的本地服务器集合中查找到的，且处于空闲状态。

本申请实施例中，本地服务器执行完成打包后，会把打包结果发送给远程服务器，并通知远程服务器该本地服务器处于空闲状态，则远程服务器接收到第一打包结果后，将本地服务器的状态修改为空闲状态。

请参考图8，图8示出了本申请实施例提供的应用程序打包系统的示例性结构框图。该系统包括远程服务器810和至少一个本地服务器820。

远程服务器810，用于接收至少一个本地服务器820中第一本地服务器发送的第一HTTP请求，在预先创建的服务器队列中查找是否存在第二本地服务器，若存在，则向第二本地服务器发送第二HTTP请求。

本地服务器820，用于接收第二HTTP请求；解析第二HTTP请求，得到存储地址和脚本数据；根据存储地址按照路由函数获取待打包对象；执行脚本数据以对待打包对象进行打包，得到第一打包结果；向远程服务器发送第一打包结果。

远程服务器810，还可以包括如图5-6描述的装置。本地服务器820，还可以包括如图7描述的装置。

应当理解，装置500-700中记载的诸单元或模块与参考图1-3描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置500-700及其中包含的单元，在此不再赘述。装置500-700可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置500-700中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

下面参考图9，其示出了适于用来实现本申请实施例的本地服务器或远程服务器的计算机系统900的结构示意图。

如图9所示，计算机系统900包括中央处理单元(CPU)901，其可以根据存储在只读存储器(ROM)902中的程序或者从存储部分908加载到随机访问存储器(RAM)903中的程序而执行各种适当的动作和处理。在RAM 903中，还存储有系统900操作所需的各种程序和数据。CPU 901、ROM 902以及RAM 903通过总线904彼此相连。输入/输出(I/O)接口905也连接至总线904。

以下部件连接至I/O接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至I/O接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本公开的实施例，上文参考流程图图1-3描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理单元(CPU)901执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括第一接收单元、查找单元、以及第一发送单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，第一接收单元还可以被描述为“用于接收至少一个本地服务器发送的打包请求”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序，当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的应用程度打包方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种应用程序打包方法，其特征在于，该方法包括：

接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求，所述第一HTTP请求至少包括待打包对象的存储地址和脚本数据，所述本地服务器预先配置路由，所述路由用于指向预先创建的路由函数；

在预先创建的服务器队列中查找是否存在第二本地服务器，所述第二本地服务器是所述服务器队列中处于空闲状态的任意一个；

若存在，则向所述第二本地服务器发送第二HTTP请求，所述第二HTTP请求至少包括所述待打包对象的存储地址和脚本数据，以使得所述第二本地服务器响应于所述第二HTTP请求，在根据所述存储地址按照所述路由函数获取所述待打包对象之后，执行所述脚本数据以对所述待打包对象进行打包处理，得到第一打包结果；

从所述第二本地服务器接收所述第一打包结果；

若不存在，则响应于所述第一HTTP请求，对所述待打包对象执行打包，以生成第二打包结果；或者，

等待查找得到的所述第二本地服务器，指示所述第二本地服务器来完成打包。

2.一种应用程序打包方法，其特征在于，该方法在至少一个本地服务器中处于空闲状态的本地服务器上执行，所述本地服务器预先配置路由，所述路由用于指向预先创建的路由函数，该方法包括：

接收第二HTTP请求，所述第二HTTP请求包括待打包对象的存储地址和脚本数据；

解析所述第二HTTP请求，得到所述存储地址和脚本数据；

根据所述存储地址按照所述路由函数获取所述待打包对象；

执行所述脚本数据以对所述待打包对象进行打包，得到第一打包结果；

向所述远程服务器发送所述第一打包结果。

3.一种应用程序打包装置，其特征在于，该装置包括：

第一接收单元，用于接收至少一个本地服务器中第一本地服务器发送的第一HTTP请求，所述第一HTTP请求至少包括待打包对象的存储地址和脚本数据，所述本地服务器预先配置路由，所述路由用于指向预先创建的路由函数；

查找单元，用于在预先创建的服务器队列中查找是否存在第二本地服务器，所述第二本地服务器是所述服务器队列中处于空闲状态的任意一个；

第一发送单元，用于若存在，则向所述第二本地服务器发送第二HTTP请求，所述第二HTTP请求包括所述待打包对象的存储地址和脚本数据，以使得所述第二本地服务器响应于所述第二HTTP请求，在根据所述存储地址按照所述路由函数获取所述待打包对象之后，执行所述脚本数据以对所述待打包对象进行打包处理，得到第一打包结果；

第二接收单元，用于从所述第二本地服务器接收所述第一打包结果。

4.根据权利要求3所述的装置，其特征在于，该装置还包括：

第一打包单元，用于如果不存在，则响应于所述第一HTTP请求，对所述待打包对象执行打包，以生成第二打包结果；或者，

延迟单元，用于等待查找得到的所述第二本地服务器，指示所述第二本地服务器来完成打包。

5.根据权利要求3所述的装置，其特征在于，所述查找单元还用于：

在所述服务器队列中轮询地或随机地查找是否存在所述第二本地服务器。

6.根据权利要求3所述的装置，其特征在于，该装置还包括：

第二发送单元，用于如果超过第一时间阈值未接收到所述第一打包结果，则从查找所述服务器队列中新的第二本地服务器，并向该新的第二本地服务器发送所述第二HTTP请求。

7.根据权利要求3所述的装置，其特征在于，该装置包括：

第三接收单元，用于接收所述至少一个本地服务器中每一个本地服务器发送的第三HTTP请求，所述第三HTTP请求中包括与该本地服务器对应的IP地址和当前时刻的工作状态；

存储单元，用于将所述IP地址和所述当前时刻的工作状态存储至所述服务器队列。

8.根据权利要求7所述的装置，其特征在于，该装置还包括：

定时监测单元，用于定时监测所述服务器队列中每一个本地服务器发送的心跳报文，所述心跳报文携带该本地服务器的工作状态标识符；

状态更新单元，用于根据所述工作状态标识符更新与之对应的所述工作状态。

9.根据权利要求8所述的装置，其特征在于，该装置还包括：

地址删除单元，用于若在第二时间阈值内未接收到所述心跳报文，则从所述服务器队列中删除与未收到所述心跳报文相对应的IP地址。

10.一种应用程序打包装置，其特征在于，该装置在至少一个本地服务器中处于空闲状态的本地服务器上执行，所述本地服务器预先配置路由，所述路由用于指向预先创建的路由函数，该装置包括：

第四接收单元，用于接收第二HTTP请求，所述第二HTTP请求包括所述本地服务器的IP地址和待打包对象的存储地址和脚本数据；

解析单元，用于解析所述第二HTTP请求，得到所述存储地址和脚本数据；

获取单元，用于根据所述存储地址按照所述路由函数获取所述待打包对象；

第二打包单元，用于执行所述脚本数据以对所述待打包对象进行打包，得到第一打包结果；

第三发送单元，用于向所述远程服务器发送所述第一打包结果。

Images