CN117742904A - 一种工作流处理方法和装置 - Google Patents

Abstract

本申请公开一种工作流处理方法和装置，包括：获得目标工作流的配置信息；基于配置信息生成第一任务的处理消息，将处理消息发送到目标消息队列，目标工作流包括至少两个任务；基于所述目标工作流对应的映射关系以及从目标消息队列获得的处理消息，确定目标调用地址，目标调用地址是调用处理第一任务的处理单元所属处理集群入口的地址，映射关系表征任务与处理任务的处理单元所属处理集群入口的对应关系；基于目标调用地址调用目标入口，处理单元处理第一任务得到第一处理结果，将第一处理结果发送到目标消息队列；基于第一处理结果触发目标工作流中第二任务的处理消息，执行将处理消息发送到目标消息队列步骤，至目标工作流中全部任务处理完成。

Description

一种工作流处理方法和装置

技术领域

本申请涉及信息技术领域，更具体的说，是涉及一种工作流处理方法和装置。

背景技术

传统的工作流编排一般采用有两种，一种是BPM(Business process management，业务流程管理)是由厂商锁定，由业务人员以零代码托拉拽的方式来设计业务流程。该编排方法一个开放规范叫做BPMN(Business Process Model and Notation，业务流程模型和标记法)，但是该规范交负责，导致产品使用门槛较高。另一种是工作流引擎(WorkflowEngine)。相比BPM而言通常更轻量，其核心专注于状态机、任务调度、定时器管理、事件处理。工作流引擎是面向专业开发人员的，有代码编排和DSL((Dynamic Script Language动态脚本语言)编排两种方式。

如图1所示的是目前云原生的AgroCD Workflow控制面设计示意图，采用的是K8SAPI(Application Program Interface，应用程序接口)server(服务器)，对于K8S的最小单元pod和工作流workkflow采用不同的方式进行设置，分别设置消息监听，对于pod建立队列(pod queue)，每个任务(worker)设置创建pod项目(processpoditem)和将该任务添加到工作流队列中功能；对于工作流建立工作流队列(WF queue)，每个任务设置创建任务流项目(processWFitem)、pod调解(POD reconciling)、程序模板(process template)和创建任务流pod等功能。

该Argo Workflow中，每一个具体的任务都是通过pod来执行，同时有一个sidecar容器来监听工作流中任务的进行。该sidecar监听方式是通过mount docker.sock来实现，这就绕过了Kubernetes APIServer RBAC机制，因此，无法实现对于用户权限的精确控制。

而且，Argo Workflow在DAG解析过程中，每一步都会根据Workflow label来扫描所有的Pod状态，以此来决定是否需要进行下一步的动作。但是每一次扫描都是串行执行，当集群中Workflow较多的时候，就会出现扫描速度缓慢，工作流的任务长时间等待的现象。

发明内容

有鉴于此，本申请提供了一种工作流处理方法和装置，如下：

一种工作流处理方法，包括：

获得目标工作流的配置信息；

基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；

基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；

基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。

可选的，上述的方法，所述获得目标工作流的配置信息包括：

接收启动目标工作流的启动请求；

基于所述启动请求获得目标工作流的配置信息。

可选的，上述的方法，获得目标工作流的配置信息之前，还包括：

基于预设交互界面接收配置信息；

基于所述配置信息，创建目标工作流。

可选的，上述的方法，所述基于所述配置信息，创建目标工作流，包括：

基于所述配置信息，创建目标工作流对应的消息队列；

分析所述配置信息，分别创建所述至少两个任务对应的消息主题和消息处理程序，所述消息处理程序用于将对应任务相关的消息发送给目标消息队列，以及监听所述目标消息队列中与所述消息主题相关的消息；

分析所述配置信息，分别得到所述至少两个任务对应的处理单元所属处理集群的调用地址；

基于所述至少两个任务以及对应的调用地址，建立映射关系。

可选的，上述的方法，所述获得目标工作流的配置信息之前，还包括：

基于预设软件开发工具包中预设创建接口接收创建目标工作流的创建任务，创建目标工作流。

可选的，上述的方法，从所述目标消息队列获得所述处理消息，包括：

确定与所述目标工作流对应的目标消息队列，基于第一任务的消息处理程序监听所述目标消息队列，获得所述处理消息；或

基于第一任务的消息处理程序监听目标消息队列，若所述目标消息队列新增消息是所述目标工作流的消息，获得所述新增消息为处理消息。

可选的，上述的方法，所述基于所述第一处理结果触发所述目标工作流中第二任务的处理消息之前，还包括：

判断所述第一处理结果是否表征处理成功；

若所述第一处理结果表征成功处理，触发所述目标工作流中第二任务的处理消息。

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

若所述第一处理结果表征处理失败且由于处理单元导致，创建目标处理单元，所述目标处理单元用于处理所述第一任务；

触发所述基于所述配置信息生成所述目标工作流中第一任务的处理消息，以基于所述目标处理单元处理所述第一任务。

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

基于目标工作流的配置信息以及至少两个处理集群中处理单元的状态，为所述目标工作流中各任务配置处理单元，得到目标工作流对应的映射关系。

一种工作流处理装置，包括：

获得模块，用于获得目标工作流的配置信息；

生成模块，用于基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；

确定模块，用于基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；

调用模块，用于基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

触发模块，用于基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。

综上，本申请中提供的一种工作流处理方法和装置，包括：接收启动目标工作流的启动请求；基于所述启动请求获得所述目标工作流的配置信息；基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。本方案中，采用消息队列，将工作流中的每个任务的处理消息以及处理结果分别发送到消息队列中实现对于工作流中的任务处理，无需采用sidecar容器监听任务的进行，无需对于所有pod的状态进行扫描，既能够保证用户权限控制，又能够提高工作流的处理效率。

附图说明

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

图1是目前云原生的AgroCD Workflow控制面设计示意图；

图2是本申请提供的一种工作流处理方法实施例1的流程图；

图3是本申请提供的一种工作流处理方法实施例1中工作流的流程编排模式示意图；

图4是本申请提供的一种工作流处理方法实施例1中工作流处理方法的应用场景示意图；

图5是本申请提供的一种工作流处理方法实施例2的流程图；

图6是本申请提供的一种工作流处理方法实施例3的流程图；

图7是本申请提供的一种工作流处理方法实施例4的流程图；

图8是本申请提供的一种工作流处理方法实施例5的流程图；

图9是本申请提供的一种工作流处理方法实施例6的流程图；

图10是本申请提供的一种工作流处理方法的场景示意图；

图11是本申请提供的一种工作流处理装置实施例的结构示意图。

具体实施方式

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

如图2所示的，为本申请提供的一种工作流处理方法实施例1的流程图，该方法应用于一电子设备，该方法包括以下步骤：

步骤S201：获得目标工作流的配置信息；

其中，所述目标工作流包括至少两个任务。

其中，在对于工作流处理时，先获得该管理者的配置信息。

其中，该配置信息包括：工作流包含的任务、任务编排模式、任务类型、工作流的生命周期信息等，当然不限制于此，可以是与工作流相关的任意信息。

其中，该工作流的配置信息可以是预先配置完成，在处理工作流时，获得该预先配置的配置信息。

具体实施中，在接收启动目标工作流的启动请求后，基于该启动请求获得目标工作流的配置信息。

其中，后续实施例中会针对获得目标工作流的配置信息进行详细说明，本实施例中不做详述。

步骤S202：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

其中，基于该配置信息确定该目标工作流中当前待处理的第一任务，生成该第一任务的处理消息。

其中，该处理消息中包含请求处理该第一任务的相关信息。

其中，每个任务对应一消息主题topic和一个消息处理程序handler。

具体实施中，该消息处理程序handler通过serverless(无服务器)实现。

具体的，每个任务基于其消息主题在消息队列中监听其主题的消息。

需要说明的是，本申请实施例中的该第一任务和第二任务仅是用于说明两个具有先后顺序的不同任务，并不限定第一任务是工作流的起始任务或者第二任务是工作流的结束任务。

步骤S203：将所述处理消息发送到目标消息队列；

其中，将该处理消息发送到目标消息队列中，使得各处理消息统一管理。

其中，若发送成功，目标消息队列反馈成功消息，若发送失败，反馈失败消息，则重试发送，以提高成功率。

步骤S204：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

其中，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口。

其中，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系。

其中，从目标消息队列获得处理消息，过程包括：确定与所述目标工作流对应的目标消息队列，基于第一任务的消息处理程序监听所述目标消息队列，获得所述处理消息；或基于第一任务的消息处理程序监听目标消息队列，若所述目标消息队列新增消息是所述目标工作流的消息，获得所述新增消息为处理消息。

其中，该目标消息队列可以是针对该目标工作流设置的消息队列，也可以是整个全部工作流对应的消息队列。

其中，同一个工作流采用的消息主题topic相同，将同一topic的消息放入同一个消息队列中，若该消息队列中有新增消息，则将该新增消息发送给该topic对应工作流中各个业务的handler。

其中，若全部工作流采用一个消息队列，若该消息队列中有新增消息，则将该新增消息推送给各个业务的handler，handler确定该新增消息与其对应业务/topic无关(不是其对应业务所在工作流对应的消息)时，丢弃该新增消息。

其中，各个处理单元是分布设置于多个处理集群中，某一处理集群中的任意两个处理单元可以执行相同的处理功能，也可以执行不同的处理功能，任意两个处理集群中的处理单元可以执行相同的处理功能，也可以执行不同的处理功能。

例如，该处理集群采用的是K8S(Kubernetes)集群，相应的，该目标入口的地址可以是K8S集群的入口地址，基于调用该K8S集群的入口地址，得到该K8S集群中的处理单元。

具体的，该处理单元是K8S集群中的pod，该pod具有处理能力，能够处理任务。

其中，Pod是Kubernetes中管理容器的最小单位。它是Kubernetes对容器的封装，提供容器的资源边界。典型的，Pod中包含紧密相关的一个或者多个容器。

其中，在从目标消息队列中获得处理消息后，基于该处理消息中包含的第一任务相关信息以及该映射关系，确定相应的处理单元，确定该处理单元所属处理集群的入口地址。

具体的，该处理集群的入口地址可以是K8S集群serverless的ingress(入口)地址。

具体实施中，有若干处理集群，处理该第一任务的处理单元属于某一处理集群，在若该处理集群中确定一处理集群。

其中，为例实现serverless的方式承载任务和工作流，本申请中的电子设备需要具有如下能力：通过CNB(Cloud Native BuildPacks)的方式进行代码到镜像的制作。即通过构建镜像创建构建pod，拉取代码，分析构建方式，调用命令进行构建，通过镜像中自带的模型进行镜像构建；提供CRD(Custom Resource Definition，自定义资源定义)和Controller定义。定义CRD，使用代码库项目描述Serverless的源能力，扩缩容策略描述扩缩容能力。研发人员仅需要编写任务的handler函数或流程编排函数的handler函数，任务涉及的消息的创建和消费的代码，将由Serverless的SDK(Software Development Kit，软件开发工具包)在构建时进行代码补齐。CRD定义的函数和底层扩缩容的策略，比如函数代码、topic的分区数、底层handler的最小副本数、最大副本数、自动扩缩容策略等。既可以简化任务的编写和执行，又可以赋予任务执行弹性扩缩容的能力。

步骤S205：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

其中，在确定了调用地址后，基于该目标调用地址调用该处理集群的目标入口，实现将该处理消息发送给该处理集群中的处理单元。

其中，该处理单元执行该任务，得到第一处理结果，将该第一处理结果作为消息发送给目标消息队列中。

步骤S206：基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S203，至所述目标工作流中的全部任务处理完成。

其中，该第一任务和第二任务是具有先后顺序的两个任务，具有编排流程嵌套的任务的前后两个部分。

其中，基于处理目标工作流中的第一任务处理完成，触发对于该目标工作流中的第二任务的处理，循环执行步骤S203，直至给目标工作流中的全部任务处理完成。

具体的，工作流的各个任务的handler监听队列中的消息，若监听到同一个消息主题topic的消息后，该handler接收该消息并对于该消息进行反序列化处理，确定待处理的处理消息。

该处理消息具体包括其相应任务的处理相关信息，如请求第一任务的消息处理程序handler的参数以及历史处理信息等。

需要说明的是，本申请中，工作流处理过程中，是基于第一任务处理完成触发第二任务的处理，其是基于事件的工作流编排。

具体的，基于事件的工作流编排的主要任务是将工作委派给无状态serverless的服务，同时又要保持业务流程执行的上下文和历史记录。通常是由一个编排客户端程序(orchestration client)启动编排器程序(orchestration worker)运行指定的业务流程，以按照一定步骤执行一系列活动。orchestration worker在执行到活动(通常对应activity worker对微服务或云函数的调用)、计时器、外部事件相关的代码时，自动发送命令到消息队列并记录下当前的执行记录到历史事件存储。本实施例中各个步骤执行的上述过程。

如图3所示的是工作流的流程编排模式示意图，包括：顺序链式、扇入扇出、数组遍历、出错补偿、外部事件+定时器和流程嵌套共6种。其中，顺序链式模式包括任务1-3，任务1执行完成触发任务2，任务2执行完成触发任务3；扇入扇出模式包括任务1-4，任务1执行完成触发任务2和任务3，任务2和任务3执行完成触发任务4；数组遍历模式包括任务1-3，任务2是一组任务，任务1执行完成触发执行任务2，任务2中的任务组全部执行完成触发任务3；出错补偿模式包括任务1-3和补偿1-2，任务1执行完成触发任务2，任务2执行完成触发任务3，若任务2失败触发补偿1-2；外部事件+定时器任务包括任务1、事件、定时和任务2，任务1执行完成触发事件和定时，事件和定时完成触发任务2；流程嵌套模式包括任务1和子编排流程，任务1执行过程中执行子编排流程，子编排流程执行完成后继续执行任务1至任务1完成。

如图4所示的是该工作流处理方法的应用场景示意图，包括控制集群401和多个被管集群402，其中，各个集群具体采用的是K8S集群，给该被管集群中包括若干处理单元，某一被管集群中的任意两个处理单元可以执行相同的处理功能，也可以执行不同的处理功能，任意两个被管集群中的处理单元可以执行相同的处理功能，也可以执行不同的处理功能。

其中，本申请中执行工作流处理方法的电子设备是控制集群，其对于集群中各个被管集群进行管理，且，执行对于工作流的处理。

综上，本实施例提供的一种工作流处理方法，包括：接收启动目标工作流的启动请求；基于所述启动请求获得所述目标工作流的配置信息；基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。本方案中，采用消息队列，将工作流中的每个任务的处理消息以及处理结果分别发送到消息队列中实现对于工作流中的任务处理，无需采用sidecar容器监听任务的进行，无需对于所有pod的状态进行扫描，既能够保证用户权限控制，又能够提高工作流的处理效率。

如图5所示的，为本申请提供的一种工作流处理方法实施例2的流程图，该方法包括以下步骤：

步骤S501：基于预设交互界面接收配置信息；

其中，执行本申请的电子设备设置有交互装置，该交互装置输出交互界面，操作者通过该交互界面输入配置信息。

具体的，该交互界面中通过组件的方式显示不同预置节点的能力进行展示，通过输入参数的方式让操作者进行节点的初始化，比如，使用一个标准的HTTP(HyperTextTransfer Protocol，超文本传输协议)请求节点，输入请求URL、请求头、请求方式和请求具体参数，完成一个HTTP请求任务的初始化。

其中，对于某一个待创建的工作流中的各个任务，拖拽多个任务节点，通过节点间的连线，完成节点关系的编排。

其中，操作者操作连接的各个任务节点、输入的参数均作为工作流的配置信息。

具体实施中，还可以定义某个任务执行成功的返回值，仅当任务执行成功时进行工作流的流转，否则根据配置的自动重试次数进行重试，当超过重试次数仍未成功时，进行出错状态等待人工介入进行流程补偿，增加重试次数或者调整输入参数，或调整上级成功返回值的定义等。其中，定义某个任务执行成功的返回值可以是一个值，也可以是多个值。

步骤S502：基于所述配置信息，创建目标工作流；

其中，基于该配置信息，确定目标工作流中各个任务节点以及任务节点间的关系编排，而且，还对于该各个任务中与目标工作流相关的信息进行创建处理等。

具体实施中，基于预设交互界面接收配置信息，控制集群中前端的处理模块基于该配置信息，生成目标工作流的配置文档，将该配置文档传递给后端的功能模块进行解析处理，构建目标工作流。

其中，该步骤S502包括：

步骤S5021：基于所述配置信息，创建目标工作流对应的消息队列；

其中，基于该配置信息，确定一目标工作流，为该目标工作流创建一对应的消息队列。

其中，该消息队列仅存储该目标工作流相关的消息。

步骤S5022：分析所述配置信息，分别创建所述至少两个任务对应的消息主题和消息处理程序；

其中，所述消息处理程序用于将对应任务相关的消息发送给目标消息队列，以及监听所述目标消息队列中与所述消息主题相关的消息。

其中，同一工作流中的任务处理消息采用相同的消息主题topic，同一消息主题的消息发送给同一个消息队列。

其中，该目标工作流中各个任务的消息主题采用相同消息主题，而且各个任务的消息处理程序handler仅对于其相同消息主题的消息进行监听。

其中，该任务的消息处理程序订阅了该消息主题的消息，该目标消息队列中接收到新的消息后，将新的消息推送给各个订阅了该消息主题的消息处理程序，能够使得同一工作流中各个任务均接收到该新消息的推送，使得基于该消息触发执行的任务触发，而其他任务丢弃该消息。

步骤S5023：分析所述配置信息，分别得到所述至少两个任务对应的处理单元所属处理集群的调用地址；

其中，基于该配置信息确定该工作流中涉及的各个任务对应处理能力的处理单元，基于该处理单元的所属的处理集群，确定一调用地址。

其中，该调用地址是该处理单元所属的处理集群的入口地址。

其中，该处理集群基于该入口地址调用，该处理集群被调用时，能够将任务消息对应请求的任务信息转发给对应的处理单元pod。

具体的，依次对于目标工作流中涉及的多个任务对应的处理单元所属集群的调用地址进行确定。

其中，同一工作流中的任务对应的处理单元，可以属于同一集群，也可可以属于不同的集群。

步骤S5024：基于所述至少两个任务以及对应的调用地址，建立映射关系；

其中，基于前述步骤确定的各个任务以及其对应的调用地址，建立任务于调用地址之间的映射关系。

其中，针对每个工作流建立一对应关系，为后续处理该工作流中的每个任务时提供调用处理集群提供调用地址。

步骤S503：获得目标工作流的配置信息；

步骤S504：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

步骤S505：将所述处理消息发送到目标消息队列；

步骤S506：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

步骤S507：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

步骤S508：基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S505，至所述目标工作流中的全部任务处理完成。

其中，步骤S503-508与实施例1中的相应步骤一致，本实施例中不做赘述。

综上，本实施例提供的一种工作流处理方法，还包括：基于预设交互界面接收配置信息；基于所述配置信息，创建目标工作流。本实施例中，操作者基于预设交互界面输入配置信息，系统提供内置任务节点模板，用户通过图形化界面初始化，通过业务联系构建业务逻辑，实现创建目标工作流的目的，操作过程简单，提高用户体验。

如图6所示的，为本申请提供的一种工作流处理方法实施例3的流程图，该方法包括以下步骤：

步骤S601：基于预设软件开发工具包中预设创建接口接收创建目标工作流的创建任务，创建目标工作流；

其中，该预设软件开发工具包具体可以是SDK。

具体的，可以通过API(Application Programming Interface，应用程序编程接口)网关(Gateway)输入该软件开发工具包。

其中，对于该预设软件开发工具包进行解析，得到其中包括的工作流相关的各种接口、方法等。

具体的，该接口包括：创建任务的接口；分配任务的接口，即发送消息到指定topic的接口，提供同步分发和异步分发两种模式，同步分发阻塞直至收到响应时返回，异步分发直接返回结果，当收到消息通知用户；定时器能力以控制定时触发的需求，异步接口，可通过等待结果获取结果；提供创建流程任务的接口，用于子流程嵌套；上下文管理的接口，用于存储和获取的任务的元数据，包括但不限于：任务的编码，工作流id(identification，身份标识号),工作流名称，重试任务序号，重试次数，上次出错信息等；通过参数查询当前执行流程的接口，如id或名称；提供等待接口，以获取异步执行的结果；提供错误查询接口，以获取最近一次出错的上下文。

具体的，该方法包括：接收和发送信号的方法等。

其中，通过该数据包中提供的各种接口，请求创建任务以及任务中的topic和handler等，并且对于任务的元数据进行输入，实现对于工作流中的各任务以及任务相关的配置信息的输入，进而基于该通过接口请求的任务以及各任务的配置信息，创建目标工作流。

具体的，基于该配置信息中提供的各种接口以及方法等，操作者通过提交函数代码的方式构建工作流或者扩展任务节点。

具体的，该函数代码可以用于指定属于同一工作流的任务节点、指示每个任务节点创建消息主题以及消息处理程序、指示任务节点调用的处理单元等。

具体的，该创建目标工作流的过程可以参考前述实施例2中的解释，本实施例中不做赘述。

步骤S602：获得目标工作流的配置信息；

步骤S603：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

步骤S604：将所述处理消息发送到目标消息队列；

步骤S605：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

步骤S606：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

步骤S607：基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S604，至所述目标工作流中的全部任务处理完成。

其中，步骤S602-607与实施例1中的相应步骤一致，本实施例中不做赘述。

综上，本实施例提供的一种工作流处理方法，还包括：基于预设软件开发工具包中预设创建接口接收创建目标工作流的创建任务，创建目标工作流。本实施例中，基于API网关输入研发人员预先生成SDK，以支持操作者提交函数代码的方式构建工作流，实现创建目标工作流的目的，操作过程简单，提高用户体验。

如图7所示的，为本申请提供的一种工作流处理方法实施例4的流程图，该方法包括以下步骤：

步骤S701：获得目标工作流的配置信息；

步骤S702：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

步骤S703：将所述处理消息发送到目标消息队列；

步骤S704：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

步骤S705：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

其中，步骤S701-705与实施例1中的相应步骤一致，本实施例中不做赘述。

步骤S706：判断所述第一处理结果是否表征处理成功；

其中，在目标消息队列中新增处理结果消息时，对于该处理结果消息进行分析，得到第一任务的处理是否成功。

具体的，该第一处理结果中具有成功或者失败、失败原因等信息。

其中，对于该第一处理结果进行分析，若该第一处理结果中包括成功信息，则确定第一任务处理成功，若该第一处理结果中包括失败信息，则确定该第一任务处理失败。

其中，该失败原因可以有多种，如处理单元故障、传输故障。

其中，若第一处理结果表征该第一任务处理成功，则基于工作流的流程编排确定下一个执行的任务。

例如，工作流是顺序链式模式，在执行完第一任务后，基于第一任务执行成功，触发执行第二任务；

例如，工作流是扇入扇出模式，在执行完第一任务后，第二任务需要第一任务和第三任务分别执行成功后触发，则基于该第一任务的处理结果和第三任务的处理结果，触发第二任务的执行。

其中，若该第一处理结果表征第一任务处理失败，基于任务的工作流编排，当集群系统出现故障时，通过事件溯源(event sourcing)模式自动恢复业务流程函数的上下文并继续执行未完成的流程，对于该第一任务进行重试，至该第一任务处理成功。

步骤S707：若所述第一处理结果表征成功处理，基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S703，至所述目标工作流中的全部任务处理完成。

其中，步骤S707与实施例1中的相应步骤一致，本实施例中不做赘述。

综上，本实施例提供的一种工作流处理方法，还包括：判断所述第一处理结果是否表征处理成功；若所述第一处理结果表征成功处理，触发所述目标工作流中第二任务的处理消息。本实施例中，对于第一任务处理结果进行分析，确定对于第一任务的处理是否成功，在该第一任务处理成功时，才触发目标工作流中第二任务的处理消息，开始对于第二任务进行处理，保证按照工作流的模式要求进行处理其中的各项任务。

如图8所示的，为本申请提供的一种工作流处理方法实施例5的流程图，该方法包括以下步骤：

步骤S801：获得目标工作流的配置信息；

步骤S802：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

步骤S803：将所述处理消息发送到目标消息队列；

步骤S804：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

步骤S805：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

步骤S806：判断所述第一处理结果是否表征处理成功；

步骤S807：若所述第一处理结果表征成功处理，基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S803，至所述目标工作流中的全部任务处理完成；

其中，步骤S801-807与实施例4中的相应步骤一致，本实施例中不做赘述。

步骤S808：若所述第一处理结果表征处理失败且由于处理单元导致，创建目标处理单元；

其中，所述目标处理单元用于处理所述第一任务；

其中，对于第一处理结果进行分析，确定该第一任务处理失败，且给失败原因是处理单元导致。

其中，该处理失败是经过多次重试，达到重试的最大次数仍然失败。

具体实施中，工作流和任务可以通过serverless的方式以不使用缩容到0，使用时进行弹性扩缩容的方式存在，当使用serverless的方式实现时，任务节点提供全局的Topic查找能力，如果没找到则创建，找到即复用该topic；也可以使用Job的方式实现，使用Job方式时，子流程的执行会重新创建Job。

具体的，K8S JOB是Kubernetes中的一种工作负载类型(workload)。

其中，若由于处理单元导致第一任务处理失败，则在集群系统进行topic查找能力，但是，若无被控集群的pod有该处理能力，则创建pod，并且复用该topic调用该创建的处理单元进行处理该第一任务；若采用Job方式，由于pod导致第一任务处理失败，则重新创建pod，以采用该重新创建的pod进行处理第一任务。

其中，在创建目标处理单元后，触发所述基于所述配置信息生成所述目标工作流中第一任务的处理消息，以基于所述目标处理单元处理所述第一任务。

其中，在重新创建执行第一任务的目标处理单元后，重新请求处理第一任务，以使得采用该目标处理单元处理该第一任务。

综上，本实施例提供的一种工作流处理方法，还包括：若所述第一处理结果表征处理失败且由于处理单元导致，创建目标处理单元，所述目标处理单元用于处理所述第一任务；触发所述基于所述配置信息生成所述目标工作流中第一任务的处理消息，以基于所述目标处理单元处理所述第一任务。本实施例中，若处理第一任务失败，且失败原因是由于处理单元，则创建目标处理单元，以使得重试请求处理第一任务时，采用目标处理单元处理该第一任务，以提高处理第一任务的成功率。

如图9所示的，为本申请提供的一种工作流处理方法实施例6的流程图，该方法包括以下步骤：

步骤S901：获得目标工作流的配置信息；

其中，步骤S901与实施例1中的相应步骤一致，本实施例中不做赘述。

步骤S902：基于目标工作流的配置信息以及至少两个处理集群中处理单元的状态，为所述目标工作流中各任务配置处理单元，得到目标工作流对应的映射关系；

其中，该目标工作流的配置信息中包括各个任务类型等，而不同类型的任务需要不同的处理单元。

其中，该处理单元的状态包括处理单元负载、处理类型、调用地址等信息，该处理类型是能够处理的任务类型。

其中，各个处理集群中包含多个处理单元，各个处理单元的处理类型、当前的负载情况不一，相应的，在获得配置信息后，基于该配置信息中各个任务的任务类型在各个处理集群的处理单元中，确定与该任务类型匹配的处理类型的处理单元，以实现为该目标工作流中的各个任务配置处理单元，将该处理单元的调用地址与其对应的任务建立映射关系，得到目标工作流对应的映射关系。

具体的，可以采用如下方式确定处理单元：

基于处理单元的处理类型确定与该目标工作流中待处理任务的任务类型对应的处理单元；和/或

基于处理单元的负载情况，确定具有处理该目标工作流中任务的处理能力的处理单元。

其中，为该目标工作流配置的处理单元，可以是该目标工作流独占的处理单元，即该处理单元仅处于该目标工作流的任务，不处理其他任务，为实现该目的，将该处理单元配置为目标工作流的独占处理单元，为该独占处理单元添加特定标识，以使得该处理单元不处理其他工作流的任务。

其中，为该目标工作流配置的处理单元，也可以是该目标工作流与其他工作流共享的处理单元，该处理单元能够处理该目标工作流中的任务，也可以处理其他工作流的任务。

需要说明的是，具体实施中，可以在配置目标工作流时，为该工作流中的任务配置处理单元，得到该目标工作流的映射关系；或者是在配置完成目标工作流后，在处理目标工作流中的任务之前，基于配置信息得到该目标工作流的映射关系，本申请中不对于步骤S901与902的先后顺序做限制。

步骤S903：基于所述配置信息生成所述目标工作流中第一任务的处理消息；

步骤S904：将所述处理消息发送到目标消息队列；

步骤S905：基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址；

步骤S906：基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

步骤S907：基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行步骤S904，至所述目标工作流中的全部任务处理完成。

其中，步骤S903-907与实施例1中的相应步骤一致，本实施例中不做赘述。

综上，本实施例提供的一种工作流处理方法，还包括：基于目标工作流的配置信息以及至少两个处理集群中处理单元的状态，为所述目标工作流中各任务配置处理单元，得到目标工作流对应的映射关系。本实施例中，基于目标工作流的配置信息以及多个处理集群中各个处理单元的状态，为该目标工作流中的各个任务确定能够处理该任务的处理单元，得到映射关系，为后续确定处理各个任务的处理单元以及对应的目标调用地址提供依据。

如图10所示的是工作流处理方法的场景示意图，该方法应用于K8S集群，该集群包括控制集群1001和多个被管集群1002以及相关的协调器、代码库和镜像库，控制集群上通过CRD及Controller实现集群管理的能力。该控制集群包括集群注册用于接收被管集群的注册请求、自动完成被管集群的纳管，与集群注册对应的元数据管理用于管理被管集群的元数据，API-Server用于接收APIServer的请求；被管集群的工作代理会通过List&Watch机制订阅控制集群的元数据变化，在数据发生变化时通过控制集群的APIServer获取对应的CR信息同时在本集群进行状态更新，并将状态更新到控制集群对应CR的Status上。元数据管理用于管理控制集群内的元数据。每个被管集群中也设置有APIserver以实现接收APIServer的请求，注册代理用于向控制集群请求注册，工作代理在运行过程中与控制集群进行代理

其中，该List&Watch机制是Kubernetes中两个重要的机制，用于监听API对象的变化；List机制允许用户列出指定API中的对象。研发人员可以通过API请求从Kubernetes集群中的API服务(Server)模块中获取对象列表，Watch机制不是一直接取对象的列表并返回，而是通过长连接持续监听对象的变化，并主动推送相关事件到用户。

其中，该各个集群设置有服务(serving)模块和运行时模块(被管集群中是运行时(客户端)，管理集群中是Cl)，这两个模块为集群系统提供serverless，该服务模块提供FaaS(功能即服务)底层的0-1、1-N(N是大于1的正数)的扩缩容能力。运行时模块提供SDK给各语言进行函数转化应用的功能，与消息系统的接口统一。同时在控制面提供函数镜像制作的能力，可以对接外部的代码库和镜像库。

其中，控制集群和被管集群分别设置有代理模块、持久化存储，二者于外部的协调器组成了该集群系统的消息系统。其中，代理为消息的生产者和消息的费者提供管理任务和主题查找的API。生产者连接到代理以发布消息，消费者连接到代理以使用消息。同时协调器负责处理涉及多个集群的协调任务。元数据管理负责维护集群的元数据，如主题元数据、模式、代理加载数据等。持久化存储用于提供保持未确认的消息，直到可以传递给消费者并得到消费者的确认。

其中，控制集群中前端可视化编排模块、代码编辑模块、配置解析模块、流程生命周期管理模块和被管集群中工作流执行模块、服务执行模块组成编排系统，其中，可视化编排模块提供研发人员根据内置节点进行自定义流程编排的能力；配置解析模块将研发人员配置的流程元数据转化为工作流模块可理解的格式；流程生命周期管理模块负责流程的生命周期管理，如启动、停止、补偿、重试等；工作流执行模块是工作流业务流转的核心管理模块，负责工作流根据配置的实例化，状态流转的管理，执行过程的记录；服务执行模块是工作流节点的执行模块，提供具体的业务能力如Restful接口的调用、PC的调用、消息发送、数据库操作、定时器触发、邮件发送、短信发送等能力。代码编辑模块用于通过代码方式创建更为复杂的工作流执行模块和服务执行模块。

与上述本申请提供的一种工作流处理方法实施例相对应的，本申请还提供了应用该工作流方法的装置实施例。

如图11所示的为本申请提供的一种工作流处理装置实施例的结构示意图，该装置包括以下结构：获得模块1101、生成模块1102、确定模块1103、调用模块1104和触发模块1105；

其中，该获得模块1101，用于获得目标工作流的配置信息；

其中，该生成模块1102，用于基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；

其中，该确定模块1103，用于基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；

其中，该调用模块1104，用于基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

其中，该触发模块1105，用于基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。

可选的，获得模块具体用于：

接收启动目标工作流的启动请求；

基于所述启动请求获得目标工作流的配置信息。

可选的，还包括：

接收模块，用于在获得目标工作流的配置信息之前，基于预设交互界面接收配置信息；

第一创建模块，用于基于所述配置信息，创建目标工作流。

可选的，创建模块具体用于：

基于所述配置信息，创建目标工作流对应的消息队列；

分析所述配置信息，分别创建所述至少两个任务对应的消息主题和消息处理程序，所述消息处理程序用于将对应任务相关的消息发送给目标消息队列，以及监听所述目标消息队列中与所述消息主题相关的消息；

分析所述配置信息，分别得到所述至少两个任务对应的处理单元所属处理集群的调用地址；

基于所述至少两个任务以及对应的调用地址，建立映射关系。

可选的，还包括：

第二创建模块，用于在所述获得目标工作流的配置信息之前，基于预设软件开发工具包中预设创建接口接收创建目标工作流的创建任务，创建目标工作流。

可选的，还包括：

消息获得模块，用于从所述目标消息队列获得所述处理消息；

该消息获得模块具体包括：

确定单元，用于确定与所述目标工作流对应的目标消息队列，基于第一任务的消息处理程序监听所述目标消息队列，获得所述处理消息；或

获得单元，用于基于第一任务的消息处理程序监听目标消息队列，若所述目标消息队列新增消息是所述目标工作流的消息，获得所述新增消息为处理消息。

可选的，还包括：

判断模块，用于判断所述第一处理结果是否表征处理成功；若所述第一处理结果表征成功处理，触发该触发模块。

可选的，还包括：

创建模块，用于若所述第一处理结果表征处理失败且由于处理单元导致，创建目标处理单元，所述目标处理单元用于处理所述第一任务；

消息触发模块，用于触发所述基于所述配置信息生成所述目标工作流中第一任务的处理消息，以基于所述目标处理单元处理所述第一任务。

需要说明的是，本实施例中提供的一种工作流处理装置中的各个组成结构，其功能解释请参考前述方法实施例中的解释，本实施例中不做赘述。

综上，本申请中提供的一种工作流处理装置、包括：获得模块，用于获得目标工作流的配置信息；生成模块，用于基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；确定模块，用于基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；调用模块，用于基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；触发模块，用于基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。本方案中，采用消息队列，将工作流中的每个任务的处理消息以及处理结果分别发送到消息队列中实现对于工作流中的任务处理，无需采用sidecar容器监听任务的进行，无需对于所有pod的状态进行扫描，既能够保证用户权限控制，又能够提高工作流的处理效率。

与上述本申请提供的一种工作流处理方法实施例相对应的，本申请还提供了与该工作流处理方法相应的电子设备以及可读存储介质。

其中，该电子设备，包括：存储器、处理器；

其中，存储器存储有处理程序；

所述处理器用于加载并执行所述存储器存储的所述处理程序，以实现如上述任一项所述的工作流处理方法的各步骤。

具体该电子设备的实现工作流处理方法，参考前述工作流处理方法实施例即可。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例提供的装置而言，由于其与实施例提供的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所提供的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所提供的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种工作流处理方法，其特征在于，包括：

获得目标工作流的配置信息；

基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；

基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；

基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。

2.根据权利要求1所述的方法，其特征在于，所述获得目标工作流的配置信息包括：

接收启动目标工作流的启动请求；

基于所述启动请求获得目标工作流的配置信息。

3.根据权利要求1所述的方法，其特征在于，获得目标工作流的配置信息之前，还包括：

基于预设交互界面接收配置信息；

基于所述配置信息，创建目标工作流。

4.根据权利要求3所述的方法，其特征在于，所述基于所述配置信息，创建目标工作流，包括：

基于所述配置信息，创建目标工作流对应的消息队列；

分析所述配置信息，分别创建所述至少两个任务对应的消息主题和消息处理程序，所述消息处理程序用于将对应任务相关的消息发送给目标消息队列，以及监听所述目标消息队列中与所述消息主题相关的消息；

分析所述配置信息，分别得到所述至少两个任务对应的处理单元所属处理集群的调用地址；

基于所述至少两个任务以及对应的调用地址，建立映射关系。

5.根据权利要求1所述的方法，其特征在于，所述获得目标工作流的配置信息之前，还包括：

基于预设软件开发工具包中预设创建接口接收创建目标工作流的创建任务，创建目标工作流。

6.根据权利要求1所述的方法，其特征在于，从所述目标消息队列获得所述处理消息，包括：

确定与所述目标工作流对应的目标消息队列，基于第一任务的消息处理程序监听所述目标消息队列，获得所述处理消息；或

基于第一任务的消息处理程序监听目标消息队列，若所述目标消息队列新增消息是所述目标工作流的消息，获得所述新增消息为处理消息。

7.根据权利要求1所述的方法，其特征在于，所述基于所述第一处理结果触发所述目标工作流中第二任务的处理消息之前，还包括：

判断所述第一处理结果是否表征处理成功；

若所述第一处理结果表征成功处理，触发所述目标工作流中第二任务的处理消息。

8.根据权利要求7所述的方法，其特征在于，还包括：

若所述第一处理结果表征处理失败且由于处理单元导致，创建目标处理单元，所述目标处理单元用于处理所述第一任务；

触发所述基于所述配置信息生成所述目标工作流中第一任务的处理消息，以基于所述目标处理单元处理所述第一任务。

9.根据权利要求1所述的方法，其特征在于，所述获得目标工作流的配置信息之后，还包括：

基于目标工作流的配置信息以及至少两个处理集群中处理单元的状态，为所述目标工作流中各任务配置处理单元，得到目标工作流对应的映射关系。

10.一种工作流处理装置，其特征在于，包括：

获得模块，用于获得目标工作流的配置信息；

生成模块，用于基于所述配置信息生成所述目标工作流中第一任务的处理消息，将所述处理消息发送到目标消息队列，所述目标工作流包括至少两个任务；

确定模块，用于基于所述目标工作流对应的映射关系以及从所述目标消息队列获得的所述处理消息，确定目标调用地址，所述目标调用地址是调用目标入口的地址，所述目标入口是处理所述第一任务的处理单元所属处理集群的入口，所述映射关系表征任务与处理所述任务的处理单元所属处理集群入口的对应关系；

调用模块，用于基于所述目标调用地址调用所述目标入口，以使得所述处理单元处理所述第一任务得到第一处理结果，并将所述第一处理结果发送到目标消息队列；

触发模块，用于基于所述第一处理结果触发所述目标工作流中第二任务的处理消息，返回执行所述将所述处理消息发送到目标消息队列步骤，至所述目标工作流中的全部任务处理完成。