一种应用程序的管理方法及系统与流程

本发明涉及计算机应用技术领域，特别涉及一种应用程序的管理方法及系统。

背景技术：

随着互联网及其应用的快速发展，绝大多数企业都建立自己的网站。为了提高网站访问响应速度和效率，可以采用cdn(contentdeliverynetwork，内容分发网络)技术。cdn的技术原理是在网络各处设置服务器节点，并将网络内容发布到处于网络边缘的边缘服务器节点(以下简称“边缘节点”)中，这样用户就可以从最接近用户的边缘节点上获得预访问的内容，从而降低了网络拥塞，提高了网络的响应速度。

目前，每个边缘节点上可以部署多个应用程序，并且对于边缘节点的管理包括两种方式，一种是不进行虚拟化，另外一种是在操作系统层面进行虚拟化。若边缘节点不进行虚拟化，由于所有应用程序均安装在一个操作系统上，应用程序之间会互相争夺服务器资源，在负载较高的时候影响对外提供的服务。并且，服务器资源无法调度，有的应用程序所占用的资源可能存在浪费或是不足。若操作系统层面虚拟化，切换服务或者资源调度，需重启服务器，从而影响对外服务。

技术实现要素：

为了解决现有技术的问题，本发明实施例提供了一种应用程序的管理方法及系统。所述技术方案如下：

第一方面，提供了一种应用程序的管理方法，所述方法包括：

在边缘节点中配置应用容器引擎；

所述边缘节点接收中心节点发送的应用部署信息；

所述边缘节点基于所述应用部署信息从所述中心节点中下载包含相应应用程序的镜像；

所述边缘节点调用应用容器引擎加载所述镜像，并运行所述应用容器引擎中的所述应用程序；

所述边缘节点为所述应用容器引擎分配可用资源。

可选的，所述边缘节点接收中心节点发送的应用部署信息之前，包括：

所述中心节点接收客户端发送的包含所述应用程序的镜像；

所述中心节点接收所述客户端发送的所述应用部署请求，所述应用部署请求包括待部署应用的边缘节点范围；

所述中心节点基于所述应用部署请求向所述边缘节点发送所述应用部署信息。

可选的，所述应用部署请求包括部署批次以及每批次对应的边缘节点范围；

所述中心节点基于所述应用部署请求向所述边缘节点发送所述应用部署信息的步骤，包括：

所述中心节点基于所述应用部署请求向第一批次边缘节点发送所述应用部署信息；

当前批次边缘节点基于所述应用部署信息完成应用部署之后，向所述中心节点发送应用部署结果以及应用运行情况；

如果所述中心节点基于所述应用部署结果以及应用运行情况，确定出当前批次边缘节点的应用部署符合要求，并且当前批次边缘节点不是最后一批次，则向下一批次边缘节点发送所述应用部署信息，并重复该步骤，否则结束该步骤。

可选的，所述应用部署信息包括资源信息，所述资源信息包括为所述应用程序分配的各种资源的大小；

相应的，所述边缘节点为所述应用容器引擎分配可用资源的步骤，包括：

所述边缘节点基于所述资源信息为所述应用容器引擎分配可用资源。

可选的，所述应用部署信息包括应用标识；

相应的，所述边缘节点基于所述应用部署信息从所述中心节点中下载包含相应应用程序的镜像的步骤，包括：

所述边缘节点基于所述应用部署信息从所述中心节点中下载所述应用标识对应的镜像。

可选的，所述边缘节点调用应用容器引擎加载所述镜像的步骤，包括：

所述边缘节点根据预设的调用策略调用空闲的应用容器引擎加载所述镜像。

可选的，所述方法还包括：

所述边缘节点按照固定周期向所述中心节点发送所述应用容器引擎的资源使用情况；

所述中心节点接收所述应用容器引擎当前的资源使用情况，并判断所述应用容器引擎当前的资源使用情况是否符合要求；

如果不符合，所述中心节点生成资源调整信息，并向所述边缘节点发送所述资源调整信息；

所述边缘节点接收所述资源调整信息，并基于所述资源调整信息重新为所述应用容器引擎分配可用资源。

可选的，在所述中心节点判断出所述应用容器引擎当前的资源使用情况不符合要求之后，还包括：

所述中心节点向客户端发送所述应用容器引擎当前的资源使用情况；

所述客户端基于所述资源使用情况，生成是否进行资源调整的指示信息；

所述客户端向所述中心节点发送所述指示信息；

所述中心节点接收所述指示信息，如果所述指示信息表明需要进行资源调整，则生成所述资源调整信息。

可选的，所述方法还包括：

所述中心节点接收客户端发送的应用升级请求，所述应用升级请求包括待升级的边缘节点范围；

所述中心节点基于所述应用升级请求，确定灰度升级策略，所述灰度升级策略包括灰度批次以及每批对应的边缘节点范围；

所述中心节点基于所述灰度升级策略分批向边缘节点发送所述应用升级信息。

可选的，所述中心节点基于所述灰度升级策略向每批次边缘节点发送所述应用升级信息之后，包括：

当前批次边缘节点接收所述中心节点发送的所述应用升级信息，并对所述应用程序进行升级；

所述当前批次边缘节点应用升级结束之后向所述中心节点发送灰度结果，所述灰度结果包括升级结果以及应用容器引擎服务状态信息。分从属

可选的，所述中心节点基于所述灰度升级策略分批向边缘节点发送所述应用升级信息的步骤，包括：

所述中心节点基于所述灰度升级策略向第一批次边缘节点发送所述应用升级信息；

所述中心节点接收所述当前批次边缘节点发送的所述灰度结果，如果所述灰度结果符合要求，则在预设时间段之后向下一批边缘节点发送所述应用升级信息，并重复该步骤，直至所有批次边缘节点应用升级结束；

如果所述灰度结果不符合要求，则向所述当前批次边缘节点发送回滚信息，以使所述当前批次边缘节点将所述应用程序回滚至升级前的应用版本。分从属

可选的，所述边缘节点接收所述中心节点发送的所述应用升级信息，并对所述应用程序进行升级，包括：

所述边缘节点接收所述中心节点发送的应用升级信息；

所述边缘节点基于所述应用升级信息利用新应用容器引擎对所述应用程序进行升级；

如果应用升级成功，所述边缘节点释放升级前为原应用容器引擎分配的可用资源。

可选的，所述中心节点用于对所述应用程序进行动态生命周期管理，其中，所述动态生命周期管理包括启动操作、停止操作以及重启操作。

第二方面，提供了一种应用程序的管理系统，包括边缘节点以及中心节点；

所述边缘节点，用于在本节点中配置应用容器引擎；接收所述中心节点发送的应用部署信息，基于所述应用部署信息从所述中心节点中下载包含相应应用程序的镜像，调用应用容器引擎加载所述镜像，并运行所述应用容器引擎中的所述应用程序，为所述应用容器引擎分配可用资源；

所述中心节点，用于向所述边缘节点发送所述应用部署信息。

可选的，所述中心节点，还用于：

接收客户端发送的包含所述应用程序的镜像；

接收所述客户端发送的所述应用部署请求，所述应用部署请求包括待部署应用的边缘节点范围；

基于所述应用部署请求生成应用部署信息；

向所述边缘节点发送所述应用部署信息。

可选的，所述应用部署请求包括部署批次以及每批次对应的边缘节点范围；

所述中心节点，用于基于所述应用部署请求向第一批次边缘节点发送所述应用部署信息；

所述边缘节点，用于基于所述应用部署信息完成应用部署之后，向所述中心节点发送应用部署结果以及应用运行情况；

所述中心节点，用于当基于所述应用部署结果以及应用运行情况，确定出当前批次边缘节点的应用部署符合要求，并且当前批次边缘节点不是最后一批次时，向下一批次边缘节点发送所述应用部署信息。

可选的，所述应用部署信息包括资源信息，所述资源信息包括为所述应用程序分配的各种资源的大小；

所述边缘节点，用于基于所述资源信息为所述应用容器引擎分配可用资源。

可选的，所述边缘节点，用于按照固定周期向所述中心节点发送所述应用容器引擎的资源使用情况；

所述中心节点，用于接收所述应用容器引擎当前的资源使用情况，并判断所述应用容器引擎当前的资源使用情况是否符合要求，如果不符合，生成资源调整信息，并向所述边缘节点发送所述资源调整信息；

所述边缘节点，用于接收所述资源调整信息，并基于所述资源调整信息重新为所述应用容器引擎分配可用资源。

可选的，

所述中心节点，用于向客户端发送所述应用容器引擎当前的资源使用情况；

所述客户端，用于基于所述资源使用情况，生成是否进行资源调整的指示信息，并向所述中心节点发送所述指示信息；

所述中心节点，用于接收所述指示信息，如果所述指示信息表明需要进行资源调整，则生成所述资源调整信息。

可选的，所述中心节点，用于：

接收客户端发送的应用升级请求，所述应用升级请求包括待升级的边缘节点范围；

基于所述应用升级请求，确定灰度升级策略，所述灰度升级策略包括灰度批次以及每批对应的边缘节点范围；

基于所述灰度升级策略分批向边缘节点发送所述应用升级信息。

可选的，所述边缘节点，用于：

接收所述中心节点发送的所述应用升级信息，并对所述应用程序进行升级；

在应用升级结束之后向所述中心节点发送灰度结果，所述灰度结果包括升级结果以及应用容器引擎服务状态信息。分从属

可选的，所述中心节点，用于：

基于所述灰度升级策略向第一批次边缘节点发送所述应用升级信息；

接收所述当前批次边缘节点发送的所述灰度结果，如果所述灰度结果符合要求，则在预设时间段之后向下一批边缘节点发送所述应用升级信息，并重复该步骤，直至所有批次边缘节点应用升级结束；

如果所述灰度结果不符合要求，则向所述当前批次边缘节点发送回滚信息，以使所述当前批次边缘节点将所述应用程序回滚至升级前的应用版本。分从属

可选的，所述边缘节点，用于：

接收所述中心节点发送的应用升级信息；

基于所述应用升级信息利用新应用容器引擎对所述应用程序进行升级；

如果应用升级成功，释放升级前为原应用容器引擎分配的可用资源。

本发明实施例将应用部署于应用容器引擎中，各个应用之间不相互干扰，实现了资源隔离，避免了应用之间的资源竞争，而且由于应用之间不相互干扰能够减少故障的发生，可靠性更强，并且应用容器引擎的可用资源可以通过合理分配，避免资源利用不均匀，在保证应用正常运行的情况下最大程度地减少资源分配，从而提高资源的利用率，节约成本，另外，在分配资源时，可以为边缘计算和系统加速分配所需要的资源，从而提高系统服务质量，同时由于采用应用容器引擎中进行应用部署，可以实现灰度、平滑升级，并可任意地对应用进行资源调度而无需中断服务。

附图说明

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

图1是本发明实施例提供的一种网络框架示意图；

图2是本发明实施例提供的一种应用程序的管理方法的流程图；

图3是本发明实施例提供的另一种应用程序的管理方法的流程图；

图4是本发明实施例提供的另一种应用程序的管理方法的流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

本发明实施例提供了一种应用程序的管理方法，该方法可以应用于图1所示的网络框架中。该网络框架包括客户端、中心节点以及边缘节点。企业为运营自己的网站，为用户提供网络服务，可以通过客户端控制将应用程序部署在多个边缘节点中，具体部署过程如下所述。客户端将应用程序打包成镜像发送到中心节点，并向中心节点发送应用部署请求，所述应用部署请求可以包括待部署应用的边缘节点范围。然后所述中心节点可以基于所述应用部署请求向相应的边缘节点发送所述应用部署信息，以使这些边缘节点基于所述应用部署信息下载包含相应应用程序的镜像，并利用应用容器引擎加载该镜像，进行应用部署。边缘节点部署应用结束后，用户可以通过访问该边缘节点，获取相应的服务，例如浏览博客、观看视频等等。本实施例中的应用容器引擎可以采用docker容器。

客户端发送的应用部署请求还可以包括部署批次以及每批次对应的边缘节点范围，也就是说，中心节点可以根据该应用部署请求，将总的待部署应用的边缘节点分批次进行应用部署。中心节点分批在边缘节点中进行应用部署的具体过程为：所述中心节点基于所述应用部署请求向第一批次边缘节点发送所述应用部署信息；当前批次边缘节点应用部署结束后，向中心节点发送应用部署结果以及应用运行情况；如果中心节点基于应用部署结果以及应用运行情况，确定出当前批次的边缘节点应用部署符合要求，并且当前批次边缘节点不是最后一批次，则向下一批边缘节点发送应用部署信息，并重复该步骤，否则结束该步骤。以防止一次性大范围部署完毕后，应用运行出现问题，需再次大范围重新部署的情况，而这种情况会造成大量人力以及时间的浪费，并且造成边缘服务器资源的浪费。

可选的，客户端发送的应用部署请求可以不包括部署批次以及每批次对应的边缘节点范围，中心节点可以根据应用部署请求中的待部署应用的边缘节点范围确定部署批次以及每批次对应的边缘节点范围。

以下详细说明对应用程序的管理方法，其中包括应用部署、应用资源调整以及应用升级等等。

参见图2，为本发明实施例提供的一种应用程序的管理方法的流程图，其中，主要详细说明边缘节点的应用部署的过程，该过程具体可以包括以下步骤。

步骤201，边缘节点在本节点中配置应用容器引擎。

边缘节点可以预先在本节点中配置预设数量的应用容器引擎。由于应用容器引擎采用沙箱机制，任意两个应用容器引擎之间存在系统级隔离，且相互之间不存在接口，所以运行在不同应用容器引擎中的应用程序之间不会相互干扰。

步骤202，所述边缘节点接收中心节点发送的应用部署信息。

边缘节点可以接收中心节点发送的应用部署信息，该应用部署信息可以包括待部署应用的应用标识。

步骤203，所述边缘节点基于所述应用部署信息从所述中心节点中下载包含相应应用程序的镜像。

中心节点中保存有多个客户端上传的应用镜像，即包含应用程序的镜像，边缘节点可以根据应用部署信息中的应用标识，从中心节点中下载该应用标识对应的镜像，从而为后续的应用部署做准备。在实施中，可以基于p2p技术实现镜像下载功能。

可选的，客户端上传的应用镜像还可以存储在其他镜像库中，本发明实施例不对应用镜像的存储位置进行具体限定。

步骤204，所述边缘节点调用应用容器引擎加载所述镜像，并运行所述应用容器引擎中的所述应用程序。

边缘节点可以随机调用空闲的应用容器引擎，或者根据预设的调用策略调用空闲的应用容器引擎用以加载所述镜像。具体地，可以通过调用应用容器引擎的接口，将镜像加载到该应用容器引擎中。镜像加载完毕后，启动应用容器引擎，以运行应用容器引擎中的应用程序。

在实施中，中心节点还负责应用的静态配置管理，主要管理应用部署时所需要的配置文件，边缘节点在部署应用的过程中可以用中心节点中下载相应的配置文件，以进行应用配置。

步骤205，所述边缘节点为所述应用容器引擎分配可用资源。

各个应用程序运行于不同的应用容器引擎中，应用程序之间独立运行，不会相互影响，所以在为应用容器引擎分配可用资源之后，应用容器引擎之间不会出现资源竞争的问题。在实施中，边缘节点可以根据预设的资源分配策略为每个应用程序分配相应的可用资源，可用资源可以包括内存、cpu、磁盘、带宽等等。可选的，客户端向中心节点发送的应用部署请求还可以包括资源信息，该资源信息包括为应用程序分配的各种资源的大小，以使中心节点生成的应用部署信息也包括该资源信息，在将该应用部署信息发送给边缘节点之后，可以使边缘节点根据该资源信息进行资源分配。

在实施中，中心节点还负责应用程序的动态生命周期管理，例如应用程序的启动、停止、重启等操作。中心节点在应用程序的动态生命周期管理过程中，可以向边缘节点发送相应的指令，以控制边缘节点对应用程序进行相应的操作。

在实施中，中心节点还负责监控边缘节点的运行情况，即边缘节点可以按照固定周期向中心节点发送状态数据，以使中心节点根据该状态数据检测边缘的运行情况。中心节点还可以向边缘节点发送边缘节点的机器信息，例如机器标识、机器类型等等，以使边缘节点获悉自身的机器信息，从而方便与其他设备进行通信。

本发明实施例将应用部署于应用容器引擎中，各个应用之间不相互干扰，实现了资源隔离，避免了应用之间的资源竞争，而且由于应用之间不相互干扰能够减少故障的发生，可靠性更强，并且应用容器引擎的可用资源可以通过合理分配，避免资源利用不均匀，在保证应用正常运行的情况下最大程度地减少资源分配，从而提高资源的利用率，节约成本，另外，在分配资源时，可以为边缘计算和系统加速分配所需要的资源，从而提高系统服务质量，同时由于采用应用容器引擎中进行应用部署，可以实现灰度、平滑升级，并可任意地对应用进行资源调度而无需中断服务。

以上主要详细说明了应用部署的过程，以下参照图3详细说明应用资源调整的过程。

参见图3，为本发明实施例提供的另一种应用程序的管理方法的流程图，其中，主要详细说明应用资源调整的过程，该过程具体可以包括以下步骤。

步骤301，所述边缘节点按照固定周期向所述中心节点发送所述应用容器引擎的资源使用情况。

应用部署成功后，边缘节点可以实时监测应用容器引擎的资源使用情况，也可以是，监测该应用容器引擎中的应用程序的资源使用情况。可选的，边缘节点还可以监测应用容器引擎的资源利用率，即当前所使用的资源与分配的可用资源之间的比值。

步骤302，所述中心节点判断所述应用容器引擎当前的资源使用情况是否符合要求。

中心节点可以根据边缘节点上传的资源使用情况，判断当前为应用程序所分配的可用资源是否存在浪费或不足。例如，当资源利用率低于预设比例时，可以确定当前为应用程序所分配的可用资源存在浪费。

步骤303，如果不符合，所述中心节点生成资源调整信息，并向所述边缘节点发送所述资源调整信息。

如果中心节点判断出当前的资源使用情况不符合要求，则可以根据当前的资源使用情况以及预设的资源分配策略重新为应用程序分配资源信息，并生成资源调整信息，该资源调整信息包括重新分配的资源信息。

可选的，中心节点生成资源调整信息的过程还可以包括：所述中心节点向客户端发送所述应用容器引擎当前的资源使用情况；所述客户端接收所述资源使用情况，以及基于所述资源使用情况生成是否进行资源调整的指示信息，；所述客户端向所述中心节点发送所述指示信息；所述中心节点接收所述指示信息，如果所述指示信息表明需要进行资源调整，则生成所述资源调整信息。

中心节点向客户端发送应用当前的资源使用情况，使客户端能够根据该资源使用情况，以及结合自身业务的发展趋势判断是否进行资源调整，从而使是否进行资源调整的决策更加适合业务的发展趋势。如果客户端判断出需要进行资源调整，则生成的指示信息可以包括重新分配的资源信息，在将该指示信息发送给中心节点之后，使中心节点生成的资源调整信息也包括该重新分配的资源信息。

步骤304，所述边缘节点接收所述资源调整信息，并基于所述资源调整信息重新为所述应用容器引擎分配可用资源。

边缘节点接收到中心节点发送的资源调整信息之后，可以根据该资源调整信息中的资源信息为应用容器引擎重新分配可用资源。

本发明实施例可以实时监控各个应用容器引擎的资源使用情况，当出现资源使用情况不合理的情况时，可以重新进行资源的合理分配，避免资源利用不均匀，在保证应用正常运行的情况下最大程度地减少资源分配，从而提高资源的利用率，节约成本，另外，在分配资源时，可以为边缘计算和系统加速分配所需要的资源，从而提高系统服务质量，并且由于采用应用容器引擎进行应用部署，可以任意地对各应用进行资源调度而无需中断服务，进一步提高系统服务质量。

参见图4，为本发明实施例提供的另一种应用程序的管理方法的流程图，其中，主要详细说明应用升级的过程，该过程具体可以包括以下步骤。

步骤401，所述中心节点接收客户端发送的应用升级请求，所述应用升级请求包括待升级的边缘节点范围。

在客户端向中心节点发送应用升级请求之前，可以先将包括升级版应用程序的镜像上传给中心节点，以使待进行应用升级的边缘节点获取该镜像，并利用该镜像进行应用升级。

步骤402，所述中心节点基于所述应用升级请求，确定灰度升级策略，所述灰度升级策略包括灰度批次以及每批对应的边缘节点范围。

本实施例采用灰度升级方式，灰度升级即局部升级，当有些服务器需要进行升级时，只对其中一部分服务器升级并测试，在确保程序无误后再升级其他服务器，以最大程度减少升级后程序bug引起的后果。在实施中，中心节点可以根据待升级的边缘节点范围确定灰度升级策略，或者，客户端向中心节点发送的应用升级请求中可以包括灰度升级策略，从而直接从该应用升级请求中获取灰度升级策略。灰度升级策略用于规定待升级的边缘节点分几批进行升级，例如，第一批升级编号1-10的边缘节点，第二批升级编号11-20的边缘节点，第三批升级编号21-30的边缘节点，从而对30个边缘节点分三批进行升级。

步骤403，所述中心节点基于所述灰度升级策略分批向边缘节点发送所述应用升级信息。

该应用升级请求可以包括待升级应用的应用标识，以使边缘节点根据该应用标识确定待进行升级的应用程序。

在实施中，中心节点根据灰度升级策略分批升级边缘节点的具体过程包括：所述中心节点基于所述灰度升级策略向第一批次边缘节点发送所述应用升级信息；当前批次边缘节点接收所述中心节点发送的所述应用升级信息，并对所述应用程序进行升级；所述当前批次边缘节点应用升级结束之后向所述中心节点发送灰度结果，所述灰度结果包括升级结果以及应用容器引擎服务状态信息；所述中心节点接收所述当前批次边缘节点发送的灰度结果，如果所述灰度结果符合要求，则在预设时间段之后向下一批边缘节点发送所述应用升级信息，并重复该步骤，直至所有批次边缘节点应用升级结束；如果所述灰度结果不符合要求，则向所述当前批次边缘节点发送回滚信息，以使所述当前批次边缘节点将所述应用程序回滚至升级前的应用版本。以下，对该过程中的各个步骤进行具体说明。

边缘节点接收到中心节点发送的应用升级信息之后，对所述应用程序进行升级。以当前批次中的一个边缘节点进行举例说明，边缘节点进行应用升级的步骤可以包括：所述边缘节点接收所述中心节点发送的应用升级信息；所述边缘节点基于所述应用升级信息利用新应用容器引擎对所述应用程序进行升级；如果应用升级成功，所述边缘节点释放升级前为原应用容器引擎分配的可用资源。其中，利用新应用容器引擎对所述应用程序进行升级的过程包括：从中心节点中下载包括升级版应用程序的镜像，调用新应用容器引擎加载该镜像，再为该新应用容器引擎分配可用资源。该过程也可以是对升级版应用程序的部署，所以与上述应用部署的过程相似，具体步骤可以参考图2所示的实施例，在此不再赘述。

在利用新应用容器引擎对所述应用程序进行升级的过程中，如果升级失败，即对升级版应用程序部署失败，边缘节点继续使用原应用程序为用户提供服务。可选的，如果应用升级成功，可以待升级后的应用程序运行一段时间，并且确定运行正常之后才删除原应用程序，以保证在发现升级后的应用程序出现问题后，快速改用原应用程序为用户提供服务。

在利用新应用容器引擎进行应用升级的过程中，升级前的应用程序依然在原应用容器引擎中正常运行，为用户提供服务，待新应用容器引擎中的应用升级成功并正常运行后，才删除原应用程序，服务不会暂停，实现了应用的平滑升级。

边缘节点在应用升级结束之后向所述中心节点发送灰度结果，所述灰度结果包括升级结果以及应用容器引擎服务状态信息。应用容器引擎服务状态信息包括资源使用情况，如果当前的资源使用情况与升级前的资源使用情况差异较大，则说明应用容器引擎服务状态不符合要求，当升级结果表明应用升级成功并且应用容器引擎服务状态符合要求时，说明该边缘节点的灰度结果正常。

中心节点接收当前批次边缘节点发送的灰度结果，如果所述灰度结果符合要求，则在预设时间段之后向下一批边缘节点发送所述应用升级信息。在实施中，中心节点中可以预先保存判断灰度结果是否符合要求的判断策略，例如当当前批次的边缘节点中灰度结果正常的边缘节点的比例大于预设比例时，可以确定前批次边缘节点发送的灰度结果符合要求，则可以继续向下一批边缘节点发送所述应用升级信息。

如果当前批次边缘节点发送的灰度结果不符合要求，中心节点则可以向当前批次边缘节点发送回滚信息，从而使这些边缘节点将升级后的应用程序回滚至升级前的应用版本，即重新为原应用程序分配资源，启用原应用程序为用户提供服务。

本发明实施例使用灰度升级的方式分批次进行升级，首先利用少部分边缘节点进行升级测试，待测试成功后才进行下一批的升级，以确保升级无误，即使升级出现问题，也能够很快控制影响面。

基于与上述方法实施例相同的发明构思，本发明实施例还提供了一种应用程序的管理系统，该系统可以包括边缘节点以及中心节点。

其中，所述边缘节点，用于在本节点中配置应用容器引擎；接收所述中心节点发送的应用部署信息，基于所述应用部署信息从所述中心节点中下载包含相应应用程序的镜像，调用应用容器引擎加载所述镜像，并运行所述应用容器引擎中的所述应用程序，为所述应用容器引擎分配可用资源；

所述中心节点，用于向所述边缘节点发送所述应用部署信息。

优选的，所述中心节点，还用于：

接收客户端发送的包含所述应用程序的镜像；

接收所述客户端发送的所述应用部署请求，所述应用部署请求包括待部署应用的边缘节点范围；

基于所述应用部署请求生成应用部署信息；

向所述边缘节点发送所述应用部署信息。

优选的，所述应用部署请求包括部署批次以及每批次对应的边缘节点范围；

所述中心节点，用于基于所述应用部署请求向第一批次边缘节点发送所述应用部署信息；

所述边缘节点，用于基于所述应用部署信息完成应用部署之后，向所述中心节点发送应用部署结果以及应用运行情况；

所述中心节点，用于当基于所述应用部署结果以及应用运行情况，确定出当前批次边缘节点的应用部署符合要求，并且当前批次边缘节点不是最后一批次时，向下一批次边缘节点发送所述应用部署信息。

优选的，所述应用部署信息包括资源信息，所述资源信息包括为所述应用程序分配的各种资源的大小；

所述边缘节点，用于基于所述资源信息为所述应用容器引擎分配可用资源。

优选的，所述应用部署信息包括应用标识；

所述边缘节点，用于基于所述应用部署信息从所述中心节点中下载所述应用标识对应的镜像。

优选的，所述边缘节点，用于根据预设的调用策略调用空闲的应用容器引擎加载所述镜像。

优选的，所述边缘节点，用于按照固定周期向所述中心节点发送所述应用容器引擎的资源使用情况；

所述中心节点，用于接收所述应用容器引擎当前的资源使用情况，并判断所述应用容器引擎当前的资源使用情况是否符合要求，如果不符合，生成资源调整信息，并向所述边缘节点发送所述资源调整信息；

所述边缘节点，用于接收所述资源调整信息，并基于所述资源调整信息重新为所述应用容器引擎分配可用资源。

优选的，所述中心节点，用于向客户端发送所述应用容器引擎当前的资源使用情况，以使所述客户端基于所述资源使用情况，生成是否进行资源调整的指示信息，并向所述中心节点发送所述指示信息；

所述中心节点，用于接收所述指示信息，如果所述指示信息表明需要进行资源调整，则生成所述资源调整信息。

优选的，所述中心节点，用于：

接收客户端发送的应用升级请求，所述应用升级请求包括待升级的边缘节点范围；

基于所述应用升级请求，确定灰度升级策略，所述灰度升级策略包括灰度批次以及每批对应的边缘节点范围；

基于所述灰度升级策略分批向边缘节点发送所述应用升级信息。

优选的，所述边缘节点，用于：

接收所述中心节点发送的所述应用升级信息，并对所述应用程序进行升级；

在应用升级结束之后向所述中心节点发送灰度结果，所述灰度结果包括升级结果以及应用容器引擎服务状态信息。分从属

优选的，所述中心节点，用于：

基于所述灰度升级策略向第一批次边缘节点发送所述应用升级信息；

接收所述当前批次边缘节点发送的所述灰度结果，如果所述灰度结果符合要求，则在预设时间段之后向下一批边缘节点发送所述应用升级信息，并重复该步骤，直至所有批次边缘节点应用升级结束；

如果所述灰度结果不符合要求，则向所述当前批次边缘节点发送回滚信息，以使所述当前批次边缘节点将所述应用程序回滚至升级前的应用版本。分从属

优选的，所述边缘节点，用于：

接收所述中心节点发送的应用升级信息；

基于所述应用升级信息利用新应用容器引擎对所述应用程序进行升级；

如果应用升级成功，释放升级前为原应用容器引擎分配的可用资源。

优选的，所述中心节点用于对所述应用程序进行动态生命周期管理，其中，所述动态生命周期管理包括启动操作、停止操作以及重启操作。

本发明实施例将应用部署于应用容器引擎中，各个应用之间不相互干扰，实现了资源隔离，避免了应用之间的资源竞争，而且由于应用之间不相互干扰能够减少故障的发生，可靠性更强，并且应用容器引擎的可用资源可以通过合理分配，避免资源利用不均匀，在保证应用正常运行的情况下最大程度地减少资源分配，从而提高资源的利用率，节约成本，另外，在分配资源时，可以为边缘计算和系统加速分配所需要的资源，从而提高系统服务质量，同时由于采用应用容器引擎中进行应用部署，可以实现灰度、平滑升级，并可任意地对应用进行资源调度而无需中断服务。

需要说明的是：上述实施例提供的应用程序的管理系统与应用程序的管理方法的实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。