管理并简化分布式应用的制作方法
管理并简化分布式应用的制作方法
【专利摘要】分布式实例系统管理各实例以及各实例之间的通信。该分布式实例系统向各实例提供有限的一组通信方法。基于所使用的通信方法的类型，该分布式实例系统知道各实例所发送的消息并且可作出关于如何处理这些消息的决策。在消息交换中所涉及的实例之一结束时，主机使用它对消息交换类型的知识来确定是否丢弃该消息、丢弃该消息的回复、和/或向尚存的实例发送出错消息。一实例可按树类结构来创建一个或多个子实例。状态数据从各子实例沿该树向上传递，并被聚集在父实例中。可根据所聚集的状态数据来生成监视数据。
【专利说明】管理并简化分布式应用
【背景技术】
[0001]大型分布式应用管理起来很复杂。具体而言，需要大量的手动干预来处理分布式通信的不可靠性质。对于可运行交换数百万消息的数百万进程的非常大规模的应用而言，这一问题恶化。传统上，这些大规模应用需要来自系统管理员的人类干预来手动地补偿和纠正出现故障的进程。另外，这些应用需要支持这一干预的广泛的基础结构，如死信队列和挂起进程报告。
[0002]例如在两个应用(如业务进程的两个组件)交换消息时，问题会发生。这些应用可通过中介来交换消息。发送实例可要求对发送给目的地实例的消息的响应。然而，如果目的地实例在接收到该消息之前结束，则该消息将处于中介中。结果，发送实例从未接收到响应，并且因此变得停止。当大型分布式应用运行数百万进程时，数千不可路由的消息可在中介中聚集。系统管理员必须手动清理这些不可路由的消息并重启停止的进程。对于极大型分布式应用而言，规模变得过大，以致人类操作员无法管理这些不可路由的消息、停止的进程以及类似问题。
[0003]这些问题不只是大型应用的问题，而是也出现在小型应用中。另外，在使用经中介的消息收发时以及在使用相关的单向点对点消息收发时，这些问题产生。其他大规模场景，如大量小型托管应用，也可能需要解决这些问题。
[0004]概述
[0005]提供本概述以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。
[0006]本解决方案通过向系统开发者提供允许将各应用表示为多个实例的增强的分布式实例系统而降低了管理开销。各实例只通过有限的一组消息交换模式来通信。该系统知晓所有各单独实例和这些实例中的每一个的寿命。通过将实例寿命意识与有限的消息交换模式的组合，该系统可以做出关于如何处理故障的适当决策。这创建了极低成本的编程平台，甚至适用于通常没有活动人类管理角色的最终用户应用。另外，该分布式实例系统提供了用于创建极大型系统的理想平台，该极大型系统利用消息收发系统中内在的最终一致性，针对分布式事务的缺少进行了优化，并且具有多承租人、高密度云计算的可伸缩性要求。
[0007]该分布式实例系统可被实现成执行环境、分布式运行时、分布式管理环境、分布式管理和执行系统、或提供实例的寿命管理的其他平台。该系统可被实现在单个机器上或可被虚拟化在多个机器、服务器或处理器上。
[0008]各实例包括行为和相关联的状态的组合。应用的状态可被分解成一系列实例，其中各单独的实例表示该应用的问题域的具体人工产物。各实例可与其他实例通信。各实例可具有显式的寿命，如显式的开始和结束。各实例在该系统中的存在和寿命可以是外部可见的并且可在外部进行管理。
[0009]各实施例可以使用实例管理器，该实例管理器担当分布式实例系统中的增强的中介，用于管理各实例之间的通信。在现有系统中，中介管理各通信，但不知道各应用所使用的消息交换模式。在本发明的系统中，与先前分布式系统中可用的实例通信知识相比，实例管理器具有更多的实例通信知识。另外，该实例管理器知道各实例的寿命并且可以基于对实例寿命的这一知识来管理通信。例如，实例管理器可以管理两个实例A和B之间的通信。实例A向实例B发送消息，并且包括与该消息有关的可被实例管理器用来作出关于该消息的决策的信息。例如，实例A可以将该消息标识为请求-回复交换的第一局。
[0010]在传统的中介系统中，如果实例A在接收到来自实例B的回复之前结束，则回复消息将被保持在死信队列中。网络管理员将必须从死信队列中手动地清除该回复消息。在极大规模应用的情况下，死信队列中可存在数千消息，并且人类网络管理员将必须分析并消除这些消息中的每一个。另外，在大量应用的情况下，可存在要按此方式手动地监视和维护的数千消息队列。
[0011]在本文公开的系统的各实施例中，该分布式实例系统具有与消息交换有关的信息一即，它是请求-回复。因此，该实例管理器可以基于消息的预期使用来作出与如何处理消息有关的决策。如果分布式实例系统知道该消息是请求-回复交换的回复部分，并且发出请求的实例A已完成或不再对该回复感兴趣，则该分布式实例系统可以只是消除该回复消息而非尝试将它递送给实例A。因为实例A已完成，所以它不关心或需要从实例B接收该回复消息，因为它将简单地将该消息作为噪声而丢弃。
[0012]类似地，如果实例B在接收到来自A的请求消息之前已完成，则该分布式实例系统(它具有与该消息交换有关的信息)可作出关于实例管理器应当如何处理该请求消息的决策。并非坚持该请求消息作为不可递送的信和/或继续尝试递送给实例B，实例管理器可向实例A发送出错消息。实例A可具有消息出错处理智能，使得它可以处理请求消息的失败，而无需停止或等待来自实例B的回复(该回复将永远不会到达)。
[0013]在一个实施例中，增强的分布式实例系统管理各实例，知晓各实例的寿命，并且提供各实例之间的有限的一组消息交换模式。通过利用该有限的一组消息交换模式，该系统可以消除或降低对用户管理的需求。请求-回复消息允许各实例之间可靠的异步请求-回复通信。此外，对话是用于支持各实例之间可靠且异步的全双工消息收发交换模式的一种机制。
[0014]分布式实例系统可以将各实例构造成一个或多个分层结构树。这允许该系统凝聚性地管理各状态并且降低管理开销。各实例组织成分层结构树使得能够降低与管理极大型分布式应用中的各实例相关联的管理复杂度。例如，大型业务进程可包括多个异步业务事务。各实例的分层组织使得能够管理该大型业务进程。另外，各实例可被组织以在必要时提供隔离来保护业务进程信息。程序可被分成可高度并行化的多个可分布的状态。此外，各实例的处理逻辑定义可以是后期绑定的和独立地版本化的。
[0015]该系统运行各应用实例并向这些实例提供有限的一组消息交换模式。存储设备保持实例状态和消息。存储设备可在物理上位于一个或多个机器中，分布在一个或多个进程上。实例管理器支持这些有限的消息交换模式。
[0016]该有限的一组消息交换模式允许该系统设备标识可被消除而无需用户干预的消息。该有限的一组消息交换模式允许各实例交换异步请求和回复消息。实例管理器基于交换中所涉及的各实例的寿命来标识应被消除的请求和回复消息。[0017]各实例可被组织成分层结构，其中一个实例担当创建和/或管理一个或多个子实例的父实例。该分层结构可具有多个层，其中子实例生成它们自己的子实例并且因此也作为父实例来操作。子实例可向它们相应的父实例发送状态报告。每一父实例在将所聚集的状态报告传递给更高层父实例之前聚集来自它们相应的子实例的状态报告。在任何层处聚集的状态报告可被传递给管理入口。
[0018]各实例可包括监视实例。携带健康和状态信息的监视消息可通过实例树被向上传播。在根层或在较低层处的监视实例可收集监视消息。各实例可被组织成提供封装端到端进程的监视信息的同构视图。
[0019]对话是分布式实例系统所跟踪的两个实例之间的成对关联。对话可通过涉及这两个参与实例的握手来建立。握手由该分布式实例系统来协调。在参与对话的一实例已结束时，通知参与该对话的另一实例。任一实例可显式地终止对话，或通过终止自己从而隐式地终止所有它相关联的对话。在一实例终止对话时，通知该对话中的另一实例。在各实例具有父-子关系时，创建对话。这一对话是创建子实例的父实例的副作用。在子实例完成时，父-子对话结束。在父-子关系之外，一实例可以通过使用该分布式实例系统所协调的握手过程登记对另一实例的寿命的兴趣，来发起对话。对话是由该基础结构维护并理解的双方成对关系。之后，对话被建立，它是对称的。在一方结束对话时，通知另一方。父-子是对话的一特定使用。父实例创建子实例并且作为该创建的副作用，父实例和子实例两者是对话的双方。如果子实例终止，则向父实例通知对话结束。类似地，如果父实例终止，则向子实例通知对话结束并且子实例也终止。
[0020]在另一实施例中，一种用于管理多个实例的方法包括在一个或多个实例处理器上发起多个实例，监视该多个实例中的每一个的寿命，以及向该多个实例提供定义的一组消
肩、O
[0021]该方法还包括提供用于发送实例和目的地实例之间的通信的请求-回复消息格式，标识目的地实例在接收到请求消息之前何时已结束，以及自动消除该请求消息。该方法还在消除请求消息时向发送实例提供出错消息。
[0022]该方法还包括提供用于发送实例和目的地实例之间的通信的请求-回复消息格式，标识发送实例在接收到回复消息之前何时已结束，以及自动消除该回复消息。
[0023]该方法还可包括提供用于发送实例和目的地实例之间的通信的单向消息格式，标识目的地实例在接收到单向消息之前何时已结束，以及自动消除该单向消息。
[0024]多个实例可被安排成分层格式，其中各实例被安排成多层父-子编组。该方法还可包括从子实例向父实例发送实例状态信息，在父实例处聚集子实例的实例状态信息，将所聚集的状态信息从父实例发送给更高的父实例，以及将进程状态信息提供给监视实例，该进程状态信息包括所聚集的状态信息。所聚集的状态信息可以提供与各实例相关联的端到端进程的同构视图。
【专利附图】
【附图说明】
[0025]图1是根据一个实施例的分布式实例系统的各组件的高级框图；
[0026]图2是根据一个实施例的分布式实例系统的拓扑结构的高级框图；
[0027]图3示出了根据一个实施例的各实例的分层结构；[0028]图4示出了用于两个实例之间的请求-回复交换的请求-回复消息收发模式；
[0029]图5示出了用于两个实例之间的请求-回复交换的另一请求-回复消息收发模式；
[0030]图6示出了用于两个实例之间的单向消息的单向消息收发模式；
[0031]图7示出了两个实例之间建立的对话；以及
[0032]图8示出了创建了不同类型的两个子实例的父实例。
【具体实施方式】
[0033]大型计算系统包括多个分布式应用。各应用负责对处理逻辑进行处理并执行可能持续数星期、数月或甚至数年的长期运行的业务进程。各应用是隔离的，除了访问共享网络之外。各应用通过在这一网络上发送消息来进行通信。各进程的执行发生在大量物理计算资源上，并且因此该基础结构和计算系统必须被设计成是容错的。在现有系统中，这一要求的常见解决方案是使得所有消息交换经由中介异步地发生，该中介通常被实现成持久队列。使用异步通信也普遍适用于具有长期运行的业务进程的系统。
[0034]如果作为较大分布式应用的一部分的业务进程失败，则该分布式应用中的其他业务进程可被留置等待该失败的进程的输出，并且结果，相关联的消息留置未经处理。留置等待的进程和消息需要某种方式的人类干预才能恢复或除去它们。例如，如果业务进程在请求-回复消息交换期间失败，则始发应用可留置等待，不知道失败或挂起的进程。此外，原始请求消息留在中介中，而中介不能够处理该消息，除了将它标志为不可递送的信之外。这些不可递送的信通常需要人类干预才能补偿和纠正失败的进程并清理中介。
[0035]业务进程在它们的寿命中横跨多个应用，并且这些应用通常具有不同的管理特性。结果，没有系统健康、端到端进程状态、或其他监视数据的单个经协调的视图。相反，系统管理员通常处理各种控制系统并且形成每一控制系统中的专家知识。
[0036]因为这些系统中的业务进程通常持续很长一段时间，所以当业务进程内的逻辑需要改变时，如由于公司购置或策略变化，难以在不中断进行中(in-flight)进程的情况下更新该逻辑。这一问题在传统上由应用开发人员来解决，他们负责实现复杂的分支逻辑以处理存在的部分完成的进程。
[0037]为了解决现有系统中的这些问题，在一个实施例中，一种增强的系统负责这些业务进程的处理和组织。通过使用有限且很好地理解的一组消息交换模式，该增强的系统使得消除挂起的进程和死信以及降低相关联的管理开销成为可能。此外，通过将这些进程的各组成部分按分层方式来组织，简化这样的系统的管理是可能的，从而提供覆盖端到端进程的单个监视和控制体验。通过使得该系统处理诸如最终一致性、故障传播、以及跨实例相关等复杂度，降低了对分布式应用的各部分进行协调的认知开销。
[0038]业务进程的各组成部分在运行时作为各实例出现，其中实例表示处理逻辑单元及其相关联的状态两者。各实例可分布在许多处理单元上而没有对特定一个处理单元的任何亲和性。
[0039]图1是根据一个实施例的分布式实例系统100的各组件的高级框图。该分布式实例系统包括运行一应用或进程的各实例的一个或多个实例处理器101。实例管理器102控制实例处理器101并分配在实例处理器101上运行的特定实例。实例管理器102还监视每一实例的寿命并且知道每一实例何时开始和结束。
[0040]各实例和应用状态可被存储在实例存储103中。虽然图1中示出了单个存储设备102，但分布式实例系统100可包括多个存储设备。在其他实施例中，作为实例存储103的补充或替换，可以使用外部存储设备。在一个实施例中，每一实例一次被绑定到一个存储设备103。如所需要的，实例-存储绑定可作为再平衡、故障切换、或迁移的一部分来改变。在其他实施例中，存储103是可任选的，并且实例状态和消息被存储在实例处理器101内，这可使得该系统工作在降低的可靠性水平上。存储设备103的使用可以是按实例决策，其中一些实例状态和消息可外部化到存储中，而其他则不会。各实例可与相同或不同应用或进程的其他实例进行通信。
[0041]在实例处理器101上运行的实例可彼此通信以允许在各实例之间交换消息。消息存储104可被用来存储消息和消息状态。实例管理器102通过消息总线105将消息路由到各系统组件并在各系统组件之间路由消息，如在实例处理器101、实例存储103、以及消息存储104之间。实例管理器102实施在该分布式实例系统上可用的消息交换模式。
[0042]实例管理器102负责执行各实例的处理逻辑并控制实例处理器101上的实例。实例管理器还管理各实例的寿命。可在实例管理器102和实例处理器101之间交换控制消息，以创建新实例和终止已有实例。实例管理器负责实现这些命令，并且结果，知道所有实例的寿命。
[0043]实例管理器还负责处理各实例之间的消息交换。向实例管理器102提供了与每一消息有关的附加知识，包括哪一实例发送了该消息以及应当接收该消息的哪一个或多个实例。实例管理器102提供有限的一组消息收发模式，这允许该系统作出有关该系统内的消息收发行为的具体声明以简化该系统及其管理。
[0044]两个主要的消息收发模式是请求-回复和单向。
[0045]请求-回复消息收发模式这一模式用于两个实例之间的异步请求-回复通信。因为该分布式实例系统知道发送者和接收者实例两者的寿命，所以该系统呈现了多个简化属性。例如，如果接收者实例在发送回复之前终止，则该系统向发送者返回出错响应。这消除了先前将被留在中介处的挂起的业务进程和死信。如果发送实例在响应被递送之前终止，则该系统可以丢弃该回复消息。如果响应的递送必须被保证，则回复实例(即，原始接收者实例)可建立与原始发送实例的请求-回复交换。
[0046]单向消息收发模式这一模式用于两个实例之间的异步单向通信。发送和接收实例可在传送单向消息之前建立对话。在一些情形中，单向消息可绑定到对话。对话是该分布式实例系统的通信模型的一部分。对话经由异步握手通过实例管理器来建立，该实例管理器可以是持久中介(如果需要持久性的话)。或者，一操作可建立对话作为直接作用或作为副作用。如果接收实例在递送单向消息之前结束和/或终止对话，则该系统按与单向消息收发的大多数实现一致的方式丢弃该消息。然而，该系统还将该对话的终止通知给发送实例。
[0047]请求-回复和单向消息收发模式可被组合，以创建其他更丰富的消息收发模式，如发布和订阅。
[0048]实例分层结构该分布式实例系统还将各实例构造成分层结构。如果实例A创建新实例B，则实例A自动变成实例B的父实例。实例A可能不能够直接创建新实例，但可改为要求该系统对新实例的创建进行仲裁。类似地，如果实例B稍后创建新实例C和D，则实例B自动变成实例C和D的父实例，以此类推。各实例之间的这一关系创建实例树。该树中的各实例将业务进程的多个分开且不同的片段组合成例如反映该端到端进程的分层结构。
[0049]每一子实例可具有与其相应父实例的自动对话。这样的父-子对话将不需要附加的握手来建立。在一些实施例中，子实例可能不能够独立于它自己的寿命来终止父-子对话。此外，父实例可能不能够通过终止父-子对话来迫使终止子实例。
[0050]各实例还可按需创建。例如，如果实例Z向实例E发送消息，但实例E尚未存在，则该分布式实例系统可具有确定哪一实例应当是实例E的父实例的功能。该系统随后通知该预期父实例(例如，以上的实例B)，并且随后预期父实例B有机会创建实例E作为子实例。实例E随后可接收来自实例Z的消息。类似地，如果实例B也尚未存在，则该过程可跨多层来被重复。例如，实例A可接收来自该系统的创建实例B的通知，并且随后实例B接收创建实例E的通知。
[0051]这一端到端进程的节点分层结构具有单个根。在其他实施例中，该分层结构可具有多个根。例如，监视实例也可以是根节点。这允许该系统提供统一的控制模型。例如，终止或挂起父实例造成该同一控制动作传播到它的所有子实例，而不必特别地解决该分层结构中每一单独的实例。此外，该分层结构呈现用于聚集来自各实例的监视和健康信息的机会。结果，监视端到端进程更简单。这可通过使用该系统所呈现的第三消息收发模式——监视消息模式一来实现。
[0052]聚集消息收发模式这一模式被用来异步地传送监视数据。实例可发出自动沿实例树向上转发的监视消息一从子实例行进到父实例，并随后到父实例自己的父实例一直至监视消息到达根实例为止。监视消息可具有与其他消息不同的时间线特性。例如，监视消息可具有比操作消息低的优先级。具体而言，监视消息可机会性地从实例转移到实例，如通过承载在其他交换上以提高系统效率。任何实例可订阅这一监视数据流，从而允许实例捕捉该分层结构的订阅实例的那一部分的所有监视数据。这将向订阅实例提供该进程的任何部分的完整画面。任何实例可抑制监视数据沿分层结构向上传播。实例既可发布监视数据又可抑制监视数据的进一步传播。将理解，监视只是一个示例，并且作为监视数据的补充或替换，各实例之间可交换任何类型的数据。
[0053]图2是根据一个实施例的分布式实例系统200的拓扑结构的高级框图。实例处理器201可被实现成多个实例处理节点201，每一实例处理节点都在实例管理器202的控制之下。实例存储203保持不活动时间段期间的各实例以及应用状态和消息状态。实例处理器在系统故障的情况下提供可靠的消息收发和可恢复性。然而，如果例如既不要求或需要可靠的消息收发又不要求或需要持久的实例，则这些能力中的任一个可被牺牲。
[0054]实例管理器202负责将各实例的处理逻辑加载到所分配的实例处理器201。这允许该系统向应用呈现多个附加的简化益处，包括加载处理逻辑的不同版本的能力以及允许各实例版本的并排执行。例如，以实例的处理逻辑的版本I开始的业务进程可继续使用该版本，即使在创建了版本2时也如此。业务进程的新实例可自动利用最新版本。
[0055]此外，该系统将业务进程表示为不同的经协调的实例的分层结构的能力极大地降低了对正在进行的进程的变更的影响，从而允许应用开发人员将各进程建模成可独立地版本化的各实例的组合。[0056]图3示出了根据一个实施例的各实例的分层结构300。根实例301被创建并且是实例302和303的父实例。进而，实例302被创建并且是实例304和305的父实例，而实例303被创建并且是实例306和307的父实例。
[0057]再参考图1，实例301-307可在一个或多个实例处理器101上运行。实例301-307可全部在同一实例处理器101上运行或可分散在多个实例处理器101上。在高度分布式的应用中，每一实例301-307可在单独的实例处理器101上运行。实例301-307中的一个或多个可在与分布式实例系统100经由外部总线105进行通信的分开的分布式实例系统上运行。这样的外部通信假定在外部总线上使用的协议与分布式实例系统所使用的有限消息交换模式之间的桥接已经完成。
[0058]任何实例301-307可参与同任何其他实例301-307的请求-回复消息交换。任何实例301-307可与任何其他实例301-307建立对话308。单向消息可通过已在各实例之间建立的对话308发送。
[0059]实例301-307形成卷升至根实例301的分层结构。监视消息沿该分层结构向上传送，并且监视实例309可订阅该监视数据。根实例301将监视数据310发布给监视实例309。监视数据310由应用创建并且表示该应用的当前状态。监视数据310沿分层结构树向上流动。监视数据在每一层处被聚集，使得实例303聚集实例304和305两者的监视数据且根实例301聚集实例301和303两者以及它们相应的子节点的监视数据。将理解，监视实例309不限于在根实例处监视，而是可插入在任何层处。例如，监视实例309可替换地接收来自实例303的监视数据311。来自实例303的监视数据311包括实例303及其子实例306和307的所聚集的状态和健康数据，而监视数据310包括所有实例301-207的所聚集的状态和健康数据。
[0060]分层结构300可扩展到任何数量的实例。父实例与其子实例之间存在隐式的对话，这允许父实例和子实例进行通信并知道相关实例的状态。通过将子实例的寿命绑定到它的父实例，简化了各实例的管理。子实例不能比它的父实例更长寿。因此，如果一实例结束，则该实例的所有子实例也结束。这提供了一种容易的方式来结束并清理该实例之下所有层处的实例，并允许最终用户将树中的各实例当成一个。以此方式，各进程被分解成更加可管理的一组实例。如果根实例301结束，则该分层结构中的所有实例结束。
[0061]情形1:图4示出了用于两个实例之间的请求-回复交换的请求-回复消息收发模式。始发实例401向目的地实例403传送操作请求402。请求402被传递给实例管理器404，实例管理器404负责将请求402转发给目的地实例403。然而，在实例管理器404能传递请求消息402之前，目的地实例403结束(405)。实例管理器404知道每一实例401、403的寿命。因此，实例管理器404知道目的地实例403已结束并且该操作请求将永远不能路由到它的目的地。因此，实例管理器404向源实例401发送出错回复406并消除请求402，从而防止请求402变成不可递送的信并且防止始发实例401变成挂起的实例。
[0062]情形2:图5示出了用于两个实例之间的请求-回复交换的另一请求-回复消息收发模式。始发实例501向目的地实例503传送操作请求502。请求502被传递给实例管理器504，实例管理器504负责在消息505中将请求502转发给目的地实例503。目的地实例503接收请求505并生成操作回复消息506，该操作回复消息在实例管理器504的控制下被发送回始发实例501。然而，在实例管理器504能传递回复消息506之前，始发实例501结束(507)。实例管理器504知道每一实例501、503的寿命。因此，实例管理器504知道始发实例501已结束并且该操作回复506将永远不能路由到它的目的地。因为始发实例501已结束，所以该回复不再需要或有用。因此，实例管理器504消除回复506，从而防止回复605变成不可递送的。
[0063]情形3:图6示出了用于两个实例之间的单向消息的单向消息收发模式。始发实例601将信号602传送到目的地603。信号602是始发实例601不会预期有响应的单向消息。实例管理器604接收消息602，消息602应被转发给目的地603。然而，目的地实例603在信号602可被递送之前结束(605)。实例管理器604知道目的地实例605的状态并且知道该实例何时已结束。因此，并非将信号602保持作为不可递送的，实例管理器604消除该信号。因为信号602是单向消息并且始发实例601没有预期来自目的地实例603的响应或确认，所以实例管理器604仅仅终止信号602并且不创建发给始发实例601的进一步的出错消息或警告。这是真实的单向消息交换，其中始发实例只需要知道该信号被发送并且不关心该信号是否被接收到。因此，在目标实例结束时，信号602可被实例管理器604安全地丢弃。
[0064]情形4:图7示出了两个实例之间建立的对话。实例A701通过向实例管理器704注册对实例B703的兴趣来建立与实例B703的对话702。一实例可向中介、实例管理器、或某一其他设备注册对另一实例的兴趣。对话是通过涉及两个参与实例的握手来建立的，该握手由分布式实例系统进行协调。一旦建立了对话702，实例701、703就可跟踪该对话并且因此可跟踪另一实例的寿命。任一实例可建立对话。对话继续，直至被一个实例取消或直至一个实例结束。将要结束的实例可通知另一实例该对话将结束，或者实例管理器可以通知一个实例对话中的另一实例已经完成。例如，在实例B703结束(705)时，实例管理器704可使用通知706来通知实例701。或者，在一个实例认识到该对话已经意外终止(即，在没有通知的情况下)，这指示另一实例已经结束。
[0065]对话可被用来支持或增强单向消息收发。例如，该对话的一个实例可向该对话中的另一实例发送信号。发送实例不要求对该单向信号消息的回复，但在发送消息时以及在传输之后的某一时间内知道目的地实例是否是活的。这一生命状态知识可被发送实例用来评估该信号是否被目的地实例接收到的可能性。具体而言，发送实例可等待(直接或间接)依赖于该信号的接收的事件。对话的终止告知该实例信号可能已经丢失，所以它可以选择做除等待该事件之外的某些事情。
[0066]本文描述的实例可以是不同类型的，并且可以与不同的进程相关联。图8示出了创建了不同类型的两个子实例802、803的父实例801。例如，在订单业务进程中，在顾客开始新订单时，订单实例801可被创建。订单实例801可生成挑选子实例802以向顾客提供物品选择进程。订单实例801还可生成运送子实例803以提供顾客所选择的物品的运送进程。
[0067]挑选实例802和运送实例803可以使用请求-回复消息收发和单向消息收发来交换信息以完成顾客的订单。挑选实例802和运送实例803还可建立对话804来跟踪另一实例的寿命。
[0068]挑选实例802和运送实例803可以向父订单实例801发送监视消息，订单实例801可进而将该健康信息沿进一步的实例树向上传播。[0069]订单实例801、挑选实例802以及运送实例803可以是在使用特定订单进程的各顾客之间提供隔离的许多独立的订单-实例树之一。这一隔离可以提供保护业务进程和个人顾客信息的安全性。
[0070]作为许多独立的订单-实例树之一，订单实例801、挑选实例802以及运送实例803提供按高度并行化方式操作的多个分布式订单进程。
[0071]本文描述的功能中的许多功能可以用硬件、软件、和/或固件、和/或其任何组合来实现。在用软件实现时，各代码段执行必要的任务或步骤。程序或代码段可被存储在处理器可读、计算机可读或机器可读介质中。处理器可读、计算机可读或机器可读介质可包括能存储或转移信息的任何设备或介质。这样的处理器可读介质的示例包括电路、半导体存储器设备、闪存、ROM、可擦除ROM (ER0M)、软盘、紧致盘、光盘、硬盘、光纤介质，等等。
[0072]例如，在图1中，存储102可以是任何易失性或非易失性存储设备，如硬盘驱动器、闪存、固态存储器、光盘、CD、DVD、计算机程序产品、或向实例处理器101提供计算机可读或机器可读介质的其他存储器设备。在其他实施例中，存储器可以是若干物理存储设备的虚拟化，其中物理存储设备是相同或不同的种类。代码段可以经由内部总线、另一计算机网络(如因特网或内联网)、或经由其他有线或无线网络等从存储102下载或转移到实例处理器101。
[0073]尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言，上述具体特征和动作是作为实现权利要求的示例形式公开的。
【权利要求】
1.一种分布式实例系统,包括: 运行一个或多个进程的实例的一个或多个实例处理器； 管理在所述实例处理器上运行的实例的一个或多个实例管理器，所述实例管理器监视所述实例的寿命并且向所述实例提供受管理的一组消息交换模式。
2.如权利要求1所述的分布式实例系统，其特征在于，有限的一组消息交换模式允许所述分布式实例系统标识无需用户干预就能被消除的消息。
3.如权利要求1所述的分布式实例系统，其特征在于，所述有限的一组消息交换模式允许各实例交换异步请求和回复消息，以及 其中所述实例管理器基于交换中所涉及的各实例的寿命来标识应被消除的请求和回复消息。
4.如权利要求1所述的分布式实例系统，其特征在于，一实例发起与另一实例的对话，其中所述对话是使用涉及这两个实例的握手来发起的，所述握手由分布式实例系统来进行协调。
5.一种用于管理多个实例的方法，包括 在一个或多个实例处理器上发起多个实例； 监视所述多个实例中的每一个的寿命；以及 向所述多个实例提供定义的一组消息。
6.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的请求-回复消息格式； 标识所述目的地实例在接收到请求消息之前何时已结束；以及 自动消除所述请求消息。
7.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的请求-回复消息格式； 标识所述发送实例在接收到回复消息之前何时已结束；以及 自动消除所述回复消息。
8.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的单向消息格式； 标识所述目的地实例在接收到单向请求之前何时已结束；以及 自动消除所述单向消息。
9.如权利要求11所述的方法，其特征在于，所述多个实例被按分层的方式来安排，其中各实例被安排成多层父-子编组，所述方法还包括: 从子实例向父实例发送实例状态信息； 在所述父实例处聚集所述子实例的实例状态信息；以及 从所述父实例向更高的父实例发送所聚集的状态信息。
10.一种存储用于管理多个实例的计算机可执行指令的计算机可读存储介质，所述指令包括用于以下操作的代码: 在一个或多个实例处理器上发起多个实例； 监视所述多个实例中的每一个的寿命；以及 向所述多个实例提供定义的一组消息。
【文档编号】G06F15/16GK103562903SQ201280025722
【公开日】2014年2月5日 申请日期:2012年5月18日 优先权日:2011年5月27日
【发明者】N·塔尔伯特, J·泰勒, S·巴特雷斯, J·布朗, K·沃尔夫, E·平特 申请人:微软公司
【专利摘要】分布式实例系统管理各实例以及各实例之间的通信。该分布式实例系统向各实例提供有限的一组通信方法。基于所使用的通信方法的类型，该分布式实例系统知道各实例所发送的消息并且可作出关于如何处理这些消息的决策。在消息交换中所涉及的实例之一结束时，主机使用它对消息交换类型的知识来确定是否丢弃该消息、丢弃该消息的回复、和/或向尚存的实例发送出错消息。一实例可按树类结构来创建一个或多个子实例。状态数据从各子实例沿该树向上传递，并被聚集在父实例中。可根据所聚集的状态数据来生成监视数据。
【专利说明】管理并简化分布式应用
【背景技术】
[0001]大型分布式应用管理起来很复杂。具体而言，需要大量的手动干预来处理分布式通信的不可靠性质。对于可运行交换数百万消息的数百万进程的非常大规模的应用而言，这一问题恶化。传统上，这些大规模应用需要来自系统管理员的人类干预来手动地补偿和纠正出现故障的进程。另外，这些应用需要支持这一干预的广泛的基础结构，如死信队列和挂起进程报告。
[0002]例如在两个应用(如业务进程的两个组件)交换消息时，问题会发生。这些应用可通过中介来交换消息。发送实例可要求对发送给目的地实例的消息的响应。然而，如果目的地实例在接收到该消息之前结束，则该消息将处于中介中。结果，发送实例从未接收到响应，并且因此变得停止。当大型分布式应用运行数百万进程时，数千不可路由的消息可在中介中聚集。系统管理员必须手动清理这些不可路由的消息并重启停止的进程。对于极大型分布式应用而言，规模变得过大，以致人类操作员无法管理这些不可路由的消息、停止的进程以及类似问题。
[0003]这些问题不只是大型应用的问题，而是也出现在小型应用中。另外，在使用经中介的消息收发时以及在使用相关的单向点对点消息收发时，这些问题产生。其他大规模场景，如大量小型托管应用，也可能需要解决这些问题。
[0004]概述
[0005]提供本概述以便以简化形式介绍将在以下详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。
[0006]本解决方案通过向系统开发者提供允许将各应用表示为多个实例的增强的分布式实例系统而降低了管理开销。各实例只通过有限的一组消息交换模式来通信。该系统知晓所有各单独实例和这些实例中的每一个的寿命。通过将实例寿命意识与有限的消息交换模式的组合，该系统可以做出关于如何处理故障的适当决策。这创建了极低成本的编程平台，甚至适用于通常没有活动人类管理角色的最终用户应用。另外，该分布式实例系统提供了用于创建极大型系统的理想平台，该极大型系统利用消息收发系统中内在的最终一致性，针对分布式事务的缺少进行了优化，并且具有多承租人、高密度云计算的可伸缩性要求。
[0007]该分布式实例系统可被实现成执行环境、分布式运行时、分布式管理环境、分布式管理和执行系统、或提供实例的寿命管理的其他平台。该系统可被实现在单个机器上或可被虚拟化在多个机器、服务器或处理器上。
[0008]各实例包括行为和相关联的状态的组合。应用的状态可被分解成一系列实例，其中各单独的实例表示该应用的问题域的具体人工产物。各实例可与其他实例通信。各实例可具有显式的寿命，如显式的开始和结束。各实例在该系统中的存在和寿命可以是外部可见的并且可在外部进行管理。
[0009]各实施例可以使用实例管理器，该实例管理器担当分布式实例系统中的增强的中介，用于管理各实例之间的通信。在现有系统中，中介管理各通信，但不知道各应用所使用的消息交换模式。在本发明的系统中，与先前分布式系统中可用的实例通信知识相比，实例管理器具有更多的实例通信知识。另外，该实例管理器知道各实例的寿命并且可以基于对实例寿命的这一知识来管理通信。例如，实例管理器可以管理两个实例A和B之间的通信。实例A向实例B发送消息，并且包括与该消息有关的可被实例管理器用来作出关于该消息的决策的信息。例如，实例A可以将该消息标识为请求-回复交换的第一局。
[0010]在传统的中介系统中，如果实例A在接收到来自实例B的回复之前结束，则回复消息将被保持在死信队列中。网络管理员将必须从死信队列中手动地清除该回复消息。在极大规模应用的情况下，死信队列中可存在数千消息，并且人类网络管理员将必须分析并消除这些消息中的每一个。另外，在大量应用的情况下，可存在要按此方式手动地监视和维护的数千消息队列。
[0011]在本文公开的系统的各实施例中，该分布式实例系统具有与消息交换有关的信息一即，它是请求-回复。因此，该实例管理器可以基于消息的预期使用来作出与如何处理消息有关的决策。如果分布式实例系统知道该消息是请求-回复交换的回复部分，并且发出请求的实例A已完成或不再对该回复感兴趣，则该分布式实例系统可以只是消除该回复消息而非尝试将它递送给实例A。因为实例A已完成，所以它不关心或需要从实例B接收该回复消息，因为它将简单地将该消息作为噪声而丢弃。
[0012]类似地，如果实例B在接收到来自A的请求消息之前已完成，则该分布式实例系统(它具有与该消息交换有关的信息)可作出关于实例管理器应当如何处理该请求消息的决策。并非坚持该请求消息作为不可递送的信和/或继续尝试递送给实例B，实例管理器可向实例A发送出错消息。实例A可具有消息出错处理智能，使得它可以处理请求消息的失败，而无需停止或等待来自实例B的回复(该回复将永远不会到达)。
[0013]在一个实施例中，增强的分布式实例系统管理各实例，知晓各实例的寿命，并且提供各实例之间的有限的一组消息交换模式。通过利用该有限的一组消息交换模式，该系统可以消除或降低对用户管理的需求。请求-回复消息允许各实例之间可靠的异步请求-回复通信。此外，对话是用于支持各实例之间可靠且异步的全双工消息收发交换模式的一种机制。
[0014]分布式实例系统可以将各实例构造成一个或多个分层结构树。这允许该系统凝聚性地管理各状态并且降低管理开销。各实例组织成分层结构树使得能够降低与管理极大型分布式应用中的各实例相关联的管理复杂度。例如，大型业务进程可包括多个异步业务事务。各实例的分层组织使得能够管理该大型业务进程。另外，各实例可被组织以在必要时提供隔离来保护业务进程信息。程序可被分成可高度并行化的多个可分布的状态。此外，各实例的处理逻辑定义可以是后期绑定的和独立地版本化的。
[0015]该系统运行各应用实例并向这些实例提供有限的一组消息交换模式。存储设备保持实例状态和消息。存储设备可在物理上位于一个或多个机器中，分布在一个或多个进程上。实例管理器支持这些有限的消息交换模式。
[0016]该有限的一组消息交换模式允许该系统设备标识可被消除而无需用户干预的消息。该有限的一组消息交换模式允许各实例交换异步请求和回复消息。实例管理器基于交换中所涉及的各实例的寿命来标识应被消除的请求和回复消息。[0017]各实例可被组织成分层结构，其中一个实例担当创建和/或管理一个或多个子实例的父实例。该分层结构可具有多个层，其中子实例生成它们自己的子实例并且因此也作为父实例来操作。子实例可向它们相应的父实例发送状态报告。每一父实例在将所聚集的状态报告传递给更高层父实例之前聚集来自它们相应的子实例的状态报告。在任何层处聚集的状态报告可被传递给管理入口。
[0018]各实例可包括监视实例。携带健康和状态信息的监视消息可通过实例树被向上传播。在根层或在较低层处的监视实例可收集监视消息。各实例可被组织成提供封装端到端进程的监视信息的同构视图。
[0019]对话是分布式实例系统所跟踪的两个实例之间的成对关联。对话可通过涉及这两个参与实例的握手来建立。握手由该分布式实例系统来协调。在参与对话的一实例已结束时，通知参与该对话的另一实例。任一实例可显式地终止对话，或通过终止自己从而隐式地终止所有它相关联的对话。在一实例终止对话时，通知该对话中的另一实例。在各实例具有父-子关系时，创建对话。这一对话是创建子实例的父实例的副作用。在子实例完成时，父-子对话结束。在父-子关系之外，一实例可以通过使用该分布式实例系统所协调的握手过程登记对另一实例的寿命的兴趣，来发起对话。对话是由该基础结构维护并理解的双方成对关系。之后，对话被建立，它是对称的。在一方结束对话时，通知另一方。父-子是对话的一特定使用。父实例创建子实例并且作为该创建的副作用，父实例和子实例两者是对话的双方。如果子实例终止，则向父实例通知对话结束。类似地，如果父实例终止，则向子实例通知对话结束并且子实例也终止。
[0020]在另一实施例中，一种用于管理多个实例的方法包括在一个或多个实例处理器上发起多个实例，监视该多个实例中的每一个的寿命，以及向该多个实例提供定义的一组消
肩、O
[0021]该方法还包括提供用于发送实例和目的地实例之间的通信的请求-回复消息格式，标识目的地实例在接收到请求消息之前何时已结束，以及自动消除该请求消息。该方法还在消除请求消息时向发送实例提供出错消息。
[0022]该方法还包括提供用于发送实例和目的地实例之间的通信的请求-回复消息格式，标识发送实例在接收到回复消息之前何时已结束，以及自动消除该回复消息。
[0023]该方法还可包括提供用于发送实例和目的地实例之间的通信的单向消息格式，标识目的地实例在接收到单向消息之前何时已结束，以及自动消除该单向消息。
[0024]多个实例可被安排成分层格式，其中各实例被安排成多层父-子编组。该方法还可包括从子实例向父实例发送实例状态信息，在父实例处聚集子实例的实例状态信息，将所聚集的状态信息从父实例发送给更高的父实例，以及将进程状态信息提供给监视实例，该进程状态信息包括所聚集的状态信息。所聚集的状态信息可以提供与各实例相关联的端到端进程的同构视图。
【专利附图】
【附图说明】
[0025]图1是根据一个实施例的分布式实例系统的各组件的高级框图；
[0026]图2是根据一个实施例的分布式实例系统的拓扑结构的高级框图；
[0027]图3示出了根据一个实施例的各实例的分层结构；[0028]图4示出了用于两个实例之间的请求-回复交换的请求-回复消息收发模式；
[0029]图5示出了用于两个实例之间的请求-回复交换的另一请求-回复消息收发模式；
[0030]图6示出了用于两个实例之间的单向消息的单向消息收发模式；
[0031]图7示出了两个实例之间建立的对话；以及
[0032]图8示出了创建了不同类型的两个子实例的父实例。
【具体实施方式】
[0033]大型计算系统包括多个分布式应用。各应用负责对处理逻辑进行处理并执行可能持续数星期、数月或甚至数年的长期运行的业务进程。各应用是隔离的，除了访问共享网络之外。各应用通过在这一网络上发送消息来进行通信。各进程的执行发生在大量物理计算资源上，并且因此该基础结构和计算系统必须被设计成是容错的。在现有系统中，这一要求的常见解决方案是使得所有消息交换经由中介异步地发生，该中介通常被实现成持久队列。使用异步通信也普遍适用于具有长期运行的业务进程的系统。
[0034]如果作为较大分布式应用的一部分的业务进程失败，则该分布式应用中的其他业务进程可被留置等待该失败的进程的输出，并且结果，相关联的消息留置未经处理。留置等待的进程和消息需要某种方式的人类干预才能恢复或除去它们。例如，如果业务进程在请求-回复消息交换期间失败，则始发应用可留置等待，不知道失败或挂起的进程。此外，原始请求消息留在中介中，而中介不能够处理该消息，除了将它标志为不可递送的信之外。这些不可递送的信通常需要人类干预才能补偿和纠正失败的进程并清理中介。
[0035]业务进程在它们的寿命中横跨多个应用，并且这些应用通常具有不同的管理特性。结果，没有系统健康、端到端进程状态、或其他监视数据的单个经协调的视图。相反，系统管理员通常处理各种控制系统并且形成每一控制系统中的专家知识。
[0036]因为这些系统中的业务进程通常持续很长一段时间，所以当业务进程内的逻辑需要改变时，如由于公司购置或策略变化，难以在不中断进行中(in-flight)进程的情况下更新该逻辑。这一问题在传统上由应用开发人员来解决，他们负责实现复杂的分支逻辑以处理存在的部分完成的进程。
[0037]为了解决现有系统中的这些问题，在一个实施例中，一种增强的系统负责这些业务进程的处理和组织。通过使用有限且很好地理解的一组消息交换模式，该增强的系统使得消除挂起的进程和死信以及降低相关联的管理开销成为可能。此外，通过将这些进程的各组成部分按分层方式来组织，简化这样的系统的管理是可能的，从而提供覆盖端到端进程的单个监视和控制体验。通过使得该系统处理诸如最终一致性、故障传播、以及跨实例相关等复杂度，降低了对分布式应用的各部分进行协调的认知开销。
[0038]业务进程的各组成部分在运行时作为各实例出现，其中实例表示处理逻辑单元及其相关联的状态两者。各实例可分布在许多处理单元上而没有对特定一个处理单元的任何亲和性。
[0039]图1是根据一个实施例的分布式实例系统100的各组件的高级框图。该分布式实例系统包括运行一应用或进程的各实例的一个或多个实例处理器101。实例管理器102控制实例处理器101并分配在实例处理器101上运行的特定实例。实例管理器102还监视每一实例的寿命并且知道每一实例何时开始和结束。
[0040]各实例和应用状态可被存储在实例存储103中。虽然图1中示出了单个存储设备102，但分布式实例系统100可包括多个存储设备。在其他实施例中，作为实例存储103的补充或替换，可以使用外部存储设备。在一个实施例中，每一实例一次被绑定到一个存储设备103。如所需要的，实例-存储绑定可作为再平衡、故障切换、或迁移的一部分来改变。在其他实施例中，存储103是可任选的，并且实例状态和消息被存储在实例处理器101内，这可使得该系统工作在降低的可靠性水平上。存储设备103的使用可以是按实例决策，其中一些实例状态和消息可外部化到存储中，而其他则不会。各实例可与相同或不同应用或进程的其他实例进行通信。
[0041]在实例处理器101上运行的实例可彼此通信以允许在各实例之间交换消息。消息存储104可被用来存储消息和消息状态。实例管理器102通过消息总线105将消息路由到各系统组件并在各系统组件之间路由消息，如在实例处理器101、实例存储103、以及消息存储104之间。实例管理器102实施在该分布式实例系统上可用的消息交换模式。
[0042]实例管理器102负责执行各实例的处理逻辑并控制实例处理器101上的实例。实例管理器还管理各实例的寿命。可在实例管理器102和实例处理器101之间交换控制消息，以创建新实例和终止已有实例。实例管理器负责实现这些命令，并且结果，知道所有实例的寿命。
[0043]实例管理器还负责处理各实例之间的消息交换。向实例管理器102提供了与每一消息有关的附加知识，包括哪一实例发送了该消息以及应当接收该消息的哪一个或多个实例。实例管理器102提供有限的一组消息收发模式，这允许该系统作出有关该系统内的消息收发行为的具体声明以简化该系统及其管理。
[0044]两个主要的消息收发模式是请求-回复和单向。
[0045]请求-回复消息收发模式这一模式用于两个实例之间的异步请求-回复通信。因为该分布式实例系统知道发送者和接收者实例两者的寿命，所以该系统呈现了多个简化属性。例如，如果接收者实例在发送回复之前终止，则该系统向发送者返回出错响应。这消除了先前将被留在中介处的挂起的业务进程和死信。如果发送实例在响应被递送之前终止，则该系统可以丢弃该回复消息。如果响应的递送必须被保证，则回复实例(即，原始接收者实例)可建立与原始发送实例的请求-回复交换。
[0046]单向消息收发模式这一模式用于两个实例之间的异步单向通信。发送和接收实例可在传送单向消息之前建立对话。在一些情形中，单向消息可绑定到对话。对话是该分布式实例系统的通信模型的一部分。对话经由异步握手通过实例管理器来建立，该实例管理器可以是持久中介(如果需要持久性的话)。或者，一操作可建立对话作为直接作用或作为副作用。如果接收实例在递送单向消息之前结束和/或终止对话，则该系统按与单向消息收发的大多数实现一致的方式丢弃该消息。然而，该系统还将该对话的终止通知给发送实例。
[0047]请求-回复和单向消息收发模式可被组合，以创建其他更丰富的消息收发模式，如发布和订阅。
[0048]实例分层结构该分布式实例系统还将各实例构造成分层结构。如果实例A创建新实例B，则实例A自动变成实例B的父实例。实例A可能不能够直接创建新实例，但可改为要求该系统对新实例的创建进行仲裁。类似地，如果实例B稍后创建新实例C和D，则实例B自动变成实例C和D的父实例，以此类推。各实例之间的这一关系创建实例树。该树中的各实例将业务进程的多个分开且不同的片段组合成例如反映该端到端进程的分层结构。
[0049]每一子实例可具有与其相应父实例的自动对话。这样的父-子对话将不需要附加的握手来建立。在一些实施例中，子实例可能不能够独立于它自己的寿命来终止父-子对话。此外，父实例可能不能够通过终止父-子对话来迫使终止子实例。
[0050]各实例还可按需创建。例如，如果实例Z向实例E发送消息，但实例E尚未存在，则该分布式实例系统可具有确定哪一实例应当是实例E的父实例的功能。该系统随后通知该预期父实例(例如，以上的实例B)，并且随后预期父实例B有机会创建实例E作为子实例。实例E随后可接收来自实例Z的消息。类似地，如果实例B也尚未存在，则该过程可跨多层来被重复。例如，实例A可接收来自该系统的创建实例B的通知，并且随后实例B接收创建实例E的通知。
[0051]这一端到端进程的节点分层结构具有单个根。在其他实施例中，该分层结构可具有多个根。例如，监视实例也可以是根节点。这允许该系统提供统一的控制模型。例如，终止或挂起父实例造成该同一控制动作传播到它的所有子实例，而不必特别地解决该分层结构中每一单独的实例。此外，该分层结构呈现用于聚集来自各实例的监视和健康信息的机会。结果，监视端到端进程更简单。这可通过使用该系统所呈现的第三消息收发模式——监视消息模式一来实现。
[0052]聚集消息收发模式这一模式被用来异步地传送监视数据。实例可发出自动沿实例树向上转发的监视消息一从子实例行进到父实例，并随后到父实例自己的父实例一直至监视消息到达根实例为止。监视消息可具有与其他消息不同的时间线特性。例如，监视消息可具有比操作消息低的优先级。具体而言，监视消息可机会性地从实例转移到实例，如通过承载在其他交换上以提高系统效率。任何实例可订阅这一监视数据流，从而允许实例捕捉该分层结构的订阅实例的那一部分的所有监视数据。这将向订阅实例提供该进程的任何部分的完整画面。任何实例可抑制监视数据沿分层结构向上传播。实例既可发布监视数据又可抑制监视数据的进一步传播。将理解，监视只是一个示例，并且作为监视数据的补充或替换，各实例之间可交换任何类型的数据。
[0053]图2是根据一个实施例的分布式实例系统200的拓扑结构的高级框图。实例处理器201可被实现成多个实例处理节点201，每一实例处理节点都在实例管理器202的控制之下。实例存储203保持不活动时间段期间的各实例以及应用状态和消息状态。实例处理器在系统故障的情况下提供可靠的消息收发和可恢复性。然而，如果例如既不要求或需要可靠的消息收发又不要求或需要持久的实例，则这些能力中的任一个可被牺牲。
[0054]实例管理器202负责将各实例的处理逻辑加载到所分配的实例处理器201。这允许该系统向应用呈现多个附加的简化益处，包括加载处理逻辑的不同版本的能力以及允许各实例版本的并排执行。例如，以实例的处理逻辑的版本I开始的业务进程可继续使用该版本，即使在创建了版本2时也如此。业务进程的新实例可自动利用最新版本。
[0055]此外，该系统将业务进程表示为不同的经协调的实例的分层结构的能力极大地降低了对正在进行的进程的变更的影响，从而允许应用开发人员将各进程建模成可独立地版本化的各实例的组合。[0056]图3示出了根据一个实施例的各实例的分层结构300。根实例301被创建并且是实例302和303的父实例。进而，实例302被创建并且是实例304和305的父实例，而实例303被创建并且是实例306和307的父实例。
[0057]再参考图1，实例301-307可在一个或多个实例处理器101上运行。实例301-307可全部在同一实例处理器101上运行或可分散在多个实例处理器101上。在高度分布式的应用中，每一实例301-307可在单独的实例处理器101上运行。实例301-307中的一个或多个可在与分布式实例系统100经由外部总线105进行通信的分开的分布式实例系统上运行。这样的外部通信假定在外部总线上使用的协议与分布式实例系统所使用的有限消息交换模式之间的桥接已经完成。
[0058]任何实例301-307可参与同任何其他实例301-307的请求-回复消息交换。任何实例301-307可与任何其他实例301-307建立对话308。单向消息可通过已在各实例之间建立的对话308发送。
[0059]实例301-307形成卷升至根实例301的分层结构。监视消息沿该分层结构向上传送，并且监视实例309可订阅该监视数据。根实例301将监视数据310发布给监视实例309。监视数据310由应用创建并且表示该应用的当前状态。监视数据310沿分层结构树向上流动。监视数据在每一层处被聚集，使得实例303聚集实例304和305两者的监视数据且根实例301聚集实例301和303两者以及它们相应的子节点的监视数据。将理解，监视实例309不限于在根实例处监视，而是可插入在任何层处。例如，监视实例309可替换地接收来自实例303的监视数据311。来自实例303的监视数据311包括实例303及其子实例306和307的所聚集的状态和健康数据，而监视数据310包括所有实例301-207的所聚集的状态和健康数据。
[0060]分层结构300可扩展到任何数量的实例。父实例与其子实例之间存在隐式的对话，这允许父实例和子实例进行通信并知道相关实例的状态。通过将子实例的寿命绑定到它的父实例，简化了各实例的管理。子实例不能比它的父实例更长寿。因此，如果一实例结束，则该实例的所有子实例也结束。这提供了一种容易的方式来结束并清理该实例之下所有层处的实例，并允许最终用户将树中的各实例当成一个。以此方式，各进程被分解成更加可管理的一组实例。如果根实例301结束，则该分层结构中的所有实例结束。
[0061]情形1:图4示出了用于两个实例之间的请求-回复交换的请求-回复消息收发模式。始发实例401向目的地实例403传送操作请求402。请求402被传递给实例管理器404，实例管理器404负责将请求402转发给目的地实例403。然而，在实例管理器404能传递请求消息402之前，目的地实例403结束(405)。实例管理器404知道每一实例401、403的寿命。因此，实例管理器404知道目的地实例403已结束并且该操作请求将永远不能路由到它的目的地。因此，实例管理器404向源实例401发送出错回复406并消除请求402，从而防止请求402变成不可递送的信并且防止始发实例401变成挂起的实例。
[0062]情形2:图5示出了用于两个实例之间的请求-回复交换的另一请求-回复消息收发模式。始发实例501向目的地实例503传送操作请求502。请求502被传递给实例管理器504，实例管理器504负责在消息505中将请求502转发给目的地实例503。目的地实例503接收请求505并生成操作回复消息506，该操作回复消息在实例管理器504的控制下被发送回始发实例501。然而，在实例管理器504能传递回复消息506之前，始发实例501结束(507)。实例管理器504知道每一实例501、503的寿命。因此，实例管理器504知道始发实例501已结束并且该操作回复506将永远不能路由到它的目的地。因为始发实例501已结束，所以该回复不再需要或有用。因此，实例管理器504消除回复506，从而防止回复605变成不可递送的。
[0063]情形3:图6示出了用于两个实例之间的单向消息的单向消息收发模式。始发实例601将信号602传送到目的地603。信号602是始发实例601不会预期有响应的单向消息。实例管理器604接收消息602，消息602应被转发给目的地603。然而，目的地实例603在信号602可被递送之前结束(605)。实例管理器604知道目的地实例605的状态并且知道该实例何时已结束。因此，并非将信号602保持作为不可递送的，实例管理器604消除该信号。因为信号602是单向消息并且始发实例601没有预期来自目的地实例603的响应或确认，所以实例管理器604仅仅终止信号602并且不创建发给始发实例601的进一步的出错消息或警告。这是真实的单向消息交换，其中始发实例只需要知道该信号被发送并且不关心该信号是否被接收到。因此，在目标实例结束时，信号602可被实例管理器604安全地丢弃。
[0064]情形4:图7示出了两个实例之间建立的对话。实例A701通过向实例管理器704注册对实例B703的兴趣来建立与实例B703的对话702。一实例可向中介、实例管理器、或某一其他设备注册对另一实例的兴趣。对话是通过涉及两个参与实例的握手来建立的，该握手由分布式实例系统进行协调。一旦建立了对话702，实例701、703就可跟踪该对话并且因此可跟踪另一实例的寿命。任一实例可建立对话。对话继续，直至被一个实例取消或直至一个实例结束。将要结束的实例可通知另一实例该对话将结束，或者实例管理器可以通知一个实例对话中的另一实例已经完成。例如，在实例B703结束(705)时，实例管理器704可使用通知706来通知实例701。或者，在一个实例认识到该对话已经意外终止(即，在没有通知的情况下)，这指示另一实例已经结束。
[0065]对话可被用来支持或增强单向消息收发。例如，该对话的一个实例可向该对话中的另一实例发送信号。发送实例不要求对该单向信号消息的回复，但在发送消息时以及在传输之后的某一时间内知道目的地实例是否是活的。这一生命状态知识可被发送实例用来评估该信号是否被目的地实例接收到的可能性。具体而言，发送实例可等待(直接或间接)依赖于该信号的接收的事件。对话的终止告知该实例信号可能已经丢失，所以它可以选择做除等待该事件之外的某些事情。
[0066]本文描述的实例可以是不同类型的，并且可以与不同的进程相关联。图8示出了创建了不同类型的两个子实例802、803的父实例801。例如，在订单业务进程中，在顾客开始新订单时，订单实例801可被创建。订单实例801可生成挑选子实例802以向顾客提供物品选择进程。订单实例801还可生成运送子实例803以提供顾客所选择的物品的运送进程。
[0067]挑选实例802和运送实例803可以使用请求-回复消息收发和单向消息收发来交换信息以完成顾客的订单。挑选实例802和运送实例803还可建立对话804来跟踪另一实例的寿命。
[0068]挑选实例802和运送实例803可以向父订单实例801发送监视消息，订单实例801可进而将该健康信息沿进一步的实例树向上传播。[0069]订单实例801、挑选实例802以及运送实例803可以是在使用特定订单进程的各顾客之间提供隔离的许多独立的订单-实例树之一。这一隔离可以提供保护业务进程和个人顾客信息的安全性。
[0070]作为许多独立的订单-实例树之一，订单实例801、挑选实例802以及运送实例803提供按高度并行化方式操作的多个分布式订单进程。
[0071]本文描述的功能中的许多功能可以用硬件、软件、和/或固件、和/或其任何组合来实现。在用软件实现时，各代码段执行必要的任务或步骤。程序或代码段可被存储在处理器可读、计算机可读或机器可读介质中。处理器可读、计算机可读或机器可读介质可包括能存储或转移信息的任何设备或介质。这样的处理器可读介质的示例包括电路、半导体存储器设备、闪存、ROM、可擦除ROM (ER0M)、软盘、紧致盘、光盘、硬盘、光纤介质，等等。
[0072]例如，在图1中，存储102可以是任何易失性或非易失性存储设备，如硬盘驱动器、闪存、固态存储器、光盘、CD、DVD、计算机程序产品、或向实例处理器101提供计算机可读或机器可读介质的其他存储器设备。在其他实施例中，存储器可以是若干物理存储设备的虚拟化，其中物理存储设备是相同或不同的种类。代码段可以经由内部总线、另一计算机网络(如因特网或内联网)、或经由其他有线或无线网络等从存储102下载或转移到实例处理器101。
[0073]尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权利要求书中定义的主题不必限于上述具体特征或动作。更确切而言，上述具体特征和动作是作为实现权利要求的示例形式公开的。
【权利要求】
1.一种分布式实例系统,包括: 运行一个或多个进程的实例的一个或多个实例处理器； 管理在所述实例处理器上运行的实例的一个或多个实例管理器，所述实例管理器监视所述实例的寿命并且向所述实例提供受管理的一组消息交换模式。
2.如权利要求1所述的分布式实例系统，其特征在于，有限的一组消息交换模式允许所述分布式实例系统标识无需用户干预就能被消除的消息。
3.如权利要求1所述的分布式实例系统，其特征在于，所述有限的一组消息交换模式允许各实例交换异步请求和回复消息，以及 其中所述实例管理器基于交换中所涉及的各实例的寿命来标识应被消除的请求和回复消息。
4.如权利要求1所述的分布式实例系统，其特征在于，一实例发起与另一实例的对话，其中所述对话是使用涉及这两个实例的握手来发起的，所述握手由分布式实例系统来进行协调。
5.一种用于管理多个实例的方法，包括 在一个或多个实例处理器上发起多个实例； 监视所述多个实例中的每一个的寿命；以及 向所述多个实例提供定义的一组消息。
6.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的请求-回复消息格式； 标识所述目的地实例在接收到请求消息之前何时已结束；以及 自动消除所述请求消息。
7.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的请求-回复消息格式； 标识所述发送实例在接收到回复消息之前何时已结束；以及 自动消除所述回复消息。
8.如权利要求11所述的方法，其特征在于，还包括: 提供用于发送实例和目的地实例之间的通信的单向消息格式； 标识所述目的地实例在接收到单向请求之前何时已结束；以及 自动消除所述单向消息。
9.如权利要求11所述的方法，其特征在于，所述多个实例被按分层的方式来安排，其中各实例被安排成多层父-子编组，所述方法还包括: 从子实例向父实例发送实例状态信息； 在所述父实例处聚集所述子实例的实例状态信息；以及 从所述父实例向更高的父实例发送所聚集的状态信息。
10.一种存储用于管理多个实例的计算机可执行指令的计算机可读存储介质，所述指令包括用于以下操作的代码: 在一个或多个实例处理器上发起多个实例； 监视所述多个实例中的每一个的寿命；以及 向所述多个实例提供定义的一组消息。
【文档编号】G06F15/16GK103562903SQ201280025722
【公开日】2014年2月5日 申请日期:2012年5月18日 优先权日:2011年5月27日
【发明者】N·塔尔伯特, J·泰勒, S·巴特雷斯, J·布朗, K·沃尔夫, E·平特 申请人:微软公司
最新回复(0)