一种应用处理方法、装置、设备及可读存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用处理方法、装置、设备及可读存储介质。

背景技术

在金融领域，随着业务大规模的容器化部署，容器化应用也越来越多。容器化应用主要用于实现应用的编排和生命周期控制。在现有Kubernetes资源管理方式中，Statefulset控制器所采用的更新模式是滚动更新的方案。也就是说，控制器在接收到更新请求之后,按照启动时间从晚到早的顺序，依次更新应用的实例。

在实际应用中，在应用的发布的过程中，有可能发现某个应用出现问题。在这种情况下，现有的方法无法对此种情况进行处理，从而导致了发布的应用无法满足正常的业务需求。

发明内容

本申请实施例提供一种应用处理方法、装置、设备及可读存储介质，以保证发布的应用能够满足业务的需求。

第一方面，本申请实施例提供了一种应用处理方法，包括：

接收对目标应用的更新请求；

根据所述更新请求，生成验证实例；

对所述验证实例进行验证；

在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；

发布所述待发布实例。

第二方面，本申请实施例还提供一种应用处理装置，包括：

第一接收模块，用于接收对目标应用的更新请求；

第一生成模块，用于根据所述更新请求，生成验证实例；

第一验证模块，用于对所述验证实例进行验证；

第二生成模块，用于在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；

发布模块，用于发布所述待发布实例。

第三方面，本申请实施例还提供一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的程序，所述处理器执行所述程序时实现如上所述的应用处理方法中的步骤。

第四方面，本申请实施例还提供一种应用处理方法，其特征在于，包括：

接收对目标应用的更新请求；

根据所述更新请求，修改所述目标应用的元数据信息；

根据修改后的所述目标应用的元数据信息，生成验证实例；

对所述验证实例进行验证；

在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；

发布所述待发布实例。

第五方面，本申请实施例还提供一种应用处理系统，包括：云管控系统和控制器；

其中，所述云管控系统，用于接收对目标应用的更新请求；根据所述更新请求，修改所述目标应用的元数据信息；所述控制器，用于根据修改后的所述目标应用的元数据信息，生成验证实例；对所述验证实例进行验证；在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；发布所述待发布实例。

第六方面，本申请实施例还提供一种可读存储介质，所述可读存储介质上存储程序，所述程序被处理器执行时实现如上所述的应用处理方法中的步骤。

在本申请实施例中，当接收到对目标应用的更新请求后，生成验证实例，并在对验证实例的验证通过之后，再根据验证实例生成待发布实例并验证。因此，利用本申请实施例的方案，由于在发布之前利用验证实例进行了验证，因此，可使得生成的待发布实例更符合业务需求。

附图说明

图1是本申请实施例提供的应用处理方法的流程图之一；

图2是本申请实施例提供的应用处理系统的示意图；

图3是本申请实施例提供的应用处理方法的过程示意图；

图4是本申请实施例提供的应用处理装置的结构图。

具体实施方式

本申请实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

本申请实施例中术语“多个”是指两个或两个以上，其它量词与之类似。

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

参见图1，图1是本申请实施例提供的应用处理方法的流程图，如图1所示，包括以下步骤：

步骤101、接收对目标应用的更新请求。

其中，所述目标应用可以指的是任意的应用。当需要更新某个应用时，用户可通过云管控系统触发对该应用的更新。当收到该更新请求后，云管控系统对该应用的元数据信息进行修改，并将修改后的元数据信息发送给控制器。相应的，控制器接收到对目标应用的更新请求，并从云管控系统获取到该目标应用修改后的元数据信息。

步骤102、根据所述更新请求，生成验证实例。

在本申请实施例中，生成的验证实例是与该更新请求相对应的，也即，验证实例需要满足该更新请求的要求。Kubernetes是一个跨主机集群的、开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作,提供以容器为中心的基础架构。因此，在本申请实施例中，具体的，可根据所述更新请求，调用Kubernetes的API(Application ProgrammingInterface，应用程序接口)生成所述验证实例。其中，生成验证实例的方法可参照现有技术的方式实现。

步骤103、对所述验证实例进行验证。

具体的，在此步骤中，可运行所述验证实例，获得运行结果。由于更新的目的是使得实例能符合业务的新要求，因此，在本申请实施例中，可主要以验证实例的运行结果是否符合业务需求为基础来判断是否验证通过。如果符合目标业务的需求时，对所述验证实例的验证通过；当所述运行结果不符合目标业务的需求时，对所述验证实例的验证不通过。通过这种方式，可使得发布的实例更符合业务的需求。

此外，还可有其他的验证方式。比如，通过直接访问实例IP:端口的方式或者直接查看验证实例的启动日志是否正常的方式，来验证验证实例是否正常等。

由于仅启动了验证实例，因此，可以在对线上业务影响最小的情况下进行功能验证，从而减少了对应用的影响，使得应用更加稳定。

步骤104、在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的。

其中，所述待发布实例的个数和所述目标应用在接收到所述更新请求时具有的实例的个数相同。

其中，目标应用在接收到所述更新请求时具有的实例，也可以理解为目标应用在未更新前已经具有的实例的个数。例如，假设目标应用在此次未更新前具有3个实例，那么，在此生成的待发布实例的个数为3。

其中，生成待发布实例的个数和生成验证实例的方式相同。由于验证实例是符合业务的需求的，那么，在此生成的待发布实例也是符合业务的需求的。生成的待发布实例可用于进行灰度测试。此时，待发布实例是不需处理业务请求的。

步骤105、发布所述待发布实例。

在发布新版本实例的过程中，新、旧版本的实例同时运行。当有业务请求时，这些业务请求将会分配到这些实例上。在本申请实施例中，在发布实例的过程中，可根据预先的配置选择逐一的发布实例，或者是批量发布多个实例。在批量发布的情况下，还可根据用户的选择控制每次发布的实例的个数等。

具体的，逐一的发布实例时，如果所述待发布实例为多个，那么，可分别发布所述待发布实例中的每个第一待发布实例，并分别关闭每个第二待发布实例，其中，所述第二待发布实例为所述目标应用更新前已有的实例中，与所述第一待发布实例对应的实例。也就是说，第一待发布实例是更新后的第二待发布实例。通过这种方式，可避免对业务的影响，平滑地将业务迁移到新发布的版本的实例上，对用户零感知。而且，在这种方式下，在发布的过程中，由于是逐一发布，因此，如果发现某个实例出现问题，还可快速的实现回滚。

例如，假设目标应用更新前已有的实例为dp1，dp2，dp3，更新后分别对应为dp11，dp21，dp31。那么，在发布的过程中，可先发布dp11，并关闭dp1。在此，关闭dp1的作用在于不使其处理业务请求。那么，原本分配到dp1的请求将被分配到dp11。接着可发布dp21，并关闭dp2，发布dp31，并关闭dp3。

具体的，批量发布实例时，如果所述待发布实例为多个，那么，在发布待发布实例的时候，可同时发布多个待发布实例，然后再同时关闭多个旧版本的实例。具体的，同时发布所述待发布实例中的至少两个第一待发布实例，并关闭第二待发布实例，其中，所述第二待发布实例为，所述目标应用更新前已有的实例中，与所述第一待发布实例对应的实例。通过这种方式，可同时实现对多个实例的更新，而且，在发布的过程中可减少发布过程的耗时，减少了实例个数对发布过程的影响。

例如，假设目标应用更新前已有的实例为dp1，dp2，dp3，更新后分别对应为dp11，dp21，dp31。那么，在发布的过程中，可同时发布dp11，dp21，dp31，并同时关闭dp1，dp2，dp3；或者，还可同时发布dp11，dp21，并同时关闭dp1，dp2，之后，再发布dp31，关闭dp3。

此外，为了节省系统空间，还可删除所述第二待发布实例和/或所述验证实例。也就是说，在新版本的实例发布之后，可删除老版本的实例以及验证实例。

可选的，在上述实施例的基础上，在步骤101之后，还可获取所述目标应用的当前运行信息，然后，根据所述更新请求，获取所述目标应用的待更新的信息。之后，将所述当前运行信息和所述待更新的信息进行比对，根据比对结果确定是否更新所述目标应用。其中，所述运行信息可以包括实例的版本信息，运行结果信息等。那么，步骤102具体为，当所述比对结果表示所述当前运行信息和所述待更新的信息不同时，根据所述更新请求，生成验证实例。通过这种方式，可避免对目标应用无用的更新，从而节约资源。

在本申请实施例中，当接收到对目标应用的更新请求后，生成验证实例，并在对验证实例的验证通过之后，再根据验证实例生成待发布实例并验证。因此，利用本申请实施例的方案，由于在发布之前利用验证实例进行了验证，因此，可使得生成的待发布实例更符合业务需求。

在上述实施例的基础上，在对所述验证实例的验证不通过时，可重新利用所述目标应用的已有实例处理业务请求。通过这种方式，可在发布之前实现实例的回滚，从而提高发布的成功率。

参见图2，图2是本申请实施例提供的应用处理系统的示意图。该系统可包括：云管控系统201和控制器202。

其中，所述云管控系统201，用于接收对目标应用的更新请求；根据所述更新请求，修改所述目标应用的元数据信息；所述控制器202，用于根据修改后的所述目标应用的元数据信息，生成验证实例；对所述验证实例进行验证；在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；发布所述待发布实例。

实际应用中，当需要更新某个应用时，用户可通过云管控系统触发对该应用的更新。当收到该更新请求后，云管控系统对该应用的元数据信息进行修改，并将修改后的元数据信息通过调用Kubernetes的API server(服务器)的方式发送给控制器。相应的，控制器从云管控系统获取到该目标应用修改后的元数据信息。

在本申请实施例中，控制器202是以Kubernetes CRD(Custom ResourceDefinition，定制资源定义)的形式实现一种自定义资源管理器，具体的，在本申请实施例中，通过Kubernetes的资源类型apiextensions定义了一种自定义资源管理器。控制器202可以通过Kubernetes的消息通知机制,从云管控系统获取到该应用修改后的元数据以及修改前的元数据。控制器202通过对比修改前后的元数据，即可确定应用是需要更新版本或者修改资源大小。如需进行更新，控制器202通过调用Kubernetes实例生命周期的接口来更新每个实例的版本或者资源,达到控制实例生命周期的目的。

结合图3，假设某个应用具有三个实例，dp1，dp2，dp3。三个实例的流量为打开状态，可接收业务请求。当需要更新时，控制器将生成一个验证实例，该验证实例的后缀名例如可以是dp0。之后，运行该验证实例。控制器通过直接访问实例IP：端口的方式，或者通过查看实例启动日志是否正常的方式，来确定验证实例的启动是否正常，功能是否达到预期。此时，验证实例不处理业务请求，也即关闭验证实例的流量。

当验证实例的验证通过后，此时，用户可通过云管控系统发送发布指令。根据该发布指令，可同时生成多个新版本的实例，其中，新版本实例的个数和旧版本实例的个数相同。在此实施例中，假设对应于dp1，dp2，dp3，生成的新版本的实例为dp4，dp5，dp6。生成的新版本的实例，可用于进行灰度测试，以保证实例运行结果的可靠性。生成新版本的实例后，响应于发布指令，分别发布dp4，dp5，dp6，并同时关闭旧版本的实例。例如，在发布dp4之后，可关闭dp1；发布dp5之后，可关闭dp2；发布dp6之后，可关闭dp3。通过这种方式，可将业务平滑的过渡到新版本的实例上，从而降低了对用户的影响。之后，还可删除dp0，dp1，dp2，dp3。

当然，在发布的过程也可同时发布dp4，dp5，dp6，并关闭dp1，dp2，dp3。此时，可使得发布的过程不受实例个数的影响。

如果验证实例的验证不通过，那么，还可控制回滚到旧版本的实例上，从而仍由旧版本实例处理业务请求。

在本申请实施例中，当接收到对目标应用的更新请求后，生成验证实例，并在对验证实例的验证通过之后，再根据验证实例生成待发布实例并验证。因此，利用本申请实施例的方案，由于在发布之前利用验证实例进行了验证，因此，可使得生成的待发布实例更符合业务需求。由于在验证过程中只是对验证实例进行验证，因此，可以在对线上业务影响最小的情况下进行功能验证，使得应用更加稳定。

此外，本申请实施例还提供了一种应用处理方法，包括：

步骤301、接收对目标应用的更新请求。

步骤302、根据所述更新请求，修改所述目标应用的元数据信息。

其中，所述目标应用可以指的是任意的应用。当需要更新某个应用时，用户可通过云管控系统触发对该应用的更新。当收到该更新请求后，云管控系统对该应用的元数据信息进行修改，并将修改后的元数据信息发送给控制器。

步骤303、根据修改后的所述目标应用的元数据信息，生成验证实例。

控制器从云管控系统获取到该目标应用修改后的元数据信息，生成验证实例。

步骤304、对所述验证实例进行验证。

步骤305、在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；

步骤306、发布所述待发布实例。

其中，步骤303-步骤306的具体过程可参照前述实施例102-步骤105的描述。

在本申请实施例中，当接收到对目标应用的更新请求后，生成验证实例，并在对验证实例的验证通过之后，再根据验证实例生成待发布实例并验证。因此，利用本申请实施例的方案，由于在发布之前利用验证实例进行了验证，因此，可使得生成的待发布实例更符合业务需求。由于在验证过程中只是对验证实例进行验证，因此，可以在对线上业务影响最小的情况下进行功能验证，使得应用更加稳定。

本申请实施例还提供了一种应用处理装置。参见图4，图4是本申请实施例提供的应用处理装置的结构图。如图4所示，应用处理装置400包括：

第一接收模块401，用于接收对目标应用的更新请求；第一生成模块402，用于根据所述更新请求，生成验证实例；第一验证模块403，用于对所述验证实例进行验证；第二生成模块404，用于在对所述验证实例的验证通过时，生成待发布实例，其中，所述待发布实例是根据所述验证实例生成的；发布模块405，用于发布所述待发布实例。

可选的，所述第一生成模块402，用于根据所述更新请求，调用Kubernetes的API生成所述验证实例。

可选的，所述第一验证模块403包括：运行子模块，用于运行所述验证实例，获得运行结果；验证子模块，用于当所述运行结果符合目标业务的需求时，对所述验证实例的验证通过；当所述运行结果不符合目标业务的需求时，对所述验证实例的验证不通过。

可选的，所述待发布实例的个数和所述目标应用在接收到所述更新请求时具有的实例的个数相同。

可选的，所述发布模块405用于，分别发布所述待发布实例中的每个第一待发布实例，并分别关闭每个第二待发布实例，其中，所述第二待发布实例为，所述目标应用更新前已有的实例中，与所述第一待发布实例对应的实例。

可选的，所述发布模块405用于，同时发布所述待发布实例中的至少两个第一待发布实例，并关闭第二待发布实例，其中，所述第二待发布实例为，所述目标应用更新前已有的实例中，与所述第一待发布实例对应的实例。

可选的，所述装置还可包括：删除所述第二待发布实例和/或所述验证实例。

可选的，所述装置还可包括：第一获取模块，用于获取所述目标应用的当前运行信息；第二获取模块，用于根据所述更新请求，获取所述目标应用的待更新的信息；第一确定模块，用于将所述当前运行信息和所述待更新的信息进行比对，根据比对结果确定是否更新所述目标应用。此时，所述第一生成模块，用于当所述比对结果表示所述当前运行信息和所述待更新的信息不同时，根据所述更新请求，生成验证实例。

可选的，所述装置还可包括：第一处理模块，用于在对所述验证实例的验证不通过时，重新利用所述目标应用的已有实例处理业务请求。

本申请实施例提供的装置，可以执行上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。

需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例还提供一种电子设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的程序，所述处理器执行所述程序时实现如上所述的应用处理方法中的步骤。

本申请实施例还提供一种可读存储介质，可读存储介质上存储有程序，该程序被处理器执行时实现上述应用处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的可读存储介质，可以是处理器能够存取的任何可用介质或数据存储设备，包括但不限于磁性存储器(例如软盘、硬盘、磁带、磁光盘(MO)等)、光学存储器(例如CD、DVD、BD、HVD等)、以及半导体存储器(例如ROM、EPROM、EEPROM、非易失性存储器(NAND FLASH)、固态硬盘(SSD))等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。根据这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁盘、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。