CN114787836A - 用于远程执行一个或更多个任意定义的工作流的系统和方法 - Google Patents

Abstract

一种用于远程执行一个或更多个任意定义的工作流的系统包括：工作流引擎，其可操作成在客户计算基础设施上执行给定工作流中定义的一个或更多个功能；以及工作流管理员，其有权访问工作流数据库，工作流数据库维护对给定工作流的状态进行定义的元数据，工作流管理员远离工作流引擎并且不在客户计算基础设施上运行。工作流管理员代理轮询工作流管理员以识别给定工作流何时被调度用于执行，并且当给定工作流被调度时，工作流管理员代理向工作流引擎发出命令以从工作流注册表中检索给定工作流并在客户计算基础设施上执行给定工作流中定义的一个或更多个功能。工作流管理员代理将关于给定工作流的执行的状态信息传输给工作流管理员以存储在工作流数据库中。

Description

用于远程执行一个或更多个任意定义的工作流的系统和方法

相关申请的交叉引用

本申请要求于2019年8月1日提交的题为“SYSTEM AND METHOD FOR THE REMOTEEXECUTION OF ONE OR MORE ARBITRARILY DEFINED WORKFLOWS”的临时专利申请第62/881,568号的优先权，该申请的公开内容在此出于所有目的通过引用并入本文中。

背景技术

工作流管理解决方案需要代表其数据正被管理的客户执行或以其他方式运行这样的工作流解决方案。这样的工作流管理解决方案的执行通常涉及控制客户代码在客户的内部网络内的执行，这还可以包括与客户网络外的资源(受信任和不受信任的资源)的对接。客户代码在客户网络内和不在客户网络内的执行提供了明显的信任问题：客户必须信任任何工作流管理软件的提供商将在客户网络内执行的代码，而软件提供商必须信任他们接收的任何客户代码和/或数据本质上不是恶意的，而不管注入这种恶意代码是否有意。

因此，本领域中需要的是提供一个或更多个工作流的混合执行的系统和方法，更具体地，是如下系统和方法：实际代码执行和数据维护发生在客户环境内但受一个或更多个远程进程编排。

发明内容

本发明的实施方式针对提供一个或更多个工作流的完全管理的远程编排的系统和方法。根据这样的实施方式，提供了将编排一个或更多个工作流的执行的任务与在客户环境内任意执行代码的任务分开的系统和方法。根据这种混合执行模式，客户代码始终保留在客户的私有基础设施中。这样，客户设计、测试和构建一个或更多个工作流，给定工作流包括一个或更多个任务。客户可以利用多个开源和闭源工具——例如，由普雷费克特科技公司提供并可从https://www.prefect.io./core下载的开源工作流编辑环境PREFECTCORE^TM——来编辑给定工作流。体现PREFECT CORE工作流引擎的一个实施方式的软件库和二进制文件可在www.github.com/PrefectHQ/prefect公开获得，其公开内容在此通过引用整体并入。

当工作流准备就绪时，客户向远程或云工作流基础设施注册工作流的存在，这导致向远程或云工作流基础设施传输足以重建无代码版本的工作流的元数据：详细信息包括但不限于：给定工作流中包含的任务，这样的任务的依赖结构；工作流的执行的调度；关于工作流的运行时环境的信息；等。

一旦远程或云工作流基础设施拥有这样的信息，它就可以开始编排工作流，即使这样的远程基础设施不能访问作为工作流的执行的一部分而执行的底层代码。根据一个实施方式的工作流执行包括将给定工作流的远程表示置于“调度”状态。在客户基础设施上运行的代理监测被调度用于执行的工作流的可用性。当代理识别被调度的工作流时，代理检索该工作流并开始执行构成该工作流的一个或更多个任务。这种执行可以在本地进行或在远程执行集群中进行，这仅是由客户自行定义的部署决策。当构成工作流的给定任务通过“运行”状态时，它最终进入包括“成功”、“失败”或“重试”的状态，其中这样的信息作为一项或更多项元数据被传送回远程或云工作流基础设施。这样，可以通过中央代理来协调在客户基础设施上执行的多个并发工作流，所有不需要访问驻留在客户基础设施上的代码或数据。

根据一个实施方式，一种用于远程执行一个或更多个任意定义的工作流的系统包括：工作流引擎，其可操作成在客户基础设施上执行给定工作流中定义的一个或更多个功能；以及工作流管理员，其有权访问工作流数据库，工作流数据库维护对给定工作流的状态进行描述的元数据，工作流管理员远离工作流引擎并且不在客户基础设施上运行。该系统还包括工作流管理员代理，其轮询工作流管理员以识别给定工作流何时处于被调度用于执行的状态。当给定工作流被调度时，工作流管理员代理向工作流引擎发出命令以从工作流注册表中检索给定工作流并在客户基础设施上执行给定工作流中定义的一个或更多个功能，工作流管理员代理将关于给定工作流的执行的状态信息传输给工作流管理员以存储在工作流数据库中。

根据本实施方式的系统还包括用于从工作流管理员代理接收请求和命令以转发给工作流管理员的API。类似地，API从工作流管理员接收对请求和命令的响应以转发给工作流管理员代理。更具体地，工作流管理员可以响应于来自工作流管理员代理的请求查询工作流数据库以检索信息，这可以包括API的使用，并且来自工作流管理员代理的请求可以包括关于需要执行的可用工作流的查询。进一步基于本实施方式，工作流注册表维护关于形成给定工作流的一部分的步骤的业务逻辑，并且工作流引擎可以位于远离客户基础设施的位置。

根据一个实施方式的一种用于远程执行一个或更多个任意定义的工作流的方法包括：执行客户基础设施上的工作流管理员代理和云基础设施上的工作流管理员，工作流管理员远离工作流引擎；以及向工作流管理员提供对工作流数据库的访问，工作流数据库维护对给定工作流的状态进行描述的元数据。工作流管理员代理轮询工作流管理员以识别给定工作流何时处于被调度用于执行的状态，并且当给定工作流被调度用于执行时，向工作流引擎发布命令以从工作流注册表中检索给定工作流并在客户基础设施上执行给定工作流中定义的一个或更多个功能。工作流管理员代理将关于给定工作流的执行的状态信息传输到工作流管理员以存储在工作流数据库中。

根据本实施方式的方法通过API从工作流管理员代理接收请求和命令来继续，该API将接收到的请求和命令转发给工作流管理员。类似地，API从工作流管理员接收对请求和命令的响应，该响应转发给工作流管理员代理。工作流管理员可以响应于来自工作流管理员代理的请求查询工作流数据库以检索信息，这可以包括与一个或更多个工作流代理的通信。根据一个实施方式，查询工作流数据库包括查询关于需要执行的可用工作流。本实施方式的方法还可以包括以下步骤：在工作流注册表处维护关于形成给定工作流的一部分的步骤的业务逻辑，以及远离客户基础设施操作工作流引擎。

附图说明

本发明在附图中示出，附图是示例性的而非限制性的，其中相似的附图标记旨在指代相似或相应的部件，其中：

图1呈现了根据本发明的一个实施方式的用于远程执行一个或更多个任意定义的工作流的系统的框图；

图2呈现了根据本发明的一个实施方式的用于将工作流部署到本地工作流基础设施以及将相应的元数据部署到远程工作流基础设施的方法的流程图；

图3呈现了根据本发明的一个实施方式的用于执行工作流的方法的流程图；

图4呈现了根据本发明的一个实施方式的用于运行工作流的方法的流程图；

图5呈现了根据本发明的一个实施方式的用于远程执行一个或任意定义的工作流的替选系统的框图；以及

图6至图10呈现了一系列屏幕图，其示出了用于管理结合本发明的各种实施方式部署的硬件和软件组件的用户接口的一个实施方式。

具体实施方式

如本文所使用的这样的术语，工作流是包括多个离散任务的过程，这些任务在最终用户计算基础设施上执行功能或向最终用户计算基础设施或从最终用户计算基础设施读取数据。根据由“工作流引擎”管理的规则系统，这些任务可能相互依赖，“工作流引擎”负责管理给定工作流中的每个任务的状态。示例性规则包括但不限于如下规则：防止任务在一个或更多个其他任务进入特定状态之前开始、允许在特定时间调度或重试任务、允许由一个任务产生的数据被后面的任务消耗等。

用于部署可执行软件系统(诸如作为本申请主题的工作流执行系统)的两种常见产品通常是完全管理的或内部部署的。完全管理的产品涉及所有代码在由服务或软件提供商拥有和/或操作的基础设施上的存储和执行，而内部部署涉及打包软件以在最终用户的基础设施上部署和执行。在本申请中描述的用于工作流部署和执行的模型被称为“混合”执行模型，因为它涉及管理模型和内部部署模型两者的合并。

鉴于上述内容，尽管在给定计算环境中执行工作流是有用的，但是需要与所调度并执行的工作流进行远程交互。本发明的各种实施方式的系统和方法允许用户将在核中开发的工作流挂钩到包括工作流数据库和API服务器的有状态体系结构中，工作流数据库和API服务器可以在工作流管理员组件(“工作流管理员”)的协调和控制下。该系统有利地提供了完整API，其允许用户与其工作流远程交互(例如，调度运行或设置状态)以及查询工作流数据库。本质上，本文所描述的编程构造“围绕”在核中开发的给定工作流，并提供管理和监测其执行所需的基础设施。

本发明的实施方式的一个特征是消除了访问实际代码或数据的任何要求，无论是对于给定工作流还是可以由给定工作流对其进行操作。这样，这些系统仅需要访问描述给定工作流本身的元数据，这允许创建允许最终用户利用核在本地机器上设计工作流的过程。一旦被设计，这些工作流被“构建”，即被部署到最终用户拥有和/或控制的基础设施。

将工作流部署到最终用户拥有或控制的基础设施时，形成工作流引擎的一部分的程序代码将元数据传输到例如位于一个或更多个云服务器上的远程工作流数据库。描述给定工作流和/或其状态的元数据可以包括但不限于诸如以下信息，构成给定工作流的一个或更多个任务的名称、构成给定工作流的各种任务之间的依赖关系，所述依赖关系可以包括时间依赖关系和数据依赖关系的各种组合等。工作流管理员可以使用该信息来重建“虚拟”版本的工作流，然后可以使用“虚拟”版本的工作流来编排真实的工作流，而不需要知道关于任何给定工作流的任何实质性信息。当最终用户希望执行已被定义和构建的给定工作流时，他或她会向工作流管理员发送信号，这可以包括在工作流管理员向最终用户公开的用户接口上选择按钮，或者通过API或CLI调用来发出命令。

当试图发起工作流的远程执行时，工作流管理员使用最终用户先前保存到工作流数据库中的元数据来加载所请求的工作流，并将虚拟版本置于“调度”状态。代理(根据一个实施方式是最终用户在他或她的私有基础设施上运行的一小段代码)监听工作流进入调度的状态，并且在发现这样的事件时，指示工作流引擎在最终用户的基础设施上部署工作流。当工作流运行时，代理将状态改变更新传送回工作流管理员以存储在工作流数据库中。对驻留在远程工作流基础设施处的虚拟工作流的任何修改——例如在任务实际运行之前手动将其置于特定状态——可以类似地同步回最终用户的基础设施。

因此，工作流管理员可以公开工作流数据库中的数据以向最终用户提供这样的最终用户已经构建的一个或更多个工作流的完整概述，例如，什么任务正在运行、什么任务失败、每个任务花费多长时间以及与那些工作流交互的方式，而不需要那些最终用户共享其敏感代码或数据。

系统基础设施

图1示出了如本文所述的用于混合部署工作流执行的系统的一个实施方式。本发明的混合部署模型涉及最终用户在他或她的本地工作流基础设施102中部署小型代理104的过程。根据一个实施方式的代理104是最终用户安装在他或她的本地工作流基础设施102上的小型应用，以从工作流注册表106检索工作流以供工作流引擎108执行，创建工作流基础设施，以及可选地拆除所述基础设施，这也可以由工作流引擎108执行。当代理104运行时，它轮询需要被执行的新工作流(范围限定在该特定的最终用户)。一旦代理104识别出这样的工作流以供执行，该工作流就被传递给在最终用户计算基础设施110上运行该工作流的工作流引擎108。

根据本发明的各种实施方式，代理104可以利用附加技术——例如，长期有效的连接、作为网络服务器的执行代理、以及本领域技术人员已知的其他消息交换技术——来识别需要执行的工作流，本文中也称为“轮询”。例如，将落入本文所用的“轮询”的范围内的另一种技术是部署一个或更多个网络套接字，与半双工替选方案例如HTTP轮询相比，所述网络套接字使代理104与远程工作流基础设施之间能够以更低的开销进行交互，这有助于向给定代理104和从给定代理104进行实时数据传输。本领域技术人员认识到允许向代理和从代理进行数据传输的其他技术落入如本文所用的“轮询”的范围内。

根据某些实施方式，可选的副进程在代理上运行，被称为资源管理器，资源管理器负责检查工作流状态以识别已完成的工作流，并删除在执行特定工作流期间创建的任何动态基础设施。资源管理器是防止最终用户计算基础设施因工作流基础设施变得超限的额外安全步骤。

除工作流管理员代理104之外，根据本实施方式的本地工作流基础设施102还包括保存工作流程序代码例如二进制文件、依赖关系等的工作流注册表106。工作流注册表106可以是适合于维护最终用户正在构建以部署在最终用户计算基础设施110上的工作流的任何形式的数据存储，例如，Docker注册表、NoSQL数据库、关系数据库系统、面向对象数据库系统、混合对象关系数据库、或本领域普通技术人员已知的其他合适的数据存储。实际上，工作流注册表可以包括可操作成或能够存储文件、二进制大对象(“BLOB”)或任何任意数字内容的任何文件系统。可以用于部署工作流注册表的技术的具体示例包括但不限于DockerHub、Google容器注册表等。

最后，工作流引擎108需要平台来运行由工作流管理员代理104指示执行的给定工作流。工作流引擎108可以运行给定工作流的示例性平台包括但不限于Kubernetes、Yarn、Mesos等。

在某些实施方式中，工作流包含作为元数据的附加信息项，包括存储(其中存储了工作流程序代码和所需数据)和执行环境(对如何运行工作流的描述)。工作流管理员代理104使用这些元数据片段从工作流注册表106检索工作流程序代码，并指示工作流引擎108在最终用户计算基础设施上执行它。

最终用户提供授权令牌(未图示)以允许工作流管理员代理104通过网络120与远程工作流基础设施112进行自身认证。通过轮询和交换元数据的过程，工作流管理员116和工作流管理员代理104经由API服务器118和网络120能够由工作流引擎108在最终用户计算基础设施110上部署和执行工作流，而无需与这样的基础设施“交谈”。这样，网络周界安全性或完整性保持完好无损，同时仍允许远程执行一个或更多个本地工作流。

这种体系结构布置允许最终用户管理他们自己的计算基础设施，这进一步允许他们维护他们的进程的安全性，并且可能更重要的是，维护他们对已经到位并由客户投入的任何安全协议和进程的使用。另外，用户编写的“结果处理程序”可以用于将任务的输出存储在私有位置，仅使得用于检索这样的数据的必要元数据(例如，位置的URI)被传送回到工作流管理员。

工作流构建和部署

图2示出了用于部署由最终用户构建的工作流的方法的一个实施方式。工作流构建的示例性方法开始于最终用户编写新工作流或修改现有工作流以重新部署在最终用户计算基础设施上，步骤202。步骤202涉及最终用户编写工作流以执行所需的一组任务，这将在本文给出的用例中更详细地阐述。在示例性ETL工作流中，最终用户试图获取和存储信息以供将来分析，这可能需要从多个源中提取、清理和合并数据。根据本发明的实施方式的工作流允许最终用户在进行提取、变换和加载操作时任意定义工作流中任务之间的依赖关系，这包括使用输入参数来进一步定义给定任务的范围或到给定任务的输入。这样，当定义给定工作流时，最终用户不被锁定到严格的线性管线中，而是具有灵活性，例如，如下表1中所示：

表1

一旦完成新工作流或对现有工作流的修改，最终用户就将工作流部署到本地工作流注册表，步骤204，本地工作流注册表是本地工作流基础设施的一部分并且通常在最终用户的控制下。

执行检查以确定将工作流部署到工作流注册表是否成功，步骤206。在该检查确定工作流部署到工作流注册表失败的情况下，系统向最终用户抛出报告错误状态的错误并中止工作流的部署，步骤208。此时程序流可以终止或者返回到步骤202，其中最终用户修改工作流中的错误，步骤202，或者尝试将工作流重新传输到工作流注册表，步骤204。

一旦在工作流注册表处成功地存储了工作流(例如，实际程序代码、二进制文件、依赖项等)的传输，步骤206，工作流管理员代理就尝试将给定工作流的元数据例如描述工作流的结构的数据(其中工作流被存储在本地工作流基础设施中)以及正确执行工作流的方式部署到工作流数据库，步骤210。与步骤2016类似，执行检查以确定将工作流部署到工作流数据库是否成功，步骤212。在该检查确定工作流部署到工作流数据库失败的情况下，系统向最终用户抛出报告错误状态的错误并中止工作流的部署，步骤208。在元数据成功传输到工作流数据库的情况下，部署完成，并且工作流代理和工作流引擎等待来自工作流管理员的执行工作流的指令，步骤214。

工作流执行

工作流执行可以开始于在远程工作流基础设施上运行的工作流管理员标识要运行的工作流，步骤304，如在图3示出的示例性程序流执行中所阐述的。根据图3的实施方式，工作流元数据可以标识根据其要执行工作流的调度。如果工作流具有调度，则工作流管理员可以根据该调度自动创建新工作流运行。调度只不过是生成新工作流运行的便捷方式；最终用户仍然可以在自动调度的运行旁边创建临时运行(即使它们具有相同的开始时间)。唯一的区别是自动调度的运行可以具有根据某些实施方式设置的“auto_scheduled＝真”标志。

工作流管理员可以将工作流标记为准备执行，这可以包括工作流管理员将工作流放置在队列中。本地工作流基础设施处的代理通过API服务器定期轮询工作流管理员，API服务器在工作流管理员代理与工作流管理员之间形成通信路径，直到代理接收到指示工作流可用于执行的信号，步骤306。当工作流管理员代理准备好获取可用于执行的工作流时，工作流管理员将工作流存储和环境信息传输到工作流引擎，步骤308。工作流存储和环境信息的传输可以包括在与工作流引擎接口之前由工作流管理员代理接收到这样的信息。

代理是在本地工作流基础设施上执行以编排一个或更多个工作流的本地执行的小型进程，并且可操作成在安装有工作流引擎的任何环境中运行。代理有助于实现贯穿本说明书描述的工作流执行的混合方法，这意味着工作流执行驻留在本地工作流基础设施例如客户基础设施内，并且仅向远程工作流基础设施发出请求。本发明的所有组件遵循通信范例。

代理可以可选地运行专用HTTP服务器以用作健康检查服务。常见的编排服务(例如，supervisord、docker、kubernetes等)可以使用健康检查来检查给定的代理是否正常运行，并且如果给定的代理没有正常运行，则采取措施(例如重新启动代理)。如果启用，则实施方式提供可经由所配置的代理地址处的特定路径来获得HTTP健康检查数据。如果代理正在运行且健康，则该路由返回给定值，例如200OK；否则，HTTP服务器返回错误。

在本地工作流基础设施处执行检查以确定是否需要附加基础设施来完成当前工作流的执行，步骤310。在步骤310处的检查评估为真的情况下，程序流被引导到步骤312，可在工作流管理员代理的控制下动作的工作流引擎在本地工作流基础设施处实例化适当完成正在执行的工作流所需的附加基础设施。

无论在步骤310处执行的评估的输出如何，程序流最终前进到工作流管理员代理指示工作流引擎根据在元数据中标识的指令从工作流注册表中提取工作流代码和相关资源的点，步骤314。一旦工作流引擎访问了工作流程序代码和工作流所依赖的任何所需资源，工作流引擎就执行工作流，步骤316。

根据某些实施方式，工作流执行(步骤316)根据调度发生。在这样的实施方式中，调度器信息可以作为与给定工作流相关联的元数据被发送到远程工作流基础设施，该元数据标识用于执行给定工作流的定时信息。如本领域技术人员所认识到的，调度对于在某些时间自动执行工作流是有用的。调度可以是简单的调度或复杂的多组件调度。根据一个实施方式的复杂调度定义时钟(以特定时间或时间间隔发出工作流执行事件)、过滤器(决定在执行时例如on_date、on_datetime、at_time等是否应当包括工作流)和调整(对通过过滤器的工作流进行修改，例如，添加时间间隔、提前到一周的下一天或未来一天等)。这三个组件允许用户将简单的功能组合成复杂的行为。结合图5更详细地描述使用调度元数据来协调调度一个或更多个工作流的执行。

在工作流的执行期间，执行检查以确定来自当前正被执行的任务的任何数据是否需要存储，步骤318。在任务数据需要存储的情况下，例如，任务的输出需要一定程度的持久性，因为它可以由一个或更多个下游进程依赖，可以根据最终用户将其编程为工作流的一部分的自定义结果处理程序来存储数据，步骤320。无论任何任务数据是否需要存储，工作流引擎将状态改变信息作为元数据传输到工作流管理员以存储在工作流数据库中，步骤322，其中元数据描述的实质性数据存储在工作流注册表中或以其他方式作为本地工作流基础设施的一部分。

关于数据处理，本文结合本发明的各种实施方式描述的混合执行模型允许客户控制代码和数据两者，确保两者都不会离开客户的内部生态系统。本文引用的数据是指来自构成给定工作流的任务的一个或更多个输入和/或输出。如本文所述，所有工作流执行都发生在客户基础设施内，例如，在客户控制下使用网络和计算资源，同时保持客户网络的完整性。

可以基于每工作流来传递数据持久性。可替选地，或者结合前述内容，可以在给定工作流内逐个任务地传递数据持久性。无论如何，当工作流必须写入数据以供以后访问时，就会发生持久性，可能例如结合任务重试(对到重试任务的一个或更多个上游输入调用结果方法)、任务队列(相当于重试，但是每当任务达到并发限值发生)、任务高速缓存(其中任务被设置为高速缓存其自己的结果)发生持久性。所有工作流执行，包括通过特定任务持久性的写入数据的调用，在客户基础设施上发生，没有在远程或云基础设施上执行客户代码。

在存储任何输出数据以及传输包括关于输出数据的任何描述的任何元数据之后，执行检查以确定工作流是否完成，步骤324。在工作流未完成的情况下，例如，存在工作流定义的附加任务或附加处理并且需要完成，程序流返回到步骤316，其中工作流引擎继续执行工作流，例如，执行工作流定义的下一任务。可替选地，完成处理并且结束例程，步骤302。

工作流执行

图4呈现了示出用于监测由工作流引擎在最终用户计算基础设施上运行的工作流并与之交互的方法的一个实施方式的流程图。根据图4的方法，工作流在本地工作流基础设施处的工作流引擎上运行，步骤402。当工作流引擎执行给定工作流时，工作流引擎执行检查以确定处理工作流是否导致状态改变，步骤404。类似地，根据某些实施方式，工作流引擎可能并行地执行检查以确定当前执行的任务是否需要存储在例如最终用户计算基础设施上的另一位置上的工作流注册表中，步骤406。

如果工作流引擎确定存在状态改变(步骤404)或者工作流正在存储输出数据(步骤406)，则工作流引擎生成描述事件的元数据。工作流管理器接收元数据，该元数据作为与工作流以及可能的特定任务相关联的更新的元数据存储在工作流数据库中，步骤408。如连接步骤404、406和408的虚线所示，该步骤408与该方法的其余步骤发生在过程之外。

根据一个实施方式，工作流数据库中的数据被公开为用于查询其中包含的元数据的完整的GraphQLAPI。可以经由GraphQL查询工作流数据库中的所有数据。这样，更新的元数据可用于最终用户询问和检索，步骤410。例如，下表2中所示的查询检索名称以“flow”结尾的所有工作流；他们最近的工作流运行的状态；以及该运行的五次任务运行的状态历史，按字母顺序排列。

表2

在执行检查以确定数据更新(步骤404和406)之后，执行另一检查以确定状态改变是否被接受或者这种改变是否导致错误状态，步骤412。在状态改变未被接受的情况下，工作流进入错误状态，这使得工作流终止，并且使得工作流引擎拆除被实例化以支持工作流的执行的任何工作流特定基础设施，步骤416。在状态改变更新被接受并且工作流未进入错误状态的情况下，执行检查以确定工作流是否处于终止状态，步骤414，例如，工作流标识的所有任务完成。在工作流处于终止状态的情况下，工作流引擎拆除被实例化以支持工作流的执行的任何工作流特定基础设施，步骤416。在状态改变被接受(步骤412)并且工作流未处于终止状态的情况下，程序流返回到步骤402，其中工作流继续在本地工作流基础设施处的工作流引擎上运行。

元数据

如本文所述，元数据提供抽象以允许对在本地工作流基础设施处定义的一个或更多个特定工作流的描述，这允许在不知道私有客户数据或基础设施细节的情况下进行远程执行和状态维护。更具体地，以编程方式围绕工作流对象的元数据片段对混合执行模型至关重要，因为它们允许最终用户工作流的编排(定义状态、状况等)，而无需与客户基础设施进行通信。这可以例如通过一系列精心设计的轮询操作来发生，由此给定工作流经由API服务器启动与工作流管理员的通信，以获得关于工作流进行方式的信息，例如基于构成工作流的一个或更多个其他任务的状态。

各种类型的可用元数据可用于描述工作流的不同方面，包括但不限于诸如通过任务和边缘的工作流结构、状态信息、工作流存储和执行步骤等方面。状态信息是元数据的特定项，其允许工作流管理员远程编排安全地发生在最终用户计算基础设施上的流。例如，当工作流完成任务时，工作流管理员代理经由API服务器将该状态元数据传送回工作流管理器。类似地，当给定工作流中的任何下游任务开始时，每个任务都可以查询API服务器，以询问作为进一步处理的先决条件的任何计算或输出的状态，即给定任务所依赖的任何任务成功完成的状态。这种报告和查询状态信息的过程能够实现诸如动态任务执行、并行工作流运行、手动干预、死锁预防的特征以及对于本领域普通技术人员而言明显的其他计算益处。

图5示出了根据本发明的一个实施方式的用于混合部署工作流执行的系统的替选实现方式。与图1的实施方式类似，图5的实施方式提供了云平台的便利性以及内部、内部部署的工作流管理解决方案的安全性。根据图5所示的通信流，云基础设施502经由其API 508接收来自客户基础设施504的请求作为元数据506。在云基础设施处拥有一组丰富的元数据510允许编排工作流而无需拥有关于底层代码或资源的任何知识。表3呈现了根据本发明的一个实施方式的用于实现示例性工作流的说明性伪代码：

表3

如来自表3的以上定义的伪代码所示，工作流512a和512b生成最多为N的数字列表，对数字进行两次映射以对每一数字加一，将该数字列表缩减到最终总和，然后记录该总和。工作流中包含的两条关键信息是属性“存储”和“环境”。Storage指定开发者存储工作流512a和512b的实际业务逻辑514的位置。这可以包括从Docker(www.docker.com)注册表到S3对象存储(aws.amazon.com/s3)到本地或远程文件系统等任何地方。根据本示例，系统使用Docker来存储包括工作流的实际业务逻辑。本领域技术人员认识到，可操作成或能够存储文件、BLOB或任何任意数字内容的任何文件系统被设想为落入本发明的各种实施方式的范围内。Environment是如下方式：指定开发者希望工作流如何执行以及工作流可能具有哪些基础设施需求。在该示例中，开发者利用静态Dask来执行工作流。

一旦开发者定义了工作流512a和512b，他或她必须向云基础设施502注册工作流512a和512b，这涉及如本文广泛描述的混合通信。相应地，包括工作流512a和512b的实际业务逻辑514没有一个被发送到云基础设施，而是仅在它们之间交换表示工作流的结构的元数据。在表3的工作流中标识的Docker存储负责保存实际的工作流代码，而元数据被发送到云基础设施。在云基础设施处接收到元数据时，系统可以注册工作流并指定工作流所属的项目。元数据是云基础设施接收到的关于给定工作流的唯一信息，它包括关于工作流的一般结构以及系统存储工作流的位置的信息。知道工作流被存储的位置意味着云基础设施既不知道工作流的内容，也无权访问这种代码和数据。

在向云基础设施502注册工作流时，客户基础设施504实例化一个或更多个代理516，其可以包括在客户或其开发者选择的任何任意平台上的实例化。例如，客户可以选择将代理516部署为Kubernetes代理，Kubernetes代理是如下代理：被设计为与KubernetesAPI服务器直接交互以在Kubernetes集群上运行作为作业的工作流。其他代理平台也落入本发明的各种实施方式的范围内，并且旨在基于开发者正在编辑的工作流的特定需求而可互换，例如，AWS Fargate集群。

给定代理516负责经由API 508轮询云基础设施502以标识被调度执行的写入元数据数据存储510的工作流，其可以由调度器518组件标识，调度器518组件可以位于云基础设施502的一部分或远离云基础设施502。这满足了本发明的实施方式被设计为满足的一个要求：能够在客户拥有和操作的基础设施504内编排客户工作流。通过云基础设施502根本不与用户基础设施504对话完全消除了障碍；相反，客户基础设施504经由API508发起工作请求。一旦找到工作，代理516将在其选择的相关平台上运行工作流。根据一个实施方式，代理516经由API 508定期轮询调度器518以标识被调度运行的任何工作流。在未利用调度器518的情况下，可以通过如下在客户基础设施504中执行给定工作流：向云基础设施的用户接口520、向云基础设施的命令行接口522发出运行给定工作流的命令，或者以编程方式将请求524直接发送到API 508。

代理516经由API 508查询调度器518以确定工作流由工作流引擎526被调度执行，根据一个实施方式，工作流引擎526通过将存储在元数据数据存储中的工作流的元数据置于“调度”状态来传送。一旦代理516获取由工作流引擎526执行的工作流，代理就将工作流状态更新为“已提交”，这也被发送到云基础设施以存储在元数据数据存储510中。这有助于确保仅一个代理516选择可用工作流512a和512b用于执行。根据一个实施方式，代理515在它开始执行其当前工作流的同时继续轮询调度器518以寻找需要执行的工作流。

一旦工作流使用工作流512a和512b中指定的环境在工作流引擎526中运行，代理515开始经由API 508将状态更新传送回云基础设施以存储在元数据数据存储510中。给定工作流的示例性任务状态管线看起来像：挂起→运行→成功。下面的表4呈现了根据一个实施方式被发送到云基础设施502以存储在元数据数据存储510中的示例性元数据状态对象：

表4

诸如表4的示例性元数据的状态元数据可以用于多种目的，包括但不限于确保幂等性、报告状况、构建可视化、提供分析等。一旦工作流的运行完成，工作流经由工作流引擎526将其最终状态报告回云基础设施，这可以导致进入“完成”的状态。这样，本发明的实施方式为客户提供了利用云基础设施来在客户基础设施内编排工作流的执行的能力，而云基础设施从未进入客户基础设施或知道工作流的内容。

通用工作流用例

与建立在本文所公开的系统和方法上的大多数用例一样，该过程通常以工作流实例化开始。例如，假设在基础设施的客户环境中工作的开发者具有他或她希望经由远程API例如经由来自图1的API服务器118提供的API编排的两个任务(“任务A”和“任务B”)。进一步假设第一任务(任务A)向第二任务(任务B)提供一段私有数据，以便第二任务实现其期望结果，该期望结果可以是客户环境中的任何任意结果，也是执行工作流的期望结果。在编写定义这些任务的代码后，用户需要配置或以其他方式标识特定于API的配置的几个附加片段：

·给定任务A的处理要求，“结果”配置指定任务A应将其数据存储在何处；这样的中间存储位置的示例可能包括但不限于云存储、客户环境中的本地存储设备等。重要的是，该存储位置的标识完全在开发者的判断和控制内，例如，他或她可以确保这种临时或中间数据从不离开客户环境。

·工作流的“存储”配置；与结果配置类似，这是开发者可以实际保存他或她的代码的位置，所述代码定义了构成工作流的步骤以及与其相关联的过程。与结果配置类似，该位置完全在开发者的控制和判断内；API服务不需要直接访问这样的位置。

在该配置就位的情况下，开发者现在通过API调用向远程API“注册”该工作流的存在。该注册步骤仅向API传输足够的元数据，以便允许具有适当访问的用户检索工作流配置和代码。例如，在开发者将工作流配置存储在Docker注册表内的情况下，注册步骤将仅发送标识图像名称、标签和注册表URL的API元数据。API接收元数据并注册其可用性以供执行。

既然已知工作流存在，工作流可以被调度运行。为了正确执行给定工作流，开发者需要在客户机环境内实例化“代理”进程，该“代理”进程可以访问远程API以及在工作流的配置和实例化期间由开发者标识的结果和存储位置。客户在他或她的基础设施内运行该进程，并且可以根据任何可接受的风险级别来配置访问控制。代理可操作成轮询远程API以获悉调度的工作，一旦发现调度的工作，就使API提供上述的元数据，该元数据指示代理在何处可以找到用于执行工作流的代码。提供了该数据，代理访问代码并将其提交以在客户基础设施内执行。注意，与其他实施方式的情况一样，远程API不需要访问客户基础设施，而是代理充当API与客户的私有基础设施之间的安全的内部中间人。

当代码运行时，它可以向API报告回状态更新(例如，“我仍在运行”、“我没有成功完成”等)。根据本用例，当任务A完成并产生私有数据时，结果配置将数据存储在客户基础设施内并告知API位置，根据某些实施方式，位置可能只是文件名，尽管复杂的位置标识符被设想为落入本发明的实施方式的范围内。与存储一样，关键方面是结果配置提供足够的信息，使得具有适当访问凭证的开发者可以检索数据。然后将数据提供给任务B，它的运行方式与A类似。如果任务B失败，或者将来重新运行，则它可以从适当的位置提取任务A产生的数据，因为它在开发者控制内的许可环境中运行。这样，远程API现在有任务A和任务B的运行的记录以及在执行任一任务期间出现的任何相关问题，所有这些都不需要使用本文提供的工作流执行服务实际访问客户的私有基础设施。在配置之外，为了允许根据本发明的各种实施方式的工作流自动化而对客户基础设施提出的唯一要求是：客户基础设施可操作成或以其他方式能够与托管API和相关资源的位置向外通信。

特定工作流用例

通过说明前述公开内容的应用的一个实施方式的特定用例，假设客户或其他最终用户希望自动化每晚午夜运行的任意工作流。示例性工作流从站点下载数据，处理数据，然后将处理后的数据插入到关系数据库中的表中的行中，所述关系数据库驻留在由客户操作或以其他方式控制的基础设施上。

客户首先在本地工作流基础设施中安装必要的组件，其提供在最终用户计算基础设施上编辑和执行工作流。最终用户利用这些组件以编程方式构建包含三个“任务”的工作流或“流”对象，并且其中用户提供自定义“运行”函数，其描述任务在由工作流引擎执行时的行为。在示例性工作流中，三个任务将具有分别下载数据，处理下载的数据和插入处理后的数据的“运行”函数或业务逻辑。以下是该示例性工作流在伪代码中可能看起来的情况，使用了一些使编写任务尽可能简单的便利方法：

注意，每个任务调用其他一些函数(本文中未定义)。用户可以将任何业务逻辑置于任务内；工作流引擎是不可知的，只要它满足围绕程序代码期望的输入和它返回的输出的一些简单契约。

当工作流管理员调用工作流底部的函数时(在“流”块中)，应用实际上不运行这些函数，而是如本文所述，实际上在工作流引擎的控制下在客户计算基础设施上运行。相反，工作流管理器可以观察调用并建立计算图。例如，在第一次调用(“download＝download_data()”)之后，工作流管理器知道“download”任务是工作流的一部分。在第二行中，程序代码将该任务传递给另一任务(“process_data”)，并且工作流管理员了解到那两个任务连接在计算图中，以及数据如何在其间移动。

当在远程工作流基础设施上执行工作流时，在本特定实施方式中自动发生多个事件：

·构建Docker容器，该Docker容器包含客户先前构建的工作流，该Docker容器允许工作流管理器实例化该确切脚本并指示工作流引擎在将来的时间运行工作流；

·该容器被存储在客户控制的Docker注册表中。由于此脚本在客户或本地工作流基础设施上运行，而不是在远程或云工作流基础设施上运行，这意味着工作流程序代码在任何时候都不会流向第三方或以其他方式离开客户的控制；以及

·描述计算图但不描述其代码的JSON文档被生成并被发送到远程或云工作流基础设施以存储在工作流数据库中。根据该文档，工作流管理员可以以“虚拟”形式重建工作流及其所有组成任务——这些虚拟工作流具有相同的名称、id、调度、连接等，但没有关键的run()函数。

根据该混合体系结构要执行的后续步骤是创建执行工作流的环境。根据一个实施方式，本地工作流基础设施托管能够部署较早建立的容器的执行集群。在该集群上安装工作流管理员代理，该工作流管理员代理经由API服务器连续轮询工作流管理员以查看是否应当运行任何工作流。如果代理发现要运行的工作流，则它启动适当的容器，该容器提供有认证令牌，以便该容器可以将其进度传送回工作流管理员。

从客户的角度来看，以下是可能的：

1)他或她可以登录到工作流管理员，以查看(除其他外)可用的工作流及其运行历史，其中经由GUI向客户提供这样的数据。

2)可以导航到由客户最初构建的工作流，并且可以指示工作流管理员运行该工作流或其他工作流。

3)工作流管理员将虚拟工作流置于“调度”状态，这是代理正在监测的事件。当代理看到所调度的工作流时，工作流引擎启动代码并经由API服务器将进度传送回工作流管理员，从而允许最终用户看到三个任务被创建、运行和(希望)在成功状态下完成。

当代理部署容器时，它只是在本地工作流基础设施上运行工作流引擎，打开钩子，以便工作流引擎从工作流管理员检索最新的任务状态信息，报告对那些状态的任何改变。与单独使用工作流引擎相比，这提供了一些优势。例如，假设任务之一失败并且需要重试。任务之一以期望的开始时间进入“重试”状态。工作流管理器和代理可以检测到该状态时间何时过去，用最新信息(包括该任务的重试状态)自动启动工作流引擎。然后，工作流引擎可以鉴于提供的更新的状态信息适当地处理任务。

在没有远程工作流基础设施的情况下模仿该行为是可能的，但需要将“重试”状态存储在持久层中，内省状态以了解开始时间，运行进程以在正确的时间正确地重启工作流，提供经认证的API以允许更新所存储的状态信息，然后将“重试”状态和所有其他状态提供给工作流引擎。这样，远程工作流基础设施不仅仅是工作流引擎的“受管版本”，而是提供管理和状态特征，其最终提供改进工作流引擎的功能和操作的结构。实际上，本文中描述的混合工作流编排模型通过如下满足本领域的需求：一方面提供数据和代码执行的分叉，其紧密地绑定到客户基础设施并在客户基础设施的控制内，另一方面提供编排、错误浮现、调度和监测，其驻留在远程云基础设施中。

迄今为止已经描述的本发明的实施方式可以向最终用户和作为软件即服务(“SaaS”)平台的管理员公开，从而允许这些方轻松地部署和执行实施方式的工作流自动化方面。例如，图6示出了呈现提供关于客户的工作流管理环境的细节的管理仪表板的网络接口602。通过仪表板602，客户可以查看关于项目604的总体信息(例如，一个或更多个工作流和相关联的任务)以及关于在客户基础设施上操作的先前定义的工作流606和代理608的详细信息。图6的示例性仪表板UI 602呈现与一段或更多段程序代码相关联的多个信息面板，这些程序代码可操作成查询底层数据源并呈现结果信息以供显示。例如，这样的信息面板可以包括但不限于：用于可视化零个或更多个工作流运行的整体结果历史的UI 610，关于聚合工作流执行的卷起的概要信息612，任何报告的错误信息614，被调度用于未来执行的工作流的标识616，概括的活动信息618，关于任何失败的工作流运行620的细节以及客户已经部署在本地或客户基础设施上的活动代理的标识624。

如上所述，图6的仪表板的实施方式包括呈现UI以允许客户查看、交互和管理零个或更多个远程代理的控件，这些远程代理可能限于当前连接的那些远程代理。在图7的示例中，选择了代理选项卡704，这导致仪表板702访问结合本发明的各种实施方式描述的软件组件和数据存储，以呈现关于零个或更多个定义的代理的信息，其中UI在单独的面板UI元素中显示给定代理。在示例性实施方式中，两个面板UI元素呈现关于第一代理710和第二代理712的信息。仪表板702向客户显示的代理信息包括但不限于：关于最后时间和自代理最后运行起经过的时间的信息714，代理与之一起工作的工作流引擎的版本信息716，安全令牌标识信息718，以及在一个或更多个数据存储中查看数据的控件720。

图8呈现了交互式API(例如本文中描述的关于远程或云基础设施的API)的示例性UI。根据图8的UI 802，交互式API呈现包括查询构建面板804和交互式结果面板806的分割面板接口。在使用中，希望对数据存储进行查询的用户可以在查询构建器面板804中提供包括查询的程序代码808。在查询构建器面板804下面的程序代码(未图示)将包括查询的程序代码808打包以供API评估或执行，API返回结果集810，结果集810被在交互式结果面板下面的程序代码接收以供显示。

作为工作流执行的一部分，本发明的实施方式包括记录功能以跟踪成功的任务执行以及可能由工作流执行产生的任何问题。图9呈现了向维护详述工作流执行事件的日志的数据存储提供窗口的用户接口902。根据图9的示例性接口902，底层编程组件查询相关数据存储并可视化结果集904，在本实施方式中，结果集904基于每任务，其中任务与各种工作流交错，这些工作流可能相互依赖或者可能不相互依赖。

图10呈现了工作流可视化引擎的示例性UI 1002，其允许用户可视化构成工作流的任务例如1004、1006和1008。除任务之外，示例性工作流还定义了存在于任何两个或更多个给定任务之间的关系或依赖关系1010。示例性UI 1002示出由“运行状态”指示符1012指示的进程内任务，以及关于在当前工作流的执行期间经过的时间量的指示1014。因此，图10的工作流可视化接口1002允许客户或管理员根据元数据确定任务和工作流名称、任务和工作流状态以及依赖关系，而无需访问客户或本地基础设施。

图1至图10是允许说明本发明的概念性图示。本领域技术人员应当理解，本发明的实施方式的各个方面可以以硬件、固件、软件或其组合来实现。在这样的实施方式中，各种组件和/或步骤将以硬件、固件和/或软件实现以执行本发明的功能。也就是说，同一块硬件、固件或软件模块可以执行一个或更多个所示的框(例如，组件或步骤)。

在软件实现方式中，计算机软件(例如，程序或其他指令)和/或数据作为计算机程序产品的一部分存储在机器可读介质上，并经由可移动存储驱动器、硬盘驱动器或通信接口加载到计算机系统或其他设备或机器中。计算机程序(也称为计算机控制逻辑或计算机可读程序代码)存储在主和/或辅助存储器中，并由一个或更多个处理器(控制器等)执行，以使一个或更多个处理器执行本文所述的本发明的功能。在本文档中，术语“机器可读介质”、“计算机程序介质”和“计算机可用介质”通常用于指诸如随机存取存储器(RAM)；只读存储器(ROM)；可移动存储单元(例如，磁盘或光盘、闪存设备等)；硬盘等的介质。

值得注意的是，上面的附图和示例并不意味着将本发明的范围限制到单个实施方式，因为通过互换所描述或示出的元素中的一些或全部，其他实施方式是可能的。此外，在可以使用已知组件部分或完全实现本发明的某些元素的情况下，仅描述这样的已知组件中的对于理解本发明所必需的那些部分，并且省略这样的已知组件的其他部分的详细描述，以免模糊本发明。在本说明书中，除非本文另有明确说明，否则示出单一组件的实施方式不应必然限于包括多个相同组件的其他实施方式，反之亦然。此外，申请人不打算将说明书或权利要求书中的任何术语赋予不常见或特殊的含义，除非明确地这样阐述。此外，本发明包括本文通过说明方式提及的已知组件的当前和未来的已知等同物。

具体实施方式的上述描述将如此充分揭示本发明的一般性质，使得其他人可以在不脱离本发明的一般概念的情况下通过应用相关领域的技术内的知识(包括所引用的并通过引用并入本文的文献的内容)容易地修改这样的具体实施方式和/或使其适应各种应用，而无需过多的实验。因此，基于本文所提出的教导和指导，这种适应和修改旨在在所公开的实施方式的等同物的含义和范围内。应理解，本文的措辞或术语是出于描述而非限制的目的，使得本说明书的术语或措辞应由本领域技术人员根据本文提出的教导和指导并结合相关领域技术人员的知识来解释。

虽然上面已经描述了本发明的各种实施方式，但是应当理解，它们是作为示例而非限制来呈现的。对于相关领域的技术人员明显的是，在不脱离本发明的精神和范围的情况下，可以在形式和细节上进行各种改变。因此，本发明不应受到上述任何示例性实施方式的限制，而是应当仅根据所附权利要求及其等同物来限定。

Claims (14)

1.一种用于远程执行一个或更多个任意定义的工作流的系统，所述系统包括：

工作流引擎，所述工作流引擎可操作成在客户基础设施上执行给定工作流中定义的一个或更多个功能；

工作流管理员，所述工作流管理员有权访问工作流数据库，所述工作流数据库维护对所述给定工作流的状态进行描述的元数据，所述工作流管理员远离所述工作流引擎并且不在所述客户基础设施上运行；以及

工作流管理员代理，所述工作流管理员代理轮询所述工作流管理员以识别所述给定工作流何时处于被调度用于执行的状态，并且当所述给定工作流被调度时，向所述工作流引擎发出命令以从工作流注册表中检索所述给定工作流并在所述客户基础设施上执行所述给定工作流中定义的一个或更多个功能，所述工作流管理员代理将关于所述给定工作流的执行的状态信息传输给所述工作流管理员以存储在所述工作流数据库中。

2.根据权利要求1所述的系统，包括用于从所述工作流管理员代理接收请求和命令以转发给所述工作流管理员的API。

3.根据权利要求2所述的系统，其中，所述API从所述工作流管理员接收对请求和命令的响应以转发给所述工作流管理员代理。

4.根据权利要求3所述的系统，其中，所述工作流管理员响应于来自所述工作流管理员代理的请求查询所述工作流数据库以检索信息。

5.根据权利要求4所述的系统，其中，来自所述工作流管理员代理的请求包括关于需要执行的可用工作流的查询。

6.根据权利要求1所述的系统，其中，所述工作流注册表维护关于形成所述给定工作流的一部分的步骤的业务逻辑。

7.根据权利要求1所述的系统，其中，所述工作流引擎远离所述客户基础设施。

8.一种用于远程执行一个或更多个任意定义的工作流的方法，所述方法包括：

执行客户基础设施上的工作流管理员代理和云基础设施上的工作流管理员，所述工作流管理员远离工作流引擎；

向所述工作流管理员提供对工作流数据库的访问，所述工作流数据库维护对给定工作流的状态进行描述的元数据；

由所述工作流管理员代理轮询所述工作流管理员以识别所述给定工作流何时处于被调度用于执行的状态，

当所述给定工作流被调度用于执行时，由所述工作流管理员代理向所述工作流引擎发出命令，以从工作流注册表中检索所述给定工作流并在所述客户基础设施上执行所述给定工作流中定义的一个或更多个功能；以及

由所述工作流管理员代理将关于所述给定工作流的执行的状态信息传输给所述工作流管理员以存储在所述工作流数据库中。

9.根据权利要求1所述的方法，包括：

通过API从所述工作流管理员代理接收请求和命令；以及

将接收到的请求和命令转发给所述工作流管理员。

10.根据权利要求9所述的方法，包括：

通过所述API从所述工作流管理员接收对请求和命令的响应；以及

将接收到的对请求和命令的响应转发给所述工作流管理员代理。

11.根据权利要求10所述的方法，包括由所述工作流管理员响应于来自所述工作流管理员代理的请求查询所述工作流数据库以检索信息。

12.根据权利要求11所述的方法，其中，查询所述工作流数据库包括查询关于需要执行的可用工作流。

13.根据权利要求8所述的方法，包括在所述工作流注册表处维护关于形成所述给定工作流的一部分的步骤的业务逻辑。

14.根据权利要求1所述的系统，包括远离所述客户基础设施操作所述工作流引擎。

Images