CN114902185A - 将有向无环图用于部署指令的技术 - Google Patents

Abstract

公开了用于将有向无环图用于部署指令的技术。计算机实现的方法可以包括各种操作。指令可以由计算设备执行以执行与部署相关联的配置数据的解析。计算设备可以使第一有向无环图(DAG)被生成，第一DAG被用于基于解析部署第一资源。第二DAG可以被生成以用于基于解析部署执行目标，第二DAG指定部署的执行目标之间的依赖关系。计算设备可以基于解析生成链表数据结构，并且可以通过链表数据结构的遍历来部署计算系统。

Description

将有向无环图用于部署指令的技术

本申请是2020年1月20日提交的题为“TECHNIQUES FOR UTILIZING DIRECTEDACYCLIC GRAPHS FOR DEPLOYMENT INSTRUCTIONS”的第62/963,477号美国临时申请和2020年11月19日提交的题为“TECHNIQUES FOR UTILIZING DIRECTED ACYCLIC GRAPHS FORDEPLOYMENT INSTRUCTIONS”的第16/953,262号美国非临时申请的非临时申请并且根据35U.S.C.119(e)要求这两个申请的权益和优先权，这些申请的内容通过引用被整体并入以用于所有目的。

背景技术

当今，云基础设施服务利用许多单独的服务来跨云基础设施服务的许多区域(分别)供应和部署代码和配置。这些工具需要大量的手动工作来使用，尤其是考虑到供应通常是声明性的并且部署代码是命令性的。附加地，随着服务团队和区域数量的增长，云基础设施服务将需要继续增长。一些云基础设施服务部署到较大数量的较小区域的策略包括每区域的支出，这可能无法良好地扩展。

发明内容

公开了用于将有向无环图用于部署指令的技术。在一些实施例中，计算机实现的方法可以包括各种操作。指令可以由计算设备执行以执行与部署相关联的配置数据的解析。计算设备可以使第一有向无环图(DAG)被生成，第一DAG被用于基于解析部署第一资源(例如，软件服务)。第二DAG可以被生成以用于基于解析部署执行目标，第二DAG指定部署的执行目标之间的依赖关系。计算设备可以基于解析生成链表数据结构，并且可以通过链表数据结构的遍历来部署计算系统。

在其他实施例中，公开了一种用于将DAG用于部署指令的系统。该系统可以包括一个或多个处理器和存储计算机可执行指令的一个或多个存储器，当这些计算机可执行指令由一个或多个处理器执行时，配置一个或多个处理器以执行各种操作。计算设备可以执行指令以执行与计算系统的部署相关联的配置数据的一个或多个解析。计算设备可以使第一DAG被生成，第一DAG被用于至少部分地基于执行一个或多个解析来部署第一资源。计算设备可以生成第二DAG以用于至少部分地基于执行一个或多个解析来部署多个执行目标，第二DAG指定部署的执行目标之间的依赖关系。计算设备可以至少部分地基于执行一个或多个解析来生成链表数据结构，链表数据结构指定多个部署阶段之间的依赖关系。并且，计算设备可以至少部分地基于遍历链表数据结构、第二DAG和第一DAG来部署计算系统。

在其他实施例中，公开了一种用于将DAG用于部署指令的计算机可读存储介质，该计算机可读存储介质可以存储计算机可执行指令，当这些计算机可执行指令由一个或多个处理器执行时，使一个或多个处理器执行各种操作。计算设备可以执行指令以执行与计算系统的部署相关联的配置数据的一个或多个解析。计算设备可以使第一DAG被生成，第一DAG被用于至少部分地基于执行一个或多个解析来部署第一资源。计算设备可以生成第二DAG以用于至少部分地基于执行一个或多个解析来部署多个执行目标，第二DAG指定部署的执行目标之间的依赖关系。计算设备可以至少部分地基于执行一个或多个解析来生成链表数据结构，链表数据结构指定多个部署阶段之间的依赖关系。并且，计算设备可以至少部分地基于遍历链表数据结构、第二DAG和第一DAG来部署计算系统。

在其他实施例中，公开了一种装置。该装置可以包括用于执行本文公开的任何方法的步骤的部件。

在其他实施例中，公开了一种计算机程序产品。计算机程序产品可以包括计算机指令，当这些计算机指令由处理器执行时，实现本文公开的任何方法的步骤。

附图说明

为了容易地标识对任何特定元素或动作的讨论，附图标记中的一个或多个最高有效数字是指该元素首次被引入的图号。

图1是根据至少一个实施例的用于实现云基础设施编排服务的至少一些元素的架构的框图。

图2是根据至少一个实施例的用于实现云基础设施编排服务的至少一些元素的架构的框图。

图3是用于图示根据至少一个实施例的示例群组(flock)的流程图。

图4是用于图示根据至少一个实施例的示例群组的流程图。

图5是根据至少一个实施例的呈现与包括多个阶段和多个执行目标的发布有关的信息的用户接口。

图6是根据至少一个实施例的用于定义阶段列表和顺序的示例代码段。

图7是根据至少一个实施例的可由云基础设施编排服务(CIOS)生成以维护与一个或多个阶段相关联的列表和顺序的示例数据结构。

图8是根据至少一个实施例的用于定义执行目标的列表和顺序的示例代码段。

图9是根据至少一个实施例的可由云基础设施编排服务(CIOS)生成以维护与和阶段相关联的一个或多个执行目标相关联的列表和顺序的示例数据结构。

图10是根据至少一个实施例的用于在执行目标的资源之间建立显式和隐式依赖关系的示例代码段。

图11是根据至少一个实施例的用于在执行目标的资源之间建立显式和隐式依赖关系的示例代码段。

图12是根据至少一个实施例的对应于云计算系统的资源的示例有向无环图。

图13是图示了根据至少一个实施例的用于编排包括对至少一种能力的依赖关系的任务的执行的示例过程的流程图。

图14是根据至少一个实施例的遍历链表、执行目标有向无环图和能力有向无环图的计算机基础设施编排服务的示例处理流程。

图15是根据至少一个实施例的用于在计算机基础设施编排服务中使用有向无环图来部署计算系统的过程的流程图。

图16是用于图示根据至少一个实施例的分布式系统的框图。

图17是用于图示根据至少一个实施例的系统环境的一个或多个组件的框图，通过该系统环境由实施例系统的一个或多个组件提供的服务可被提供为云服务。

图18是其中可以实现本公开的各种实施例的示例计算机系统的框图。

具体实施方式

在一些示例中，基础设施即服务(IaaS)是一种特定类型的云计算。IaaS可以被配置为通过公共网络(例如，互联网)提供虚拟化计算资源。在一些示例中，IaaS是云计算服务的三个主要类别(或子类别)之一。大多数认为其他主要类别是软件即服务(SaaS)和平台即服务(PaaS)，并且有时SaaS可能被认为是更广泛的类别，其包含PaaS和IaaS两者，甚至有些认为IaaS也是PaaS的子类别。

在IaaS模型中，云计算提供商可以托管基础设施组件(例如，服务器、存储设备、网络节点(例如，硬件)、部署软件、平台虚拟化(例如，管理程序层)等)。

在一些情况下，IaaS提供商还可以提供多种服务来伴随那些基础设施组件(例如，计费、监控、日志记录、安全性、负载平衡和集群等)。因此，由于这些服务可能是策略驱动的，所以IaaS用户可能能够实现策略来驱动负载平衡以维护应用程序的可用性和性能。

在一些情况下，IaaS客户可以通过诸如互联网之类的广域网(WAN)访问资源和服务，并且可以使用云提供商的服务来安装应用程序堆栈的其余元素。例如，用户可以登录IaaS平台以创建虚拟机(VM)、在每个VM中安装操作系统(OS)、部署诸如数据库之类的中间件、为工作负载和备份创建存储桶以及甚至将企业软件安装到该VM。然后，客户可以使用提供商的服务来执行各种功能，包括平衡网络流量、解决应用程序问题、监控性能、管理灾难恢复等。

在大多数情况下，云计算模型将需要云提供商的参与。云提供商可以但不一定是专门提供(例如，销售)IaaS的第三方服务。实体也可以选择部署私有云，从而成为其自己的基础设施服务提供商。

在一些示例中，IaaS部署是将新应用程序或新版本放置到准备好的应用服务器等上的过程。它还可以包括准备服务器的过程(例如，安装库、守护进程等)。这通常由云提供商在管理程序层之下(例如，服务器、存储、网络硬件和虚拟化)管理。因此，客户可以负责(例如，在(例如，可以按需启动(spun up)的)自助服务虚拟机上等)处理(OS)、中间件和/或应用程序部署。

在一些示例中，IaaS供应可以指获取计算机或虚拟主机以供使用，以及甚至在它们上安装所需的库或服务。大多数情况下，部署不包括供应，并且供应可能需要先执行。

在一些情况下，对于IaaS供应存在两个不同的问题。首先，存在在任何东西运行之前供应初始基础设施集合的初始挑战。其次，存在一旦一切都已被供应，演进现有基础设施(例如，添加新服务、变更服务、移除服务等)的挑战。在一些情况下，可以通过使得基础设施的配置能够被声明性定义来解决这两个挑战。换句话说，基础设施(例如，什么组件被需要以及它们如何交互)可以由一个或多个配置文件定义。因此，基础设施的整体拓扑(例如，什么资源依赖于哪些，以及它们各自如何一起工作)可被声明性地描述。在一些情况下，一旦定义了拓扑，就可以生成创建和/或管理配置文件中描述的不同组件的工作流。

在一些实施例中，IaaS供应可以包括生成有向无环图(DAG)。DAG可以是包括任何合适数量的节点和边的有限有向图，其中每条边从一个节点指向另一个节点。节点和边可被布置以避免有向循环。即，DAG被布置为使得不存在从任何节点开始并遵循最终循环回相同节点的一致定向边序列的路线。IaaS供应可以包括解析对应于系统的一个或多个资源(例如，服务、软件资源等)的配置文件。单独的DAG可以针对每个资源被生成。每个资源的DAG可以定义该资源对系统的一个或多个其他资源(例如，服务、软件资源等)的能力的依赖关系。例如，第一DAG可被生成并用来部署第一资源(例如，软件服务，也被称为“计算服务”，诸如被配置为管理一个或多个用户的电子消息的电子邮件服务)。第一DAG可以指示第一资源对由第二资源提供的能力(例如，与第一资源不同的附加软件服务，诸如被配置为基于先前获取的凭证验证/认证用户身份的身份服务)的依赖关系。第一资源和/或第二资源可以各自地是由计算系统提供的多个服务中的一个服务。“能力”可以旨在指给定资源的功能的一部分(例如，第二资源验证/认证用户身份的能力)。过程可被实例化以遍历DAG。当与当前不可用的能力相对应的DAG的节点被达到时，过程可以向调度服务公布过程已达到对能力的依赖关系并且因此在其能够继续之前正在等待该特定能力变得可用的指示。当系统的各种资源被部署和/或引导时，这些资源可以在能力变得可用时向调度服务公布各种能力可用性的指示。如本文所使用的，术语“引导(boot)”、“正在引导(booting)”、“已引导(booted)”是指执行与特定资源(例如，软件/计算服务、计算设备等)相对应的操作的启动序列的过程。部署资源(例如，软件服务)可以包括引导和/或以其他方式使资源提供的功能的至少一部分(例如，一个或多个能力)可用。当调度服务确定特定能力变得可用时，它可以从它最后退出的点(例如，就在发布对能力的需求之后)重新启动过程。过程可以重新生成DAG并(例如，从最后访问的节点开始)重新开始遍历。通过利用每个资源的DAG，系统可以管理不同资源的能力之间的依赖关系，使得不再需要人类操作员手动启动复杂的系统。

在一些示例中，基础设施可以具有许多互连的元素。例如，可能存在一个或多个虚拟私有云(VPC)(例如，潜在按需的可配置和/或共享计算资源池)，也被称为核心网络。在一些示例中，还可以存在被供应以定义网络的安全性将如何被设置的一个或多个安全组规则以及一个或多个虚拟机(VM)。诸如负载平衡器、数据库等之类的其他基础设施元素也可以被供应。随着越来越多的基础设施元素被期望和/或添加，基础设施可以逐渐演进。

如上所述，供应基础设施的一种方式是声明性地描述它。因此，配置文件可以是仅描述上述每个基础设施组件以及它们如何交互的声明性文件。配置文件可以描述创建元素所需的资源和相关字段，然后引用先前描述的元素的其他元素可被描述。在一些示例中，供应工具然后可以生成用于创建和管理配置文件中描述的元素的工作流。

在一些情况下，供应工具的工作流可以被配置为执行各种命令。可被执行的一项功能是视图调和，其中供应工具可以将当前基础设施的视图(例如，基础设施的预期状态)与基础设施实际正如何运行进行比较。在一些情况下，执行视图调和功能可以包括查询各种资源提供者或基础设施资源以识别哪些资源实际正在运行。供应工具可以执行的另一个功能是计划生成，其中供应工具可以将实际运行的基础设施组件与供应工具希望状态看起来像什么(例如，期望的配置)进行比较。换句话说，计划生成功能可以确定需要做出哪些变更来使资源达到最新的预期。在一些情况下，第三功能是执行(例如，应用)功能，其中供应工具可以执行由计划生成功能生成的计划。

通常，供应工具可以被配置为获得配置文件，解析其中包括的声明性信息，并且以编程方式/自动确定资源需要被供应以执行计划的顺序。例如，如果VPC需要在安全组规则和VM被启动之前被启动，则在无需用户干预和/或无需该信息必须包括在配置文件中的情况下，供应工具将能够做出该决定并按该顺序实现启动。

在一些情况下，可以采用连续部署技术来实现跨各种虚拟计算环境的基础设施代码的部署。附加地，所描述的技术可以在这些环境内实现基础设施管理。在一些示例中，服务团队可以编写期望被部署到一个或多个但通常是许多不同的生产环境(例如，跨各种不同的地理位置，有时跨越整个世界)的代码。但是，在一些示例中，代码将被部署在其上的基础设施必须首先被设置。在一些情况下，供应可以手动完成，供应工具可用于供应资源，和/或一旦基础设施被供应，则部署工具可用于部署代码。

如上所述，通常存在用于处理基础设施资源的供应和代码的部署中的每一个以控制基础设施资源的两个不同的工具，其中这两个工具之间的编排被手动执行。然而，在一定规模上，手动实现总是导致偏差。因此，可以供应和部署虚拟基础设施的自动化工具实现用于实现虚拟云环境的更有效和更可靠的技术。

在一些示例中，当两个工具被使用时，当用户在供应阶段和部署阶段之间手动地对代码做出变更时可能出现问题。如本文所述，使用单个工具以用于供应和部署两者的技术可以通过使过程自动化而使得不存在用于手动代码变更的机会来缓解该情况。可能有这样的情况，对一个用户对一些东西进行编码的方式的轻微改变可能在部署阶段创建重大问题。在一些示例中，操作者第一次在新区域中执行动作(例如，代码中的打字错误)时，用打字错误编码的对象可能永远是那样。如果用该打字错误部署应用程序，并且应用程序对该打字错误不敏感(例如，它仍然起作用)，则有可能在将来的某个时间，附加的代码变更可能变得对该打字错误敏感，并使整个系统崩溃。因此，本文提供的技术可以移除通常可能导致问题的供应和部署之间的差距(gap)。

通常，建模部署是声明性的，使得配置文件可用于声明基础设施资源。例如，创建、读取、更新、删除(CRUD)指令通常用于使用一般代表状态转移(REST)概念(例如，REST应用程序编程接口(API))生成部署文件。但是，部署本身通常不遵循相同的概念。附加地，虽然基础设施供应工具倾向于真的强大和/或富有表现力，但部署工具倾向于关于它们可以执行的操作限制更多(例如，它们是命令性的而不是声明性的)。因此，长期以来一直需要一种能够在云环境内处理两种功能需求(例如，基础设施元素的供应和部署)的工具。

在一些示例中，本文描述了用于实现云基础设施编排服务(CIOS)的技术。如上面简要描述的，这样的技术可以被配置为管理云环境内基础设施资产的供应和部署。在一些情况下，CIOS可以包括两类服务：中心和区域组件(例如，CIOS中心和CIOS区域)。以下术语将在全文中被使用：

·基础设施组件——支持运行代码的长期存在的基础设施部分。

o示例：部署应用程序、负载平衡器、域名系统(DNS)条目、对象存储桶等。

·工件——正被部署到部署应用程序或Kubernetes引擎集群的代码，或正被应用于基础设施组件的配置信息(以下，“config”)。这些可能是只读资源。

·部署任务——通常与部署或测试代码相关联的短期任务。附加地，部署任务被建模为生存长度不超过创建它们的发布的资源。

o示例：“deploy$artifact to$environment”、“watch$alarm for 10minutes”、“execute$testSuite”或“wait for$manualApproval”

o例如，CIOS可以将部署编排器部署建模为创建在它完成时转换为可用状态的资源。

o由于CIOS维护其云基础设施服务声明性供应器的状态，因此CIOS可以控制这些短期资源的生命周期，因为它与发布相关。

·资源——可以CRUD的资源

o CIOS将上面列出的每个构造建模为资源。下一节详细讨论此建模。

·群组——CIOS的封装了控制区域及其所有组件的模型。主要为了对基础设施组件的所有权进行建模而存在并指向基础设施组件。

_·群组config——描述与单个服务相关联的所有基础设施组件、工件和部署任务的集合。

o每个群组只有一个群组config。群组config签入源控制。

o群组config是声明性的。他们希望CIOS提供领域、区域、ad和工件版本作为输入。

o群组是细粒度的——群组由单个服务和支持性基础设施组成。

·状态——群组中每个资源状态的时间点快照。

·发布——具体版本的群组config和它引用的每个工件的具体版本的元组。

o将发布视为描述可能尚不存在的状态。

·发布计划——CIOS将采取的把所有区域从其当前状态转换到发布所描述的状态的步骤集合。

o发布计划具有有限数量的步骤和明确定义的开始和结束时间。

·应用——这是一个名词。执行发布计划的单次尝试。执行变更了群组的当前状态。

CIOS可以被描述为将配置应用到下游系统(例如，全世界范围)的编排层。它被设计为允许全世界范围基础设施供应和代码部署而无需来自服务团队的手动工作(例如，在一些情况下超出初始批准)。CIOS的高级职责包括但不限于：

·向团队提供由CIOS管理的资源的当前状态的视图，包括任何正在进行的变更活动。

·帮助团队计划和发布新的变更。

·协调区域内跨各种下游系统的活动，以执行批准的发布计划而无需人工干预。

·协调跨地区/领域的活动以在全世界范围执行批准的发布计划。

在一些示例中，CIOS通过使团队能够经由签入代码向CIOS提供配置信息来处理登录(onboarding)。附加地，CIOS可以自动化更多的事情，因此与先前的实现相比，这是一项分量更重的实践。在一些情况下，CIOS通过为团队提供自动部署和测试代码的能力来处理预部署。在一些情况下，CIOS可以通过在团队构建新工件时实现自动生成计划以推出新工件(例如，全世界范围)来处理变更管理(CM)策略的编写。它可以通过检查每个区域的当前状态和当前CIOS config(其本身可以是工件)来做到这一点。附加地，团队可以检查这些计划，并可以通过变更CIOS config并要求CIOS重新计划来对计划进行迭代。一旦团队对计划满意，他们就可以创建引用计划的“发布”。然后计划可以被标记为被批准或被拒绝。虽然团队仍然可以编写CM，但他们只是CIOS计划的指向者。因此，团队可以花更少的时间来推理计划。计划更准确，因为它们是机器生成的。计划对于人类处理来说几乎太详细了；但是，它可以经由复杂的用户接口(UI)显示。

在一些示例中，CIOS可以通过自动执行部署计划来处理CM的执行。一旦发布计划被创建并批准，除非CIOS发起回滚，否则工程师将不再参与CM。在一些情况下，这可能需要团队将当前手动的任务自动化。在一些示例中，当CIOS在执行时检测到服务健康状况下降时，CIOS可以通过自动生成将群组返回到其原始(例如，预发布)状态的计划来处理回滚变更管理(CM)。在一些示例中，CIOS可以通过接收范围为CIOS管理的区域子集和/或资源子集的发布计划以及然后执行该计划来处理部署紧急/战术变更。

附加地，CIOS可以支持定义全自动全世界范围部署所必需的原语。例如，CIOS可以通过监控警报和执行集成测试来测量服务健康状况。在服务降级的情况下，CIOS可以帮助团队快速定义回滚行为，然后可以自动执行它。CIOS可以自动生成和显示发布计划并可以跟踪批准。在一些情况下，团队用来描述期望的部署行为的语言可以是声明性的。在一个系统中CIOS可以结合代码部署和基础设施config(例如，供应)的功能。CIOS还支持跨区域和跨区域内组件的灵活排序。团队可以经由签入config表达排序。团队可以以编程方式调用CIOS的计划和发布API。

图1描绘了用于图示用于至少实现CIOS中心102的技术的架构100。在一些示例中，CIOS中心102可以是在“群组”级别处理操作的服务。CIOS中心102有一些职责，包括但不限于：

·作为用于群组元数据变更和发布操作的认证网关。

·为群组存储群组元数据到部署工件和CIOS存储库的权威映射。

·跨阶段和目标协调全球发布。

·同步以实行比如“一次不超过一个正在进行的群组的发布”的策略。

·检测对群组配置(config)和工件的变更，并触发关于这样的变更的发布生成。

在一些示例中，源代码版本控制管理服务(SCVMS)104可以被配置为存储权威的群组配置，并且工件通知服务(ANS)106可以由CIOS中心102订阅，使得CIOS中心102可被通知新的工件构建。CIOS中心102然后可以将传入的变更映射到受影响的群组，并在期望的地方发起发布计划。附加地，在一些示例中，在到目标的发布之前，工件推送服务(APS)可以由CIOS中心102调用，以确保在发布之前成功发布所需的任何工件都存在于目标区域中。

在一些示例中，客户(例如，工程师)108可以调用CIOS中心102以CRUD群组和/或发布，并查看正在进行的CIOS活动的状态。群组管理服务110可以包括一个或多个API来操纵群组，查看/计划/批准服务112可以包括CRUD API来创建和批准计划，并查看所有CIOS管理的资源的状态的中心副本，变更监控服务114可以监视SCVMS 104以获取对群组config的变更，并且可以从ANS 106接收关于对其他工件的变更的通知，并且状态摄取器服务116可以在CIOS中心数据库(DB)118中创建区域状态的副本，使得查看/计划/批准112可以暴露它们。在一些示例中，CIOS中心DB 118可以是群组、计划和状态的DB。群组信息可以是权威的；而其他一切可以是来自CIOS区域120的数据的陈旧副本。CIOS中心102可以被配置为提供任何合适的部分和/或数量的用户接口(例如，用户接口500-1300)，用于呈现与群组、发布、基础设施组件、工件等相关的任何合适的数据。在一些实施例中，CIOS中心102可以经由与一个或多个发布相关的任何合适的接口数据来呈现。发布可以包括与一个或多个基础设施组件和/或对一个或多个应用程序(例如，工件)的一个或多个代码更改相关的任务的任何合适组合。CIOS中心102提供的用户接口的一些示例在下面关于图5-图13进行描述。

在一些示例中，工程师108可以(例如，通过入口代理群集122)对群组管理服务110执行API调用以创建群组列表。进行这样的API调用的协议可以是安全超文本传输协议(HTTPS)等。用于此操作的相关访问控制列表(ACL)可以包括局域网(LAN)124或其他私有连接。例如，CIOS可以管理/控制使用公共互联网将客户的本地数据中心或网络与CIOS连接的网络连接替代方案(例如，专用、租用和/或私有连接)。附加地，(例如，工程师108的)认证和授权可以由允许用户管理机器基础设施的预约系统门户(例如，预约服务)来执行。在一些情况下，CIOS中心102可以使用Java数据库连接(JDBC)等将群组元数据、计划和状态存储在中心DB 118中。在一些示例中，ANS 106可以被配置为在新工件已被发布时通知变更监控服务114。ANS 106可以使用HTTPS，并且认证和授权两者都可以由相互传输层安全服务来处理。附加地，在一些情况下，变更监控服务114可以轮询SCVMS 104以获取群组配置变更。此轮询可以使用安全外壳(SSH)或其他协议执行。变更监控服务114的认证可以由CIOS系统帐户处理，并且授权可以由SCVMS 104处理。

在一些示例中，工程师108可以使用查看/计划/批准服务112来进行以下操作中的一个或多个。工程师108可以通过调用CIOS中心102以生成和批准计划来计划和/或批准。工程师108可以通过调用CIOS中心102以查看全世界范围正在进行的CIOS活动的状态来查看。附加地，工程师108可以CIOS中心102查看全世界范围CIOS管理的资源的状态的副本。这些API调用(等)可以经由HTTPS协议或类似协议执行。附加地，相关的ACL可以由LAN 124控制，并且认证和授权两者都可以由预约服务处理。在一些示例中，查看/计划/批准服务112可以请求计划并(例如，使用HTTPS等)将计划批准推送到CIOS区域120的所有区域。相关的ACL可以使用由广域网(WAN)网关126管理的安全列表来控制。认证可以通过相互传输层安全来处理，并且授权可以通过各种身份策略来处理。此外，状态摄取器服务116可以监视CIOS区域120以获取作业状态或状态变更，使得CIOS可以根据请求(例如，也使用HTTPS等)提供它们的中心视图。针对此的ACLS也可以由WAN网关126处理，并且认证和授权两者都可以由相互传输层安全服务处理。

图2描绘了用于图示用于至少实现CIOS区域202的技术的架构200。在一些示例中，CIOS区域202是声明性供应和计划的大部分工作以及被批准的发布应用程序可以发生的地方。在一些情况下，CIOS区域202的每个实例都可以有可以在“执行目标”级别处理操作的区域前端。它可被配置为执行以下：

·处理来自CIOS中心102的传入操作的所有CIOS认证。

·实行针对给定的执行目标一次只有一个“执行”(计划/导入资源/应用计划)可以正在进行的规则。

·在声明性基础设施供应执行期间管理用于输入和输出的声明性供应工件的二进制工件存储。输入的示例是声明性基础设施供应配置文件和输入状态文件。典型的输出是最终状态文件。

·对于任何给定的执行，请求来自CIO执行器的工作以及对来自CIO执行器的结果的轮询。

在一些情况下，CIOS前端可以依赖于CIOS执行器206(本文中也被称为“调度器”)，其可以处理实际执行。在一些示例中，CIOS执行器在“执行”级别运行，并且它可以：

·跟踪可用工作者节点池

·查询传入的作业请求，并在可用时将它们分配给符合条件的工作者

·跟踪工作者状态和执行更新以用于向客户端报告

·经由租用协议检测死节点，并可以使分配给死节点的任务失败，这依赖于任务状态。

·提供取消/终止/暂停/恢复执行的设施，并可以将那些执行映射到设施上，以将取消/终止/恢复信息传递到工作者节点。

在一些情况下，CIOS执行器可以依赖于CIOS工作者，该CIOS执行器可以将用于执行的任务分配给工作者，并为工作者提供设施以更新作业进度。工作者服务在“任务”的粒度上操作。每个工作者是执行分配给该工作者的任务并报告任务状态和输出的代理。每个工作者可以：

·针对分配的工作项轮询执行器工作者API，并采取动作

以使分配状态与其本地状态匹配：

o启动用于轮询本地不存在的任务项的容器

o针对本地运行的没有对应分配任务项的容器终止容器

·报告作业状态

·使作业容器执行的输入和输出发生

·启动和监控声明性基础设施供应容器以用于进行针对执行目标的发布的实际工作。

CIOS工作者可以依赖于CIOS执行器来轮询来自CIOS执行器的工作者端点的工作并向其报告结果。对于所有协调，工作者可以依赖执行器。附加地，CIOS工作者还可以依赖于CIOS区域202，其中工作者服务从与区域前端服务相关联的一个或多个API读取输入并向其写入输出。输入示例是配置和启动状态文件以及导入映射。输出示例是声明性供应过程、输出声明性供应状态文件以及导入结果状态。

在一些示例中，CIOS区域202可以是用于管理CIOS的区域实例/部署的区域服务。CIOS区域202负责权威地存储和管理与特定区域有关的计划和状态。区域DB 204可以是用于特定区域中的状态和计划的CIOS DB。这是图1的中心DB 118的区域子集的权威副本。调度器206可以负责管理工作者群集容量，将任务分配给工作者，并保持对任务状态的跟踪。在一些情况下，任务DB 208是用于任务状态的另一个CIOS DB。此DB中的数据主要用于操作目的。附加地，工作者210可以是管理声明性供应镜像的Java虚拟机(JVM)群集。这些从调度器206接收指令并将结果传送给调度器206和CIOS区域202两者。CIOS容器212可以在其自己的私有docker 214容器中运行声明性供应动作。此容器不需要包含秘密。附加地，在一些示例中，签名代理216可以被配置为经由声明性供应工具防止秘密渗漏，以避免将秘密放入声明性供应镜像中。相反，CIOS可以在代理中执行请求签名或发起相互传输层安全(mTLS)服务。这也使得使用遵循FIPS的加密库更容易。

在一些示例中，CIOS中心102可以调用CIOS区域202以创建计划、推送批准、监视作业状态(服务主体)和提取声明性供应器状态(服务主体)。入口代理218可以被配置为ACL，并且各种身份策略可以用于认证和授权两者。替代地，在一些示例中，入口代理218可以用被配置为平衡传入请求、计划等的负载的负载平衡器代替。在一些情况下，CIOS区域202可以通过要求调度器206运行声明性供应器来运行声明性供应器。工作者210可以询问调度器206它应该运行什么，并且可以在完成时向调度器206报告状态。在一些情况下，mTLS可以为CIOS区域202和工作者210处理认证和授权两者。附加地，当工作者210需要运行声明性供应器时，它通过与本地docker 214交互来在docker容器中这么做。此阶段的认证可由本地unix套接字处理。docker协议可用于此最后一步；但是，HTTPS可以用于先前的步骤。

在一些实施例中，CIOS区域202可以被配置为提供任何合适的部分和/或数量的用户接口(例如，用户接口500-1300)，用于呈现与群组、发布、基础设施组件、工件等相关的任何合适的数据。在一些实施例中，CIOS区域202可以经由与一个或多个发布相关的任何合适的接口数据来呈现。发布可以包括与一个或多个基础设施组件和/或对一个或多个应用程序(例如，工件)的一个或多个代码更改相关的任务的任何合适的组合。CIOS区域202提供的用户接口的一些示例在下面关于图5-图13进行描述。

在一些示例中，CIOS容器212使声明性供应器能够(经由API)与签名代理216交互，而声明性供应器认为它正在调用各种CIOS服务。签名代理216对声明性供应器的每个调用实例侦听只有该声明性供应器知道的一个临时端口。签名代理216可以发起请求签名或mTLS，并且可以将声明性供应器的调用传递给服务飞地(enclave)内的其他CIOS服务。在一些情况下，签名代理216还可以与一个或多个公共CIOS服务220通信。例如，签名代理216将在可能的情况下使用公共服务的内部端点。对于没有内部端点的服务，它必须使用出口代理222以到达外部端点。签名代理216的此使用可能不用于跨区域通信；例如，每个区域中的出口代理白名单可能仅用于该区域的公共IP范围。在一些示例中，工作者210然后可以将来自CIOS区域202中的声明性供应器的状态和日志持久保存，使得它们可以被渗漏到CIOS中心102。

使用CIOS，存在代表性客户经历的几个阶段：登录、预发布、全世界范围发布和战术发布。对于预发布阶段，以下是在新工件正被构建和发布工件至发布一(例如，R1)之间发生了什么的示例。这应该代替当前变更管理过程的一些或大部分。随着相关的工件被构建，CIOS可以使用“群组中一切东西的最新版本”自动生成发布。发布是具有具体输入(例如工件版本、领域、区域和ad)的群组config的具体版本。发布包含每区域一个前滚计划和描述区域排序的元数据。每个区域计划是声明性供应器将采取以实现该区域中的群组配置的操作集合。具有预发布环境的团队可以使用CIOS在所述环境中自动发布和测试软件。团队可以配置CIOS以自动测试回滚计划。团队将能够通过CIOS UI检查和批准发布。团队可以批准发布内的区域计划中的一些但不是全部。如果“一切东西的最新版本”没有产生合适的计划，则团队可以要求CIOS为精心挑选的工件版本生成计划。

对于全世界范围发布阶段，以下是团队如何执行今天的“正常CM”的明天版本的示例。一旦发布被批准，CIOS就将每个被批准的区域计划推送到相应的区域。CIOS在每个区域内独立行动以应用被批准的计划。CIOS将仅执行该区域计划中明确描述的动作集合。它将失败，而不是“独立思考”。CIOS UI向团队示出执行进度。CIOS UI在需要手动批准时提示团队。如果由于CIOS或下游服务中断而执行失败，则CIOS可以通知团队并可以提示他们下面的步骤(例如，中止、重试)。CIOS确实执行重试，但一些下游系统中断将超出其重试的意愿。如果由于服务健康状况下降或测试失败而执行失败，则CIOS将协助团队将群组回滚到其开始状态。CIOS将在其发起自动回滚时通知(例如，寻呼)团队。团队必须批准回滚计划，然后CIOS将执行它。

对于战术发布阶段，以下是团队可以如何执行“紧急CM”的明天版本的示例。当生成计划时，团队可能要求CIOS以若干方式将计划针对具体资源：以拓扑(例如，领域、区域、AD等)方式、按资源类型(例如，“仅度量config”或“仅部署编排服务部署”等)或以上的组合(例如，以分离的方式)。团队批准战术发布就像全世界范围发布一样。CIOS以类似方式编排它们。如果团队需要在存在活跃的全世界范围发布时部署战术发布，CIOS将停止在目标区域执行全世界范围发布，然后开始执行战术发布。

在一些示例中，声明性供应器的状态(例如，传统上是文件)是由声明性供应器管理的资源组的权威记录。它包含来自配置文件的每个资源的逻辑标识符与资源的实际标识符之间的映射。当声明性供应器正创建资源时，某些种类的故障可能阻止实际标识符被记录在状态中。当这发生时，对于声明性供应器，实际标识符丢失。这些可被称为“孤立资源”。

对于大多数资源，孤儿表示浪费——声明性供应器启动(例如)其忘记的实例，但相反在它下次运行时将启动另一个实例。对于具有唯一性约束或客户端提供的标识符的资源，孤儿阻止声明性供应器取得进展。例如，如果声明性供应器创建用户“nglass”并且失败孤立了它，那么声明性供应器的下一次运行将尝试创建“nglass”并失败，因为具有该用户名的用户已经存在。在一些情况下，孤儿只是向状态添加新资源时的问题。在一些情况下，声明性供应器的刷新行为可以自然地从失败中恢复以记录更新和删除。

CIOS需要在下游服务中断或CIOS自身中断的情况下是健壮的。因为CIOS可以利用声明性供应器来应用变更，这意味着围绕运行声明性供应器和维护声明性供应器状态应该存在健壮性。声明性供应器执行“小规模”重试——足以避免持续少量分钟数的中断。例如，云提供商将重试长达30分钟。持续超过30分钟的下游系统中断将导致声明性供应器失败。当声明性供应器失败时，它记录它在状态中成功做出的所有变更，然后退出。为了重试，CIOS必须重新执行声明性供应器。重新执行声明性供应器还允许CIOS在CIOS本身故障的情况下重试。在一些情况下，CIOS可以循环运行以下操作：

·刷新——声明性供应器调用GET API来检索在其状态中描述的每个资源的新快照。

·计划——考虑到最近刷新的当前状态，声明性供应器生成将实现期望的状态的计划(一组具体的API调用)。

·应用——声明性供应器执行计划中的步骤集合。

当执行声明性供应器时，CIOS可以总是运行所有这三个步骤。刷新操作有助于从未被记录的任何更新或删除中恢复。CIOS检查计划操作的结果并将其与被批准的发布计划进行比较。如果新生成的计划包含未在被批准的发布计划中的操作，则CIOS可能会失败并可以通知服务团队。

图3描绘了用于图示示例群组302的有向无环图(DAG)300。对于CIOS中的单个群组config，代码/config从签入到生产的进程可以从首次测试部署到最后生产(prod)部署自始至终被描述。在内部，CIOS调用进程中的每个元素，执行目标(ET)——这遍布我们的内部API，并且不泄漏到群组config中。CIOS基于群组config中定义的DAG 200执行ET。每个ET(例如，ET-1、ET-2、ET-3、ET-4、ET-5、ET-6和ET-7)大致是群组config描述的服务的一个副本。

图4描绘了图示示例群组402的DAG 400。在群组config中，CIOS关于团队如何表达此进程非常固执己见——他们必须使用云基础设施租赁和区域对其进行建模。团队不应使用领域来对进程建模。CIOS允许团队使用一个领域内的多个租赁和一个租赁内的多个区域。但是，CIOS不允许团队在一个租赁内使用相同的区域两次(尽管他们可以在一个领域内使用相同区域两次——在不同的租赁中)。DAG 400图示了用租赁和区域表达的来自图3的DAG 300的版本。此示例是用于覆盖服务，其中预生产ET位于生产区域中。服务飞地服务将在发布一中具有不稳定和稳定的租赁。在DAG 400中，IAD是华盛顿特区杜勒斯机场的区域机场代码，YYZ是安大略多伦多的区域机场代码，PHX、LHR和FRA分别是凤凰城、伦敦和法兰克福的区域机场代码，并且LUF和LFI用于两个不同的空军基地。

在一个实施例中，本文描述的CIOS和/或其他技术是对Terraform(声明性供应工具)、Tanden(代码生成工具)和Oracle部署编排器(ODO)中的每一个的改进。附加地，在一些示例中，本文描述的CIOS和/或其他技术可以使用Terraform、Tanden和ODO工具的至少部分来实现。

图5是根据至少一个实施例的呈现与包括多个阶段和多个执行目标的发布相关的信息的用户接口(UI)500。UI 500可以包括阶段区502和执行目标区504。阶段区502可以指示阶段的有序列表，诸如阶段506(例如，“R_n”)、阶段507(例如，“R_s”)、阶段508(例如，“R_e”)和阶段509(例如，“R_w”)。在一些实施例中，阶段顺序可被从左到右描绘，其中最左侧阶段将在其右侧阶段完成之前完成，继而该右侧阶段又将在其右侧阶段之前完成，等等。在一些实施例中，阶段的有序列表可以存储在诸如链表之类的任何合适的数据结构中。示例链表下面结合图7被更详细地讨论。

每个阶段可以与多个任务(例如，包括将一个或多个基础设施资源部署到一个或多个执行目标的任务)相关联。UI 500中所示的阶段列表包括四个阶段，但是任何合适数量的阶段可以被包括在阶段区502中以用于在一个或多个执行目标处部署基础设施资源。在一些实施例中，阶段区502内呈现的阶段的有序列表可以是可水平滚动的。阶段区502可以指示阶段的总数510、状态511、执行目标的已完成数量和/或总数513、以及群组配置标识符514。阶段的总数510可以指示包括在链表中的阶段的总数并且状态511可以指示发布的状态(例如，发布包括)。如图5所示，状态511是“正在应用”，但是状态511可以是任何合适的状态指示符(例如，“未开始”、“已完成”、“已失败”等)。如图5所示，执行目标的已完成数量和/或总数513指示在总共57个执行目标中对执行目标的24个部署已完成。执行目标的已完成数量和/或总数512可以以任何合适的方式呈现在UI 500上。群组配置标识符514在UI 500上呈现为“13380fb2832”，但是群组配置514可以以任何合适的方式呈现在UI 500上以用于传达对应于图5中描绘的发布的群组配置文件的唯一标识符。

对应于阶段的每个子区可以包括阶段标识符(例如，阶段标识符516)、总执行目标指示符(例如，总执行目标指示符518)、时间戳信息(例如，时间戳信息520)、执行目标跟踪器区(例如，执行目标跟踪器区522)，以及与阶段相关的任何其他合适的信息。例如，标识符516(例如，“R_s”)可以是用于唯一地识别阶段的任何合适的字母数字串。在一些实施例中，总执行目标指示符518可以相邻于标识符516呈现。总执行目标指示符518指示与给定阶段相关联的总执行目标的数量(例如，14)。

时间戳信息520可以包括分别与阶段开始和/或完成的时间相关联的开始时间和/或结束时间。在一些实施例中，时间戳信息520可以包括用于指示对应阶段的状态的任何合适的指示符(例如，“未开始”、“已失败”、“已完成”等)。在一些实施例中，与阶段相关的任何合适的信息可以在阶段区502中描绘。与每个阶段相关的信息可以类似地呈现，或者阶段信息的呈现可以被不同地格式化和/或可以包括比图5中描绘的更多或更少的信息。

执行目标跟踪器区(例如，阶段506的执行目标跟踪器区522)可以呈现在每个阶段内。每个阶段的执行目标跟踪器区可以包括一个或多个执行目标指示符(例如，执行目标指示符524、526和528)。每个执行目标指示符可以包括指示要被并发执行的任务(例如，到对应的执行目标的部署)的数量的数字。举例来说，执行目标指示符524指示到特定执行目标的部署可被执行。执行目标指示符526及其放置到执行目标指示符524的右侧指示到不同执行目标的另一部署要在对应于执行目标指示符524的第一任务完成之后被执行。执行目标指示符528及其放置到执行目标指示符526的右侧指示到12个不同执行目标的12个单独部署要在对应于执行目标指示符524的第二任务完成之后被执行。执行目标指示符524、526和528的组合共同描绘了有向无环图的折叠形式(例如，下文结合图9讨论的DAG 900)。

在一些实施例中，执行目标指示符524-528可以对应于数据结构，该数据结构被配置为维护与阶段相关联的执行目标的列表以及任务(例如，到每个执行目标的部署)要被执行的顺序。用于维护此列表和顺序的示例数据结构结合图9更详细地被描述。每个执行目标指示符可以包括环(例如，环530)。环可以被划分为对应于与执行目标指示符相关联的执行目标的数量的任何合适数量的部分。在所描绘的示例中，环530可以被分成12个相等的部分。环530的每个部分可以对应于特定的执行目标并且可以用与对应于该特定执行目标的任务状态相对应的颜色来着色。举例来说，环530可以(例如，经由九个绿色部分)指示到执行目标的九个部署已经完成。环530的(例如，着色为白色的)其余三个部分可以指示对应于三个执行目标的三个任务尚未开始。作为另一示例，环530的其余三个部分可以被着色为不同的颜色(例如，黄色)，从而指示对应的任务已经开始但尚未完成。因此，通过观察环530，用户能够快速且可见地识别与执行目标指示符528相关联的任务的当前状态。通过查看执行目标跟踪器区522内的执行目标指示符，用户可以确定到11个执行目标的部署完成并且3个正在进行中。在一些实施例中，每个执行目标指示符可以对应于与给定阶段(例如，“R_s”)相关联的有向无环图(DAG)(例如，图9的DAG 900)的节点。

执行目标区504可以包括执行目标栏532、进度栏534和操作栏536。执行目标栏532可以包括与结合给定阶段(例如，如图所示，阶段506)执行的任务(例如，部署)相对应的目标(例如，执行目标)的列表。在一些实施例中，执行目标栏532可以按时序或用于对任务执行进行排序的任何其他合适的方法来排序。进度栏534可以包括指示对应于每个执行目标的状态(例如，“已成功”、“未开始”、“进行中”等)的进度指示符的列表。操作栏536可以包括要相对于执行目标栏532中指示的给定执行目标执行的操作的列表。例如，操作栏536中包括的操作列表可以包括创建、读取、更新和删除(CRUD)操作等。

图6是根据至少一个实施例的用于定义阶段的列表和顺序的示例代码段600。如图6所示，在代码段600中定义了四个阶段。每个阶段被定义为“阶段”类型的资源并被分配标识符(例如，“R_n”、“R_s”、“R_e”和“R_n”)。如代码段600中所示，资源602、604、606和608对应于相应阶段。每个阶段可以包括一个或多个变量，其中的一个变量可以包括用于指示每个阶段的执行顺序的指示符。在一些实施例中，指示符可以指示对一个或多个其他阶段的依赖关系和/或缺乏依赖关系。举例来说，指示符618(例如，第5行的predecessors＝[])可以指示缺乏对任何其他阶段的依赖关系。这可以被系统解释为定义要被执行的第一阶段。指示符620(例如，predecessors＝[phase.R_n.variable 1])可用于通过包含对应于与另一个阶段(例如，阶段“R_n”)相关联的变量的值的分配来指示对另一个阶段(例如，阶段“R_n”)的依赖关系。类似地，指示符622可以指示对另一阶段(例如，阶段“R_s”，通过包含对应于与“R_s”相关联的变量的值的分配)的依赖关系，并且指示符624可以指示对又一个阶段(例如，阶段“R_e”，通过包含对应于与“R_e”相关联的变量的值的分配)的依赖关系。

在一些实施例中，代码段600可被包括在对应于发布的配置文件中。作为执行预处理过程的一部分，配置文件可以被解析/遍历一次或多次。在这些遍历之一中，代码段600可被分析以生成数据结构，利用该数据结构可以维护对应于一个或多个阶段的身份和执行顺序。图7描绘了可用于维护此信息的一个示例数据结构(例如，链表)。

指示符618-624可用于建立阶段要被执行的具体顺序。例如，如图6所描绘的，首先执行阶段“R_n”，然后是阶段“R_s”，然后是阶段“R_e”，然后是阶段“R_w”。应当理解，依赖关系可以指示在与给定阶段相关联的任务开始之前要完成的一个或多个其他阶段。尽管在图6中定义了四个阶段，但应当理解，可以以类似方式定义任何合适数量的阶段。

图7是由云基础设施编排服务(CIOS)生成以维护与一个或多个阶段相关联的列表和顺序的示例数据结构(例如，链表700)。链表700可被生成以识别如在图6的代码段600中定义的阶段和执行顺序。如图7所示，链表700包括四个节点702、704、706和708，该四个节点各自可以对应于在代码段600中定义的四个阶段中的一个阶段。链表的每个节点可以对应于被配置为存储与给定阶段相对应的任何合适的信息的数据对象。举例来说，给定节点可以存储与特定阶段相对应的任何合适数量的变量、标识符、数据结构、指针、引用等。作为非限制性示例，对应于阶段“R_n”的节点702可以存储在代码段600中定义为对应于阶段“R_n”的三个变量。链表700的每个节点可以包括对应于给定阶段的任何合适数量的变量。

链表的每个节点可以包括到链表中的另一个节点的指针/引用(在存在多个阶段的场景中)。举例来说，节点702可以包括对节点704的引用，节点704可以包括对节点706的引用，节点706可以包括对节点708的引用，节点708可以(例如，经由空指针)指示它是链表700的末端节点。在一些实施例中，这些指针/引用可以基于代码段600的指示符618-624来识别。

在一些实施例中，在执行时，CIOS可以至少部分地基于在节点702(例如，起始节点)开始遍历链表700来识别要执行特定阶段的顺序。这些阶段的执行可以利用存储在每个对应节点内的数据的任何合适组合。一旦完成对应于给定阶段的操作，CIOS就可以遍历到下一个阶段，将此过程重复任何合适的次数，直到对应于链表700的末端节点(例如，节点708)的操作已经完成。在一些实施例中，如果给定节点的操作不成功(例如，产生错误)，则CIOS可以不遍历到下一个节点，而是可以停止部署并返回通知以提醒用户该情况。

链表700的每个节点可以对应于被配置为识别和维护对应于一个或多个执行目标的执行顺序的数据结构。图8和图9更详细地讨论了这样的数据结构的定义和使用。应当理解，链表700可以提供由图5的UI 500用来呈现与阶段相关联的任何合适信息的信息(例如，标识符516、时间戳信息520、执行目标518等)。

图8是根据至少一个实施例的用于定义执行目标(例如，对应于特定阶段的执行目标)的列表和顺序的示例代码段800。如图8所示，在代码段800中定义了四个执行目标。每个执行目标被定义为“执行目标”类型的资源并被分配标识符(例如，“us-la”、“us-sj”、“us-sf”和“us-sd”)。如代码段800中所示，资源802-808各自对应于唯一的执行目标。每个执行目标可以与一个或多个变量相关联，其中一个变量可以包括用于指示每个阶段的执行顺序的指示符。在一些实施例中，指示符可以指示对一个或多个其他执行目标的一个或多个依赖关系和/或缺乏依赖关系。举例来说，指示符818(例如，第5行的predecessors＝[])可以指示缺乏对任何其他阶段的依赖关系。这可以被系统解释为定义第一执行目标。指示符620(例如，predecessors＝[execution_target.us-la.variable 1])可用于通过包含对应于与另一个执行目标(例如，执行目标“us-la”)相关联的变量的值的分配来指示对另一个执行目标(例如，阶段“us-la”)的依赖关系。类似地，指示符822可以指示对另一阶段(例如，执行目标“us-sj”，通过包含对应于与执行目标“us-sj”相关联的变量的值的分配)的依赖关系，并且指示符624可以指示对又一个阶段(例如，执行目标“us-sf”，通过包含对应于与执行目标“us-sf”相关联的变量的值的分配)的依赖关系。

在一些实施例中，代码段800可以被包括在对应于发布的配置文件(例如，包括代码段800的相同或不同的配置文件)中。作为执行预处理过程的一部分，配置文件可以被解析/遍历一次或多次。在这些遍历之一中，代码段800可被分析以生成数据结构，利用该数据结构可以维护对应于给定阶段的身份和执行目标的顺序。图9描绘了可用于维护此信息的一个示例数据结构(例如，有向无环图(DAG))。

指示符818-824可用于建立执行目标要被执行的具体顺序。例如，如图8所描绘的，首先执行与执行目标“us-la”相关联的任务，然后是与执行目标“us-sj”相关联的任务，然后是与执行目标“us-sf”相关联的任务，然后是与执行目标“us-sd”相关联的任务。应当理解，依赖关系可以指示一个或多个其他执行目标，在与给定执行目标相关联的任务开始之前要完成用于该一个或多个其他执行目标的对应任务。尽管在图8中定义了四个执行目标，但应当理解，可以以类似方式定义任何合适数量的阶段。在一些实施例中，执行目标可以共享共同的依赖关系(例如，相同的前驱定义)。共同的依赖关系可用来指示与共享共同的依赖关系的执行目标相关联的任务可被并发执行。

图9是根据至少一个实施例的可由云基础设施编排服务(CIOS)生成以维护与和阶段相关联的一个或多个执行目标相关联的列表和顺序的示例数据结构(例如，有向无环图(DAG)900)。根据至少一个实施例，DAG 900可以是响应于CIOS对与发布相关联的配置文件的一个或多个解析而生成的多个DAG之一。DAG 900的每个节点可以对应于单个执行目标。如图9所示，DAG 900包括六个节点(例如，节点902、904、906、908、910和912)，该六个节点可以各自对应于以与关于图8的代码段800描述的类似方式定义的六个执行目标之一。DAG900的每个节点可以对应于被配置为存储与给定执行目标相对应的任何合适信息的数据对象。举例来说，给定节点可以存储与特定执行目标相对应的任何合适数量的变量、标识符、数据结构、指针、引用等。

DAG 900的每个节点可以包括到DAG 90)中的一个或多个节点的指针/引用。举例来说，节点902可以包括对节点904的引用，该节点904可以包括对节点906-910的引用，这些节点906-910各自可以包括对节点912的引用，节点912可以(例如，经由空指针)指示它是DAG 900的末端节点。在一些实施例中，这些指针/引用可以基于类似于上面结合图8讨论的指示符818-824的指示符来识别。在一些实施例中，节点906、908和910可以共享对节点904的共同依赖关系，因此与节点906-910相关联的任务可以至少部分地被并发执行。在一些实施例中，节点912可以对应于依赖于节点906-910的执行目标。因此，与对应于节点912的执行目标相关联的任务仅在与对应于节点906-910的所有执行目标相关联的任务已经完成之后才可以被执行。

在一些实施例中，DAG 900可以与上面结合图7讨论的链表700的单个节点相关联。即，(例如，由DAG 900的节点识别和表示的)一个或多个执行目标可以与链表700的特定阶段(例如，单个节点)相关联。在一些实施例中，链表700的节点可以包括对DAG 900的引用，或者DAG 900的一个或多个节点可以包括对链表700的节点的引用。

在一些实施例中，CIOS可以遍历配置文件(例如，包括图8的代码段800)并且根据此遍历生成DAG 900。DAG 900的生成可以作为在运行时间之前或在运行时间执行的预处理过程的一部分来完成。一旦完成对应于给定执行目标的操作后，CIOS就可以遍历到下一个(或多个)执行目标，将此过程重复任何合适的次数，直到对应于DAG 900的一个或多个末端节点(例如，节点912)的操作已经完成。在一些实施例中，如果对应于给定节点的操作不成功(例如，产生错误)，则CIOS可以不遍历到下一个节点，而是可以返回通知以提醒用户该情况。

DAG 900的每个节点可以对应于被配置为识别和维护对应于一个或多个资源(例如，服务、软件模块等)的执行顺序的数据结构。图10-图12更详细地讨论了这样的数据结构(例如，能力的DAG)的定义和使用。举例来说，DAG 900的每个节点可以对应于另一个DAG(例如，图12的DAG 1200，指示资源和/或能力的列表和顺序，识别任务执行的顺序)。应当理解，DAG 900可以提供由图5的UI 500用来呈现与执行目标指示符524-528相关联的任何合适的信息的信息。因此，执行目标跟踪区522中描绘的信息可以描绘DAG 900的简化版本(对应于诸如阶段“R_s”之类的给定阶段的DAG)。DAG的简化版本可以将DAG 900的并发可执行节点压缩成单个节点(例如，参见描绘DAG的12个节点压缩成单个节点的执行目标指示符528)。在一些实施例中，CIOS可以至少部分地基于遍历DAG 900来部署基础设施资源和/或发布软件工件。具体任务和任务顺序如结合图10-图12所描述的被识别。

图10是根据至少一个实施例的用于在执行目标的资源之间建立显式和隐式依赖关系的示例代码段1000。代码段1000，如图10所示，包括两个模块1002和1004以及一个资源1006。模块1002和1004每个包括分别被示为“apps_example1”和“apps_example2”的名称1008和1010。模块可以包括任何合适长度的名称，包括任何合适的(一个或多个)字母数字字符。模块1002和1004可以定义用户希望引导或以其他方式供应的应用程序/服务。模块1002和1004可用于分别将应用程序部署到可用性域1和到可用性域2。资源1006可以包括多参数列表，该多参数列表包括在图10中示为“类型”的资源类型1012和在图10中示为“执行器”的资源名称1014。资源类型1012可以是适合部署的任何类型，资源名称1014可以是任何名称。

资源1006可以是一种能力并且可以包括隐式依赖关系、显式依赖关系或两者。如代码段1000中所描绘的，资源1006尝试将变量“variable1”分配给等于“module.apps_example1.variable1”的值，该值可经由apps_example1模块(例如，模块1002)访问。这旨在描绘在资源1006和模块1002之间形成的隐式依赖关系。形成的隐式依赖关系可以防止资源1006在模块1002已经完成部署之前执行。负责引导资源1006的过程可以接收模块1002已经完成部署的通知。通知可以由调度器(例如图2的调度器206)发送并且可以由负责引导资源1006的过程接收。形成的隐式依赖关系被认为是隐式的，因为如图10所示的资源1006没有直接定义模块1002和资源1006之间的依赖关系。

相反，资源1006在图10的第29行包括显式依赖关系，其包括显式定义资源1006和app_example2模块之间的依赖关系。如第29行的代码段1000中所描绘的，资源1006包括“depends_on＝apps_example2.variable2”。基于第29行的代码，显式依赖关系可被形成，并且显式依赖关系可以防止资源1006被部署，直到app_example2已被成功部署。一旦成功部署apps_example2，通知就可以由调度器发送并且可以由负责部署资源1006的过程接收。虽然图10的代码段1000包括包含一个隐式依赖关系和一个显式依赖关系的一个资源1006，但是普通技术人员应当理解，资源1006、隐式依赖关系和显式依赖关系的任何组合都可以用于实现CIOS的用户的目标。

CIOS(或上面讨论的诸如CIOS的声明性供应工具之类的声明性基础设施供应器)可用于解析包括代码段1000的配置文件。通过此解析，CIOS(或声明性供应供应器)可为每个资源、模块和/或能力生成编译和定义对其他资源、模块和/或能力的依赖关系的有序列表的有向无环图(DAG)。在尝试部署资源时，CIOS可以遍历DAG以识别资源何时依赖于另一个资源、模块和/或能力。每个资源的DAG可以指定隐式依赖关系、显式依赖关系或其组合，并且可以用于用CIOS引导或以其他方式部署对应资源。

图11是根据至少一个实施例的用于在执行目标的资源之间建立显式和隐式依赖关系的示例代码段1100。如图11所示的代码段1100包括四个资源1102、1104、1106和1108。资源1102、1104、1106和1108中的每个资源可以对应于一种能力并且可以包括隐式依赖关系、显式依赖关系或其组合。

如图11所示的资源1102包括被示为“object_storage”的名称1110，被示为“type1”的类型1112(例如，指示资源是一种能力)和多个变量(例如，变量1-3，尽管可以利用更多或更少的变量)。如图11所示的资源1104包括被示为“worker”的名称1116，以及被示为“depends_on＝type1.object_storage”的显式依赖关系1118。资源1102的参数列表包括可用于指代该资源的标识符1115(或名称1110可被类似地使用)。由于对type1.object_storage的引用，语句1118形成对资源1102的显式依赖关系。此显式依赖关系可以防止资源1104被部署，直到资源1102完成部署。如图11所示的资源1106包括被示为“peacock”的标识符1120、类型(例如，指示能力的“type1”)和多个变量(例如，variable1和variable2)。如图11所示的资源1108包括类型(例如，“type4”)、被示为“LB”的名称1124和语句1126(“count＝type1.peacock.exists”)。语句1126的使用可以形成对资源1106的隐式依赖关系。尽管资源1108不使用显式依赖关系构造(例如，“depends_on”)，但由于尝试向变量“count”分配等于能力“peacock”是否存在的值(如从语句type1.peacock.exists确定的)，因此隐式依赖关系仍然存在。因此，由于在第18行尝试的分配，资源1108可以直到资源1106“peacock”部署才被部署。虽然图11的代码段1100包括包含一个隐式依赖关系和一个显式依赖关系的四个资源1102、1104、1106和1108，但是相关领域的普通技术人员应该理解，资源、隐式依赖关系和显式依赖关系的任何组合都可以用于实现CIOS的用户的目标。

CIOS(或上面讨论的诸如CIOS的声明性供应工具之类的声明性基础设施供应器)可用于解析包括代码段1100的配置文件。通过此解析，CIOS(或声明性供应供应器)可为每个资源、模块和/或能力生成编译和定义对其他资源、模块和/或能力的依赖关系的有序列表的有向无环图(DAG)。在尝试部署资源时，CIOS可以遍历DAG以识别资源何时依赖于另一个资源、模块和/或另一个资源的能力。每个资源的DAG可以指定隐式依赖关系、显式依赖关系或其组合，并且可以用于用CIOS引导或以其他方式部署对应资源。

图12是根据至少一个实施例的对应于云计算系统的资源(例如，资源A)的示例有向无环图(DAG)1200。如图所示，DAG1200可以是有限有向图，其包括任何合适数量的节点(例如，如图12所示的六个节点)和边(例如，如图12所示的七个边)，其中如图12中所示每条边从一个节点指向另一个节点。节点和边可被布置为避免有向循环。即，DAG 1200被布置使得不存在从任何节点开始并遵循最终循环回到相同节点的一致定向的边序列的路线。最后一个节点(例如，节点“6”)可以指向空值或以其他方式指示DAG的末端。

尽管DAG 1200描绘了六个节点和七个边，但是DAG可以包括任何合适数量的节点和有向边。在一些实施例中，每个节点对应于一组操作(例如，用于执行诸如部署和/或引导资源(诸如资源A)之类的任务的操作)或操作的下一个节点所依赖的一组能力。每个DAG的有向边定义了执行这些操作的顺序和/或与节点相关联的操作子集和与紧接在该节点之前的节点相关联的能力子集之间的依赖关系。

作为一个简单的示例，DAG 1200的节点1、2、5、6旨在描绘对应于四个单独的操作集合的节点。基于图1200中描绘的边，每个节点的操作将按照与节点1、2、5和6的顺序相对应的顺序执行。节点3和4旨在描绘单独地与一个或多个依赖关系相对应的节点。举例来说，节点3可以与对应于节点5的操作对与不同资源(例如，资源B)相关联的能力的依赖关系相对应。类似地，节点4可以与对应于节点5的操作对与不同资源(例如，资源C)相关联的能力的依赖关系相对应。在一些实施例中，不同的能力节点(例如，识别对特定资源的能力/多个能力的依赖关系的节点)可以用于不同的资源，或者单个节点可以用来指定所有依赖关系，而不管依赖关系引用多少资源。因此，在一些实施例中，(例如，在节点3中识别的)对应于资源B的依赖关系和(例如，在节点4中识别的)对应于资源C的依赖关系可以组合在单个节点中。

DAG 1200可以以关于图10-图12更详细描述的方式遍历，以关于对其他资源的能力(或其他资源本身)的一个或多个依赖关系来编排用于在云计算环境中引导和/或部署资源的操作的执行。

图13是图示了根据至少一个实施例的用于编排包括对至少一种能力(例如，不同资源的能力)的依赖关系的任务(例如，部署资源)的执行的示例过程1300的流程图。如图13所示，过程流1300包括调度器1302(例如图2的调度器206)、工作者1304(例如图2的工作者210)和IP过程1306(例如图2的CIOS容器212)。

在1308处，调度器1302可以接收用于在区域中部署基础设施资源的任务，并且调度器1302可以将与任务有关的数据发送到工作者1304。在一些实施例中，调度器1302可以实例化工作者1304以处理资源(例如，服务)的部署。

在1310处，工作者1304可以实例化IP过程1306，该IP过程1306可以被配置为执行声明性基础设施供应器(例如，上面讨论的声明性供应工具Terraform)的实例。

在1312处，IP过程1306可以解析与部署相关联的配置文件(例如，包括图10和图11的代码段1000和/或1100的配置文件)以为特定资源生成有向无环图(DAG)。通过解析配置，IP过程1306(声明性基础设施供应器)可以识别对其他资源的能力的任何合适数量的隐式和/或显式依赖关系。一旦被识别，IP过程1306就构建指定用于引导和/或部署潜在具有一个或多个节点的资源的任务的DAG，该一个或多个节点(例如，根据在解析期间识别的隐式和/或显式依赖关系)对应于资源所依赖的能力。

在1314处，IP过程1306可以开始遍历DAG，在DAG的各种节点被到达时执行特定资源的部署和/或引导的至少一部分。根据DAG的至少一个节点，任何合适的操作可被执行以使对应于资源的功能的一部分变得可用。可能的是，对应于资源的功能的多个部分变得可用。在一些实施例中，IP过程1306可以向调度器1302发送指示资源的一个或多个能力现在可用的通知(未被描绘)。DAG的至少一个节点可以对应一个或多个其他资源的能力。当这些类型的节点被达到时，IP过程1306可以检查以查看能力是否可用。如果是这样，则IP过程1306可以继续其对DAG的遍历。

在1316处，IP过程1306可以达到对应于一个或多个其他资源的一个或多个能力的DAG的节点。在一些实施例中，IP过程1306可以确定与节点相关联的至少一个能力还不可用。

在1320处，响应于确定与节点相关联的至少一个能力不可用，IP过程1306可以向调度器1302发送数据，该数据指示对应于IP过程1306的资源所依赖的、已被确定为不可用的一个或多个能力。

在1322处，IP过程1306可以在潜在地存储状态信息之后退出，该状态信息指示DAG的哪些操作和/或节点已经完成和/或IP过程1306最后访问DAG的哪个特定节点。IP过程1306退出、被终止、被挂起或以其他方式停止执行。

在1324处，调度器1302可以存储指示特定资源正在等待资源恢复引导和/或用于部署目的所需的一个或多个特定能力的信息。

在1326处，调度器1302可以接收资源正在等待的一个或多个能力已经变得可用的一个或多个通知。在一些实施例中，当对应资源的各种能力变得可用时，调度器1302可以从其他IP过程接收指示那些能力的各种通知。调度器1302可以维护可用的各种能力和/或资源当前正在等待的各种能力的一个或多个记录。调度器1302可以从一个或多个记录中识别对应于IP过程1306的资源正在等待的特定能力/多个能力已经变得可用。因此，调度器1302可以进行到1328。

在1328处，响应于确定对应于IP过程1306的资源所依赖的能力已经变得可用，调度器1302可以返回到步骤1308，在该步骤中它向工作者1304发送与原始任务(例如，部署资源)有关的数据。在一些实施例中，调度器1302可以实例化新工作者或利用先前的工作者1304(如所描绘的)来继续处理与资源相关联的任务。工作者1304可以实例化IP过程(未描绘)，该IP过程可以被配置为执行解析配置文件以生成资源的DAG。IP过程可以访问存储的状态信息，以识别DAG中最后访问的节点(例如，对应于资源正在等待的一个或多个能力的节点)。由于一个或多个能力现在可用，IP过程可以以与上面讨论的类似方式继续其对DAG的遍历，在每个节点处执行操作会执行任务的一部分或者检查任务的下一部分所依赖的能力，直到DAG的末端节点的操作已经完成。

如上面讨论的类似的过程可以针对任务的每个资源来执行。举例来说，当部署具有多个资源(例如，多个服务)的系统时，过程1300可以代表每个资源执行，以在系统中部署每个资源。

图14是根据至少一个实施例的用于(例如，通过CIOS)执行发布的示例过程流程1400。在事件编号1处，调度器1402(例如图2的调度器206)可以向工作者1404(例如图2的工作者210)发送任务。任务可以包括部署计算系统或其子集，诸如将基础设施资源部署到一组执行目标。任务可以涉及遍历链表(例如，图7的链表700的示例)、DAG(例如，图9和图12分别的DAG 900和1200)、其组合、或用于部署计算系统的任何其他适合的任务。工作者1404可以从调度器206接收任务。工作者1404可以是工作者节点群集中的一个工作者节点。工作者节点群集可以包括用于部署计算系统的任何合适数量的工作者节点。工作者1404可以由调度器1402至少部分地基于工作者1404的能力来选择。例如，如果工作者1404在工作者节点群集中具有最大量的计算能力，则调度器1402可以选择将任务发送到工作者1404。

在事件编号2处，工作者1404可以执行配置文件1406的一个或多个解析/遍历。配置文件1406可以包括用于部署计算系统的指令，并且执行一个或多个解析可以导致识别期望被引导或以其他方式部署以用于部署计算系统的资源或其他能力。作为非限制性示例，配置文件1406可以包括图6、图8、图10和图11分别的代码段600、800、1000和1100。

在事件编号3处，来自配置文件1406的信息可以被发送到IP过程1408(例如，图2的IP过程212)。IP过程1408可以基于由工作者1404执行的一个或多个解析/遍历从配置文件1406接收信息。信息可以包括一组能力、执行目标或用于部署计算系统的任何其他合适的资源。

在事件编号4处，响应于从配置文件1406接收到信息，IP过程1408可以确定要部署用于部署计算系统的能力或任何其他合适资源的顺序。IP过程1408可以生成阶段的链表1410(例如图7的链表700的示例)、执行目标的DAG 1412(例如图9的DAG 900的示例)、能力的DAG 1414(例如图12的DAG 1200的示例)，或任何其他合适的列表、图形或数据结构。阶段的链表1410、执行目标的DAG 1412和能力的DAG 1414(被统称为“发布数据结构”)可以以任何合适的顺序生成。

发布数据结构可用于识别和确定执行发布的任务的顺序。例如，阶段的链表1410的每个节点对应于执行目标的DAG的单独实例(例如，执行目标的DAG 1412的示例)，其中执行目标的DAG的每个节点对应于能力的DAG(例如，能力的DAG 1414的示例)。IP过程1408可以从链表1400的第一节点开始，以识别执行目标的对应的DAG。执行目标的DAG的第一节点可用于识别能力的对应的DAG。与该能力的DAG相关联的任务可以根据能力的DAG来执行，并且一旦完成，IP过程1408就可以遍历到执行目标的DAG的下一个节点以识别下一个对应的能力的DAG。执行目标的DAG的每个节点可被遍历，并且当对应于这些节点的任务完成时，IP过程1408然后可以遍历到链表1400的下一个节点以识别下一个阶段。此过程可被重复任何合适的次数，直到与发布的最后阶段相关联的每个执行目标所关联的所有任务都已完成。

作为示例，在事件编号5处，达到阶段的链表1410的第一节点。IP过程1408识别对应于第一节点的执行目标的DAG。

在事件编号6处，达到执行目标的DAG 1412的第一节点。可以至少部分基于与执行目标的DAG 1412的第一节点相关联来识别能力的DAG 1414。

在事件编号7处，至少部分地基于遍历能力的DAG 1414来执行给定执行目标的任务。当那些任务已被完成时，IP过程1408可以遍历到执行目标的DAG的下一个节点，确定对应的能力的DAG，并根据遍历该能力的DAG来执行任务。此过程可以继续进行，直到与执行目标的DAG 1412的最后一个节点相关联的任务已经被执行。IP过程1408然后可以遍历到阶段的链表1410的下一个节点。事件编号5-7的操作可被重复任何合适的次数，直到与阶段的链表1410的最后一个节点相关联的所有执行目标相关联的所有任务已被执行。一旦完成任务、执行目标和/或阶段，IP过程1408就可以更新图5的UI 500或引起对图5的UI 500的更新以描绘任务、执行目标和/或阶段的当前状态。

在事件编号8处，IP过程1408向调度器1402发送发布的遍历完成的信号。调度器1402可以从IP过程1408接收信号并且可以广播计算系统准备好使用的通知。

图15是根据至少一个实施例的用于在CIOS中使用DAG部署计算系统的过程1500的流程图。在框1502处，CIOS可以执行用于执行对与计算系统的部署相关联的配置数据的一个或多个解析的指令。配置数据可被包括在配置文件中，并且在执行对配置数据的一个或多个解析时，CIOS可以确定要执行以部署计算系统的一组任务。包括在任务集合中的任务可以包括在执行目标处部署基础设施资源或用于部署计算系统的任何其他合适的任务。

在框1504处，CIOS使第一DAG(例如图12的DAG 1200)被生成以用于基于配置文件部署资源。第一DAG可以是能力的DAG，其可以概述要被引导或以其他方式部署的能力的特定顺序。第一DAG可以包括用于部署能力的任何合适数量的任务并且可以包括要被部署的能力之间的任何合适数量的依赖关系。

在框1506处，CIOS生成第二DAG(例如图9的DAG 900)，该第二DAG定义执行目标之间的依赖关系以用于基于配置文件部署执行目标。第二DAG可以是指定部署执行目标的顺序的执行目标的DAG。第二DAG可以包括用于部署计算系统的任何合适数量的执行目标，并且可以包括用于部署执行目标的任何合适数量的依赖关系。

在框1508处，CIOS生成基于配置文件指定阶段之间的依赖关系的链表(例如图7的链表700)。阶段可以包括第一DAG、第二DAG或其组合，并且链表可以定义执行阶段的顺序。链表的阶段可以串联执行，也可以不包括要被并行执行的任何阶段。链表可以包括用于部署计算系统的任何合适数量的阶段。

在框1510处，CIOS通过遍历第一DAG、第二DAG和链表来部署计算系统。CIOS可以遍历链表，并且第一DAG和第二DAG可被同时遍历(即第一DAG和第二DAG可被包括在链表中)。链表、第一DAG和第二DAG的成功遍历可以导致计算系统的成功部署。

说明性系统

图16-图18图示了根据各种实施例的用于实现本公开的方面的示例环境的方面。图16描绘了用于实现本公开的实施例的分布式系统1600的简化图。在所示实施例中，分布式系统1600包括一个或多个客户端计算设备1602、1604、1606和1608，它们被配置为通过一个或多个网络1610执行和操作客户端应用程序，诸如网络浏览器、专有客户端(例如，Oracle Forms)等。服务器1612可以经由网络1610与远程客户端计算设备1602、1604、1606和1608通信地耦合。

在各种实施例中，服务器1612可以适于运行诸如提供身份管理服务的服务和应用程序之类的一个或多个服务或软件应用程序。在某些实施例中，服务器1612还可以提供其他服务或软件应用程序可以包括非虚拟和虚拟环境。在一些实施例中，这些服务可以作为基于网络的服务或云服务或在软件即服务(SaaS)模型下被提供给客户端计算设备1602、1604、1606和/或1608的用户。操作客户端计算设备1602、1604、1606和/或1608的用户继而可以利用一个或多个客户端应用程序与服务器1612交互以利用由这些组件提供的服务。

在图16中描绘的配置中，系统1600的软件组件1618、1620和1622被示为在服务器1612上实现。在其他实施例中，系统1600的一个或多个组件和/或由这些组件提供的服务也可以由客户端计算设备1602、1604、1606和/或1608中的一个或多个来实现。操作客户端计算设备的用户然后可以利用一个或多个客户端应用程序来使用由这些组件提供的服务。这些组件可以以硬件、固件、软件或其组合实现。应当理解，可以不同于分布式系统1600的各种不同的系统配置是可能的。因此，图16中所示的实施例是用于实现实施例系统的分布式系统的一个示例并且不旨在进行限制。

客户端计算设备1602、1604、1606和/或1608可以包括各种类型的计算系统。例如，客户端计算设备可以包括运行诸如Microsoft Windows

之类的软件，和/或诸如iOS、Windows Phone、Android、BlackBerry 10、Palm OS等之类的多种移动操作系统的便携式手持设备(例如，

蜂窝电话、

计算平板电脑、个人数字助理(PDA))或可穿戴设备(例如，Google

头戴式显示器)。设备可以支持各种应用程序，诸如各种互联网相关的应用程序、电子邮件、短消息服务(SMS)应用程序，并且可以使用各种其他通信协议。客户端计算设备还可以包括通用个人计算机，包括例如运行各种版本的Microsoft

Apple

和/或Linux操作系统的个人计算机和/或膝上型计算机。客户端计算设备可以是运行各种可商用

或类UNIX操作系统(包括但不限于各种GNU/Linux操作系统，诸如例如Google Chrome OS)中的任何一种的工作站计算机。客户端计算设备还可以包括能够通过(一个或多个)网络1610进行通信的电子设备，诸如瘦客户端计算机、启用互联网的游戏系统(例如，具有或不具有

姿势输入设备的Microsoft Xbox游戏控制台)和/或个人消息传递设备。

尽管图16中的分布式系统1600被示出为具有四个客户端计算设备，但是任何数量的客户端计算设备可以被支持。其他设备(诸如具有传感器的设备等)可以与服务器1612交互。

分布式系统1600中的(一个或多个)网络1610可以是本领域技术人员熟悉的可以支持使用多种可用协议中的任一种的数据通信的任何类型的(一个或多个)网络，这些协议包括但不限于TCP/IP(传输控制协议/互联网协议)、SNA(系统网络架构)、IPX(互联网分组交换)、AppleTalk等。仅举例来说，(一个或多个)网络1610可以是局域网(LAN)，基于以太网、令牌环的网络、广域网、互联网、虚拟网络、虚拟专用网络(VPN)、内联网、外联网、公共交换电话网络(PSTN)、红外网络、无线网络(例如，在电气和电子学会(IEEE)1002.16协议套件、

和/或任何其他无线协议中的任何一个下操作的网络)，和/或这些和/或其他网络的任何组合。

服务器1612可由一个或多个通用计算机、专用服务器计算机(举例来说，包括PC(个人计算机)服务器、

服务器、中型服务器、大型计算机、机架式服务器等)、服务器场、服务器集群或任何其他适当的布置和/或组合组成。服务器1612可以包括运行虚拟操作系统的一个或多个虚拟机或涉及虚拟化的其他计算架构。一个或多个灵活的逻辑存储设备池可被虚拟化以维护服务器的虚拟存储设备。虚拟网络可以由服务器1612使用软件定义的联网来控制。在各种实施例中，服务器1612可以适于运行在前述公开中描述的一个或多个服务或软件应用程序。例如，服务器1612可以对应于根据本公开的实施例的用于执行上述处理的服务器。

服务器1612可以运行操作系统，包括上面讨论的那些中任一个，以及任何可商用的服务器操作系统。服务器1612还可以运行各种附加服务器应用程序和/或中间层应用程序中的任一个，包括HTTP(超文本传输协议)服务器、FTP(文件传输协议)服务器、CGI(公共网关接口)服务器、

服务器、数据库服务器等。示例性数据库服务器包括但不限于可从Oracle、Microsoft、Sybase、IBM(国际商业机器)等商用的数据库服务器。

在一些实现中，服务器1612可以包括一个或多个应用程序以分析和整合从客户端计算设备1602、1604、1606和1608的用户接收的数据馈送和/或事件更新。作为示例，数据馈送和/或事件更新可包括但不限于

馈送、

更新或从一个或多个第三方信息源和连续数据流接收的实时更新，其可包括与传感器数据应用程序、金融报价机、网络性能测量工具(例如，网络监控和流量管理应用程序)、点击流分析工具、汽车交通监控等相关的实时事件。服务器1612还可以包括一个或多个应用程序以经由客户端计算设备1602、1604、1606和1608的一个或多个显示设备来显示数据馈送和/或实时事件。

分布式系统1600还可以包括一个或多个数据库1614和1616。这些数据库可以提供一种用于存储诸如用户身份信息之类的信息和本公开的实施例使用的其他信息的机制。数据库1614和1616可以驻留在多种位置。举例来说，数据库1614和1616中的一个或多个可以驻留在服务器1612本地(和/或驻留在服务器1612中)的非暂时性存储介质上。替代地，数据库1614和1616可以远离服务器1612并且经由基于网络的连接或专用的连接来与服务器1612通信。在一组实施例中，数据库1614和1616可以驻留在存储区域网络(SAN)中。类似地，用于执行归属于服务器1612的功能的任何必要文件可以被本地存储在服务器1612上和/或远程存储，视情况而定。在一组实施例中，数据库1614和1616可以包括关系数据库，诸如由Oracle提供的数据库，其适于响应于SQL格式的命令来存储、更新和检索数据。

图17图示了可以用于实现本公开的实施例的示例计算机系统1700。在一些实施例中，计算机系统1700可用于实现上述各种服务器和计算机系统中的任何一个。如图17所示，计算机系统1700包括各种子系统，包括经由总线子系统1702与多个外围子系统通信的处理子系统1704。这些外围子系统可以包括处理加速单元1706、I/O子系统1708、存储子系统1718和通信子系统1724。存储子系统1718可以包括有形的计算机可读存储介质1722和系统存储器1710。

总线子系统1702提供了用于让计算机系统1700的各种组件和子系统按预期相互通信的机制。尽管总线子系统1702被示意性地示为单个总线，但是总线子系统的替代实施例可以利用多个总线。总线子系统1702可以是使用多种总线架构中的任何一种的若干类型的总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线和本地总线。例如，这样的架构可包括工业标准架构(ISA)总线、微通道架构(MCA)总线、增强型ISA(EISA)总线、视频电子标准协会(VESA)局部总线和可以被实现为按照IEEE P1386.1标准制造的夹层总线的外围组件互连(PCI)总线等。

处理子系统1704控制计算机系统1700的操作并且可以包括一个或多个处理单元1732、1734等。处理单元可以包括一个或多个处理器，包括单核或多核处理器、处理器的一个或多个核或其组合。在一些实施例中，处理子系统1704可以包括一个或多个专用协处理器，诸如图形处理器、数字信号处理器(DSP)等。在一些实施例中，处理子系统1704的一些或所有处理单元可以使用诸如专用集成电路(ASIC)或现场可编程门阵列(FPGA)之类的定制电路来实现。

在一些实施例中，处理子系统1704中的处理单元可以执行存储在系统存储器1710或计算机可读存储介质1722中的指令。在各种实施例中，处理单元可以执行多种程序或代码指令并且可以维护多个并发执行的程序或过程。在任何给定时间，要被执行的一些或全部程序代码可以驻留在系统存储器1710和/或计算机可读存储介质1710上，包括潜在地在一个或多个存储设备上。通过合适的编程，处理子系统1704可以提供上述各种功能以用于响应于使用模式来动态地修改文档(例如，网页)。

在某些实施例中，处理加速单元1706可被提供用于执行定制处理或用于卸载由处理子系统1704执行的一些处理以便加速由计算机系统1700执行的整体处理。

I/O子系统1708可以包括用于向计算机系统1700输入信息和/或用于从或经由计算机系统1700输出信息的设备和机制。通常，术语“输入设备”的使用旨在包括用于将信息输入到计算机系统1700的设备和机制的所有可能的类型。用户接口输入设备可包括，例如，键盘、诸如鼠标或轨迹球之类的指点设备、并入显示器中的触摸板或触摸屏、滚轮、点击轮、拨号盘、按钮、开关、小键盘、带有语音命令识别系统的音频输入设备、麦克风和其他类型的输入设备。用户接口输入设备还可以包括运动感测和/或姿势识别设备，诸如使用户能够控制输入设备(Microsoft

360游戏控制器，提供用于接收使用姿势和口头命令的输入的接口的设备)并与输入设备交互的Microsoft

运动传感器。用户接口输入设备还可以包括眼睛姿势识别设备，诸如Google

眨眼检测器，其检测来自用户的眼睛活动(例如，拍照和/或做出菜单选择时的“眨眼”)，并将眼睛姿势转换为到输入设备(例如，Google

)的输入。附加地，用户接口输入设备可以包括使用户能够通过语音命令与语音识别系统(例如，

导航器)进行交互的语音识别感测设备。

用户接口输入设备的其他示例包括但不限于三维(3D)鼠标、操纵杆或指点杆、游戏手柄和图形输入板，以及音频/视觉设备，诸如扬声器、数码相机、数码摄像机、便携式媒体播放器、网络摄像头、图像扫描仪、指纹扫描仪、条形码读取器3D扫描仪、3D打印机、激光测距仪和眼睛注视跟踪设备。附加地，用户接口输入设备可以包括例如医学成像输入设备，诸如计算机断层扫描、磁共振成像、正电子发射断层扫描、医学超声设备。用户接口输入设备还可以包括例如音频输入设备，诸如MIDI键盘、数字乐器等。

用户接口输出设备可包括显示子系统、指示灯或诸如音频输出设备之类的非视觉显示器等。显示子系统可以是阴极射线管(CRT)、诸如使用液晶显示器(LCD)或等离子显示器的平板设备之类的平板设备、投影设备、触摸屏等。通常，术语“输出设备”的使用旨在包括用于将信息从计算机系统1700输出到用户或其他计算机的所有可能类型的设备和机制。例如，用户接口输出设备可以包括但不限于以视觉方式运送文本、图形和音频/视频信息的多种显示设备，诸如监视器、打印机、扬声器、耳机、汽车导航系统、绘图仪、语音输出设备和调制解调器。

存储子系统1718提供用于存储由计算机系统1700使用的信息的储存库或数据存储库。存储子系统1718提供用于存储提供一些实施例的功能的基本编程和数据构造的有形非暂时性计算机可读存储介质。当由处理子系统1704执行时提供上面描述的功能的软件(程序、代码模块、指令)可以被存储在存储子系统1718中。这些软件可以由处理子系统1704的一个或多个处理单元执行。存储子系统1718还可以提供用于存储根据本公开被使用的数据的储存库。

存储子系统1718可以包括一个或多个非暂时性存储器设备，包括易失性和非易失性存储器设备。如图17所示，存储子系统1718包括系统存储器1710和计算机可读存储介质1722。系统存储器1710可以包括多个存储器，包括用于在程序执行期间存储指令和数据的易失性主随机存取存储器(RAM)和存储固定指令的非易失性只读存储器(ROM)或闪存。在一些实现中，包含有助于诸如在启动期间在计算机系统1700内的元素之间传输信息的基本例程的基本输入/输出系统(BIOS)可被存储在ROM中。RAM可以包含当前由处理子系统1704操作和执行的数据和/或程序模块。在一些实现中，系统存储器1710可以包括多种不同类型的存储器，诸如静态随机存取存储器(SRAM)或动态随机存取存储器(DRAM)。

举例来说，而非限制，如图17所示，系统存储器1710可以存储可以包括客户端应用程序、网络浏览器、中间层应用程序、关系数据库管理系统(RDBMS)等的应用程序1712、程序数据1714和操作系统1716。举例来说，操作系统1716可以包括各种版本的Microsoft

Apple

和/或Linux操作系统、多种可商用

或类UNIX操作系统(包括但不限于多种GNU/Linux操作系统、Google

OS等)和/或移动操作系统，诸如iOS、

Phone、

OS、

10OS和

OS操作系统。

计算机可读存储介质1722可以存储提供一些实施例的功能的编程和数据构造。当由处理子系统1704执行时处理器提供上面描述的功能的软件(程序、代码模块、指令)可以被存储在存储子系统1718中。举例来说，计算机可读存储介质1722可以包括非易失性存储器，诸如硬盘驱动器、磁盘驱动器、诸如CD ROM、DVD、

盘或其他光学介质之类的光盘驱动器。计算机可读存储介质1722可以包括但不限于

驱动器、闪存卡、通用串行总线(USB)闪存驱动器、安全数字(SD)卡、DVD盘、数字视频带等。计算机可读存储介质1722还可以包括基于非易失性存储器的固态驱动器(SSD)(诸如基于闪存的SSD、企业闪存驱动器、固态ROM等)、基于易失性存储器的SSD(诸如基于固态RAM、动态RAM、静态RAM、DRAM的SSD)、磁阻RAM(MRAM)SSD以及使用基于DRAM的SSD和基于闪存的SSD的组合的混合SSD。计算机可读介质1722可以为计算机系统1700提供计算机可读指令、数据结构、程序模块和其他数据的存储。

在某些实施例中，存储子系统1700还可以包括可以进一步被连接到计算机可读存储介质1722的计算机可读存储介质读取器1720。计算机可读存储介质1722与系统存储器1710一起并且，可选地与系统存储器1710组合，可以综合地表示远程、本地、固定和/或可移动存储设备以及用于存储计算机可读信息的存储介质。

在某些实施例中，计算机系统1700可以为执行一个或多个虚拟机提供支持。计算机系统1700可以执行诸如管理程序之类的程序以用于促进对虚拟机的配置和管理。每个虚拟机可以被分配存储器资源、计算资源(例如，处理器、核)、I/O资源和联网资源。每个虚拟机可以运行其自己的操作系统，该操作系统可以与由计算机系统1700执行的其他虚拟机执行的操作系统相同或不同。因此，多个操作系统可以潜在地由计算机系统1700并发运行。每个虚拟机通常独立于其他虚拟机运行。

通信子系统1724提供到其他计算机系统和网络的接口。通信子系统1724用作用于从计算机系统1700接收来自其他系统的数据以及向其他系统发送数据的接口。例如，通信子系统1724可以使计算机系统1700能够经由互联网建立到一个或多个客户端设备的通信信道，用于从客户端设备接收信息并将信息发送到客户端设备。附加地，通信子系统1724可用于将成功登录的通知或重新输入密码的通知从特权帐户管理器传送给请求用户。

通信子系统1724可以支持有线和/或无线通信协议两者。例如，在某些实施例中，通信子系统1724可以包括用于(例如，使用蜂窝电话技术、高级数据网络技术，诸如3G、4G或EDGE(全球演进的增强数据速率)、WiFi(IEEE 802.11系列标准，或其他移动通信技术，或其任何组合)访问无线语音和/或数据网络的射频(RF)收发器组件、全球定位系统(GPS)接收器组件和/或其他组件。在一些实施例中，除了无线接口之外或替代无线接口，通信子系统1724可以提供有线网络连接(例如，以太网)。

通信子系统1724可以接收和发送各种形式的数据。例如，在一些实施例中，通信子系统1724可以接收结构化和/或非结构化的数据馈送1726、事件流1728、事件更新1730等形式的输入通信。例如，通信子系统1724可以被配置为从社交媒体网络和/或其他通信服务的用户实时接收(或发送)数据馈送1726，诸如

馈送、

更新、诸如丰富站点摘要(RSS)馈送之类的网络馈送和/或来自一个或多个第三方信息源的实时更新。

在某些实施例中，通信子系统1724可以被配置为接收连续数据流形式的数据，该数据可以包括实时事件的事件流1728和/或事件更新1730，其本质上可以是连续的或无界的，而没有明确的结束。生成连续数据的应用程序的示例可以包括例如传感器数据应用程序、金融报价机、网络性能测量工具(例如，网络监控和流量管理应用程序)、点击流分析工具、汽车交通监控等。

通信子系统1724还可以被配置为将结构化和/或非结构化的数据馈送1726、事件流1728、事件更新1730等输出到一个或多个数据库，该一个或多个数据库可以与耦合到计算机系统1700的一个或多个流数据源计算机通信。

计算机系统1700可以是各种类型中的一种，包括手持便携式设备(例如，

蜂窝电话、

计算平板、PDA)、可穿戴设备(例如，Google

头戴式显示器)、个人计算机、工作站、大型机、信息亭、服务器机架或任何其他数据处理系统。

由于计算机和网络的不断变化的性质，图17中描绘的计算机系统1700的描述仅旨在作为具体示例。具有比图17中描绘的系统更多或更少组件的许多其他配置是可能的。基于本文提供的公开和教导，本领域的普通技术人员将理解实现各种实施例的其他方式和/或方法。

可以以各种配置来提供图中的一些图中描绘的系统。在一些实施例中，系统可以被配置为分布式系统，其中系统的一个或多个组件跨一个或多个云基础设施系统中的一个或多个网络分布。

云基础设施系统是一个或多个服务器计算设备、网络设备和/或存储设备的集合。这些资源可以以一些方式由云服务提供商划分并分配给其客户。例如，云服务提供商(诸如加利福尼亚州红木海岸的Oracle公司)可以提供各种类型的云服务，包括但不限于在软件即服务(SaaS)类别下提供的一项或多项服务、在平台即服务(PaaS)类别下提供的服务、在基础设施即服务(IaaS)类别下提供的服务或包括混合服务的其他类别的服务。SaaS服务的示例包括但不限于构建和交付一套按需应用程序(诸如Oracle Fusion应用程序)的能力。SaaS服务使客户能够利用在云基础设施系统上执行的应用程序，而无需客户为应用程序购买软件。PaaS服务的示例包括但不限于使组织(诸如Oracle)能够在共享的公共架构上整合现有应用程序的服务，以及构建利用平台提供的共享服务(诸如Oracle Java云服务(JCS)、Oracle数据库云服务(DBCS)以及其他服务)的新应用程序的能力。IaaS服务可以促进利用由SaaS平台和PaaS平台提供的服务的客户管理和控制底层计算资源，诸如存储、网络和其他基础计算资源。

图18是根据本公开的实施例的系统环境1800的一个或多个组件的简化框图，通过该系统环境1800由实施例系统的一个或多个组件提供的服务可以被提供为云服务。在所示实施例中，系统环境1800包括一个或多个客户端计算设备1804、1806和1808，用户可以使用该一个或多个客户端计算设备与提供云服务的云基础设施系统1802交互。客户端计算设备可以被配置为操作客户端应用程序，诸如网络浏览器、专有客户端应用程序(例如，OracleForms)或一些其他应用程序，客户端计算设备的用户可以使用客户端应用程序与云基础设施系统1802交互以使用云基础设施系统1802提供的服务。

应当理解，图中所描绘的云基础设施系统1802可以具有所描绘的那些组件以外的其他组件。此外，图中所示的实施例仅是可以结合本公开的实施例的云基础设施系统的一个示例。在一些其他实施例中，云基础设施系统1802可以具有比图中所示的更多或更少的组件，可以组合两个或更多个组件，或者可以具有不同的组件配置或布置。

客户端计算设备1804、1806和1808可以是与上面针对1602、1604、1606和1608描述的设备类似的设备。

尽管示例性系统环境1800被示为具有三个客户端计算设备，但是任何数量的客户端计算设备可以被支持。其他设备(诸如具有传感器的设备等)可以与云基础设施系统1802交互。

(一个或多个)网络1810可以促进客户端1804、1806和1808与云基础设施系统1802之间的通信和数据交换。每个网络可以是本领域技术人员熟悉的可支持使用多种可商用协议中的任何一种的数据通信的任何类型的网络，这些协议包括上面针对(一个或多个)网络1810描述的那些协议。

云基础设施系统1802可以包括一个或多个计算机和/或服务器，这些计算机和/或服务器可以包括上面针对服务器1812描述的那些。

在某些实施例中，云基础设施系统提供的服务可以包括按需提供给云基础设施系统的用户的大量服务，诸如在线数据存储和备份解决方案、基于网络的电子邮件服务、托管办公室套件和文档协作服务、数据库处理、受管理的技术支持服务等。云基础设施系统提供的服务可以动态缩放以满足其用户的需求。由云基础设施系统提供的服务的具体实例化在本文中被称为“服务实例”。通常，从云服务提供商的系统经由通信网络(诸如互联网)对用户可用的任何服务都被称为“云服务”。在公共云环境中，组成云服务提供商的系统的服务器和系统不同于客户自己的内部部署的服务器和系统。例如，云服务提供商的系统可以托管应用程序，并且用户可以经由诸如互联网之类的通信网络按需订购和使用应用程序。

在一些示例中，计算机网络云基础设施中的服务可以包括对存储装置、托管的数据库、托管的网络服务器、软件应用程序或由云供应商提供给用户的或如本领域以其他方式所已知的其他服务的受保护的计算机网络访问。例如，服务可以包括通过互联网对云上的远程存储装置进行受密码保护的访问。作为另一示例，服务可以包括基于网络服务的托管的关系数据库和供网络开发者专用的脚本语言中间件引擎。作为另一示例，服务可以包括对托管在云供应商网站上的电子邮件软件应用程序的访问。

在某些实施例中，云基础设施系统1802可以包括以自助服务、基于订阅、弹性可扩展、可靠、高度可用和安全的方式交付给客户的一套应用程序、中间件和数据库服务产品。这样的云基础设施系统的示例是本受让人提供的Oracle公共云。

在各种实施例中，云基础设施系统1802可以适于自动供应、管理和跟踪客户对云基础设施系统1802提供的服务的订阅。云基础设施系统1802可以经由不同的部署模型提供云服务。例如，可以在公共云模型下提供服务，在该公共云模型中云基础设施系统1802由销售云服务的组织拥有(例如，由Oracle拥有)并且服务对一般公众或不同行业企业可用。作为另一示例，可以在私有云模型下提供服务，在该私有云模型中云基础设施系统1802仅针对单个组织被操作并且可以为组织内的一个或多个实体提供服务。还可以在社区云模型下提供云服务，在该社区云模型中云基础设施系统1802和由云基础设施系统1802提供的服务由相关社区中的若干组织共享。也可以在混合云模型下提供云服务，该混合云模型是两个或多个不同模型的组合。

在一些实施例中，由云基础设施系统1802提供的服务可以包括在软件即服务(SaaS)类别、平台即服务(PaaS)类别、基础设施即服务(IaaS)类别下提供的一个或多个服务，或包括混合服务的其他类别的服务。客户经由订阅订单可以订购由云基础设施系统1802提供的一项或多项服务。云基础设施系统1802然后执行处理以提供客户的订阅订单中的服务。

在一些实施例中，云基础设施系统1802提供的服务可以包括但不限于应用程序服务、平台服务和基础设施服务。在一些示例中，应用程序服务可以由云基础设施系统经由SaaS平台提供。SaaS平台可以被配置为提供属于SaaS类别的云服务。例如，SaaS平台可以提供在集成开发和部署平台上构建和交付一套按需的应用程序的能力。SaaS平台可以管理和控制用于提供SaaS服务的底层软件和基础设施。通过利用SaaS平台提供的服务，客户可以利用在云基础设施系统上执行的应用程序。客户可以获得应用程序服务，而不需要客户购买单独的许可和支持。可以提供各种不同的SaaS服务。示例包括但不限于为大型组织提供销售业绩管理、企业集成和业务灵活性的解决方案的服务。

在一些实施例中，平台服务可以由云基础设施系统经由PaaS平台提供。PaaS平台可以被配置为提供属于PaaS类别的云服务。平台服务的示例可以包括但不限于使组织(诸如Oracle)能够在共享的公共架构上整合现有应用程序的服务，以及构建利用平台提供的共享服务的新应用程序的能力。PaaS平台可以管理和控制用于提供PaaS服务的底层软件和基础设施。客户可以获得云基础设施系统提供的PaaS服务，而不需要客户购买单独的许可和支持。平台服务的示例包括但不限于Oracle Java云服务(JCS)、Oracle数据库云服务(DBCS)及其他。

通过利用PaaS平台提供的服务，客户可以采用云基础设施系统支持的编程语言和工具，并且还可以控制部署的服务。在一些实施例中，云基础设施系统提供的平台服务可以包括数据库云服务、中间件云服务(例如，Oracle Fusion中间件服务)和Java云服务。在一个实施例中，数据库云服务可以支持共享服务部署模型，该模型使组织能够汇集数据库资源并以数据库云的形式向客户提供数据库即服务。在云基础设施系统中，中间件云服务可以为客户提供平台以开发和部署各种业务应用程序，并且Java云服务可以为客户提供平台以部署Java应用程序。

各种不同的基础设施服务可以由云基础设施系统中的IaaS平台提供。基础设施服务促进利用SaaS平台和PaaS平台提供的服务的客户对底层计算资源(诸如存储、网络和其他基础计算资源)的管理和控制。

在某些实施例中，云基础设施系统1802还可以包括基础设施资源1830，用于提供用于向云基础设施系统的客户提供各种服务的资源。在一个实施例中，基础设施资源1830可以包括硬件(诸如服务器、存储装置和联网资源)的预集成和优化的组合，以执行由PaaS平台和SaaS平台提供的服务。

在一些实施例中，云基础设施系统1802中的资源可以由多个用户共享并且按需求动态地重新分配。附加地，资源可以被分配给不同时区中的用户。例如，云基础设施系统1830可以使第一时区中的第一组用户能够利用云基础设施系统的资源指定的小时数，然后使相同的资源能够重新分配给位于不同时区中的另一组用户，从而最大化对资源的利用。

在某些实施例中，可以提供由云基础设施系统1802的不同组件或模块以及由云基础设施系统1802提供的服务共享的多个内部共享服务1832。这些内部共享服务可以包括但不限于安全和身份服务、集成服务、企业储存库服务、企业管理器服务、病毒扫描和白名单服务、高可用性、备份和恢复服务、启用云支持的服务、电子邮件服务、通知服务、文件传输服务等。

在某些实施例中，云基础设施系统1802可以提供对云基础设施系统中的云服务(例如，SaaS、PaaS和IaaS服务)的综合管理。在一个实施例中，云管理功能可以包括用于供应、管理和跟踪由云基础设施系统1802接收的客户的订阅的能力等。

在一个实施例中，如图中所描绘的，云管理功能可以由一个或多个模块(诸如订单管理模块1820、订单编排模块1822、订单供应模块1824、订单管理和监控模块1826、和身份管理模块1828)提供。这些模块可以包括一个或多个计算机和/或服务器或使用一个或多个计算机和/或服务器来提供，该一个或多个计算机和/或服务器可以是通用计算机、专用服务器计算机、服务器场、服务器集群或任何其他适当的布置和/或组合。

在示例性操作1834中，使用诸如客户端设备1804、1806或1808之类的客户端设备的客户可以通过请求由云基础设施系统1802提供的一个或多个服务并下订单订阅由云基础设施系统1802提供的一个或多个服务来与云基础设施系统1802交互。在某些实施例中，客户可以访问云用户接口(UI)，云UI 1812、云UI 1814和/或云UI 1816，并经由这些UI下订阅订单。响应于客户下订单而由云基础设施系统1802接收的订单信息可以包括识别客户和客户旨在订阅的由云基础设施系统1802提供的一个或多个服务的信息。

在客户已经下订单之后，订单信息经由云UI 1812、1814和/或1816被接收。

在操作1836处，订单被存储在订单数据库1818中。订单数据库1818可以是由云基础设施系统1818操作并结合其他系统元素操作的若干数据库之一。

在操作1838处，订单信息被转发到订单管理模块1820。在一些情况下，订单管理模块1820可以被配置为执行与订单相关的计费和记账功能，诸如验证订单，并且在验证后，预订订单。

在操作1840处，关于订单的信息被传送到订单编排模块1822。订单编排模块1822可以利用订单信息来编排用于客户下的订单的服务和资源的供应。在一些情况下，订单编排模块1822可以编排资源的供应以使用订单供应模块1824的服务来支持订阅的服务。

在某些实施例中，订单编排模块1822使得能够管理与每个订单相关联的业务过程并应用业务逻辑来确定订单是否应该进行供应。在操作1842处，在接收到新订阅的订单时，订单编排模块1822向订单供应模块1824发送请求以分配资源并配置满足订阅订单所需的那些资源。订单供应模块1824使得能够为客户订购的服务分配资源。订单供应模块1824在由云基础设施系统1800提供的云服务与用于供应资源以提供所请求的服务的物理实现层之间提供抽象级别。订单编排模块1822因此可以与实现细节隔离，实现细节诸如服务和资源实际是被即时供应还是被预先供应并且仅在请求时才被分配/指派。

在操作1844处，一旦服务和资源被供应，所提供的服务的通知就可以由云基础设施系统1802的订单供应模块1824发送到客户端设备1804、1806和/或1808上的客户。在操作1846处，客户的订阅订单可以由订单管理和监控模块1826管理和跟踪。在一些情况下，订单管理和监控模块1826可以被配置为收集订阅订单中的服务的使用统计信息，诸如使用的存储装置的量、传输的数据量、用户数量以及系统运行时间和系统停机时间的量。

在某些实施例中，云基础设施系统1800可以包括身份管理模块1828。身份管理模块1828可以被配置为提供身份服务，诸如云基础设施系统1800中的访问管理和授权服务。在一些实施例中，身份管理模块1828可以控制关于希望利用云基础设施系统1802提供的服务的客户的信息。这样的信息可以包括认证这样的客户的身份的信息和描述那些客户被授权相对于各种系统资源(例如，文件、目录、应用程序、通信端口、存储器段等)执行哪些动作的信息。身份管理模块1828还可以包括对关于每个客户以及关于可以如何以及由谁访问和修改该描述性信息的描述性信息的管理。

尽管本公开的具体实施例已被描述，但是各种修改、改变、替代构造和等价物也包含在本公开的范围内。本公开的实施例不限于某些具体数据处理环境内的操作，而是可以在多个数据处理环境内自由操作。附加地，尽管已经使用特定系列的事务和步骤描述了本公开的实施例，但是本领域技术人员应该清楚本公开的范围不限于所描述的事务和步骤系列。上述实施例的各种特征和方面可以单独或联合使用。

此外，虽然本公开的实施例已经使用硬件和软件的特定组合被描述，但是应当认识到硬件和软件的其他组合也在本公开的范围内。本公开的实施例可以仅以硬件、或仅以软件、或使用其组合来实现。本文描述的各种过程可以在相同处理器或不同处理器上以任何组合实现。因此，在组件或模块被描述为被配置为执行某些操作的情况下，这样的配置可以通过例如设计电子电路以执行操作、通过对可编程电子电路(诸如微处理器)进行编程以执行操作或其任何组合来实现。过程可以使用多种技术进行通信，这些技术包括但不限于用于过程间通信的常规技术，并且不同的过程对可以使用不同的技术，或者相同过程对可以在不同的时间使用不同的技术。

因此，说明书和附图被认为是说明性的而不是限制性的。然而，将明显的是，在不背离权利要求所阐述的更广泛精神和范围的情况下，可以对其做出添加、减少、删除以及其他修改和变更。因此，尽管具体的公开实施例已被描述，但这些并不旨在进行限制。各种修改和等价物都在以下权利要求的范围内。

Claims (22)

1.一种计算机实现的方法，包括：

由计算设备执行指令以执行与计算系统的部署相关联的配置数据的一个或多个解析；

由所述计算设备使第一有向无环图DAG被生成，第一DAG用于至少部分地基于执行所述一个或多个解析来部署第一资源；

由所述计算设备生成用于至少部分地基于执行所述一个或多个解析来部署多个执行目标的第二DAG，第二DAG指定所述部署的执行目标之间的依赖关系；

由所述计算设备至少部分地基于执行所述一个或多个解析来生成链表数据结构，所述链表数据结构指定多个部署阶段之间的依赖关系；以及

由所述计算设备至少部分地基于遍历所述链表数据结构、第二DAG和第一DAG来部署所述计算系统。

2.如权利要求1所述的计算机实现的方法，其中第一DAG由声明性基础设施供应器生成。

3.如权利要求1或2所述的计算机实现的方法，其中第一DAG指定所述计算系统的第一资源对所述计算系统的第二资源的能力的依赖关系。

4.如权利要求3所述的计算机实现的方法，其中第一资源或第二资源中的每一个是多个计算服务中的计算服务，并且其中所述能力是第二资源的功能的一部分。

5.如权利要求1至4中任一项所述的计算机实现的方法，其中第二DAG的至少一个节点引用第一DAG的节点。

6.如权利要求1-5中任一项所述的计算机实现的方法，其中所述链表数据结构的节点引用第二DAG的至少一个节点。

7.如权利要求1-6中任一项所述的计算机实现的方法，其中执行用于执行所述配置数据的所述一个或多个解析的所述指令包括：

经由所述配置数据中提供的显式语句来检测第一依赖关系；或者

至少部分地基于识别在所述配置数据中提供的隐式依赖关系来检测第二依赖关系。

8.如权利要求1-7中任一项所述的计算机实现的方法，其中所述配置数据经由一个或多个依赖关系指示用于执行用于部署多个资源的基础设施部署操作的顺序。

9.如权利要求1-8中任一项所述的计算机实现的方法，其中所述依赖关系是利用声明性语句来定义的。

10.一种系统，包括：

一个或多个处理器；以及

一个或多个存储器，存储计算机可执行指令，所述计算机可执行指令当由所述一个或多个处理器执行时，将所述一个或多个处理器配置为：

通过计算设备执行指令以执行与计算系统的部署相关联的配置数据的一个或多个解析；

通过所述计算设备使第一DAG被生成，第一DAG用于至少部分地基于执行所述一个或多个解析来部署第一资源；

通过所述计算设备生成用于至少部分地基于执行所述一个或多个解析来部署多个执行目标的第二DAG，第二DAG指定所述部署的执行目标之间的依赖关系；

通过所述计算设备至少部分地基于执行所述一个或多个解析来生成链表数据结构，所述链表数据结构指定多个部署阶段之间的依赖关系；以及

通过所述计算设备至少部分地基于遍历所述链表数据结构、第二DAG和第一DAG来部署所述计算系统。

11.如权利要求10所述的系统，其中第一DAG由声明性基础设施供应器生成，并且其中第一DAG指定所述计算系统的第一资源对所述计算系统的第二资源的能力的依赖关系。

12.如权利要求11所述的系统，其中第一资源或第二资源中的每一个是多个计算服务中的计算服务，并且其中所述能力是第二资源的功能的一部分。

13.如权利要求10至12中任一项所述的系统，其中第二DAG的至少一个节点引用第一DAG的节点，并且其中所述链表数据结构的节点引用第二DAG的至少一个节点。

14.如权利要求10-13中任一项所述的系统，其中所述配置数据经由一个或多个依赖关系指示用于执行用于部署多个资源的基础设施部署操作的顺序，其中所述一个或多个依赖关系是利用声明性语句来定义的，并且其中执行用于执行所述配置数据的所述一个或多个解析的所述指令包括：

经由所述配置数据中提供的显式语句来检测第一依赖关系；或者

至少部分地基于识别在所述配置数据中提供的隐式依赖关系来检测第二依赖关系。

15.一种计算机可读存储介质，存储计算机可执行指令，所述计算机可执行指令当由一个或多个处理器执行时，使所述一个或多个处理器执行操作，所述操作包括：

通过计算设备执行指令以执行与计算系统的部署相关联的配置数据的一个或多个解析；

通过所述计算设备使第一DAG被生成，第一DAG用于至少部分地基于执行所述一个或多个解析来部署第一资源；

通过所述计算设备生成用于至少部分地基于执行所述一个或多个解析来部署多个执行目标的第二DAG，第二DAG指定所述部署的执行目标之间的依赖关系；

通过所述计算设备至少部分地基于执行所述一个或多个解析来生成链表数据结构，所述链表数据结构指定多个部署阶段之间的依赖关系；以及

通过所述计算设备至少部分地基于遍历所述链表数据结构、第二DAG和第一DAG来部署所述计算系统。

16.如权利要求15所述的计算机可读存储介质，其中第一DAG由声明性基础设施供应器生成，并且其中第一DAG指定所述计算系统的第一资源对所述计算系统的第二资源的能力的依赖关系。

17.如权利要求16所述的计算机可读存储介质，其中第一资源或第二资源中的每一个是多个计算服务中的计算服务，并且其中所述能力是第二资源的功能的一部分。

18.如权利要求15-17中任一项所述的计算机可读存储介质，其中第二DAG的至少一个节点引用第一DAG的节点，并且其中所述链表数据结构的节点引用第二DAG的至少一个节点。

19.如权利要求15-18中任一项所述的计算机可读存储介质，其中执行用于执行所述配置数据的所述一个或多个解析的所述指令包括：

经由所述配置数据中提供的显式语句来检测第一依赖关系；或者

至少部分地基于识别在所述配置数据中提供的隐式依赖关系来检测第二依赖关系。

20.如权利要求15-19中任一项所述的计算机可读存储介质，其中所述配置数据经由一个或多个依赖关系指示用于执行用于部署多个资源的基础设施部署操作的顺序，并且其中所述一个或多个依赖关系是利用声明性语句来定义的。

21.一种包括用于执行根据权利要求1-9中任一项所述的步骤的部件的装置。

22.一种计算机程序产品，包括计算机指令，所述计算机指令当由处理器执行时实现如权利要求1-9中任一项所述的方法的步骤。

Images