CN114035823A - 一种业务服务的更新方法及装置 - Google Patents

Abstract

本申请提出了一种业务服务的更新方法及装置，用以解决现有技术中，由于更新服务带来的响应延迟的问题。该方法包括：管理节点接收更新指令；更新指令用于指示将提供业务服务功能的应用进行更新；管理节点向业务节点发送第一pod的配置文件和延迟指示信息；第一pod的配置文件用于提供给业务节点创建第一pod；延迟指示信息用于指示业务节点在完成创建第一pod的设定时间后删除第二pod，以及用于指示业务节点若在完成创建第一pod后的设定时间内接收到请求，则按照设定比例为第一pod和第二pod分配请求；其中，第一pod用于提供更新后的业务服务功能，第二pod用于提供更新前的业务服务功能。

Description

一种业务服务的更新方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及一种业务服务的更新方法及装置。

背景技术

在云平台集群环境下，例如Kubernetes的容器云集群下，服务的版本迭代频繁，需要经常对服务进行滚动升级。云平台集群下，业务服务滚动升级的过程是：创建并部署用于提供新的业务服务的新版本实例(pod)，删除用于提供旧的业务服务的旧版本pod。新版本的pod部署完成后，将由新版本的pod接收来自外部请求提供服务。但是，由于新版本的pod在启动之初，即新版本的pod在接收到第一个请求时，需要从新的业务服务的配置文件中将响应请求所需的类加载到内存中，加载类之后才可以响应请求提供服务。这就导致了在新版本的pod启动之初，会出现响应延迟的问题。

目前的解决方案是新版本的pod在启动之初会请求更多的处理资源，以降低响应时延。但是新版本的pod只有在启动之初才需要较多的处理资源，类加载完成之后就不再需要过多的请求资源了，所以现有的方案会导致处理资源浪费的问题。

发明内容

本申请实施例提供了一种业务服务的更新方法及装置，用以解决现有技术中，由于更新服务带来的响应延迟的问题。

第一方面，本申请实施例提供了一种业务服务的更新方法，包括：

管理节点接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

所述管理节点向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示所述业务节点在完成创建所述第一pod的设定时间后删除第二pod，以及用于指示所述业务节点若在完成创建所述第一pod后的设定时间内接收到请求，则按照设定比例为所述第一pod和所述第二pod分配所述请求；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

基于上述方案，在进行业务服务功能的更新时，在业务节点完成创建用于提供新的业务服务功能的新版本的pod之后，先不删除旧版本的pod，而是在一定的时间内由两个版本的pod共同接收请求，既保证新版本的pod完成加载响应请求所需的类，使得新版本的pod后续可以正常提供服务。也通过旧版本的pod继续响应请求，避免了由于响应延迟导致影响用户使用体验的问题。另外，上述方案也解决了由于现有技术中采用通过获取更多的处理资源来解决响应延迟，导致资源浪费的问题。

第二方面，本申请实施例提供了另一种业务服务的更新方法，包括：

业务节点接收管理节点在更新提供业务服务功能的应用时发送的第一pod的配置文件和延迟指示信息；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

所述业务节点根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

第三方面，本申请实施例提供了一种业务服务的更新装置，所述装置为管理节点，或者所述装置应用于管理节点，所述装置包括：

接收单元，用于接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

发送单元，用于向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示所述业务节点在完成创建所述第一pod的设定时间后删除第二pod，以及用于指示所述业务节点若在完成创建所述第一pod后的设定时间内接收到请求，则按照设定比例为所述第一pod和所述第二pod分配所述请求；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

第四方面，本申请实施例提供了另一种业务服务的更新装置，所述装置为业务节点，或者所述装置应用于业务节点，所述装置包括：

接收单元，用于接收管理节点在更新提供业务服务功能的应用时发送的第一pod的配置文件和延迟指示信息；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

处理单元，用于根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

第五方面，本申请实施例提供了一种业务服务更新系统，包括：

管理节点，用于接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

所述管理节点，还用于向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

所述业务节点，用于所述管理节点发送的第一pod的配置文件和延迟指示信息；

所述业务节点，还用于根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

在一些实施例中，所述延迟指示信息是根据所述业务服务功能的类型确定的。

在一些实施例中，所述管理节点，在向所述业务节点发送第一pod的配置文件和延迟指示信息之前，还用于：

确定所述业务节点为所述管理节点所管理的业务节点中负载最小的业务节点。

在一些实施例中，所述业务节点，还用于：

在所述第一pod创建完成后的设定时间内，若接收到请求，则按照所述设定比例为所述第一pod和所述第二pod分配所述请求。

第六方面，本申请实施例提供了另一种业务服务更新装置，包括存储器以及处理器；

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序执行第一方面或者第二方面的任一实现方式中的方法。

第七方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行上述方法。

另外，第二方面至第七方面中任一种实现方式所带来的技术效果可参见第一方面不同实现方式所带来的技术效果，此处不再赘述。

附图说明

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

图1为本申请实施例提供的一种业务服务更新系统的架构示意图；

图2为本申请实施例提供的一种业务服务的更新方法流程示意图；

图3为本申请实施例提供的另一种业务服务的更新方法流程示意图；

图4为本申请实施例提供的一种用于提供业务服务更新方法的装置结构示意图；

图5为本申请实施例提供的一种业务服务更新装置的结构示意图。

具体实施方式

为使本申请的目的、实施方式和优点更加清楚，下面将结合本申请示例性实施例中的附图，对本申请示例性实施方式进行清楚、完整地描述，显然，所描述的示例性实施例仅是本申请一部分实施例，而不是全部的实施例。

基于本申请描述的示例性实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请所附权利要求保护的范围。此外，虽然本申请中公开内容按照示范性一个或几个实例来介绍，但应理解，可以就这些公开内容的各个方面也可以单独构成一个完整实施方式。

需要说明的是，本申请中对于术语的简要说明，仅是为了方便理解接下来描述的实施方式，而不是意图限定本申请的实施方式。除非另有说明，这些术语应当按照其普通和通常的含义理解。

图1示出了本申请提供的一种业务服务更新系统的架构示意图。应理解，本申请实施例并不限于图1所示的系统中，此外，图1中的装置可以是硬件，也可以是从功能上划分的软件或者以上二者结合后的结构。如图1所示，本申请提供的业务服务更新系统中包括管理节点100，业务节点200，终端设备300，以及业务节点200中包括的第一pod210和第二pod220。第一pod中包含至少一个容器以及第二pod中包含至少一个容器。需要说明的是，本申请对于业务服务更新系统中包括的业务节点的数量不作具体限定，即管理节点100可以管理多个业务节点，在图1中仅以业务节点200为例进行介绍。本申请对于业务节点200中包括的pod的数量，以及每个pod中包括的容器的数量也不作具体限定。

首先，管理节点100的功能包括：管理和维护系统中包含的业务节点以及每个业务节点中包括的至少一个pod、系统中的任务调配(即根据业务节点的资源剩余情况，完成任务的部署，以实现系统中各个业务节点负载均衡)、提供服务接口(API Server)以及保存系统中各个节点的配置信息和负载变化情况等等。本申请提出的管理节点100的功能可以由服务器来实现，也可以由服务器集群来实现，本申请对此不作具体限定。可选地，管理节点100中还可以包含多种组件，用以实现上述功能，例如：

(1)服务接口：可选地，服务接口可以是API server，后续将以API server为例进行介绍。负责对外提供Restful接口服务，管理节点100中的其他组件可以通过API server实现各自的功能，例如，通过API server实现监控各个业务节点的负载情况，或者通过APIserver实现pod或者容器的删除、新增或者查看等操作。

(2)状态存储(ETCD)：一个采用键值对的方式存储数据的数据库，用于保存系统中所有的网络配置和资源对象的状态信息(例如，某一个业务节点的剩余资源情况)，也就是保存了整个系统的状态。

(3)调度器(Scheduler)：用于监控新建pod副本信息，并通过资源调度算法为需要部署的该新建pod选择一个最合适的业务节点进行部署。部署成功之后，会将pod的信息与其部署的业务节点的信息进行绑定，并存储在ETCD中。

(4)控制器管理组件(Controller Manager)：负责管理执行各种功能的控制器(controller)。controller负责维护系统的状态，例如故障检测、自动扩展或者滚动升级等。例如，当系统中某个节点上部署的某一个pod的状态发生变化，controller是可以监测到的。

其次，业务节点200，用于为多个pod(或者可以说多个容器)提供运行环境，主要的功能包括：负责pod的创建、启停等操作，负责将接收到的请求转发到具体地某一个pod上。需要说明的是，业务节点200的功能也可以由一个服务器或者服务器集群来实现。可选地，业务节点200中还可以包括用于实现上述功能的组件，例如：

(1)代理组件(比如可以是kubelet)：负责监听和管理各个pod的生命周期，还用于实现pod的创建、删除、启动或者停止等操作。

(2)请求转发组件(kube-proxy)：负责将接收到的请求转发到具体的某一个pod上。

进一步地，第一pod210(或者第二pod220)为系统中的最小运行单元，一个pod中可以包含一个容器，也可以包含多个容器。用于接收来自终端的业务请求，实现对应的业务服务功能。

图1中涉及的终端设备300，又称之为终端、移动台(Mobile Station，MS)、移动终端(Mobile Terminal，MT)等，是一种向用户提供语音和/或数据连通性的设备，例如，具有无线连接功能的手持式设备、车载设备等。目前，一些终端的举例为：手机(mobile phone)、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(Mobile Internet Device，MID)、可穿戴设备，虚拟现实(Virtual Reality，VR)设备、增强现实(Augmented Reality，AR)设备、工业控制(Industrial Control)中的无线终端、无人驾驶(self driving)中的无线终端、远程手术(remote medical surgery)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端等。

需要说明的是，图1仅作为一种示例，本申请对于业务服务更新系统中包含的管理节点、业务节点、终端设备、pod以及容器的数量不作具体限定。后续为了便于描述，将管理节点100简称为管理节点、将业务节点200简称为业务节点、将终端设备300简称为终端设备、将第一pod210以及第二pod220分别简称为第一pod和第二pod。

相关技术中，在云平台环境下，提供某一项业务服务功能的应用在进行更新时，需要创建用于提供新的业务服务功能的新版本pod，然后将旧版本的pod删除，由新版本的pod接收请求提供服务。但是新版本的pod在最初启动时，需要将响应请求所需的类加载到内存中，加载类会消耗一定的时间，导致响应延迟，降低用户的使用体验。

本申请实施提供了一种业务服务的更新方法及装置，在用于提供新的业务服务功能的新版本pod创建完成后，延迟删除旧版本的pod。在新版本的pod创建完成的设定时间内，若接收到来自终端设备的请求，则根据设定的比例为新、旧两个版本的pod分配请求，为新版本的pod分配较少的请求使得新版本的pod可以根据这些请求将响应请求所需的类加载完成。同时，由旧版本的pod接收大部分的请求，不会延迟响应，不影响用户正常使用。

首先，为了理解本申请提出的业务服务的更新方案，参见图2，为本申请实施例提供的一种业务服务的更新方法流程图，具体包括：

201，管理节点接收更新指令。

可选地，更新指令可以是运维人员下发到管理节点的。所述更新指令可以用于指示将提供某一项业务服务的应用整体进行更新，或者更新该应用的某一部分功能。例如，以应用A为例，更新指令可以用于指示将应用A的每一项业务服务功能都进行更新，也可以将应用A中具体的某一项服务进行更新。

202，管理节点向业务节点发送第一pod的配置文件和延迟指示信息。

其中，第一pod的配置文件是提供给业务节点来创建第一pod的，第一pad是用于提供更新后的业务服务功能的。延迟指示信息是用于向业务节点指示延迟删除用于提供更新之前的旧版本业务服务功能的第二pod的。需要说明的是，用于提供更新后的业务服务功能的pod可以有多个，本申请实施例中仅以一个为例，即以第一pod为例进行介绍。同理，用于提供更新前的业务服务功能的pod也可以有多个，本申请以第二pod为例进行介绍。

可选地，延迟指示信息中可以包括设定时间和设定比例。作为一种举例，设定时间可以是用于指示业务节点在第一pod创建完成后的设定时间内删除第二pod。例如，设定时间为10秒钟，则业务节点可以在完成创建第一pod的10秒钟后删除第二pod。可选地，设定比例可以用于指示业务节点在完成创建第一pod的设定时间内按照设定比例为第一pod和第二pod分配接收到的请求。例如，设定时间为10秒钟，设定比例为1000:1(第二pod：第一pod)，则业务节点若在完成创建第一pod后的10秒钟内接收到请求，比如接收到1001个请求，则将1000个请求发送到第二pod来处理，将1个请求发送到第一pod来处理。

203，业务节点接收第一pod的配置文件和延迟指示信息，并根据第一pod的配置文件创建第一pod。

204，业务节点根据延迟指示信息在完成创建第一pod的设定时间后删除第二pod。

在一些实施例中，若业务节点在完成创建第一pod的设定时间内接收到来自终端设备的请求，则可以按照设定比例为第一pod和第二pod分配请求。在达到设定时间后，则将第二pod删除，将之后来自终端设备的所有请求全部发送到第一pod进行处理。

可选地，业务节点在删除第二pod之前，还可以先从路由中将第二pod剔除，即停止由第二pood接收请求。

基于上述方案，在进行业务服务功能的更新时，在业务节点完成创建用于提供新的业务服务功能的新版本的pod之后，先不删除旧版本的pod，而是在一定的时间内由两个版本的pod共同接收请求，既保证新版本的pod完成加载响应请求所需的类，使得新版本的pod后续可以正常提供服务。也通过旧版本的pod继续响应请求，避免了由于响应延迟导致影响用户使用体验的问题。

作为一种可选的方式，管理节点在向其管理的某一个业务节点下发第一pod的配置文件之前，可以首先确定该业务节点为其所管理的所有的业务节点中负载最小的业务节点。例如，可以由管理节点中的调度器来获取第一pod的信息，比如第一pod所需的处理资源和内存，然后根据资源调度算法将选取一个负载最小的业务节点作为用于部署第一pod的业务节点，然后将第一pod的配置文件发送到该业务节点中。

基于上述方案，管理节点将新的pod部署到所管理的所有的业务节点中负载最小的业务节点中，可以保证所管理的所有的业务节点负载均衡，避免一个或几个业务节点中部署太多的pod，导致这些节点接收到的请求过程，响应请求较慢的问题。

可选地，管理节点在确定好业务节点后，将新版本的pod发送到该业务节点的同时也可以将延迟指示信息发送到该节点中。延迟指示信息中包括设定时间和设定比例，指示业务节点在创建根据新的pod的配置文件完成创建新的pod之后的设定时间内，按照设定比例为新、旧pod分配来自终端设备的请求。而在设定时间内，新的pod可以根据接收到的一部分请求将响应请求所需的类加载到内存中。例如，以新的pod的配置文件是采用Java语言编写的为例，创建的新的pod即为Java虚拟机(Java Virtual Machine，JVM)的形式，JVM在响应请求时，需要首先加载响应请求所需的类，然后才能响应请求提供服务。基于本申请提出的方案，JVM可以在启动后的设定时间内根据接收到的部分请求加载类。当然，上述场景仅作为一种举例，本申请提出的方案对于采用其他语言编写的应用也同样适用。以延迟指示信息来保证不会出现响应延迟的同时可以使得新版本的应用达到最高性能。

在一些实施例中，延迟指示信息中可以包括设定时间和设定比例，延迟指示信息可以是根据业务服务功能设定的。可选地，不同类型的业务服务功能可以对应不同的设定时间和设定比例。作为一种举例，某一个应用的功能A使用比较频繁，则在该应用功能A进行更新时，其对应的设定时间可以较短，设定比例可以较大。例如，可以将设定时间设置为5秒钟，将设定比例设置为10000:1(旧版本的pod接收的请求：新版本的pod接收的请求)。作为另一种举例，该应用的功能B使用的频率较低，则可以在功能B进行更新时，其对应的设定时间可以较长，设定比例可以较小，以保证接收到足够的请求以使新版本的pod可以完成加载类的过程。作为一种可能实现的方式，每一个部署在云平台集群下的应用中的每一项功能都可以有对应的设定时间和设定比例，在任意一项功能启动更新时，可以自动触发其对应的设定时间和设定比例。

基于上述方案，不同的业务类型对应不同的设定时间和设定比例，对于使用比较频繁、请求较多的功能配置较短的设定时间和较大的设定比例，保证尽快由新版本的pod提供服务。对于使用不频繁、请求较少的功能配置较长的设定时间和较小的设定比例，保证新版本的pod能够完成加载类的过程。

下面，为了更进一步理解本申请提出的方案，结合管理节点和业务节点中的各个组件对本申请的方案进行具体介绍。关于管理节点和业务节点中各个组件的介绍可以参见上述图1中的具体介绍，在此不再进行赘述。参见图3，为本申请实施例提供的另一种业务服务更新方法流程图，具体包括：

301，API server接收更新指令。

其中，更新指令用于指示将某一个业务服务功能进行更新。

可选地，所述更新指令可以是运维人员下发的，例如可以是运维人员触发滚动升级时生成的。在一些实施例中，API server接收到的更新指令还可以携带有用于创建新版本的pod的配置文件，新版本的pod可以提供更新后的业务服务功能。为了便于描述，在本实施例中，将新版本的pod简称为第一pod，将用于提供更新前的业务服务功能的旧版本的pod简称为第二pod。

302，Scheduler从多个业务节点中确定用于部署第一pod的业务节点，将第一pod的配置文件和延迟指示信息发送到该业务节点。

可选地，Scheduler可以根据多个节点的负载情况以及第一pod所需的处理资源和内存，确定将要部署第一pod的业务节点，然后将第一pod的配置文件发送到该业务节点。

进一步地，Scheduler还可以获取与待更新的业务服务功能对应的延迟指示信息，即设定时间和设定比例。然后将延迟指示信息也发送到确定的第一pod。

303，kubelet接收第一pod的配置文件，根据第一pod的配置文件创建第一pod。

可选地，kubelet在完成创建第一pod之后还可以对第一pod进行健康检查，例如检查第一pod是否可以正常接受请求。

需要说明的是，执行步骤303的kubelet是Scheduler确定的用于部署第一pod的业务节点的kubelet。

304，kube-proxy接收延迟指示信息，根据延迟指示信息在第一pod启动的设定时间内为第一pood和第二pod分配请求。

具体地，若kube-proxy在第一pod启动后的设定时间内接收到请求，则按照延迟指示信息中包括的设定比例为第一pod和第二pod分配请求，具体详细的介绍可以参见上述实施例，在此不再进行详述。

需要说明的是，执行步骤304的kube-proxy是Scheduler确定的用于部署第一pod的业务节点的kube-proxy。

305，在第一pod启动的设定时间后，kube-proxy将接收到的请求全部发送到第一pod。

306，在第一pod启动的设定时间后，kubelet将第二pod删除。

需要说明的是，步骤305和步骤306可以没有先后顺序，可以先执行步骤305，也可以先执行步骤306，本申请对此不作具体限定。

基于与上述方法的同一构思，参见图4，为本申请实施例提供的一种用于实现业务服务更新的装置400。装置400可以执行上述方法中的任一步骤，为了避免重复，不再进行详述。装置400包括：接收单元401、发送单元402和处理单元403。

在一种可能实现的场景下：

接收单元401，用于接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

发送单元402，用于向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示所述业务节点在完成创建所述第一pod的设定时间后删除第二pod，以及用于指示所述业务节点若在完成创建所述第一pod后的设定时间内接收到请求，则按照设定比例为所述第一pod和所述第二pod分配所述请求；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

在一些实施例中，所述延迟指示信息是根据所述业务服务功能的类型确定的。

在一些实施例中，所述装置还包括：

处理单元403，用于在发送单元402向业务节点发送第一pod的配置文件和延迟指示信息之前，确定所述业务节点为所述管理节点所管理的业务节点中负载最小的业务节点。

在另一些可能实现的场景下：

接收单元401，用于接收管理节点在更新提供业务服务功能的应用时发送的第一pod的配置文件和延迟指示信息；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

处理单元403，用于根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

在一些实施例中，所述处理单元403，还用于：

在所述第一pod创建完成后的设定时间内，若接收到请求，则按照所述设定比例为所述第一pod和所述第二pod分配所述请求。

在一些实施例中，所述延迟指示信息是根据所述业务服务功能的类型确定的。

本申请实施例还提供另一种业务服务更新装置500，参见图5。本申请实施例中的装置500还可以包括通信接口503，该通信接口503例如是网口，电子设备可以通过该通信接口503传输数据，例如通信接口503可以实现上述图4中的接收单元401和发送单元402的功能。

存储器502，用于存储程序指令。处理器501，用于调用所述存储器502中存储的程序指令，按照获得的程序执行上述实施例中提出的任一方法。例如，处理器501可以用于实现上述图4中的处理单元403所实现的功能。

本申请实施例中不限定上述处理器501、存储器502以及通信接口503之间的具体连接介质，比如总线，总线可以分为地址总线、数据总线、控制总线等。

其中，处理器501是电子设备的控制中心，可以利用各种接口和线路连接整个电子设备的各个部分，通过运行或执行存储在存储器502内的指令以及调用存储在存储器502内的数据。可选的，处理器501可包括一个或多个处理单元，处理器501可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器501中。在一些实施例中，处理器501和存储器502可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器501可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的数据统计平台所执行的步骤可以直接由硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器502作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器502可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器502是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。本申请实施例中的存储器502还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

通过对处理器501进行设计编程，例如，可以将前述实施例中介绍的神经网络模型的训练方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行前述的神经网络模型训练方法的步骤，如何对处理器501进行设计编程为本领域技术人员所公知的技术，这里不再赘述。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种业务服务的更新方法，其特征在于，包括：

管理节点接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

所述管理节点向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示所述业务节点在完成创建所述第一pod的设定时间后删除第二pod，以及用于指示所述业务节点若在完成创建所述第一pod后的设定时间内接收到请求，则按照设定比例为所述第一pod和所述第二pod分配所述请求；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

2.如权利要求1所述的方法，其特征在于，所述延迟指示信息是根据所述业务服务功能的类型确定的。

3.如权利要求1或2所述的方法，其特征在于，所述管理节点在向所述业务节点发送第一pod的配置文件和延迟指示信息之前，所述方法还包括：

确定所述业务节点为所述管理节点所管理的业务节点中负载最小的业务节点。

4.一种业务服务的更新方法，其特征在于，包括：

业务节点接收管理节点在更新提供业务服务功能的应用时发送的第一pod的配置文件和延迟指示信息；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

所述业务节点根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

在所述第一pod创建完成后的设定时间内，所述业务节点在接收到请求时，按照所述设定比例为所述第一pod和所述第二pod分配所述请求。

6.如权利要求4或5所述的方法，其特征在于，所述延迟指示信息是根据所述业务服务功能的类型确定的。

7.一种业务服务的更新装置，其特征在于，包括：

接收单元，用于接收更新指令；所述更新指令用于指示将提供业务服务功能的应用进行更新；

发送单元，用于向业务节点发送第一pod的配置文件和延迟指示信息；所述第一pod的配置文件用于提供给所述业务节点创建第一pod；所述延迟指示信息用于指示所述业务节点在完成创建所述第一pod的设定时间后删除第二pod，以及用于指示所述业务节点若在完成创建所述第一pod后的设定时间内接收到请求，则按照设定比例为所述第一pod和所述第二pod分配所述请求；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

8.如权利要求7所述的装置，其特征在于，所述延迟指示信息是根据所述业务服务功能的类型确定的。

9.一种业务服务更新装置，其特征在于，包括：

接收单元，用于接收管理节点在更新提供业务服务功能的应用时发送的第一pod的配置文件和延迟指示信息；所述延迟指示信息用于指示在第一pod创建完成后的设定时间内按照设定比例调整所述第一pod和第二pod的处理资源；

处理单元，用于根据所述第一pod的配置文件创建所述第一pod，并根据所述延迟指示信息在完成创建所述第一pod的设定时间后，删除所述第二pod；

其中，所述第一pod用于提供更新后的业务服务功能，所述第二pod用于提供更新前的业务服务功能。

10.如权利要求9所述的装置，其特征在于，所述处理单元，还用于：

在所述第一pod创建完成后的设定时间内，若接收到请求，则按照所述设定比例为所述第一pod和所述第二pod分配所述请求。

Images