CN115202821A - 非云原生应用编排方法及其系统、电子设备、存储介质 - Google Patents

Abstract

本申请涉及云计算技术领域，尤其是涉及一种非云原生应用编排方法及其系统、电子设备、存储介质。本申请非云原生应用编排方法中，先获取编排控制指令以及应用特性信息。再基于应用特性信息在Kubernetes云平台中配置适配中间件，并将编排控制指令发送至适配中间件。进一步，经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令。最终基于目标编排指令对非云原生应用进行部署编排。本申请的非云原生应用编排方法，以适配中间件对编排控制指令进行处理，从而生成符合非云原生应用兼容适配特性的目标编排指令，使得Kubernetes云平台与非云原生应用之间的兼容适配问题得到解决。

Description

非云原生应用编排方法及其系统、电子设备、存储介质

技术领域

本申请涉及云计算技术领域，尤其是涉及一种非云原生应用编排方法及其系统、电子设备、存储介质。

背景技术

目前IT基础设施软件化已经成为了业界共识，而这一概念对应到实践上就是所谓的云原生基础架构，让IT基础设施从而具有了高度抽象、屏蔽底层细节、统一化的特征。云原生从字面意思上来看可以分成云和原生两个部分，其中，云是和本地相对的，传统的应用大多运行在本地服务器上，而现在流行的应用较多运行在云端。

Kubernetes(K8S)是为容器服务而生的一种可移植容器的编排管理技术。Kubernetes在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列功能。根据相关技术，将非云原生应用迁移到云原生环境，并经由Kubernetes对非云原生应用进行编排的过程中，往往会遇到兼容适配问题，即非云原生应用不适应Kubernetes对云原生基础资源管理的编排。因此，如何解决非云原生应用在云原生环境中的兼容适配，成为业内亟待解决的难题。

发明内容

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请提出一种非云原生应用编排方法及其系统、电子设备、存储介质，能够解决非云原生应用在云原生环境中的兼容适配问题。

根据本申请的第一方面实施例的非云原生应用编排方法，包括：

获取编排控制指令以及应用特性信息，所述编排控制指令由Kubernetes云平台生成，所述应用特性信息用于标识非云原生应用的兼容适配特性；

基于所述应用特性信息在所述Kubernetes云平台中配置适配中间件，并将所述编排控制指令递送至所述适配中间件；

经由所述适配中间件处理所述编排控制指令，生成符合所述非云原生应用兼容适配特性的目标编排指令；

基于所述目标编排指令对所述非云原生应用进行部署编排。

根据本申请的一些实施例，所述基于所述应用特性信息在所述Kubernetes云平台中配置适配中间件，包括：

从预设数据库中调用与所述应用特性信息匹配的功能脚本程序；

在所述适配中间件中设置钩子函数，并基于所述钩子函数将所述功能脚本程序引入所述适配中间件。

根据本申请的一些实施例，所述从预设数据库中调用与所述应用特性信息匹配的功能脚本程序之前，还包括：

获取预设脚本程序与多类预设适配信息，多类所述预设适配信息用于标识各种类型的兼容适配特性；

根据所述预设脚本程序与各类所述预设适配信息，形成各类预设脚本程序；

基于所述预设脚本程序与所述预设适配信息之间的映射关系，将各类所述预设脚本程序录入所述预设数据库。

根据本申请的一些实施例，所述从预设数据库中调用与所述应用特性信息匹配的功能脚本程序，包括：

获取与所述应用特性信息相匹配的所述预设适配信息；

基于与所述应用特性信息相匹配的所述预设适配信息，在所述预设数据库中筛选得到所述功能脚本程序，所述功能脚本程序为符合所述非云原生应用兼容适配特性的所述预设脚本程序。

根据本申请的一些实施例，所述在所述适配中间件中设置钩子函数，并基于所述钩子函数将所述功能脚本程序引入所述适配中间件，包括：

在所述适配中间件中对所述钩子函数进行声明；

对所述钩子函数进行声明之后，经由所述钩子函数中的command命令将所述功能脚本程序引入所述适配中间件。

根据本申请的一些实施例，所述经由所述适配中间件处理所述编排控制指令，生成符合所述非云原生应用兼容适配特性的目标编排指令，包括：

基于所述功能脚本程序，对所述编排控制指令的功能指令类型进行识别；

当所述功能指令类型与预设指令类型一致，执行所述功能脚本程序中的目标代码，生成所述目标编排指令。

根据本申请的一些实施例，所述预设指令类型为退出指令，所述基于所述目标编排指令对所述非云原生应用进行部署编排，包括：

基于所述目标编排指令，向所述非云原生应用发出关断预警信息，所述关断预警信息用于使所述非云原生应用执行数据保存操作；

当所述数据保存操作执行完毕，控制所述非云原生应用执行退出操作。

根据本申请的第二方面实施例的非云原生应用编排系统，包括：Kubernetes云平台、适配中间件、非云原生应用；

所述Kubernetes云平台，用于生成编排控制指令以及获取应用特性信息，并基于所述应用特性信息在所述Kubernetes云平台中配置所述适配中间件，所述应用特性信息用于标识非云原生应用的兼容适配特性；

所述适配中间件，用于处理所述编排控制指令，并生成符合所述非云原生应用兼容适配特性的目标编排指令，所述目标编排指令用于对所述非云原生应用进行部署编排；

所述非云原生应用，用于接收并执行所述目标编排指令。

第三方面，本申请实施例提供了一种电子设备，包括：存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如本申请第一方面实施例中任意一项所述的非云原生应用编排方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述存储介质存储有程序，所述程序被处理器执行实现如本申请第一方面实施例中任意一项所述的非云原生应用编排方法。

根据本申请实施例的非云原生应用编排方法及其系统、电子设备、存储介质，至少具有如下有益效果：

本申请非云原生应用编排方法中，先获取编排控制指令以及应用特性信息，编排控制指令由Kubernetes云平台生成，应用特性信息用于标识非云原生应用的兼容适配特性。再基于应用特性信息在Kubernetes云平台中配置适配中间件，并将编排控制指令发送至适配中间件。进一步，经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令。最终基于目标编排指令对非云原生应用进行部署编排。本申请的非云原生应用编排方法，以适配中间件对编排控制指令进行处理，从而生成符合非云原生应用兼容适配特性的目标编排指令，使得Kubernetes云平台与非云原生应用之间的兼容适配问题得到解决。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例提供的非云原生应用编排方法流程示意图；

图2为本申请实施例提供的功能脚本程序代码片段示意图；

图3为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图4为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图5为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图6为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图7为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图8为本申请实施例提供的非云原生应用编排方法另一流程示意图；

图9为本申请实施例提供的非云原生应用编排系统模块示意图；

图10为执行本申请实施例提供的非云原生应用编排方法的电子设备示意图。

具体实施方式

下面详细描述本申请的实施例，实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

在本申请的描述中，若干的含义是一个或者多个，多个的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。

在本申请的描述中，需要理解的是，涉及到方位描述，例如上、下、左、右、前、后等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示意性实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

本申请的描述中，需要说明的是，除非另有明确的限定，设置、安装、连接等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本申请中的具体含义。另外，下文中对于具体步骤的标识并不代表对于步骤顺序与执行逻辑的限定，各个步骤之间的执行顺序与执行逻辑应参照实施例所表述的内容进行理解与推定。

目前IT基础设施软件化已经成为了业界共识，而这一概念对应到实践上就是所谓的云原生基础架构，让IT基础设施从而具有了高度抽象、屏蔽底层细节、统一化的特征。云原生从字面意思上来看可以分成云和原生两个部分，其中，云是和本地相对的，传统的应用大多运行在本地服务器上，而现在流行的应用较多运行在云端。

Kubernetes(K8S)是为容器服务而生的一个可移植容器的编排管理工具。Kubernetes在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列功能，提高了大规模容器集群管理的便捷性和高可用性。根据相关技术，将非云原生应用迁移到云原生环境，并经由Kubernetes对非云原生应用进行编排的过程中，往往会遇到兼容适配问题，即非云原生应用不适应Kubernetes对云原生基础资源管理的编排。因此，如何解决非云原生应用在云原生环境中的兼容适配，成为业内亟待解决的难题。

需要说明的是，Kubernetes云平台是一个容器集群管理系统，提供以容器为中心的基础架构，用于让部署容器化的应用简单并且高效。Kubernetes云平台支持自动化部署、大规模可伸缩、应用容器化管理，在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes云平台中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。Kubernetes云平台具有可移植、可扩展、自动化等优点。其中，可移植指的是Kubernetes云平台支持公有云、私有云、混合云、多重云；可扩展指的是Kubernetes云平台支持模块化、插件化、可挂载、可组合；自动化指的是Kubernetes云平台支持自动部署、自动重启、自动复制、自动伸缩/扩展。Kubernetes云平台为应用供了部署、规划、更新、维护等机制。应理解，传统的应用部署方式是通过插件或脚本来安装应用，其缺点在于应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。而Kubernetes云平台则是通过部署容器方式实现对应用的部署编排，每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

根据本申请提供的一些实施例，在将基础资源托管给云原生平台后，需要将原先的非云原生应用迁移到云原生环境中。由于非云原生应用的非云原生属性，非云原生应用不会调用Kubernetes云平台的服务接口，也不会提供管理接口给Kubernetes云平台，故而非云原生应用无法充分利用Kubernetes云平台最为核心的编排管理能力，因此势必会产生非云原生应用在云原生环境中的兼容适配问题，即应用不适应云原生基础资源管理的方式。比如作为Kubernetes云平台核心的闭环控制带来的服务自动重启修复、资源异常后的自动再建，对于直接面向前端用户的非云原生应用来说，以上功能实现不了，意味着非云原生应用的使用过程中将不时发生闪退，从而影响用户体验。为了兼容适配云原生环境，一般都需要对非云原生应用进行改造，然而对于种类多样的非云原生应用进行改造将产生非常繁重的工作量，另外改造较早版本的非云原生应用所需要花费的重构成本也非常高。

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请提出一种非云原生应用编排方法及其系统、电子设备、存储介质，能够解决非云原生应用在云原生环境中的兼容适配问题。

下面以附图为依据作出进一步说明。

参照图1，根据本申请的第一方面实施例的非云原生应用编排方法，包括：

步骤S101，获取编排控制指令以及应用特性信息，编排控制指令由Kubernetes云平台生成，应用特性信息用于标识非云原生应用的兼容适配特性；

需要说明，编排控制指令指的是Kubernetes云平台为了编排部署非云原生应用而生成的控制指令。应用特性信息，指的是用于标识非云原生应用的兼容适配特性的信息。应理解，基于非云原生应用的组件类型、组件版本等方面的差异，对应的应用特性信息也会不同，例如Nginx(engine x)是一个HTTP和反向代理web服务器、Spring Boot是用于简化Spring应用的初始搭建以及开发过程的框架，其中Nginx与2.3版本之后的Spring Boot均支持优雅退出，而2.3版本之前的Spring Boot则不支持优雅退出，因此对应的应用特性信息也各自存在差异。需要明确，优雅退出指的是通过预先通知机制，在应用关闭前先清理资源、保存必要中间状态、持久化内存数据的退出模式。应理解，优雅退出模式的兼容适配仅仅是非云原生应用在云原生环境中面临的其中一类兼容适配问题，因此编排控制指令与应用特性信息的类型可以包括，但不限于上述举出的具体实施例。

步骤S102，基于应用特性信息在Kubernetes云平台中配置适配中间件，并将编排控制指令递送至适配中间件；

需要说明，中间件(Middleware)指的是介于应用系统和系统软件之间的一类软件，它使用系统软件所提供的基础服务(功能)，衔接网络上应用系统的各个部分或不同的应用，能够达到资源共享、功能共享的目的。中间件是基础软件的一大类，属于可复用软件的范畴。应理解，中间件在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在众多关于中间件的定义中，比较普遍被接受的是互联网数据中心(InternetData Center，IDC)表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。随着计算机技术的快速发展，更多的应用软件被要求在许多不同的网络协议、不同的硬件生产厂商以及不一样的网络平台和环境上运营。这导致了软件开发者需要面临数据离散、操作困难、系统匹配程度低，以及需要开发多种应用程序来达到运营的目的。所以，中间件技术的产生，在极大程度上减轻了开发者的负担，使得网络的运行更有效率。

根据本申请提供的一些实施例，为了解决非云原生应用在云原生环境中的兼容适配问题，需要基于应用特性信息在Kubernetes云平台中配置适配中间件，并将编排控制指令递送至适配中间件。由于应用特性信息指的是用于标识非云原生应用的兼容适配特性的信息，因此，基于应用特性信息能够在Kubernetes云平台中配置适配中间件，从而将适配中间件作为解决兼容适配问题的信息交互枢纽，进一步，将编排控制指令递送至适配中间件，以使得适配中间件对编排控制指令进行处理，生成符合非云原生应用兼容适配特性的目标编排指令。

步骤S103，经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令；

根据本申请提供的一些实施例，由于适配中间件是基于应用特性信息在Kubernetes云平台中配置得到的，因此以适配中间件来处理编排控制指令，能够在适配中间件的作用下，将编排控制指令转换为符合非云原生应用兼容适配特性的目标编排指令，从而进一步以目标编排指令对非云原生应用进行部署编排。需要说明的是，基于非云原生应用的组件类型、组件版本等方面的差异，对应的应用特性信息也会不同，故而基于应用特性信息在Kubernetes云平台中配置得到的适配中间件类型亦会不同。例如，Nginx与2.3版本之后的Spring Boot均支持优雅退出，那么基于应用特性信息在Kubernetes云平台中配置得到的适配中间件，则可以将编排控制指令直接翻译为Nginx或者2.3版本之后的SpringBoot能够识别的优雅退出执行语句，生成符合非云原生应用兼容适配特性的目标编排指令，即可解决非云原生应用在云原生环境中的兼容适配问题；又例如，2.3版本之前的Spring Boot不支持优雅退出，那么基于应用特性信息在Kubernetes云平台中配置得到的适配中间件，则需要在适配中间件中植入一段2.3版本之前的Spring Boot能够识别的优雅退出执行代码，从而生成符合非云原生应用兼容适配特性的目标编排指令，即可解决非云原生应用在云原生环境中的兼容适配问题。应理解，优雅退出模式的兼容适配仅仅是非云原生应用在云原生环境中面临的其中一类兼容适配问题，因此经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令，可以包括，但不限于上述举出的具体实施例。

步骤S104，基于目标编排指令对非云原生应用进行部署编排。

根据本申请提供的一些实施例，由于编排控制指令指的是Kubernetes云平台为了编排部署云原生应用生成的控制指令，而目标编排指令是由编排控制指令转换而成，并且目标编排指令符合非云原生应用兼容适配特性，因此，基于目标编排指令对非云原生应用进行部署编排能够解决非云原生应用在云原生环境中的兼容适配问题。

本申请非云原生应用编排方法中，先获取编排控制指令以及应用特性信息，编排控制指令由Kubernetes云平台生成，应用特性信息用于标识非云原生应用的兼容适配特性。再基于应用特性信息在Kubernetes云平台中配置适配中间件，并将编排控制指令发送至适配中间件。进一步，经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令。最终基于目标编排指令对非云原生应用进行部署编排。本申请的非云原生应用编排方法，以适配中间件对编排控制指令进行处理，从而生成符合非云原生应用兼容适配特性的目标编排指令，使得Kubernetes云平台与非云原生应用之间的兼容适配问题得到解决。

参照图2，根据本申请的一些实施例，基于应用特性信息在Kubernetes云平台中配置适配中间件，包括：

步骤S201，从预设数据库中调用与应用特性信息匹配的功能脚本程序；

根据本申请提供的一些实施例，预设数据库指的是预先设置的、用于储存各种预设适配信息的数据库。其中预设适配信息用于标识各种类型的兼容适配特性。应理解，基于非云原生应用的组件类型、组件版本等方面的差异，对应的预设适配信息也会不同，故而与预设适配信息对应的预设脚本程序亦会不同。需要说明的是，考虑到多种类型预设适配信息之间的差异，预设脚本程序的内部代码可以根据各种应用场景下的兼容适配需求预先设置。例如，针对支持信号量控制的非云原生应用，希望使其实现优雅退出，就可以发送信号量后令非云原生应用等待一段时间，再执行关闭操作；又例如，针对支持HTTP控制的非云原生应用，使用curl、wget等工具实现命令行请求中间件服务，这种场景需要在应用容器中提前打包好curl、wget等工具，或者，使用Kubernetes云平台的Pod单元初始化容器(initContainer)在启动的时候将curl、wget工具植入应用容器；再例如，对均不支持以上控制方式的非云原生应用，可以但不限于通过以下两种方式进行改造：其一，通过使用Pod单元的sidecar模式，在应用容器中增加一个sidecar容器，使用Nginx或者Evony代理应用容器的请求，在sidecar容器中植入预设脚本程序，借用代理网关的能力来实现，其二，构造合适的就绪探针(Readiness Probe)，通过脚本改变就绪探针的状态，使得实例在Service资源中离线来实现，其中Kubernetes云平台的Pod单元定时检查自定义的就绪探针的状态，如果返回状态失败，那么则不会将新的资源分发到该实例。需要说明的是，上述其一的方案，优势在于适用性强，改造方案统一，方便后续维护，缺点在于需要增加一个sidecar容器，增加了计算成本；而上述其二的方案，优点在于无需多余算力成本，劣势在于需要精心设计就绪探针的实现，使得钩子函数能够改变其探测状态，需要针对每个具体应用独立设计，根据应用场景，可以灵活选用上述提到的预设脚本程序设置方案。

应理解，预设脚本程序的设置方式可以包括，但不限于上述举出的具体实施例。

需要说明的是，功能脚本程序指的是用于解决Kubernetes云平台与非云原生应用之间的兼容适配问题的程序，应理解，功能脚本程序能够对编排控制指令进行处理，进而生成符合非云原生应用兼容适配特性的目标编排指令。本申请一些实施例中，需要预先根据应用特性信息，从从预设数据库中调用与应用特性信息匹配的预设脚本程序，再进一步将与应用特性信息匹配的预设脚本程序确定为功能脚本程序。应理解，功能脚本程序可以Shell脚本程序，也可以python脚本程序，还可以是其他类型的脚本程序。

步骤S202，在适配中间件中设置钩子函数，并基于钩子函数将功能脚本程序引入适配中间件。

根据本申请提供的一些实施例，钩子函数(Pod Hook)是能够感知容器生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。需要说明的是，钩子函数由Kubelet组件发起，在容器中的进程启动后或者容器中的进程终止前运行。其中，Kubelet组件是工作节点上的主要服务组件，用于定期从Kube-API Server组件接收新的或修改的Pod规范，并确保Pod单元及其容器在期望规范下运行，同时Kubelet组件作为工作节点的监控组件，向Kube-API Server汇报主机的运行状况。本申请一些实施例中，Kubernetes为我们提供了两种钩子函数：其一，PostStart钩子函数，这类钩子函数在容器创建后立即执行，但是并不能保证钩子将在容器入口点(Entrypoint)之前运行,因为没有参数传递给处理程序，主要用于资源部署、环境准备等，不过需要注意的是如果钩子花费太长时间以至于不能运行或者挂起,容器将不能达到运行状态。其二，PreStop钩子函数，这类钩子函数在容器终止之前立即被调用，它必须在删除容器的调用发出之前完成，主要用于优雅关闭应用程序、通知其他系统等，如果PreStop钩子函数在执行期间挂起，Pod单元将停留在运行状态并且不会达到运行失败状态。

参照图3示出的代码片段示意图，根据本申请一些较为具体的实施例，在适配中间件中设置钩子函数，并基于钩子函数将功能脚本程序引入适配中间件，例如可以在适配中间件中先引入example-grace.yaml，其中“example-grace”即为yaml文件的名称，yaml是一种专门用来写配置文件的语言，通过yaml语言编写的配置文件成为yaml文件；进一步，“Lifecycle”意指容器的生命周期，与PreStop钩子函数搭配使用，而“exec:command:[……]”即为exec指令，意指在容器内执行一次“command:[……]”命令。因此，通过图3示出的代码片段即可利用example-grace.yaml在适配中间件中设置PreStop钩子函数，并基于PreStop钩子函数将功能脚本程序在command:[……]中引入适配中间件。应理解，在适配中间件中设置钩子函数，并基于钩子函数将功能脚本程序引入适配中间件可以通过多种方式实现，可以包括，但不限于上述举出的具体实施例。

参照图4，根据本申请的一些实施例，从预设数据库中调用与应用特性信息匹配的功能脚本程序之前，还包括：

步骤S401，获取预设脚本程序与多类预设适配信息，多类预设适配信息用于标识各种类型的兼容适配特性；

根据本申请提供的一些实施例，预设数据库指的是预先设置的、用于储存各种预设适配信息的数据库。其中多类预设适配信息用于标识各种类型的兼容适配特性。应理解，基于非云原生应用的组件类型、组件版本等方面的差异，对应的预设适配信息也会不同，故而与预设适配信息对应的预设脚本程序亦会不同。需要明确，预设脚本程序指的是参照多类预设适配信息以及可能出现的各类应用场景预先设置的脚本程序。

步骤S402，根据预设脚本程序与各类预设适配信息，形成各类预设脚本程序；

根据本申请提供的一些实施例，考虑到多种类型预设适配信息之间的差异，预设脚本程序的内部代码可以根据各种应用场景下的兼容适配需求预先设置。例如，Nginx与2.3版本之后的Spring Boot均支持优雅退出，那么与预设适配信息对应形成的各类预设脚本程序则可以将用户输入的控制指令直接翻译为Nginx或者2.3版本之后的Spring Boot能够识别的优雅退出执行语句，即可解决非云原生应用在云原生环境中的兼容适配问题；又例如，2.3版本之前的Spring Boot不支持优雅退出，那么与预设适配信息对应形成的各类预设脚本程序则可以根据用户输入的控制指令在适配中间件中植入一段2.3版本之前的Spring Boot能够识别的优雅退出执行代码，从而解决非云原生应用在云原生环境中的兼容适配问题。根据本申请一些较为具体的实施例，对于2.3版本之后的Spring Boot，虽然支持优雅重启，然而通过功能脚本程序植入Spring Boot能够识别的优雅退出执行代码，来解决非云原生应用在云原生环境中的兼容适配问题，可以避免暴露acuator服务端点，以防止产生数据安全隐患。其原因在于，通过功能脚本程序来解决兼容适配问题可以通过配置限制服务端点等方式进行自定义配置，从而使得非原生应用能够只接受本地请求避免遭受外部安全隐患。

根据本申请提供的一些实施例，在预设脚本程序中进行自定义配置的过程可以参照各种应用场景下的兼容适配需求。例如，针对支持信号量控制的非云原生应用，希望使其实现优雅退出，就可以发送信号量后令非云原生应用等待一段时间，再执行关闭操作；又例如，针对支持HTTP控制的非云原生应用，使用curl、wget等工具实现命令行请求中间件服务，这种场景需要在应用容器中提前打包好curl、wget等工具，或者，使用Kubernetes云平台的Pod单元初始化容器(initContainer)在启动的时候将curl、wget工具植入应用容器；再例如，对均不支持以上控制方式的非云原生应用，可以但不限于通过以下两种方式进行改造：其一，通过使用Pod单元的sidecar模式，在应用容器中增加一个sidecar容器，使用Nginx或者Evony代理应用容器的请求，在sidecar容器中植入预设脚本程序，借用代理网关的能力来实现，其二，构造合适的就绪探针(Readiness Probe)，通过脚本改变就绪探针的状态，使得实例在Service资源中离线来实现，其中Kubernetes云平台的Pod单元定时检查自定义的就绪探针的状态，如果返回状态失败，那么则不会将新的资源分发到该实例。需要说明的是，上述其一的方案，优势在于适用性强，改造方案统一，方便后续维护，缺点在于需要增加一个sidecar容器，增加了计算成本；而上述其二的方案，优点在于无需多余算力成本，劣势在于需要精心设计就绪探针的实现，使得钩子函数能够改变其探测状态，需要针对每个具体应用独立设计，根据应用场景，可以灵活选用上述提到的预设脚本程序设置方案。应理解，根据预设脚本程序与各类预设适配信息，形成各类预设脚本程序可以包括，但不限于上述举出的具体实施例。

步骤S403，基于预设脚本程序与预设适配信息之间的映射关系，将各类预设脚本程序录入预设数据库。

根据本申请提供的一些实施例，为了从预设数据库中能够调用与应用特性信息匹配的功能脚本程序，预设数据库需要预先录入各种类型的预设适配信息、各种类型的预设脚本程序以及预设适配信息与预设脚本程序之间的映射关系。需要说明的是，基于非云原生应用的组件类型、组件版本等方面的差异，对应的预设适配信息也会不同，故而与预设适配信息对应的预设脚本程序亦会不同。需要说明的是，考虑到多种类型预设适配信息之间的差异，预设脚本程序的内部代码可以根据各种应用场景预先设置。因此，各种预设适配信息与对应预设脚本程序之间的映射关系是在对预设脚本程序的内部代码进行预先设置的过程中，即可获取。进一步，将预设脚本程序或者预设适配信息录入预设数据库，即可参照各种预设适配信息与对应预设脚本程序之间的映射关系，将各种类型的预设适配信息、各种类型的预设脚本程序以及预设适配信息与预设脚本程序之间的映射关系录入预设数据库。应理解，构建预设数据库的方式多种多样，包括但不限于上述举出的具体实施例。

参照图5，根据本申请的一些实施例，从预设数据库中调用与应用特性信息匹配的功能脚本程序，包括：

步骤S501，获取与应用特性信息相匹配的预设适配信息；

根据本申请提供的一些实施例，应用特性信息，指的是用于标识非云原生应用的兼容适配特性的信息。应理解，基于非云原生应用的组件类型、组件版本等方面的差异，对应的应用特性信息也会不同。由于预设数据库中预先存储有用于标识各种类型的兼容适配特性多类预设适配信息，因此，以非云原生应用对应的应用特性信息为线索，可在预设数据库中查询获取与应用特性信息相匹配的预设适配信息。故而，即可利用与应用特性信息相匹配的预设适配信息、预设脚本程序与预设适配信息之间的映射关系，在预设数据库中筛选得到功能脚本程序。

步骤S502，基于与应用特性信息相匹配的预设适配信息，在预设数据库中筛选得到功能脚本程序，功能脚本程序为符合非云原生应用兼容适配特性的预设脚本程序。

需要强调的是，基于非云原生应用的组件类型、组件版本等方面的差异，对应的预设适配信息也会不同，故而与预设适配信息对应的预设脚本程序亦会不同。需要说明的是，考虑到多种类型预设适配信息之间的差异，预设脚本程序的内部代码可以根据各种应用场景预先设置。因此，预设数据库中预先存储的多种预设脚本程序覆盖了可能出现的各类应用场景。又由于各类预设脚本程序与各类预设适配信息之间建立有映射关系，故而，利用与应用特性信息相匹配的预设适配信息、预设脚本程序与预设适配信息之间的映射关系，即可在预设数据库中筛选得到功能脚本程序。应理解，从预设数据库中调用与应用特性信息匹配的功能脚本程序的方式多种多样，可以包括，但不限于上述举出的具体实施例。

参照图3、图6，根据本申请的一些实施例，在适配中间件中设置钩子函数，并基于钩子函数将功能脚本程序引入适配中间件，包括：

步骤S601，在适配中间件中对钩子函数进行声明；

根据本申请提供的一些实施例，钩子函数(Pod Hook)是能够感知容器生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。需要说明的是，钩子函数由Kubelet组件发起，在容器中的进程启动后或者容器中的进程终止前运行。其中，Kubelet组件是工作节点上的主要服务组件，用于定期从Kube-API Server组件接收新的或修改的Pod规范，并确保Pod单元及其容器在期望规范下运行，同时Kubelet组件作为工作节点的监控组件，向Kube-API Server汇报主机的运行状况。本申请一些较为优选的实施例中，选用PreStop钩子函数作为本申请实施例中将功能脚本程序引入适配中间件的钩子函数。

参照图3示出的代码片段示意图，根据本申请一些较为具体的实施例，适配中间件中对PreStop钩子函数进行的声明，需要在yaml文件中进行，故而，可以通过“example-grace.yaml：……”此种形式的代码，作为对PreStop钩子函数进行声明固定语句，另外，对PreStop钩子函数进行声明的固定语句还包括“Lifecycle”，Lifecycle意指容器的生命周期。需要说明的是，PreStop钩子函数支持，但不限于使用如下三种方式定义动作：exec指令，指的是在容器内执行一次命令；tcpSocket，指的是在当前容器尝试访问指定的socket；httpGet，指的是在当前容器中向某url发起HTTP请求。本申请一些实施例中，将exec指令与PreStop钩子函数进行组合，组合成了图3示出的代码片段。应理解，在适配中间件中对钩子函数进行声明的方式多种多样，可以包括，但不限于上述举出的具体实施例。

步骤S602，对钩子函数进行声明之后，经由钩子函数中的command命令将功能脚本程序引入适配中间件。

需要说明的是，对钩子函数进行声明之后，经由钩子函数中的command命令将功能脚本程序引入适配中间件，可以如图3所示出的代码片段，在适配中间件中先引入example-grace.yaml，其中“example-grace”即为yaml文件的名称；进一步，将“Lifecycle”作为对PreStop钩子函数进行声明的固定语句，与PreStop钩子函数搭配使用，而“exec:command:[……]”即为exec指令，exec指令与PreStop钩子函数进行组合，意指在容器在容器终止之前执行一次“command:[……]”命令。因此，通过图3示出的代码片段即可对钩子函数进行声明，并且在声明之后，经由PreStop钩子函数中的command命令将功能脚本程序引入适配中间件。应理解，“command:[……]”之中的“……”即为需要引入的功能脚本程序。应理解，将功能脚本程序引入适配中间件可以通过多种方式实现，可以包括，但不限于上述举出的具体实施例。

参照图7，根据本申请的一些实施例，经由适配中间件处理编排控制指令，生成符合非云原生应用兼容适配特性的目标编排指令，包括：

步骤S701，基于功能脚本程序，对编排控制指令的功能指令类型进行识别；

步骤S702，当功能指令类型与预设指令类型一致，执行功能脚本程序中的目标代码，生成目标编排指令。

根据本申请提供的一些实施例，功能脚本程序指的是用于解决Kubernetes云平台与非云原生应用之间的兼容适配问题的程序，应理解，功能脚本程序能够对编排控制指令进行处理，进而生成符合非云原生应用兼容适配特性的目标编排指令。本申请一些实施例中，需要预先根据应用特性信息，从从预设数据库中调用与应用特性信息匹配的预设脚本程序，再进一步将与应用特性信息匹配的预设脚本程序确定为功能脚本程序。需要说明的是，基于非云原生应用的组件类型、组件版本等方面的差异，对应的预设适配信息也会不同，故而与预设适配信息对应的预设脚本程序亦会不同。故而，根据应用特性信息，从从预设数据库中匹配得到的预设脚本程序，能够将编排控制指令转换为符合非云原生应用兼容适配特性的目标编排指令，因此从从预设数据库中匹配得到的预设脚本程序即为能够解决非云原生应用与Kubernetes云平台之间兼容适配问题的功能脚本程序。需要明确，编排控制指令的功能指令类型，指的是编排控制指令的所述类别。例如，当编排控制指令为Kubernetes云平台为了使非云原生应用能够执行优雅退出，而对其进行编排部署的控制指令，则对应的功能指令类型即为优雅退出类型；又例如，当编排控制指令为Kubernetes云平台为了使非云原生应用能够避免暴露acuator服务端点，而对其进行编排部署的控制指令，则对应的功能指令类型即为本地请求类型。应理解，对编排控制指令的功能指令类型进行识别、功能指令类型的分类不限于上述举出的具体实施例。

需要说明的是，对编排控制指令的功能指令类型进行识别的目的在于，根据编排控制指令，从预设数据库中找到对应的预设脚本程序作为功能脚本程序，从而进一步通过功能脚本程序执行功能脚本程序中的目标代码，生成符合非云原生应用兼容适配特性的目标编排指令。

参照图8，根据本申请的一些实施例，预设指令类型为退出指令，基于目标编排指令对非云原生应用进行部署编排，包括：

步骤S801，基于目标编排指令，向非云原生应用发出关断预警信息，关断预警信息用于使非云原生应用执行数据保存操作；

步骤S802，当数据保存操作执行完毕，控制非云原生应用执行退出操作。

根据本申请提供的一些实施例，优雅退出指的是通过预先通知机制，在应用关闭前先清理资源、保存必要中间状态、持久化内存数据的退出模式。具体而言，优雅退出模式下，当Kubernetes云平台生成的编排控制指令为退出指令，则编排控制指令递送至适配中间件，经由适配中间件根据应用特性信息配置得到的功能脚本程序对编排控制指令进行处理，从而生成目标编排指令，当基于目标编排指令对非云原生应用进行部署编排时，非云原生应用首先接收到的是关断预警信息，其中断预警信息用于使非云原生应用执行数据保存操作，之后当数据保存操作执行完毕，再进一步控制非云原生应用执行退出操作，从而解决非云原生应用与Kubernetes云平台之间，关于优雅退出模式的兼容适配问题。本申请一些较为具体的实施例中，判断数据保存操作执行是否完毕的条件，可以是预先设置一段执行时间，当执行时间届满则视作数据保存操作执行完毕；还可以是预先在功能脚本程序设置响应机制，当数据保存操作执行完毕则适配中间件将受到响应信号，收到响应信号则视作数据保存操作执行完毕。应理解，判断数据保存操作执行是否完毕有多种方式，包括但不限于上述举出的具体实施例。

参照图9，根据本申请的第二方面实施例的非云原生应用编排系统900，包括：Kubernetes云平台901、适配中间件902、非云原生应用903；

Kubernetes云平台901，用于生成编排控制指令以及获取应用特性信息，并基于应用特性信息在Kubernetes云平台901中配置适配中间件902，应用特性信息用于标识非云原生应用903的兼容适配特性；

适配中间件902，用于处理编排控制指令，并生成符合非云原生应用903兼容适配特性的目标编排指令，目标编排指令用于对非云原生应用903进行部署编排；

非云原生应用903，用于接收并执行目标编排指令。

图10示出了本申请实施例提供的电子设备1000。电子设备1000包括：处理器1001、存储器1002及存储在存储器1002上并可在处理器1001上运行的计算机程序，计算机程序运行时用于执行上述的非云原生应用编排方法。

处理器1001和存储器1002可以通过总线或者其他方式连接。

存储器1002作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本申请实施例描述的非云原生应用编排方法。处理器1001通过运行存储在存储器1002中的非暂态软件程序以及指令，从而实现上述的非云原生应用编排方法。

存储器1002可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序。存储数据区可存储执行上述的非云原生应用编排方法。此外，存储器1002可以包括高速随机存取存储器1002，还可以包括非暂态存储器1002，例如至少一个储存设备存储器件、闪存器件或其他非暂态固态存储器件。在一些实施方式中，存储器1002可选包括相对于处理器1001远程设置的存储器1002，这些远程存储器1002可以通过网络连接至该电子设备1000。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实现上述的非云原生应用编排方法所需的非暂态软件程序以及指令存储在存储器1002中，当被一个或者多个处理器1001执行时，执行上述的非云原生应用编排方法，例如，执行图1中的方法步骤S101至步骤S104、图2中的方法步骤S201至步骤S202、图4中的方法步骤S401至步骤S403、图5中的方法步骤S501至步骤S502、图6中的方法步骤S601至步骤S602、图7中的方法步骤S701至步骤S702、图8中的方法步骤S801至步骤S802。

本申请实施例还提供了计算机可读存储介质，存储有计算机可执行指令，计算机可执行指令用于执行上述的非云原生应用编排方法。

在一实施例中，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令被一个或多个控制处理器执行，例如，执行图1中的方法步骤S101至步骤S104、图2中的方法步骤S201至步骤S202、图4中的方法步骤S401至步骤S403、图5中的方法步骤S501至步骤S502、图6中的方法步骤S601至步骤S602、图7中的方法步骤S701至步骤S702、图8中的方法步骤S801至步骤S802。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、储存设备存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。还应了解，本申请实施例提供的各种实施方式可以任意进行组合，以实现不同的技术效果。

以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的共享条件下还可作出种种等同的变形或替换，这些等同的变形或替换均包括在本申请权利要求所限定的范围内。

Claims (10)

1.一种非云原生应用编排方法，其特征在于，包括：

获取编排控制指令以及应用特性信息，所述编排控制指令由Kubernetes云平台生成，所述应用特性信息用于标识非云原生应用的兼容适配特性；

基于所述应用特性信息在所述Kubernetes云平台中配置适配中间件，并将所述编排控制指令递送至所述适配中间件；

经由所述适配中间件处理所述编排控制指令，生成符合所述非云原生应用兼容适配特性的目标编排指令；

基于所述目标编排指令对所述非云原生应用进行部署编排。

2.根据权利要求1所述的方法，其特征在于，所述基于所述应用特性信息在所述Kubernetes云平台中配置适配中间件，包括：

从预设数据库中调用与所述应用特性信息匹配的功能脚本程序；

在所述适配中间件中设置钩子函数，并基于所述钩子函数将所述功能脚本程序引入所述适配中间件。

3.根据权利要求2所述的方法，其特征在于，所述从预设数据库中调用与所述应用特性信息匹配的功能脚本程序之前，还包括：

获取预设脚本程序与多类预设适配信息，多类所述预设适配信息用于标识各种类型的兼容适配特性；

根据所述预设脚本程序与各类所述预设适配信息，形成各类预设脚本程序；

基于所述预设脚本程序与所述预设适配信息之间的映射关系，将各类所述预设脚本程序录入所述预设数据库。

4.根据权利要求3所述的方法，其特征在于，所述从预设数据库中调用与所述应用特性信息匹配的功能脚本程序，包括：

获取与所述应用特性信息相匹配的所述预设适配信息；

基于与所述应用特性信息相匹配的所述预设适配信息，在所述预设数据库中筛选得到所述功能脚本程序，所述功能脚本程序为符合所述非云原生应用兼容适配特性的所述预设脚本程序。

5.根据权利要求2至4任一项所述的方法，其特征在于，所述在所述适配中间件中设置钩子函数，并基于所述钩子函数将所述功能脚本程序引入所述适配中间件，包括：

在所述适配中间件中对所述钩子函数进行声明；

对所述钩子函数进行声明之后，经由所述钩子函数中的command命令将所述功能脚本程序引入所述适配中间件。

6.根据权利要求2至4任一项所述的方法，其特征在于，所述经由所述适配中间件处理所述编排控制指令，生成符合所述非云原生应用兼容适配特性的目标编排指令，包括：

基于所述功能脚本程序，对所述编排控制指令的功能指令类型进行识别；

当所述功能指令类型与预设指令类型一致，执行所述功能脚本程序中的目标代码，生成所述目标编排指令。

7.根据权利要求6所述的方法，其特征在于，所述预设指令类型为退出指令，所述基于所述目标编排指令对所述非云原生应用进行部署编排，包括：

基于所述目标编排指令，向所述非云原生应用发出关断预警信息，所述关断预警信息用于使所述非云原生应用执行数据保存操作；

当所述数据保存操作执行完毕，控制所述非云原生应用执行退出操作。

8.一种非云原生应用编排系统，其特征在于，包括：Kubernetes云平台、适配中间件、非云原生应用；

所述Kubernetes云平台，用于生成编排控制指令以及获取应用特性信息，并基于所述应用特性信息在所述Kubernetes云平台中配置所述适配中间件，所述应用特性信息用于标识非云原生应用的兼容适配特性；

所述适配中间件，用于处理所述编排控制指令，并生成符合所述非云原生应用兼容适配特性的目标编排指令，所述目标编排指令用于对所述非云原生应用进行部署编排；

所述非云原生应用，用于接收并执行所述目标编排指令。

9.一种电子设备，其特征在于，包括：存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7中任意一项所述的非云原生应用编排方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现如权利要求1至7中任意一项所述的非云原生应用编排方法。

Images