基于Kubernetes架构的工作流处理方法、装置

技术领域

本申请涉及工作流技术领域，更具体地说，涉及一种基于Kubernetes架构的工作流处理方法、装置及一种电子设备和一种计算机可读存储介质。

背景技术

在基于Kubernetes架构的容器云管理平台中，由于Kubernetes本身并没有对应的工作流模块，类似的云管理平台在实现工作流处理时，通常的做法是在系统中通过业务代码集成第三方的工作流引擎，不仅需要耗费人力成本编写业务代码，还会造成业务代码与工作流引擎之间的耦合。

因此，如何解决上述问题是本领域技术人员需要重点关注的。

发明内容

本申请的目的在于提供一种基于Kubernetes架构的工作流处理方法、装置及一种电子设备和一种计算机可读存储介质，实现了工作流引擎与业务代码的解耦。

为实现上述目的，本申请提供了一种基于Kubernetes架构的工作流处理方法，应用于工作流引擎，所述方法包括：

通过云管理平台接收用户终端发起的工作流程；

根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；

通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；

根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。

可选的，所述工作流单元的创建过程包括：

获取所述用户终端发送的针对所述工作流单元的资源参数，所述资源参数包括CPU、内存、副本数和环境变量；

接收为所述工作流单元选择的包含对应业务逻辑的容器镜像，完成所述工作流单元的创建。

可选的，所述工作流单元还包括有标识信息，所述标识信息用于表示所述工作流单元的运行状态，包括运行中、运行成功、运行失败和运行暂停。

可选的，所述预设工作流序列的创建过程包括：

基于整个工作流过程为每一步选择对应的工作流单元；

对所有所述工作流单元的执行顺序和各个所述工作流单元对应的执行逻辑进行设置，完成所述预设工作流序列的创建。

可选的，所述基于整个工作流过程为每一步选择对应的工作流单元，包括：

利用预设的可视化界面对系统已有的工作流单元以及所述用户终端上传的工作流单元进行显示；

通过所述可视化界面，接收所述用户终端下发的选择指令，所述选择指令用于针对工作流过程中的每一步选择对应的工作流单元。

可选的，所述根据所述工作流程查找并启动对应的工作流单元，包括：

根据所述工作流程，确定每一步对应的所述工作流单元；

对各个所述工作流单元执行启动操作，在启动过程中将各个所述工作流单元对应的工作流ID及创建时间基于annotation的形式注入到所述工作流单元中；

相应的，所述根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程之前，还包括：

确定所述状态变化结果对应的目标工作流单元，解析所述目标工作流单元的annotation信息，以获取所述目标工作流单元对应的所述预设工作流序列。

为实现上述目的，本申请提供了一种基于Kubernetes架构的工作流处理装置，应用于工作流引擎，所述装置包括：

流程接收模块，用于通过云管理平台接收用户终端发起的工作流程；

单元启动模块，用于根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；

状态接收模块，用于通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；

流程控制模块，用于根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。

可选的，还包括：

工作流单元创建模块，用于获取所述用户终端发送的针对所述工作流单元的资源参数，所述资源参数包括CPU、内存、副本数和环境变量；接收为所述工作流单元选择的包含对应业务逻辑的容器镜像，完成所述工作流单元的创建。

为实现上述目的，本申请提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现前述公开的任一种基于 Kubernetes架构的工作流处理方法的步骤。

为实现上述目的，本申请提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述公开的任一种基于Kubernetes架构的工作流处理方法的步骤。

通过以上方案可知，本申请提供的一种基于Kubernetes架构的工作流处理方法，该方法应用于工作流引擎，包括：通过云管理平台接收用户终端发起的工作流程；根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。由上可知，本申请将于Kubernetes中的job资源作为基本的工作流单元，无需编写代码集成第三方工作流引擎，实现了工作流引擎与业务代码的解耦。另外，通过订阅 Kubernetes的监听机制，获取工作流单元的状态变化以驱动工作流的流转，当某个工作流单元状态发生变化后，工作流引擎可以立即响应，而不是被动等待底层同步信息，加快了工作流的效应速度，提高了工作流引擎的工作效率。

本申请还公开了一种基于Kubernetes架构的工作流处理装置及一种电子设备和一种计算机可读存储介质，同样能实现上述技术效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请。

附图说明

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

图1为本申请实施例公开的一种基于Kubernetes架构的工作流处理方法的流程图；

图2为本申请实施例公开的一种创建工作流单元的流程示意图；

图3为本申请实施例公开的一种创建工作流序列的流程示意图；

图4为本申请实施例公开的一种具体的工作流处理系统的架构图；

图5为本申请实施例公开的一种基于Kubernetes架构的工作流处理装置的结构图；

图6为本申请实施例公开的一种电子设备的结构图；

图7为本申请实施例公开的另一种电子设备的结构图。

具体实施方式

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

在传统基于Kubernetes架构的容器云管理平台中，在实现工作流处理时，通常的做法是在系统中通过业务代码集成第三方的工作流引擎，不仅需要耗费人力成本编写业务代码，还会造成业务代码与工作流引擎之间的耦合。

因此，本申请实施例公开了一种基于Kubernetes架构的工作流处理方法，实现了工作流引擎与业务代码的解耦，同时提高了工作流引擎的工作效率。

参见图1所示，本申请实施例公开的一种基于Kubernetes架构的工作流处理方法，该方法应用于工作流引擎，具体包括：

S101：通过云管理平台接收用户终端发起的工作流程；

本申请实施例中，可通过云管理平台接收用户终端发起的工作流程。

S102：根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；

在具体实施中，可根据用户终端发起的工作流程查找对应的工作流单元，并启动对应的工作流单元。其中，上述工作流单元可以基于Kubernetes中的 job资源实现，其具体为整个工作流过程中每一步运行的最小逻辑单元。

需要指出的是，上述工作流单元的创建过程可以具体包括：获取用户终端发送的针对工作流单元的资源参数，所述资源参数包括CPU、内存、副本数和环境变量；接收为工作流单元选择的包含对应业务逻辑的容器镜像，完成工作流单元的创建。

作为一种优选的实施方式，本申请实施例中的工作流单元还包括有标识信息，该标识信息用于表示工作流单元的运行状态，包括运行中、运行成功、运行失败和运行暂停。

具体地，上述基于整个工作流过程为每一步选择对应的工作流单元时，可以利用预设的可视化界面对系统已有的工作流单元以及用户终端上传的工作流单元进行显示；进而可以通过可视化界面，接收用户终端下发的选择指令，所述选择指令用于针对工作流过程中的每一步选择对应的工作流单元，从而可为工作流程中的每一步选择对应的工作流单元。

需要说明的是，在根据所述工作流程查找并启动对应的工作流单元的过程中，可以首先根据工作流程，确定每一步对应的工作流单元；对各个工作流单元执行启动操作，在启动过程中将各个所述工作流单元对应的工作流ID 及创建时间基于annotation的形式注入到工作流单元中。相应的，根据上述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程之前，还包括：可确定所述状态变化结果对应的目标工作流单元，解析所述目标工作流单元的annotation信息，以获取所述目标工作流单元对应的所述预设工作流序列。

S103：通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；

本申请实施例中，工作流引擎可订阅Kubernetes架构中原生的监听机制，通过该监听机制，即可自动向工作流引擎推送工作流单元的状态变化结果。

S104：根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。

可以理解的是，当工作流引擎接收到工作流单元的状态变化结果之后，可根据当前的状态变化结果，获取对应的预设工作流序列，进而根据预设工作流序列进行工作流控制处理，例如启动下一个工作流程、回退至上一个工作流程或者结束整个工作流程等。

上述预设工作流序列的创建过程可以包括：基于整个工作流过程为每一步选择对应的工作流单元；对所有工作流单元的执行顺序和各个工作流单元对应的执行逻辑进行设置，完成预设工作流序列的创建。

通过以上方案可知，本申请提供的一种基于Kubernetes架构的工作流处理方法，该方法应用于工作流引擎，包括：通过云管理平台接收用户终端发起的工作流程；根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。由上可知，本申请将于Kubernetes中的job资源作为基本的工作流单元，无需编写代码集成第三方工作流引擎，实现了工作流引擎与业务代码的解耦。另外，通过订阅 Kubernetes的监听机制，获取工作流单元的状态变化以驱动工作流的流转，当某个工作流单元状态发生变化后，工作流引擎可以立即响应，而不是被动等待底层同步信息，加快了工作流的效应速度，提高了工作流引擎的工作效率。

下面通过一种具体的示例对本申请实施例提供的基于Kubernetes架构的工作流处理方法进行介绍。具体地，首先创建工作流单元，即整个工作流过程中每一步运行的最小的逻辑单元。在本申请实施例中，可基于Kubernetes 的job设计工作流单元，在每一个工作流单元中，除了本身工作流单元的业务逻辑之外，需要额外定义成功标志。创建工作流单元时，用户需要填写job对应的资源参数，如cpu、内存、副本数，启动命令、环境变量并选择包含对应业务逻辑的容器镜像，即可创建一个工作流单元。当工作流单元运行以后，云管理系统会根据工作流单元的成功标志或者退出机制，动态的改变工作流单元的状态。其中，工作流单元状态有运行中、运行成功、运行失败、运行暂停等。

参见图2所示，可具体通过上传容器镜像或上传jar包/war包的方式设置工作流单元，以构成容器镜像，生成工作流单元并可保存在云管理平台的存储中心。由于工作流单元基于k8s的容器镜像创建，因此实现了工作流单元与编程语法、运行环境之间的解耦，云管理平台无需关心工作流单元的编译、运行、业务逻辑等。

在云管理平台中，用户可以通过自定义的形式创建工作流序列。具体地，参见图3所示，创建工作流序列时主要包含两部分：为每一步选择工作流单元，如图3中设置工作流单元1，其中，在每一步中工作流单元均可以以图形化的方式选择用户已经上传的工作流单元；编写工作流的中每一步的工作流顺序与逻辑，如图3中设置工作流单元1的业务逻辑信息，具体可选择工作流单元的下一步的工作流单元，以及逻辑条件、当前工作流结束后流转等。例如若当前工作流单元执行成功后调整的下一工作流节点或者结束当初工作流，若当前工作流单元执行失败后是退回执行上一工作流单元或者是直接退出当前工作流。用户在云管理平台中定义的工作流信息会保存在云管理平台工作流对应的数据库中，以供复用。

可以理解的是，工作流引擎对整个工作流的流程控制实际上是通过对工作流单元的运行状态进行管理，即通过工作流单元的运行状态来驱动流程的继续执行或回退。在K8s中存在一种原生的list-watch机制，该机制的作用原理为通过动态监听机制监听K8s中资源状态的变化从而实现对应的业务逻辑。因此，工作流引擎只需要订阅list-watch机制即可接收工作流单元的状态变化结果，当k8s中list-watch获取到工作状态的变化后，会主动推送给工作流引擎，工作流引擎接受到推送结果后基于已经定义好的工作流序列进行业务逻辑处理。

参见图4所示，用户可以在云管理平台中发起工作流程，工作流引擎可启动对应的工作流单元。通过监听K8s中的所有工作流单元的工作状态的变化，可接收k8s list-watch机制推送的工作流单元的状态变化结果，在获取到工作流单元的状态后触发查找该工作流单元所属的工作流序列的过程，进而即可回调工作流引擎根据系统中记录的工作流序列，进行一系列的工作流处理流程。

下面对本申请实施例提供的一种基于Kubernetes架构的工作流处理装置进行介绍，下文描述的一种基于Kubernetes架构的工作流处理装置与上文描述的一种基于Kubernetes架构的工作流处理方法可以相互参照。

参见图5所示，本申请实施例提供了一种基于Kubernetes架构的工作流处理装置，应用于工作流引擎，所述装置包括：

流程接收模块201，用于通过云管理平台接收用户终端发起的工作流程；

单元启动模块202，用于根据所述工作流程查找并启动对应的工作流单元；其中，所述工作流单元为基于Kubernetes中的job资源实现的整个工作流过程中每一步运行的最小逻辑单元；

状态接收模块203，用于通过订阅Kubernetes架构中的监听机制，接收所述工作流单元的状态变化结果；

流程控制模块204，用于根据所述状态变化结果，基于预设工作流序列启动下一个工作流程/回退至上一个工作流程/结束整个工作流程。

关于上述模块201至204的具体实施过程可参考前述实施例公开的相应内容，在此不再进行赘述。

在上述实施例的基础上，作为一种优选实施方式，本申请实施例提供的基于Kubernetes架构的工作流处理装置还可以进一步包括：

工作流单元创建模块，用于获取所述用户终端发送的针对所述工作流单元的资源参数，所述资源参数包括CPU、内存、副本数和环境变量；接收为所述工作流单元选择的包含对应业务逻辑的容器镜像，完成所述工作流单元的创建。

本申请还提供了一种电子设备，参见图6所示，本申请实施例提供的一种电子设备包括：

存储器100，用于存储计算机程序；

处理器200，用于执行所述计算机程序时可以实现上述实施例所提供的步骤。

具体的，存储器100包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机可读指令，该内存储器为非易失性存储介质中的操作系统和计算机可读指令的运行提供环境。处理器200在一些实施例中可以是一中央处理器(CentralProcessing Unit，CPU)、控制器、微控制器、微处理器或其他数据处理芯片，为电子设备提供计算和控制能力，执行所述存储器100中保存的计算机程序时，可以实现前述任一实施例公开的基于 Kubernetes架构的工作流处理方法。

在上述实施例的基础上，作为优选实施方式，参见图7所示，所述电子设备还包括：

输入接口300，与处理器200相连，用于获取外部导入的计算机程序、参数和指令，经处理器200控制保存至存储器100中。该输入接口300可以与输入装置相连，接收用户手动输入的参数或指令。该输入装置可以是显示屏上覆盖的触摸层，也可以是终端外壳上设置的按键、轨迹球或触控板，也可以是键盘、触控板或鼠标等。

显示单元400，与处理器200相连，用于显示处理器200处理的数据以及用于显示可视化的用户界面。该显示单元400可以为LED显示器、液晶显示器、触控式液晶显示器以及OLED(Organic Light-Emitting Diode，有机发光二极管)触摸器等。

网络端口500，与处理器200相连，用于与外部各终端设备进行通信连接。该通信连接所采用的通信技术可以为有线通信技术或无线通信技术，如移动高清链接技术(MHL)、通用串行总线(USB)、高清多媒体接口(HDMI)、无线保真技术(WiFi)、蓝牙通信技术、低功耗蓝牙通信技术、基于IEEE802.11s的通信技术等。

图7仅示出了具有组件100-500的电子设备，本领域技术人员可以理解的是，图7示出的结构并不构成对电子设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。

本申请还提供了一种计算机可读存储介质，该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。该存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现前述任一实施例公开的基于Kubernetes架构的工作流处理方法。

本申请将于Kubernetes中的job资源作为基本的工作流单元，无需编写代码集成第三方工作流引擎，实现了工作流引擎与业务代码的解耦。另外，通过订阅Kubernetes的监听机制，获取工作流单元的状态变化以驱动工作流的流转，当某个工作流单元状态发生变化后，工作流引擎可以立即响应，而不是被动等待底层同步信息，加快了工作流的效应速度，提高了工作流引擎的工作效率。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。