并发执行服务的制作方法

本公开涉及服务的执行，并且更具体地涉及并发地执行服务。

背景技术：

协调(orchestration)通过自动化工作流、供应和变化管理来限定策略和服务级别。协调的使用可以在服务导向的架构、虚拟化、供应、融合的基础架构、电信和数据中心主题的上下面中来讨论。如此，协调提供计算资源的集中式管理，其允许进行管理，包括为了所限定的目的来创建、配置、移除或以其他方式修改应用的能力。

技术实现要素：

根据一些实施例，提供了一种并发地执行计算服务的协调的方法，该方法包括：开发一组服务的表示，其中每个服务经由不同类型的关系与其他服务相关；将一组依赖性规则应用于一组服务内的每种类型的关系，使得依赖性规则的应用创建表示一组服务的状态转换的步骤之间的步骤间依赖性；以及基于步骤间依赖性来开发协调计划，协调计划允许非依赖的步骤的并发执行。

根据另一些实施例，提供了一种非暂态计算机可读介质，包括被存储于其上的计算机可执行指令，计算机可执行指令在由一个或多个处理单元执行时，执行并发地执行服务的协调计划的方法，该非暂态计算机可读存储介质包括指令，该指令用以：开发一组服务的表示，其中每个服务经由不同类型的关系与其他服务相关；将一组依赖性规则应用于一组服务内的每种类型的关系，使得依赖性规则的应用创建表示一组服务的状态转换的步骤之间的步骤间依赖性；以及基于步骤间依赖性的创建来开发协调计划，该协调计划在步骤不依赖于第二步骤的情况下允许步骤执行。

根据又一些实施例，提供了一种用以开发协调执行计划的系统，包括：建模器，该建模器经由不同类型的关系将每个服务的表示开发为与其他服务相关；计划器，该计划器连接到建模器和处理器，处理器将一组依赖性规则应用于每个服务和其他服务之间的每种类型的关系，并且基于一组依赖性规则的应用创建表示每个服务的状态转换的步骤之间的步骤间依赖性，并且开发允许非依赖的步骤的并发执行的协调计划。

附图说明

本文描述的示例可以通过结合附图参考以下描述来理解，其中相同的附图标记标识相同的元素。

图1是根据一个或多个示例实施例的满足服务的系统的示意性表示。

图2是根据一个或多个示例实施例的状态模型。

图3是根据一个或多个示例实施例的服务关系的表示。

图4是根据一个或多个示例实施例的开发协调执行计划的系统架构的表示。

图5是根据一个或多个示例实施例的步骤图和调度器。

图6是根据一个或多个示例实施例的并发地执行服务的方法的流程图。

图7是根据一个或多个示例实施例的具有硬件处理器和可访问机器可读指令的示例计算设备。

图8是根据一个或多个示例实施例的可以被用来实现功能和过程的计算机处理设备的示意性表示。

尽管本文描述的示例易受各种修改和备选形式的影响，但附图通过示例的方式图示了本文详细描述的具体实施例。然而，应当理解，本文中对具体实施例的描述不旨在限制为所公开的特定形式，相反，旨在覆盖在本文中和所附权利要求描述的示例的精神和范围内的所有修改、等同方案和备选方案。

具体实施方式

参考附图详细描述了一个或多个示例。为了一致性，各个附图中的相同的元件由相同的附图标记来表示。在下面的详细的描述中，阐述具体的细节是为了提供对下面所要求保护的主题的透彻理解。在其他实例中，具有本公开的优点的、对于本领域普通技术人员公知的特征没有被描述，以避免混淆对所要求保护的主题的描述。

协调提供了涉及实现服务协调请求中所限定的目标和目的的动作过程。服务协调可以包括组成架构、工具和过程，将软件和硬件拼接在一起，以及在适用于递送经限定的服务时连接且自动化工作流。随着对新资源的要求随新应用的引入而不断增加，通过协调方式的自动化工具能够执行先前由在物理堆栈的各个部分操作的多个管理方处置的任务。使状态模型序列化指示了基于对模型的一个或多个节点的修改的事件序列。序列化依赖图模型可以用于简单的分解模型和无状态模型；然而，对于更复杂的图模型，可以实现其他解决方案来解决更大数目的可能的模型变换。

如本文所述的“服务”指的是复杂系统中的变化的协调，其包括用于创建通信服务的交互式服务、网络和系统。

一种解决方案使用自组(adhoc)的分解方法和基于队列的执行计划。例如，由处理器可执行的机器代码可以以旨在生成正确的动作序列的次序来推动动作队列。该解决方案导致不可预测的实例并且可能无法处置特定用例的复杂重新创建。例如，当进行有效地清除和重新创建配置拓扑的各部分的状态转换时，使用分解方法和基于队列的执行是限制性的。此外，自组方法可能无法检测冲突的要求，这可能导致执行引擎做出不可预测的仲裁决策。不可预测的仲裁决策会导致不稳定的端到端协调解决方案，因为解决方案变得不可验证。

第二种解决方案使用被宣称为图模板的模型，其被称为用于改进结构化信息标准(“oasis”)标准语言的、用于云应用的拓扑和协调规范(“tosca”)组织。在toscaoasis解决方案中，标准语言被用来描述基于云的web服务的拓扑、它们的组件、关系和管理web服务的过程。在该解决方案中所得到的模型是静态的并且不可以被修改。对所得到的模型的修改会引起完整模型和组件的清除和重新创建，并且这样做可能导致停机时间。

第三种解决方案使用由层级分解所限定的服务，层级分解是一种简化模型的类型。在层级分解中，层级决策过程被用来评估动作序列；然而，该解决方案不能捕捉图结构化服务，因为对层级结构的修改会引出对完整结构的重新设计。在该示例中，层级分解解决方案更多的是一种静态方法，在服务的变化发生时不提供修改，并且因此可能无法在没有完整的重新设计的情况下处置跨度层级的变化。在层级分解的另一示例中，可以使用树模型来表示服务之间的关系。在这样的模型中，结构中的每个节点可以包括父节点和/或子节点。从建模的角度看，树结构比其他分解和状态模型更简单。这样的模型没有考虑包括树的节点之间的各种相互依赖关系的更加困难和复杂的模型。在某些状况下，节点可能不共享共同性。

另一种解决方案使用简单的状态模型，其中服务的各种状态彼此相互依赖。在该解决方案中，图中的节点在状态中被表示为完全配置的或不存在的。该方法减少了对图中的相关节点的状态之间的依赖性进行建模的问题；然而，该方法无法处置外部系统配置的复杂性。

涉及基于复杂依赖模型的计划执行步骤的解决方案不考虑过程步骤之间的关系。步骤被线性地执行，并且步骤的线性执行减慢了处理速度，因为不依赖于正被执行的步骤的各步骤保持空闲。本公开包括计划器，该计划器确定步骤是否彼此依赖。从而可以并发地处理非依赖的步骤。该计划器对具有图节点之间的、基于状态的关系的复杂步骤图起作用。

更具体地，本公开使用计算系统来创建一组服务的表示。基于关系，一组依赖性规则被应用于表示中的每种类型的关系。响应于该组依赖性规则的应用，在表示针对该组服务的状态转换的步骤之间创建步骤间依赖性。根据步骤间依赖性，可以开发协调计划。协调计划源于限定所表示的步骤之间的关系的所生成的步骤图。该步骤图例如可以是有向图或各种步骤之间的关系的其他类型的表示。从而，步骤图可以允许并发地计划和执行非依赖的步骤，从而允许系统持续地处理步骤，同时减少等待非依赖步骤的时间。

本公开的实现可以进一步提供允许并发执行步骤的建模器、计划器、调度器和执行器。在某些实现中，建模器可以将每个步骤的表示开发为与其他步骤相关。然后计划器可以将一组依赖性规则应用于每个步骤之间的每种类型的关系。步骤间依赖性的开发从而可以允许协调计划的开发，该协调计划允许非依赖的步骤的并发执行。调度器可以跟踪每个步骤之间的依赖性，从而允许不依赖于先前步骤的步骤执行。因此，调度器可以在步骤完成时更新步骤计划，从而允许所有非依赖的步骤执行。从而，这样的步骤的并发执行可以允许加快处理时间。这样的系统还可以具有执行器，该执行器连接到执行由调度器指示的非依赖步骤的计划器。

转到图1，示出了根据一个或多个实施例的履行服务的系统的示意性表示。在这样的系统100中，处理器105连接到建模器110和计划器115。在某些系统100中，多于一个处理器105可以连接到建模器110和/或计划器115。处理器105可以包括虚拟设备或物理设备，诸如电子电路装置，包括集成电路、可编程电路、应用集成电路、控制器、处理器、半导体、处理资源、芯片组或能够管理系统100的其他类型的组件。

建模器110构建表示一组服务和这样的服务之间的关系的模型(未示出)。该模型可以被用作计划器115的输入，其可以应用依赖性规则来限定服务之间的不同类型的关系。关系的示例可以包括作为兄弟相关的两个或更多个服务，其中服务可以并发操作并且不彼此依赖。其他类型的关系可以包括父子关系，其中子服务可以依赖于父服务。在这样的父子关系中，子服务不会被执行，直到父服务完成。依赖性规则的应用从而创建了一组服务内的某些步骤之间的步骤间依赖性。创建步骤间依赖性允许计划器115开发协调计划，该协调计划包括限定特定步骤的执行次序的步骤图。

如下面将详细讨论的，步骤图可以允许并发地执行非依赖的步骤。建模器110可以是物理设备，诸如电子电路装置，包括集成电路、可编程电路、应用集成电路、控制器、处理器、半导体、处理资源、芯片组或能够管理系统100的其他类型的组件。备选地，建模器110可以包括指令，例如，被存储在机器可读介质上的指令，该指令在由处理器105执行时构建模型。模型的实现可以包括状态模型、多技术操作系统接口模型(“mtosi”)、概念模型、数学模型、计算机模型或由不同类型的关系说明一组服务彼此的互联性的其他类型的模型。

计划器115可以使用由建模器110提供的模型来应用依赖性规则，以在各种服务之间创建步骤间依赖性。基于步骤间依赖性的创建，计划器15可以继续开发协调计划。如下面将详细说明的，在某些实现中，计划器115可以在开发协调计划之前开发步骤图。计划器115可以使用模型来确定特定步骤是依赖的还是非依赖的。然后，非依赖的步骤可以被标识并且被调度为并发执行。非依赖的步骤可以包括不依赖于计划内的其他步骤的任何步骤，并且将在下面详细讨论非依赖的步骤。

计划器115可以是物理设备，诸如电子电路装置，包括集成电路、可编程电路、应用集成电路、控制器、处理器、半导体、处理资源、芯片组或能够管理系统100的其他类型的组件。备选地，计划器115可以包括指令，例如，被存储在机器可读介质上的指令，该指令在由处理器105执行时开发协调计划。

依赖性规则可以被用来限定模型中创建的服务之间的不同类型的关系。例如，一组依赖性规则可以应用于父类型的关系。另一组依赖性规则可以应用于子关系、兄弟关系或其中所限定的其他关系。关系的示例可以包括作为兄弟相关的两个或更多个服务，其中服务可以并发操作并且不彼此依赖。其他类型的关系可以包括父子关系，其中子服务可以依赖于父服务。在这样的父子关系中，子服务可以不被执行，直到父服务完成。计划器115对依赖性规则的应用得到表示一组服务中的状态转换的不同步骤之间的步骤间依赖性。为了产生状态转换的步骤间依赖性，依赖性规则可以包括一组原则，该组原则限定系统100内的不同类型的关系的状态转换。

协调计划由计划器115在创建步骤间依赖性时产生。协调计划限定步骤将被执行的次序。由于步骤间依赖性的创建，协调计划允许非依赖的步骤被标识，使得某些步骤的执行可以并行地继续进行，从而允许某些非依赖的步骤被并发执行。

系统100可以进一步包括执行器120，该执行器120执行所设计的协调计划。当计划基于自动生成的修改或用户输入而被修正时，执行器210可以从计划器115接收所修正的协调计划。执行器120可以是物理设备，诸如电子电路装置，包括集成电路、可编程电路、应用集成电路、控制器、处理器、半导体、处理资源、芯片组或能够管理系统100的其他类型的组件。备选地，执行器120可以包括指令，例如，被存储在机器可读介质上的指令，该指令在由处理器105执行时执行协调计划。

系统100还可以包括调度器125。调度器125可以基于步骤执行的开始和步骤的完成来跟踪协调计划的进度。然后调度器可以指示哪些步骤不具有阻止它们执行的依赖性，此时执行器120可以开始所有非依赖的步骤。为了跟踪非依赖的步骤，调度器可以为每个步骤分配依赖性计数。如果一个步骤依赖于另一步骤，其计数可以为1。如果其依赖于两个其他步骤，那么其计数可以为2，也可以为1。当步骤的依赖性计数为零时，没有步骤阻止该步骤的执行。因此，执行器120可以提供开始步骤的指令。当服务完成时，所有依赖的步骤使其各自的依赖性计数减少1。如此，调度器125基本上持续地更新计划，从而允许所有非依赖的步骤在服务不再具有任何依赖性时执行。还可以采用跟踪步骤依赖性的其他方法。例如，可以使用利用增加值、减少值或达到特定值来计数的依赖性计数。

可以将某些参数添加到协调计划和/或调度器125，以阻止步骤执行。例如，可以建立最大负载参数，其中用户或其他系统限定可以同时运行的步骤的最大数目。例如，用户可以指示可以同时执行最多二百五十个(250)步骤。可以添加该参数以阻止过多的步骤同时运行，这可能会降低系统100的性能。可以将最大负载参数指定为建模语言中限定的经配置的默认值、每个请求的最大值和/或动态的每个服务的最大值。如果一个步骤的条件是在请求时最大值小于并发执行的步骤的当前数目，则系统100将在执行后续步骤之前等待正确数目的步骤完成。基于特定系统100的软件和硬件限制以及所期望的性能速度，最大负载参数可能不同。

调度器125还可以给系统100提供关于失败步骤的信息。如果步骤失败，则调度器125可以指示该步骤没有完成，从而允许对计划进行修改，以考虑失败的步骤。在某些实现中，可以调整依赖于失败步骤的所有步骤的依赖性。例如，依赖的步骤可以被告知开始执行、取消步骤或以其他方式调整这样的依赖的步骤。

类似地，系统100可以停止提交依赖于另一步骤的步骤，这依赖于对协调计划的修正。协调计划可以在没有其他步骤要执行时，被后续地重新计算。如此，系统100可以继续操作，而无需基于依赖的步骤的经修正的协调计划。

转到图2，示出了根据一个或多个实施例的状态模型。状态模型205图示了给定服务的潜在状态转换210a-210e。状态模型205被表示为mtosi，其包括初始状态转换210a和潜在状态转换210b-210f。该模型可以由服务提供方使用，作为管理复杂网络和对应的服务的机制，诸如图3的服务200。在其他的实现中，状态模型205可以包括概念模型或表示给定服务的各种状态的其他视觉描绘。状态模型205可以通过呈现可能的状态转换210a-210f进一步提供一组服务的互联性的视觉描述。

在本实现中，依赖性规则的应用创建服务间依赖性212a-212d。服务间依赖性212a-212d是存在于服务之间的状态转换之间的依赖性，其中在该示例中，服务是给定的服务(由状态模型205表示)和相关的子服务214。在该示例中，从状态“已检查”210a到“已设计”210b的给定的服务转换创建了服务间依赖性212a，该服务间依赖性依赖于子服务214中的状态转换(未示出)。在另一示例中，从“已设计”210b到“已保留”210c的给定的状态转换具有与子服务214中的另一状态转换(未图示)的依赖性212b。在另一示例中，从“已保留”210c到“已供应”210d的状态转换具有与对应于子服务214的另一状态转换的服务间依赖性212c。在又一示例中，从“已供应”210d到“活动”210e的给定服务的状态转换具有与对应于子服务214的另一状态转换的服务间依赖性212d。因此，依赖性规则的应用创建相关的多个服务之间的服务间依赖性212a-212d。尽管本文讨论的是父子依赖性，但是可以为系统中的所有服务创建服务间依赖性212a-212d。因此，可以为系统内的每个依赖性关系创建这样的状态模型205。下面详细解释可以应用的依赖性规则的类型的具体示例。

转到图3，示出了根据一个或多个实施例的服务关系的表示。服务200之间的不同类型的关系可以包括例如父关系、兄弟关系、引用方关系、引用关系、先决条件关系等。箭头表示给定服务200到其他服务的关系。例如，存在给定服务200的父服务215。还存在给定服务200的兄弟服务220，其中兄弟服务210还具有作为父服务215的子服务的关系。限定服务之间的关系允许以图形方式表示可以被完成的特定服务的次序。在该示例中，服务200在其可以开始之前可能必须等待父服务215完成。兄弟服务220在其开始之前可能也必须等待父服务215完成，然而，兄弟服务220可以与服务200同时执行。附加的服务可以包括给定服务200的引用方225，以及给定服务200的引用服务230和任何数目的先决条件服务235。图2中开发的状态模型还可以包括给定服务200和其他服务之间的不同类型的关系。取决于关系的类型，可以将一组依赖性规则应用于不同类型的关系，以创建图4中所图示的服务间依赖性。

转到图4，示出了根据一个或多个实施例的开发协调计划的系统架构的表示。图4示出了服务205如何通过不同类型的关系(例如，父关系、兄弟关系、子关系、引用方关系、先决条件关系、引用关系等)与其他服务相关。影响模型245可以开发由计划器247使用的模型。计划器247应用特定于不同类型的关系的依赖性规则250。通过应用依赖性规则250，计划器247创建给定服务205和由240表示的其他服务之间的步骤间依赖性。

通过创建步骤间依赖性，计划器247创建步骤图(未图示)。在下面的附图中讨论步骤图的示例。通过使用步骤图，计划器可以应用拓扑排序算法255来获得执行器260执行的状态转换列表。状态转换的列表由协调计划(未图示)开发。在示例实现中，协调计划包括用于执行的状态转换的经排列的次序。组件影响模型245、计划器247和执行器260的实现可以包括电子电路装置(即，硬件)，诸如集成电路、可编程电路、应用集成电路(asic)、控制器、处理器、半导体、处理资源、芯片组或能够构建模型240并且开发要在其中执行的状态转换列表的其他类型的硬件组件。备选地，影响模型245、计划器247和执行器260可以包括指令(例如，被存储在机器可读介质上的指令)，该指令在由硬件组件(例如，控制器和/或处理器)执行时，构建模型并相应地开发状态转换的经排列的次序。

参考图5，示出了根据一个或多个实施例的步骤图和调度器。步骤图265包括一定数目的单独的步骤270，这些步骤具有与它们各自的位置相关的一个或多个依赖性。在该示例中，步骤1(270a)具有两个依赖性，如步骤2(270b)和3(270c)所示。步骤2(270b)具有两个依赖性，如步骤4(270d)和5(270e)所示。步骤3(270c)具有一个依赖性步骤6(270f)，并且类似地，步骤6(270f)具有一个依赖性步骤7(270g)。步骤4(270d)和5(270e)具有一个依赖性步骤7(270g)。步骤7(270g)依赖于步骤4(270d)、步骤5(270e)和步骤6(270f)。

在操作期间，调度器275跟踪每个步骤的依赖性计数。当特定步骤的依赖性计数达到0时，该步骤可以继续进行。在该示例中，步骤1(270a)的依赖性计数为0，因为其不依赖任何其他的步骤。步骤2-6(270b-270f)的依赖性计数为1，因为每个步骤仅依赖于前面的一个步骤270。步骤7(270g)的依赖性计数为3，因为其依赖于三个先前的步骤270d-270f。在步骤1(270a)完成后，调度将所有直接依赖步骤270的依赖性计数减少1。因此，在步骤1(270a)完成后，步骤2(270b)和3(270c)的依赖性计数具有为0的新的依赖性计数。因为现在步骤2(270b)和3(270c)的依赖性计数为0，所以这些步骤可以被并发执行。然而，步骤4-7(270d-270g)的依赖性计数没有被减少，因为它们之前的步骤没有被完成。

在步骤2(270b)完成后，步骤3(270c)可能仍然在处理中。在先前的解决方案中，依赖于步骤2(270b)的所有步骤在执行前必须等待步骤3(270c)完成。然而，当步骤2(270b)被完成时，调度器将步骤4(270d)和步骤5(270e)的依赖性计数减少1，这使它们的依赖性计数为0，从而允许它们与步骤3(270c)并发执行。在完成步骤3(270c)时，步骤6(270f)可以开始。当步骤4(270d)、步骤5(270e)和步骤6(270f)完成时，调度器275将跟踪它们的完成。步骤7(270g)不能开始执行，直到步骤4-5(270d-270f)全部完成。例如，步骤4(270d)可能第一个完成，此时，调度器275将步骤7(270g)的依赖性计数减少1，从而将其依赖性计数变为2。当步骤7(270g)的依赖性计数达到0时，步骤7(270g)可以开始执行。在步骤7(270g)完成时，调度器可以重新开始该过程，或者以其他方式遵循协调计划中提供的其他指令。

在结束协调计划前，步骤图265可以被拓扑地排序，以确定是否存在可能导致步骤270进入无限循环的循环。例如，如果步骤1(270a)依赖于步骤3(270c)，并且步骤3(270c)依赖于步骤1(270a)，那么将会创建无限循环，从而阻止操作继续进行。步骤图265可以由计划器使用线性时间算法来排序。在一种实现中，计划器可执行的线性时间算法可以包括tarjan算法。

上面讨论的跟踪特定步骤270之间的依赖性的方法表示用于跟踪步骤270依赖性的一种方法。在其他的实现中，跟踪依赖性可以包括增加依赖性计数、增加依赖性计数或当达到特定的所分配或所得出的值时执行步骤270。因此，跟踪步骤270依赖性是指确定特定步骤270是否依赖于会阻止主体步骤270的执行的另一特定步骤270的能力。

具体转到图6，示出了根据一个或多个实施例的并发执行步骤的方法的流程图。在本示例中，开发(600)一组服务的表示，其中每个服务经由不同类型的关系与其他服务相关。诸如上文所讨论的特定的关系可以包括父、子、关系、引用、先决条件等。取决于服务的类型，关系图可以包括包含节点和弧的有向非循环图(dag)，以及包括生成树的森林的有向dag，它们之间有交叉引用。在其他实现中，图可以是包含具有一个或多个连接的节点和弧的循环有向图，以及包括生成树的森林的循环有向图，其中生成树包含节点之间的交叉引用。根据本文所讨论的实现可以使用各种类型的有向图。

在表示的开发(600)期间，通过不同类型的关系将每个服务都建模为与其他服务相关。在一种实现中，计算设备可以构建mtosi模型作为输入。通过构建模型，计算设备表示存在于每个服务之间关系类型。

该方法还包括针对该组服务内的每个关系类型应用(605)一组依赖性规则，使得依赖性规则的应用创建表示该组服务的状态转换的步骤之间的步骤间依赖性。如上所述，每个服务都可以被定义为包括特定的步骤间依赖性，从而避免特定步骤的执行，直到一个或多个其他步骤完成为止。依赖性规则可以允许对随后讨论的图的自动生成和修改。

该组依赖性规则可以依赖给定服务和其他服务之间的关系类型。该组依赖性规则的示例可能可以查看状态转换，状态转换应当在给定的依赖性规则之前和之后被执行。这提供了该组依赖性规则可以导致表示服务的状态转换的步骤之间的依赖性的指示。下面列出了依赖性规则的示例，然而，也可以实现其他依赖性规则。因此，可能会有额外的依赖性规则或比下面列出的更少的依赖性规则。例如，一组依赖项规则根据关系类型被分组。对于子关系类型，依赖性规则可以包括如下内容：

child_setup–在子服务/组件在被设置为相同的mtosi状态之前，子级等待其父级达到给定的mtosi状态。

child_teardown–父服务等待被清除成任何给定的mtosi状态，直到它们的子组件/服务最多首先处于该状态。

resource_teardown–资源子级在被清除之前等待父级被终止。

在另一示例中，对于父关系，依赖性规则可以包括如下内容：

parent_complete–在父级本身被标记为完成之前，父级等待其子级完成。注意“完成”的含义取决于所期望的服务的状态。

parent_lock_step–如果在描述符中定义了锁定步骤：是选项，则父设置进程将根据mtosi状态模型来等待子状态进行锁定步骤，从而使得父状态不会比子状态提前的一个状态。

parent_lock_step_teardown–如果在描述符中定义了锁定步骤：是选项，则父清除进程将根据mtosi状态模型等待子状态进行锁定步骤，从而使得父状态不会比子状态高出一个状态。

resource_setup–在父级变为已设计状态之前，父服务将等待资源变为活动状态。

在又一示例中，对于参考关系，依赖性规则可以包括如下内容：

reference_setup–在进展到保留状态之前，服务应当等待它的参考达到其期望的状态(通常是活动状态)。

reference_teardown–所参考的服务在其最后一个参考项被清除之前不会被自动清除。而且，如果最后一个参考项将其参考参数更改为不同的服务，则可能仍然存在旧参考的影子版本。因此，对所参考的服务的清除将一直等到影子版本被删除。

softref_setup(p1,p2,…,pn)–当先决条件参数(不同于参考和辅助参考)参考服务时，则在设置期间参考项的状态保持在所参考的服务的状态之后。注意这与reference_setup不同，因为所参考的服务不会在参考项之前被强制变为活动状态；相反，参考项可以处于较低的mtosi状态。依赖性列出了创建依赖性的(多个)参数的名称–因此这些参数有可能是先决条件：否注释的候选。

softref_teardown(p1,p2,…,pn)–与softref_setup相同，但是用于避免所参考的服务的清除。

reference_lockstep–与softref_setup类似，但将所参考的服务的状态抑制为保持至多领先参考项服务一个mtosi状态。与softref_teardown类似，但将所参考的服务的状态抑制为保持比参考项服务大至多一个mtosi状态。

resref_setup(p1,p2,…,pn)–这与软参考类似，但是当使用先决条件：资源来指定参数时，将生成此规则，而不是softref_setup。通过此规则，即使在当前服务变为设计状态之前，由列出的参数参考的服务也将变为其期望的状态。因此，与reference_setup类似，但其适用于任何参数，甚至限制性更强。在版本2.2.1中，先决条件：资源注释不能用于参数参考和辅助参考。

resref_teardown(p1,p2,…,pn)–与resref_setup相同，但是用于避免过早清除所参考的服务。

transition_order–由mtosi状态模型定义的状态转换序列。

该方法还包括基于步骤间依赖性的创建来开发(610)协调计划，该协调计划允许非依赖步骤的并发执行。如关于图5所述，协调计划可以基于生成的步骤图，该步骤图包括多个步骤。步骤图上的每个步骤可以表示一个过程，并且可以被表示为或基于上面讨论的一个或多个类型的有向图。在操作期间，调度器可以跟踪步骤图上的特定步骤之间的依赖性。在某些实现中，调度器可以使用依赖性计数来跟踪依赖性。当一个步骤所依赖的所有步骤都完成时，调度器可以随后减少该步骤的依赖性计数。因此，在某些实现中，一个步骤可以依赖于一个以上的在先步骤。该步骤可以等待其所依赖的每一个步骤的执行。通过创建和绘制各个步骤之间的关系，不依赖其他步骤的步骤可以并发执行。因此，该方法还包括并发执行至少两个非依赖的步骤。当特定步骤具有的依赖性计数为0时，非依赖的步骤可以执行。因此，多个步骤可以同时运行，取决于具有依赖性计数为0的特定步骤。诸如上文所讨论的其他计数步骤的方法也可以用于确定哪些步骤可以并发执行。

尽管本文关于图5讨论了具有7个步骤的过程，但是在操作中，过程可以有数百甚至数千个步骤。类似地，尽管本文明确地公开了一到三个依赖性，但在实践中，每个步骤都可以依赖于超过三个的多个步骤。

该方法还可以包括各种其他实现来进一步提高执行速度。例如，在一种实现中，如果步骤图包含会导致无限循环的环形，则可以拒绝该步骤图。例如，如果两个步骤彼此依赖，则该过程将不会前进，因为将永远不会完成，从而导致无限循环。为了避免这样的循环，在开发协调计划时，计划器可以提供排序功能，其对步骤图的拓扑进行排序。在某些实现中，可以使用tarjan算法来执行拓扑排序。

转到图7，根据一个或多个示例实施例示出了具有硬件处理器和可访问的机器可读指令的示例计算设备。图7提供了示例计算设备625，该计算设备具有硬件处理器630和存储在机器可读介质635上的可访问的机器可读指令，该可访问的机器可读指令用于执行具有上文关于一个或多个公开的示例实现所讨论的多个非依赖步骤的协调计划的执行。图7示出了被配置为执行块600、605和615中描述的流程以及关于图6详细讨论的块600、605和615中描述的流程的计算设备625。然而，计算设备625还可以被配置为执行本公开中描述的其他方法、技术、功能或过程的流程。

在本实现中，基于步骤间依赖性的创建的协调计划的开发包括，如果第一步骤不依赖于第二步骤，则允许第一步骤执行。例如，如果第二步骤依赖于第一步骤，则第二步骤具有防止其在第一步骤完成之前执行的步骤间依赖性。示例步骤间依赖性可以包括父子关系。在另一示例中，第二步骤可以依赖于第一步骤与第二步骤之间的步骤。在这样的示例中，第二步骤可以具有父孙关系并且子步骤可以创建除了父步骤之外的依赖性。在某些实现中，第一步骤和第二步骤可以并发执行，只要两个步骤彼此不依赖，并且两个步骤都不依赖于与第一步骤或第二步骤相关的第三步骤。

诸如图7的635的机器可读存储介质可以包括易失性的和非易失性的、可移动的和不可移动的介质二者，并且可以是任何电子、磁、光学或其他物理存储设备，其包含或存储可执行的指令、数据结构、程序模型或处理器可访问的其他数据，例如固件、可擦除可编程只读存储器(eprom)、随机存取存储器(ram)、非易失性随机存取存储器(nvram)、光盘、固态硬盘(ssd)、闪存芯片等。机器可读存储介质可以是非瞬态存储介质，其中术语“非瞬态”不包含瞬时传播的信号。

转到图8，示出了可用于实现根据一个或多个示例实施例的功能和进程的计算机处理设备的示意表示。图8示出了可以用于实现本公开的系统、方法和过程的计算机处理设备700。例如，图8所示的计算设备700可以表示客户端设备或物理服务器设备，并且包括依赖于计算设备抽象级别的(多个)硬件或虚拟处理器。在一些实例中(非抽象)，如图8所示的计算设备7及其元件分别与物理硬件相关。备选地，在一些实例中，一个、多个或所有元件可以使用模拟器或虚拟机作为抽象级别来实现。在任何情况下，无论距离物理硬件多少抽象级别，在其最低级别的计算设备700都可以在物理硬件上实现。在一种实现中，计算设备700可以允许用户远程访问一个或多个数据中心。类似地，用户使用的管理工具可以包括在这样的计算设备700上运行的软件解决方案。

图7示出了根据一个或多个示例实施例的计算系统700。计算系统700可以包括被布置在一个或多个印刷电路板(未另行示出)上的一个或多个中央处理单元(单数形式“cpu”或复数形式“cpu”)705。一个或多个cpu705中的每一个可以是单核处理器(未单独示出)或多核处理器(未单独示出)。多核处理器通常包括被布置在同一物理芯片(未示出)上的多个处理器核心(未示出)或被布置在多个芯片(未示出)上的多个处理器核心(未示出)，这些芯片被共同布置在同一机械封装内(未示出)。计算系统700可以包括一个或多个核心逻辑设备，诸如主机桥710和输入/输出(io)桥715。

cpu705可以包括到主机桥710的接口708、到系统存储器720的接口718、以及到诸如，例如图像处理单元(gfx)725等一个或多个io设备的接口723。gfx725可以包括一个或多个图像处理器核心(未单独示出)和到显示器730的接口728。在某些实施例中，cpu705可以将gfx725的功能和接口直接与显示器730集成在一起(未示出)。主机桥710可以包括到cpu705的接口708、到io桥715的接口713，对于cpu705不包括到系统存储器720的接口718的实施例，可以包括到系统存储器720的接口716，以及对于cpu705不包括集成的gfx725或到gfx725的接口723的实施例，可以包括到gfx725的接口721。本领域普通技术人员将认识到cpu705和主机桥710可以被全部或部分集成来减少芯片数目、主板的覆盖区、热设计功率和功耗。io桥715可以包括到主机桥710的接口713、到一个或多个io扩展设备735的一个或多个接口733、到键盘740的接口738、到鼠标745的接口743、到一个或多个本地存储设备750的接口748、以及到一个或多个网络接口设备755的接口753。

每个本地存储设备750可以是固态存储器设备、固态存储器设备阵列、硬盘驱动器、硬盘驱动器阵列或任何其他非瞬态计算机可读介质。每个网络接口设备755可以提供一个或多个网络接口，包括例如以太网，光纤通道，wimax，wi-fi，蓝牙或任何其他适用于促进连网通信的网络协议。计算系统700可以包括除了或代替一个或多个本地存储设备750的一个或多个网络附加存储设备760。网络附接存储设备760可以是固态存储器设备、固态存储器设备阵列、硬盘驱动器、硬盘驱动器阵列或任何其他非瞬态计算机可读介质。网络附接存储设备760可以或不可以与计算系统700并置，并且可以由计算系统700经由一个或多个网络接口设备755所提供的一个或多个网络接口访问。

本领域普通的技术人员将会认识到计算系统700可以包括一个或多个专用集成电路(asic)，该一个或多个asic被配置为执行某个功能，例如，以更有效的方式进行散列(未示出)。该一个或多个asic可以直接与cpu705、主机桥760、系统存储器720或io桥715进行接口连接。备选地，专用计算系统(未示出)，有时被称为开采系统，可以被简化为执行所期望的功能的组件，诸如经由一个或多个散列asic进行散列，来减少芯片数目、主板的覆盖区、热设计功率和功耗。因此，本领域普通技术人员将会认识到cpu705、主机桥710、io桥715或asic或它们的功能或特征的各种子集、超集或组合可以全部或部分地被集成，或者以可基于根据一个或多个示例实施例的应用、设计或形状因子而改变的方式被分布在各种设备之间。因此，对计算系统700的描述只是示例性的，并且不旨在限制构成计算系统的组件的类型、种类或配置，该计算系统适合于执行计算操作，包括但不限于散列功能。此外，本领域普通技术人员将认识到计算系统600、专用计算系统(未示出)或它们的组合可以按照独立的、桌面的、服务器的或机架上可安装的形状因子来布置。

本领域普通技术人员将认识到计算系统700可以是基于云的服务器、服务器、工作站、台式电脑、笔记本电脑、上网本、平板电脑、智能手机、移动设备和/或根据一个或多个示例实施例的任何其他类型的计算系统。

应当理解的是，以上所有概念的组合(假设这样的概念不是相互矛盾的)被视为本文公开的发明主题的一部分。特别地，出现在本公开的结尾处的所要保护的主题的组合被视为本文公开的发明主题的一部分。还应当理解的是，在本文中明确使用的、也可以出现在通过引用并入的任何公开中的术语应被赋予与本文中公开的特定概念最一致的含义。

尽管已经结合各种示例描述了本教导，但不旨在将本教导限制于这样的示例。上文描述的示例可以用多种方式中的任何一种来实现。

此外，本文描述的技术可以被体现为已经对其提供至少一个示例的方法。作为该方法一部分而执行的动作可以任何适当的方式排序。因此，可以构造这样的示例，其中动作以不同于所示的顺序来执行，其可以包括同时执行一些动作，即使在说明性示例中被示为顺序动作。

一个或多个示例实施例的优点可以包括以下中的一个或多个：

在一个或多个示例中，本文公开的系统和方法可以用于提高执行服务集合中的非依赖步骤的处理速度。

在一个或多个示例中，本文公开的系统和方法可以用于降低用于执行计划的时间。

并非所有实施例都必然表现所有这些优点。就各种实施例可以表现出这些优点中的一个或多个的程度而言，并非所有的实施例都将表现出相同的程度。

尽管已经关于上述实施例描述了要保护的主题，但受益于本公开的本领域技术人员将认识到可以设计如本文公开的示例实施例所示的权利要求范围内的其他实施例。