分布式计算依赖管理系统的制作方法

分布式计算依赖管理系统
1.本申请是国际申请日为2016年12月26日、于2018年6月29日进入中国国家阶段、中国国家申请号201680077394.8、发明名称为“分布式计算依赖管理系统”的发明专利申请的分案申请。
技术领域
2.本公开的实施例涉及信息技术领域，更具体地，涉及分布式计算依赖管理系统。


背景技术：

3.大规模联网系统是在各种设置中采用的常见平台，用于运行应用并且为流量和运营功能维护数据。例如，数据中心(例如，物理云计算平台)可以同时为多个客户提供各种服务(例如，web应用、电子邮件服务、搜索引擎服务等)。这些大规模联网系统通常包括遍布整个数据中心或遍布全球的一个或多个地区中的多个数据中心的大量资源。资源可以类似于在物理节点或主机上运行的物理机器或虚拟机(vm)。数据中心在相互依赖以进行操作的硬件(例如，电源、机架和网络接口控制器(nic))和软件组件(应用、应用编程接口(api)、sql数据库)上运行。具体而言，包括一个或多个组件的服务基于与彼此的依赖关系来进行操作。服务经常由不同的团队经常采用特别方法来被独立管理，用于解决与其他组件发生的依赖问题。


技术实现要素：

4.本文中描述的实施例提供用于实现用于基础设施(例如，分布式计算基础设施)的依赖管理系统的方法和系统。在高级别处，依赖管理便于针对基础设施中的租户服务自动发现、构建和分析依赖关系。依赖管理系统的依赖服务管理器包括便于生成依赖数据的多个依赖管理系统组件(例如，收集器、标准名称提供器和依赖聚合器)。依赖数据包括作为基础设施的租户服务的依赖服务租户的依赖关系和从属关系。依赖服务租户与依赖管理系统相关联。依赖数据是基于由多个收集器检索的数据而生成的。来自多个收集器的收集器是基于收集器的对应收集时间属性检索与基础设施的依赖服务租户相关联的数据的代理。收集器在以下收集时间之一处访问数据以用于生成依赖数据：设计时间、部署时间和运行时。依赖服务管理器操作以交叉检查由多个收集器收集的数据，并且生成依赖服务租户和对应的依赖和从属组件之间的关系。
5.所生成的依赖数据然后被存储在数据存储库中，并且被传送给用户访问该依赖数据的依赖服务界面。在实施例中，基础设施包括同步该依赖数据的内部部署基础设施。依赖服务界面支持提供依赖数据的不同视图以允许用户访问和分析该依赖数据。依赖数据还经由数据图形表示可访问；数据图表示提供依赖数据的备选访问和功能视图。经由依赖服务界面或数据图表示来呈现的依赖数据可以进一步被用于执行基础设施的依赖服务操作。
6.提供本发明内容从而以简化方式介绍以下在详细描述中进一步描述的概念的选择。本发明内容并非旨在标识所要求保护的主题的关键特征或必要特征，也不旨在被孤立
地用作确定所要求保护的主题的范围中的辅助。
附图说明
7.本发明在下文中参考所附附图来被描述，其中：
8.图1a
‑
1c是根据本文描述的实施例的用于访问依赖数据的示例性依赖服务界面；
9.图2a
‑
2b是根据本文描述的实施例的依赖数据的示例性图形表示；
10.图3a是其中可以采用本文描述的实施例的示例性分布式计算基础设施和依赖管理系统的框图；
11.图3b是根据本文描述的实施例的示例性依赖管理过程流的框图；
12.图3c是根据本文描述的实施例的依赖服务租户的示例性工件和关系逻辑的图示；
13.图4是示出根据本文描述的实施例的用于提供依赖管理系统的示例性方法的流程图；
14.图5是示出根据本文描述的实施例的用于提供依赖管理系统接口的示例性方法的流程图；
15.图6是适用于在实现本文描述的实施例中使用的示例性计算环境的框图；以及
16.图7是适用于在实现本文描述的实施例中使用的示例性计算环境的框图。
17.具体实现
18.分布式计算基础设施(例如，云计算基础设施)可以为不同类型的应用和服务提供构建、部署和管理功能。分布式计算基础设施可以包括便于提供基于云的计算功能的若干物理和虚拟资源。例如，数据中心包括许多分布式资源，包括在物理节点或主机上运行的物理机器或虚拟机(vm)。数据中心运行在相互依赖以进行操作的硬件(例如，电源、机架和网络接口控制器(nic))和软件组件(应用、应用编程接口(api)、sql数据库)上。可以使用分布式计算平台内核(例如，结构控制器(“fc”))来监视和管理分布式计算基础设施。分布式计算基础设施还可以包括内部部署基础设施(例如，分布式计算基础设施的租户)，服务和应用在功能上延伸到其中内部部署以用于执行内部部署的操作。
19.通常，分布式计算基础架构中包括一个或多个组件的服务基于彼此的依赖关系来操作。服务经常由不同团队经常利用特别方法来被独立管理，以解决与其他组件发生的依赖问题。此外，一些团队操作在虚拟化环境中运行的服务，并且可能不知道对物理资源(例如，网络设备、电力设备或发电机)的依赖关系。利用用于解决依赖管理的不同方法，确定存在哪些依赖、传送依赖和解决依赖问题可能为分布式计算基础设施提出挑战。因此，用于配置、标识和通信分布式计算基础设施组件之间的依赖关系的全面系统能够改善分布式计算基础设施的评估、理解和可靠性。
20.本发明的实施例涉及用于依赖管理的高效方法和系统。依赖管理系统可以被实现为分布式计算基础设施中的服务或应用(以下称为“依赖服务”)。在高级别处，依赖管理便于针对基础设施中的租户服务自动发现、构建和分析依赖关系。依赖管理系统的依赖服务管理器包括便于生成依赖数据的多个依赖管理系统组件(例如，收集器、标准名称提供器和依赖聚合器)。依赖数据包括作为基础设施的租户服务的依赖服务租户的依赖关系和从属关系。依赖服务租户与依赖管理系统相关联。依赖数据是基于由多个收集器检索的数据而生成的。来自多个收集器的收集器是基于收集器的对应收集时间属性检索与基础设施的依
赖服务租户相关联的数据的代理。收集器在以下收集时间之一处访问数据以用于生成依赖数据：设计时间、部署时间和运行时。依赖服务管理器操作以交叉检查由多个收集器收集的数据，并且生成依赖服务租户和对应的依赖和从属组件之间的关系。
21.依赖数据可以被利用用于依赖服务操作。有利地，所生成的依赖数据使得能够验证依赖管理系统的声明式服务依赖模型、警报缺少的依赖关系、抑制通知噪声以及诸如帮助事件影响分析的其他操作。分析服务(即，验证声明式服务依赖模型、警报缺少的依赖关系和抑制通知噪声)可以进一步被用于彼此验证和扩展。依赖数据通过引入恢复路径和与恢复工作流集成，进一步帮助开发者理解依赖并且确定服务恢复的优先级。
22.由依赖服务支持和发现的特定服务和组件可以被称为依赖服务租户。依赖服务租户可以与依赖服务租户的管理员、所有者、操作者或客户端相关联。依赖服务租户可以被实现为依赖服务租户的一个或多个实例。租户名称可以与依赖服务租户相关联；然而租户名称不一定是全局唯一标识符(guid)，而是更有意义的名称。
23.贯穿本公开，若干缩写和简写符号被用来辅助关于相关联的系统和服务的特定概念的理解。这些缩写和简写符号旨在帮助提供传送本文中表达的想法的简单方法，并不意味着限制本发明的范围。
24.almap 应用层映射
‑
服务分层顺序的静态(构建时间)声明
25.cs
ꢀꢀꢀꢀ
配置存储库
‑
配置/设置的仓库
26.dns
ꢀꢀꢀ
域名服务
27.fc
ꢀꢀꢀꢀ
结构控制器
28.fma
ꢀꢀꢀ
故障模型分析
‑
设计时间(声明)依赖图
29.ma
ꢀꢀꢀꢀ
监视代理
‑
在服务内部署的代理
30.mds
ꢀꢀꢀ
监视和诊断服务
‑
用于监视和诊断数据的分析服务
31.svd
ꢀꢀꢀ
服务模型定义
‑
设计时间
32.tfs
ꢀꢀꢀ
团队基础服务器
33.vip
ꢀꢀꢀ
虚拟ip地址
34.依赖管理系统可以支持图形用户界面，其便于访问依赖系统所支持的特征和功能并与其交互。依赖数据经由数据图形表示可访问。依赖数据可以被生成并被存储在数据存储库中，并且被传送到依赖服务界面以供用户访问该依赖数据。可以通过api(应用程序编程接口)进一步提供依赖数据以供其他服务利用(例如，警报抑制服务可以插入依赖数据api以抑制来自依赖于失败服务的服务的警报)。在示例性实施例中，依赖管理系统可以包括web前端(“fe”)，其向用户提供可视化针对给定的依赖服务租户的依赖关系和依赖服务租户的从属(受影响)服务两者的能力。依赖管理系统发现依赖租户服务所依赖的组件内的组件或服务，连同其他依赖关系。例如，如果依赖服务租户依赖于存储，则依赖服务进一步标识并暴露与依赖服务租户相关联的存储帐户和证书。
35.依赖管理系统支持不同类型的查看体验以提供对依赖数据的访问。依赖管理系统可以将依赖数据传送给在显示器上生成的依赖服务界面。依赖管理系统还可以支持依赖数据的数据图表示，如在本文中更详细地讨论的。参照图1a
‑
1c，提供了示例性依赖服务界面100(例如，门户)。依赖服务界面100可以是用于传送经由依赖管理系统配置和实现的信息的门户。依赖服务界面100可以支持用于呈现和访问依赖数据的可选视图。在每个视图内，
用户可以浏览一系列依赖信息，聚合并对依赖(和资源)进行排序。视图聚合了共同的服务；然而，用户应该能够看到各个服务依赖。作为示例，门户可以包括两个视图来呈现依赖信息：“按服务的依赖”视图和“按位置的依赖”视图。按服务的依赖视图可以作为逻辑视图操作，其帮助用户调查服务故障的影响。该视图是针对组件所有者或单一服务故障的。如图1a所示，可以经由依赖服务界面100提供可选择的下拉菜单102以通过服务视图选择依赖。按服务选择依赖利用服务(例如，tenant_service_alpha；tenant_service_beta；和tenant_service_charlie)的依赖信息填充依赖服务界面100的依赖信息部分104a。依赖服务信息可以在树状分层结构中被提供(例如tenant_service_beta下的树状层次结构中所示的tenant_service_beta_02 112)
36.按位置的依赖视图可以作为物理视图来操作，其帮助管理员调查物理位置(诸如数据中心损失)或逻辑位置(诸如，更新的域或故障域)的影响。如图1b所示，可以经由依赖服务界面100提供可选下拉菜单102以选择按位置的依赖视图。选择按位置的依赖视图利用基于位置(例如，loc_alpha；loc_beta；和loc_charlie)的服务的依赖信息来填充依赖服务界面100的依赖信息部分104b。
37.依赖管理系统支持不同类型的依赖探索体验来执行对依赖数据的分析。依赖分析的特征在于找到一个或多个感兴趣的服务。这样，为了充分支持依赖探索，经由依赖管理系统使以下探索能力可用：在示例性实施例中，参照图1c，依赖服务界面100包括支持标识搜索到的服务的依赖信息的依赖搜索栏110。依赖信息可以进一步包括依赖服务部分114的细节，其填充依赖接口100的对应传入关系部分116和传出关系部分118中的传入关系和传出关系。作为示例，用户可以按名称(例如，tenant_service_beta_02 110b)搜索具体租户以及包括依赖于搜索到的tenant_service_beta_02的租户服务列表(即，传入关系)和生成搜索到的tenant_service_beta_02的租户服务列表(即，传出关系)的依赖信息。用户可以按名称搜索服务集合。然后用户可以按位置或层次结构来探索租户。
38.依赖管理系统支持不同类型的依赖注释体验来执行对依赖数据的分析。依赖管理系统被配置为利用适当的服务名称检测并注释每个依赖并解析所有依赖。有可能存在缺失的链接或解析依赖名称的故障，诸如实用机器(utility machine)和基础设施的外部服务。依赖管理系统提供了定义新服务实例和一个或多个服务分组规则的方法。组件团队(拥有该服务)可以注释依赖模型(例如控制平面、操作平面和数据平面)和边缘方向。依赖管理可以存储该信息并将其应用于租户服务的所有实例。
39.依赖管理系统支持门户(例如，前端网站)以查看依赖信息，其可以被托管在内部和/或在云中。网站的依赖数据可以来自sql(sql azure或具有自动故障转移功能的本地sql)，以确保该网站始终可用。该网站可以被实现为确保高可用性。可以设想，作为门户的一部分或独立于门户，使得依赖数据的数据图形表示可访问。依赖管理系统进一步支持可以以编程方式访问的web
‑
api来检索给定依赖服务租户的依赖数据。
40.数据图操作为依赖数据的图解说明，其提供依赖数据的可视化表示以供进一步分析。例如，用户可以下载完整图形或部分图形作为文件以供详细分析。数据图表示可以基于有向图的可扩展标记语言表示。例如，数据图可以采用有向图标记语言(dgml)文件格式，其允许用户经由门户或其他应用以交互方式浏览依赖图，以理解分析已经检测到的底层链接。支持查看数据图表示的应用可以支持不同类型的模式，以允许查看数据图表示中的灵
活性。例如，对于更大的图形，不同模式可以提供依赖的聚合视图。
41.作为示例，图2a和图2b图示了示例性依赖管理系统的数据图表示。具体而言，图2a是若干不同的依赖租户服务的部分图形表示，其包括它们的依赖关系和从属关系。图2a中的数据图包括依赖租户服务202a、204、206、208、210和212。链接(例如，链接214a)显示直接依赖，并且便于分析以理解rack_ip_01和store_web_01_01之间的活动。服务和链接可以进一步被注释，以在数据图视图内提供附加的细节。在图2b中，数据图的备选视图可以提供对依赖数据的访问。例如，图2b包括对应于tenant_service_alpha(202a)的tenant_service_alpha(202b)，并且在另一视图中图示tenant_service_alpha的依赖关系和从属关系。本文描述的实施例考虑了依赖数据的数据图视图的其他变型和组合。
42.参照图3a，可以参照作为用于实现依赖管理系统300的本文描述的功能的操作环境的示例性分布式计算基础设施300a来讨论本公开的实施例。依赖管理系统300包括依赖服务管理器310、多个收集器320(320a、320b、320c和320d)、标准名称提供器330、依赖聚合器340、依赖数据存储库350和前端352。
43.如本文所使用的，系统是指任何设备、方法、或服务或其组合。系统可以使用作为硬件、软件、固件、专用设备或其任何组合的组件来被实现。系统可以被集成到单个设备中，或者它可以被分布在多个设备上。系统的各种组件可以是共同定位的或分布式的。该系统可以从其他系统及其组件来被形成。应该理解的是，本文描述的这个布置和其他布置仅作为示例被阐述。
44.已经标识了分布式计算环境中的各种组件，应注意的是可以使用任意数量的组件以实现本公开内容的范围内的所需功能。为了清楚起见，图3a中的各种组件利用线条来被示出。此外，尽管图3a的一些组件被描绘为单个组件，但是描述在本质上和数量上是示例性的，并且不被解释为限制本公开的所有实现。可以基于上面列出的组件的功能和特征来进一步描述依赖管理系统功能。
45.其它的布置和元素(例如，机器、接口、功能、次序、以及功能的分组等)可以被附加于或代替所示出的那些来被使用，并且一些元件可以一起被省略。此外，本文描述的元件中的许多元件是功能实体，其可以被实现为离散或分布式组件，或与其他组件相结合来被实现，并且以任何合适的组合和位置来被实现。本文描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件来执行。例如，各种功能可以由执行被存储在存储器中的指令的处理器来执行。
46.在操作中，依赖管理系统300的依赖服务管理器310支持分析流水线并且利用定义的流中的数据来适当地优化依赖数据。使用多个收集器320来检索在依赖数据的分析和生成中被使用的数据。收集器被配置为检索关于服务的信息或数据。收集器的目标是在设计时间、运行时和部署时间收集信息。收集器可以与收集时间相关联(例如，经由收集时间属性)，使得收集器基于特定收集时间来检索数据。收集器还可以在收集时注释任何收集的数据，以提供收集到的数据的历史视图。
47.存在多个收集器320可以支持的若干不同类型的收集时间或阶段。设计时间集合支持理解模块和服务类型之间的依赖关系(例如，客户端库或通用库的使用)。设计时间集合可以包括静态依赖分析、层映射和故障模型分析。静态依赖分析是指用于确定程序二进制文件之间的依赖关系的技术。通过分析所使用、所引用的或被包含在软件包中的的二进
制文件，静态依赖分析被完成。这些依赖关系表明对服务的依赖关系，而不是对服务的具体实例的依赖关系。层映射是指将服务分组为层次结构，其允许在服务之间进行适当分层(例如，较低级别的服务不依赖于较高级别的服务)。层映射可以支持验证数据图表示并确保适当的设计。层级图(layermap)是程序二进制文件之间依赖关系的模型，并且可以不是精确表示。故障模型是描述程序在运行时可能发生故障的各种方式以及这些故障对执行的影响的模板。故障模型分析是用于依赖分层的手动文档设计，以示出一个或多个依赖关系中的故障如何通过系统传播。例如，依赖关系可以在sql上被建模作为非关键的，这意味着sql中的故障不应该是固有故障。就此而言，任何分析都不应将sql组件中的故障视为服务故障的可能原因。
48.部署时间集合(例如，名称解析器)支持将特定部署映射到服务类型(例如，tenant_serivce_alpha_01实例是逻辑tenant service_alpha的一部分)并且重新映射名称(例如，部署guid到名称)。部署时间集合还支持下载和解析部署工件以收集静态声明的依赖关系。静态声明的依赖关系可以包括从第一服务到第二服务到第一服务实例到第二服务实例的依赖关系的具体实例化。就此而言，如果多个实例存在，则可推断若干单独的依赖关系。静态设计时间工具可能仅在服务级别处提供依赖关系，而部署和运行时工具则提供服务实例级别的依赖关系。部署时间收集进一步支持集群的物理库存和虚拟机和互联网协议地址(虚拟机/ip)逻辑库存。部署时间集合可以包括tfs和数据中心设置(例如，datacenter.xml文件)。运行时收集支持在服务正在执行操作时至少部分基于它们之间的网络流量来发现服务的依赖关系。所设想的是，服务之间的通信可以直接经由api或间接经由诸如数据存储库或事件系统的中间组件。运行时收集可以包括租户配置(svd)和分布式计算基础设施事件。依赖服务管理器310可以操作以交叉检查由收集器填充的数据集(例如，表)中的数据或依赖信息。依赖服务管理器310生成租户和资源之间的关系。
49.如图3a所示，依赖服务管理器310与多个外部组件一起操作。数据存储库(例如，依赖数据库350)可以存储依赖数据或依赖信息，并且支持由服务支持的数据处理功能，并且前端352可以与数据存储库通信并且支持传送信息以用于经由显示器进行显示。数据存储库可以基于api来操作以提供本文描述的功能。在实施例中，分布式计算基础设施可以包括内部部署基础设施354。内部部署基础设施可以用于分布式计算基础设施的客户端、用于访问依赖服务的远程基础设施、或者外部部署的高可用性、以及灾难恢复基础设施。内部部署基础设施可以包括内部部署依赖数据库356和内部部署前端358，其中内部部署数据库被同步以包含依赖数据的最新信息，并且经由内部部署前端来传送依赖数据。
50.继续参考图3a，标准名称提供器330负责将跨服务的不同命名约定关联到归一化形式。标准名称提供器330组件可以操作以从不同类型的代理(例如，运行器)获取输入数据并且输出标准名称。在一个示例性实现中，标准名称提供器330使用包括以下的工作流：标准名称提供器330从收集器接收请求，来自具体类型的收集器的请求使用由该收集者收集的数据来查询标准名称提供器330。标准名称提供器330然后输出目标依赖服务租户的标准名称；并且收集器使用该标准名称来更新依赖服务租户的元数据信息。元数据信息可以经由依赖服务界面来被提供，如本文中更详细地讨论的。
51.收集器可以检索数据项，该数据项被用于从标准名称提供器请求标准名称。收集器可以针对特定服务检索不同类型的数据项。检索到的数据项中的一个或多个数据项可被
专门用于查找每种类型的集合。例如，在下面的表1中，表1示出了用于检索标准名称的不同收集器类型和收集到的数据(例如，输入数据)。突出显示的数据项可以被用于查找以便于获得标准名称。mds收集器可以使用tenantid，svd收集器可以使用tenantid和vip两者，dns收集器可以使用vip和时间戳(timestamp)。
[0052][0053]
表1
[0054]
就此而言，标准名称提供器操作以基于由收集器提供的数据来查找标准名称。标准名称提供器可以使用用于查找目的的不同数据结构以便于找到标准名称。在示例性实施例中，标准名称提供器330使用表(例如，标准名称表)。除了使用用于查找和逻辑的标准名称表外，该表或者用于查找和逻辑的对应数据结构也可以被用于依赖服务租户和角色查找。
[0055]
示例性标准名称表在下面的表2中被示出。标准名称表可以被配置为允许重复的记录(例如，名称和类型的相同组合)。利用这种配置，依赖服务可以从不同运行器的视角提供同一依赖服务租户的不同视图。例如，租户watasksn1利用新的vip 200.1.4.6被升级，而不是200.1.3.5。svd的收集器具有此升级信息，并且插入新记录(例如，vip|200.1.4.6|watasksn1|2013
‑
07
‑
04 11:05:17|)，如下表2所示。时间戳列可以指示数据的新鲜度。基于此，可以实现垃圾收集或清理逻辑来删除由守护线程维护的记录。查找逻辑基于种类(kind)和值(value)的组合，其中种类和值的组合是有利地唯一的。
[0056]
[0057]
表2
[0058]
一旦svd运行器得到标准名称，则它可以更新表“租户元数据实体(tenantmetadataentities)”中的元数据。举例来说，表“tenantmetadataentities”可以看起来如表3所示：
[0059][0060]
表3
[0061]
依赖管理系统300还可以支持存储在依赖管理系统中定义的多个对象的工件表。示例性工件可以是依赖服务的组件，其中组件的属性被捕获在工件表中。例如，如表4所示，组件名称是watask，watask的对应属性可以被填充到表中。特别地，工件表中的“相对路径(relativepath)”列可以是标准名称，并且唯一性在此列上被强制执行。
[0062][0063]
表4
[0064]
依赖管理系统包括若干不同类型的收集器。收集器可以是基于部署时间、设计时间或运行时的收集器。每个类别中的若干收集器可以进一步被指定为mds相关收集器、标准名称收集器、mds依赖收集器和基于svd的收集器。特别地，一个或多个基于运行时的收集器可以包括：mds相关收集器(例如，标准名称收集器、mds依赖收集器)、基于svd的收集器。与mds相关的收集器可以为运行时依赖收集提供基准信息集。在mds内运行的收集器根据需要使用不同的平台或服务(例如，运行器、看门狗、插件、规则或嵌入式服务)来被完成。
[0065]
参考图3b，图3b示出了使用依赖服务管理器实现的数据聚合机制。在高级别处，数据聚合机制包括名称提供器聚集器360a和标准名称解析器360b、依赖分析器370、网络数据解析器380和符号网络数据386。上述组件在操作上耦合到依赖聚合器390，其与依赖数据库392和前端394通信。在组合中，组件支持依赖管理系统中的依赖聚合和依赖数据通信。
[0066]
名称提供器聚合器360a与多个标准名称收集器(例如，数据服务362、事件租户
364、部署事件366、数据中心监视器368)相关联。标准名称收集器可以作为第一层收集器操作。第一层收集器使用各种类型的信息来构建ip(vip或dip)以稳定依赖服务租户名称映射。标准名称服务提供了稳定的平台，以归一化名称和依赖服务租户信息以用于任何进一步的关联或注释。在一个实施例中，标准名称收集器可以作为运行器(例如，ma列表、cs)和规则(例如，事件处理)来被实现，以生成名称的稳定列表和ip到标准名称映射的当前集合。
[0067]
标准名称收集器监视不同类型的事件。例如，mds监视代理、硬件和软件组件、前端、以及租户部署和更新事件。这提供了已知的依赖服务租户的列表及其用于依赖解析的当前vip分配。cs收集器监视数据中心库存改变(通过监视cs改变)并且将名称分配给硬件实体，如集群、机架、配电单元、机架顶部交换机等。这些项还允许物理视图和分配的未来构建。
[0068]
第二层收集器可以包括mds依赖收集器。基于mds的收集器通过将原始网络事件(例如，windows套接字事件)转换为符号稳定版本来更新依赖图。网络数据解析器380可以作为过滤器操作，并且可以利用标准名称提供器以将特定ip地址解析为服务依赖关系，引发winsock/dns事件和导致在事件被处理时更新服务对服务的依赖关系。如图3b所示，mds依赖收集器包括网络规范382(例如，winsock/dns)和网络命名系统384(例如，dns服务)，其与标准名称解析器360b(即，动态名称解析信息)结合操作以基于网络事件来更新依赖数据。就此而言，网络数据解析器380聚合来自具体机器实例的数据，因此它提供依赖关系的聚合视图而不是单独的机器信息。网络数据解析器380操作以提供名称(例如，account.blob.storage.cloud
‑
service.com)到ip地址的映射。就此而言，网络数据解析器380向ip提供具体存储帐户(或其他名称)的更细粒度的信息，以通过中间存储帐户或其他事件系统或机制来启用在细粒度级别处的关联以及依赖关系和服务之间的关联。例如，如果服务a和服务b两者都使用帐户abqueue.queue.cloud
‑
service.com，则依赖服务系统因此提供服务a和服务b依赖于queue.cloud
‑
service.com并且服务a和b彼此依赖的信息。尽管服务a和b可能不直接通信。
[0069]
基于svd收集器(例如，服务模型定义372)可以基于服务模型定义来操作，以收集用于生成依赖数据的数据。作为背景，服务模型可以指代可以被用于创建服务实例的模板，并且包括若干不同的元素(例如，服务、角色、组、信道、拓扑和托管环境)。例如，
[0070]
服务：角色、组和信道的结构化集合，其描述类型的服务。该服务提出了配置设置集合(其必须被绑定到用于部署的特定值)、一系列输入接口(构成其合同)以及其他服务合同接口的一系列依赖关系。
[0071]
组件：各自独立地为可伸缩单元，其中它可以是角色或组。角色：服务的每种类型的组件，程序类型，被设计成被多次实例化。组：其他组、角色和信道的集合。最小组是角色。启用角色和信道的预定义集合的实例化。
[0072]
信道：建立组之间的连接，以各种方式(例如负载平衡器、有状态和无状态交换机信道)与实例关联。
[0073]
拓扑结构：服务的结构的描述(组、角色、信道和相关联的互连、角色之间的亲和性等)
[0074]
宿主环境：角色所需要的运行时(例如，特定的os sku)
[0075]
可以利用对应的svd文件来创建或更新分布式计算基础设施的每个租户，并且svd
文件包含服务的服务模型定义以及暗示对其他服务的引用的一些设置。svd和操作模式(尤其当被规定或标准化时)可以通过使用试探法和倡导适当的指南来被利用。就此而言，服务模型定义可以包括定义中的对象，这些对象可以由收集器标识，并且然后被用于生成依赖数据。依赖收集器可以在依赖服务租户实际运行之前发现大多数依赖关系。基于svd标识依赖数据可以基于以下中的一项或多项：svd的输入端点；svd的规范，其中声明输入端点以供其他服务引用；设置的名称遵循公知的命名约定；并且该设置的值与某个公知的模式(例如，dns名称)相匹配。在一个示例中，收集器可以使用xml表示来生成对数据的依赖引用。因此，收集器可以将存储帐户(storage_account_alpha)解析为具体vip(ip_storage_account_alpha)和依赖关系的来源。整体依赖关系可以包括指向存储组件的依赖关系和存储组件的名称。
[0076]
继续参考图3b，设计时间收集器(例如，设计时间收集器374)操作以使用符号表示来捕获用户(例如，服务管理员)的意图。符号表示允许从运行时依赖关系(非偶发性)进行更强大的推断，并且检测并非始终处于使用状态的依赖关系。设计时间收集模型允许更多的属性，包括：数据流方向，fma平面，业务影响的依赖关系的优先级、设想的设计时间依赖关系(例如，前端取决于位置服务、存储基础设施、操作硬件或软件基础设施或sql服务器和服务)。设计集合模型可以用xml表示。尤其是，设计时间集合的表示被缩进以捕获开发者提供的信息并且优先考虑在运行时发现的依赖关系。多个收集器被用于将其他依赖关系跟踪工具信息(例如layermap、almap、包分析)转换为通用格式。layermap可以指代软件栈的部分之间的声明式分层，以确保引用的正确模式。layermap可以在操作系统内被使用，以确保操作系统较高部分中的代码仅引用较低的适合的部分，并且在另一方向上不存在引用(即，从较低到较高)。almap是指为针对fma的设计，以在云操作系统而不是传统os内文档记录跨服务的分层图。包分析可以指代使用现有包(例如，nuget、cspkg)并打开其内容或依赖关系列表来了解可以利用哪些其他服务。设计时间收集器的益处是设计时间收集器通常噪音较小并且要求低的处理成本。
[0077]
参考部署收集器，部署收集器被设计为监视部署信息，以便能够得到有关部署(何时、何处、谁)的附加元数据，并对触发解析逻辑的刷新以得到对数据的立即更新。tfs收集器自动从tfs记录中枚举分布式计算基础架构的依赖关系和从属关系。tfs源代码管理器包括代码的自动构建以及其他功能。tfs收集器数据有助于将租户分类为服务组并与组件团队相关联。cs收集器枚举被存储在cs配置存储库内的配置数据，以在部署转换之前收集用于部署的当前设置(符号的而不是具体的)。它还可以收集硬件位置/ip/分配以从具体硬件/vm映射到集群信息。该信息在cs中的存储仅是示例性的实现，而不意味着限制。在另一示例性实施例中，数据可以被存储在其他数据存储库或数据结构中，诸如生产硬件管理服务。
[0078]
参照图3b，依赖聚合器390在操作上耦合到用于动态名称解析的标准名称解析器360b、符号网络数据386、提供服务模型定义和设计时间收集器数据的依赖分析器370。在聚合过程期间，依赖聚合器从收集器中检索数据，并将依赖数据存储在依赖数据库392中，该依赖数据库392支持将依赖数据传送到前端394。依赖数据库392还可以支持将依赖数据传送给web
‑
api服务，以启用编程访问来检索数据从而启用自动恢复操作，而不是早门户上显示数据以供用户来解析。所设想的是，依赖数据库392和前端394可以与内部部署的基础设
施同步。许多核心组件都支持多租户，这会导致核心组件代表依赖服务租户来初始化网络流量。
[0079]
表5是不同类型的收集器的图示。下表进一步总结了从上述收集器中的每一个收集的数据：
[0080]
[0081][0082]
表5
[0083]
符号：[depends_on]指示依赖，—其中一个对象基于另一个的功能来操作的耦合—和[contained_in]指示被包含—当一个特定项是一个更大的概念的一部分时。例如，刀片是机架的一部分，机架是数据中心的一部分。角色可以是服务的一部分。
[0084]
依赖管理系统还支持手动编辑。虽然大多数依赖信息可以是使用本文描述的组件而被自动推断和关联的，但是用户仍然需要修改和注释信息。为此，依赖服务界面(例如，门户)支持附加的编辑体验。例如，组件团队可以通过门户或底层数据服务来上载设计的依赖关系。
[0085]
有利地，该组件团队可以文档记录所有的服务引用，使得服务被适当地分类。当存在运行时检测到的依赖关系时，组件团队成员可以定义fma平面和流边缘的方向。依赖管理系统还可以操作以捕获中央位置中的输入。捕获中央位置中的输入确保服务所有者的编辑体验是流畅的。组件团队可以开发审查过程，所以这些改变可以反映回到组件团队的源代码中，并且适当地倡导依赖关系。
[0086]
例如，经由门户的依赖服务界面可以进一步使得用户能够将未解析的通信目标与服务或像内部dns服务器等的适当分类的节点相关联。依赖管理系统聚合数个来源以生成定期更新的依赖图。不同的收集器从数个来源检索和传送数据以收集关于平台租户的信息，将它们分组到服务中并且将它们与组件团队相关联。收集器被配置为从各种来源(代码、配置、运行时和部署信息)收集分布式计算基础设施的信息，分布式计算基础设施包括云计算平台和内部部署基础设施。聚合的数据可以被存储在多个位置中以用于灾难恢复(dr)情况下的高可用性，并且被维护在所有位置处的合理的新鲜度内。依赖管理系统300操作以监视任何数据的陈旧性，以确保它正在提供与真实世界一致的视图。
[0087]
依赖管理系统300还支持可靠性和维护框架。依赖管理系统300可以包括恢复依赖服务ui。恢复依赖关系可以是冗余的，以提供独立于潜在故障的信息。在一个实施例中，恢复依赖服务位于内部部署和云计算平台之内，以向本地和区域故障提供冗余。依赖管理系统300可以利用同步技术来确保两个位置在合理的时间内被保持更新。
[0088]
有利地，处理流水线位于云计算平台内，以利用云环境的可扩展性和低维护。多个收集器访问资源作为现有流水线的一部分(例如，cs复制、云计算平台分析)。处理流水线利用现有的监视技术(mds)以监视健康状况、针对流水线问题的报警以及监视流水线kpi。
[0089]
依赖管理系统可以支持依赖数据层。如上所述，依赖数据层可以基于依赖图或其他图形表示来被实现。依赖图或数据图可以包括与经由依赖管理系统实现的故障恢复机制相关联的节点和边缘。在具有依赖图的实施例中，依赖图中的节点是用于操作者或开发者的恢复操作和依赖显示的单位。一些感兴趣的主要节点是服务实例(租户)端点和实用机器(例如，到自举服务的跳转块)。因为恢复动作需要以人工可管理的方式来被呈现，所以恢复
图的粒度通常显示依赖租户级别的工件。较小的资源(例如，存储装置、机器)可以被突出显示以用于潜在的恢复动作，但是对于完整的旋转选项不是必需的。图的边缘是定向的；信息流向对恢复顺序而言至关重要。图的边缘可以包含服务的故障模型，例如运行时平面、管理平面、监视平面或控制平面。边缘包含反映链路的重要性的权重(一阶近似将是交通量，但也可以使用其他测量)。
[0090]
依赖数据层还包括节点命名机制。图中的节点可以被配置有全局id，其遵循标准化的分类法。该方法可以被用于通过层次结构来标识节点。层次结构可以是按照逻辑服务所有权或按照物理位置的。此外，该节点可以由约定层次来被标识，例如，存储账户访问：组件/租户/账户名称/dns名称；租户：组件/租户；角色实例：组件/租户/角色名称/角色实例；和刀片：数据中心/集群/机架/刀片。按照惯例，节点(组件、租户、角色，二进制文件和源/配置文件)可以具有稳定的统一资源标识符(uri)。该uri的分段包含组件名称(componentname)、工件种类(kind)以及工件相对路径(relativepath)。关系边缘仍然可以具有详细的版本，所以客户端可以选择性地合并信息。依赖数据层可以进一步以图形表示(例如，依赖图)呈现。依赖图可以被用于批量上传和终端用户浏览场景。信息可以以各种格式被编码，以解决针对不同场景的功能和性能要求。
[0091]
依赖数据层还包括工件/关系，用于捕获公共数据合同来交换依赖信息。如图3c所示，依赖信息的交换可以基于工件和关系(例如，工件种类302和工件304以及关系306和关系种类308)以及它们的对应属性之间的依赖图逻辑格式。各种服务可以根据情况适当地交换二进制文件、xml和其他格式的依赖信息。
[0092]
继续参考经由依赖数据层而支持的图形表示，节点和边缘可以承载一组属性，具有编入索引以用于更快的搜索一些公知的属性。以下是用户友好名称的示例标签。种类用于分类节点或链接并简化搜索体验。组件名称(componentname)：服务的逻辑名称。相对路径(relativepath)：唯一路径标识该组件和种类中的节点。权重帮助客户按重要性对信息进行排序。最后更新时间(lastupdatetime)用于信息被更新的最后时间，因此收集器能够缓存旧信息、执行增量更新并且使旧记录退休。种类、组件名称和相对路径的示例如下表6所示。
[0093][0094][0095]
表6
[0096]
依赖数据层可以提供附加的数据服务，其可以查询类似下面的属性。每种类型的节点可以具有不同类型的属性集，如服务节点具有部署id、服务模型等。图的主存储装置可以是sql数据源，数据库在内部部署中被备份以提供灾难恢复可用性。在不意味着限制的一个示例性实现中，依赖数据层可以使用实体框架将实体模型映射到sql数据库中的表以简化维护。依赖数据层还可以提供用于将图的切片上载/下载到xml/dgml/等的文件中。
[0097]
依赖管理系统300可以提供对间接依赖关系的支持。可以完成附加依赖处理来检测依赖服务租户之间的间接依赖关系。例如，间接依赖关系可以指代使用存储、服务总线、sql作为通信信道的依赖关系。就此而言，依赖关系不仅仅针对“信道”上的一个服务(提供通信的服务—例如存储)，还包括两个服务之间的服务。这些依赖关系更难以检测，因为这两个服务之间可能不存在直接通信。在这种情况下，通信信道(存储)将利用相同的帐户/队列/表名称，并且这两个服务都将读取/写入这些位置。通过将依赖分析用于确切的账户，有可能通过查找具有多个服务所利用的相同帐户来推断这种依赖关系。间接依赖关系发现机制可以检测两个依赖服务租户之间的协同依赖性。自动化分析可以标记这些依赖关系以供进一步处理，因此组件团队可能被要求声明它们。
[0098]
依赖管理系统300还可以支持归一化。举例来说，如果依赖管理系统使用如“fabric”中的原始依赖服务租户名称，则依赖数据层必须执行具有脆弱绑定的不必要的操作。依赖管理系统提供了一种机制来标准化分布式计算环境中的通用依赖服务租户名称。数据可以适当地被聚合到反映服务名称和缩放单元名称的底层逻辑实体。可以为组件团队提供命名约定指南，因此依赖分析器可以自动识别其依赖服务租户的稳定名称。
[0099]
现在转到图4，提供了示出用于提供依赖管理的方法400的流程图。该方法可以使用本文描述的依赖服务管理器来执行。初始地在框410处，接收来自多个收集器的数据。收集器基于与对应收集器相关联的收集时间属性来访问数据，收集时间属性选自以下之一：设计时间收集；部署时间收集；和运行时收集。收集器基于对应的收集时间属性来检索和更新依赖服务租户的数据。设计时间收集包括标识开发者提供的依赖信息，该信息支持标识依赖服务租户的依赖关系和从属关系。部署时间收集包括基于监视依赖管理系统的分布式计算基础设施的部署操作将部署服务映射到依赖服务租户。运行时收集包括当依赖服务租户的操作至少部分基于在组件之间传送的网络流量正在被执行时标识所述依赖服务租户的依赖关系。在实施例中，数据的至少一部分被传送到标准名称提供器，该标准名称提供器使用数据的部分来查找或生成用于依赖服务租户的标准名称。
[0100]
在框420处，分析由多个收集器收集的数据以交叉检查并生成依赖服务租户与对应的依赖和从属组件之间的关系。分析可以包括处理来自收集器的数据，然后生成依赖数据。在框430处，在分析数据时，依赖数据被生成，该依赖数据包括与依赖管理系统的依赖服务租户相关联的依赖关系和从属关系。生成依赖数据基于实现操作以至少部分地基于服务模型定义和为了基于所述服务模型定义来标识依赖服务租户而定义的试探法来检索数据的依赖聚合机制。生成依赖数据还基于使用用于构建依赖服务租户到名称的映射的第一层收集器和用于提供网络事件的依赖数据表示的第二层收集器来实现依赖聚合机制。该方法可以进一步包括传送依赖数据以支持基于依赖服务界面和数据图表示对依赖数据的访问，该依赖服务界面包括逻辑视图界面，其具有支持呈现和访问依赖数据的至少两个可选视图，并且数据图表示包括与故障恢复机制相关联的节点和边缘。
[0101]
现在转到图5，提供了示出用于提供依赖管理的方法500的流程图。计算机存储介质具有在其上实施的计算机可执行指令，该计算机可执行指令在被一个或多个处理器执行时，使一个或多个处理器执行用于依赖管理的方法。在框510处，生成依赖服务界面。依赖服务界面包括逻辑视图界面，其具有支持呈现和访问依赖数据的至少两个可选视图。依赖数据是基于来自多个收集器的数据而被生成的，依赖数据包括与依赖管理系统的租户服务相关联的依赖关系和从属关系。多个收集器基于与对应收集器相关联的收集时间属性来访问用于生成依赖数据的数据，收集时间属性选自以下之一：设计时间收集；部署时间收集；和运行时收集。在框520处，利用从由多个收集器检索的数据生成的依赖数据来填充依赖服务界面。
[0102]
逻辑视图界面的第一可选逻辑视图是支持查看租户服务的故障的按照服务的依赖视图，并且逻辑视图界面的第二可选逻辑视图是支持查看租户服务位置的故障的按照位置的依赖视图。依赖服务界面进一步包括依赖搜索栏，依赖搜索栏支持搜索租户服务，其中传入关系和传出关系被填充在使用依赖搜索栏执行的基于依赖服务界面的搜索上。所设想的是，有可能呈现更多的依赖关系的视图，诸如按位置的过滤器、服务或位置的当前健康状况。此外，视图可以与其他数据源集成，其他数据源诸如合规性、健康状况、错误率、当前网络负载和cpu负载，以提供依赖数据的更全面和综合的视图。有利地，不同的附加视图丰富了分布式计算系统的依赖图和其他健康模型。
[0103]
依赖服务界面基于api来操作，该api支持至少部分基于对依赖数据的数据图表示的自动化访问来查询和检索依赖数据，该数据图表示包括与故障恢复机制相关联的节点和边缘。
[0104]
依赖服务界面进一步操作为用于查看依赖数据的门户，其中该门户进一步支持提供对依赖数据的数据图表示的访问，其中在数据图表示中的节点与恢复动作相关联并且边缘指示对应依赖服务租户的故障模型。
[0105]
参考依赖管理系统，本文描述的实施例支持配置、发现和传送分布式计算系统中的服务之间的依赖关系。依赖管理系统组件是指用于管理依赖关系的集成组件。集成组件是指使用依赖管理系统服务平台支持数据访问功能的硬件体系结构和软件框架。硬件体系结构是指物理组件及其相互关系，而软件框架是指提供可以利用在设备上操作的硬件来实现的功能的软件。端到端的基于软件的依赖管理系统服务平台可以在依赖管理系统服务平台组件内操作，以操作计算机硬件来提供依赖管理系统服务平台功能。这样，依赖管理系统服务平台组件可以管理资源并为依赖管理系统功能提供服务。本发明的实施例可以设想任何其他变型和组合。
[0106]
作为示例，依赖管理系统平台可以包括api库，其包括用于例程，数据结构、对象类和变量的规范，其可以支持设备的硬件结构和依赖管理系统服务平台系统的软件框架之间的交互。这些api包括依赖管理系统平台系统的配置规范，使得驱动器组件和其中的组件可以在依赖管理系统服务平台中彼此通信，如本文所描述的。特别是，api可以支持外部服务(例如，健康监视、合规评审等)来检索依赖信息。
[0107]
已经简要描述了本发明的实施例的概览，其中本发明的实施例可以被实现的示例性操作环境在以下被描述，以便于提供针对本发明的各个方面的一般上下文。初始地参考图6，特别地，用于实现本发明的实施例的示例性操作环境被示出并且被一般性地指定为计
算设备600。计算设备600仅仅是合适的计算环境的一个示例，并不意图为暗示对本发明的用途或功能的范围的任何限制。计算设备600也不应被解释为具有与所示组件中的任一项或组合相关的任何依赖关系或要求。
[0108]
可以在计算机代码或机器可用指令的一般上下文中描述本发明，该计算机代码或机器可用指令包括由计算机或其他机器(诸如个人数据助理或其他手持设备)执行的计算机可执行指令(诸如程序模块)。通常，包括例程、程序、对象、组件、数据结构等的程序模块是指执行特定任务或实现特定抽象数据类型的代码。本发明可以在各种系统配置中被实践，包括手持设备、消费电子产品、通用计算机、更专业的计算设备等。本发明还可以在分布式计算环境中被实践，其中任务由远程处理设备执行，远程处理设备通过通信网络被链接。
[0109]
参照图6，计算设备600包括直接或间接耦合以下设备的总线610：存储器612、一个或多个处理器614、一个或多个呈现组件616、输入/输出端口618、输入/输出组件620以及说明性电源622。总线610表示可以是一个或多个总线(诸如地址总线、数据总线或其组合)的总线。尽管图6的各个框为了清楚起见用线条被示出，但实际上，描绘各种组件并不那么清楚，并且线条在比喻上更准确地是灰色和模糊的。例如，可以将诸如显示设备的呈现组件看作是i/o组件。另外，处理器具有存储器。我们认识到这是本领域的本质，并且重申图6中的图仅仅是说明可以结合本发明的一个或多个实施例来使用的示例性计算设备。在诸如“工作站”、“服务器”、“膝上型计算机”、“手持设备”等类别之间没有进行区分，因为所有这些被设想在图6的范围内并参考“计算设备”。
[0110]
计算设备600通常包括各种计算机可读介质。计算机可读介质可以是能够由计算设备600访问的任何可用介质，并且包括易失性和非易失性介质，可拆卸和不可拆卸介质。作为示例而非限制，计算机可读介质可以包括计算机存储介质和通信介质。
[0111]
计算机存储介质包括易失性和非易失性、可拆卸和不可拆卸介质，其以用于存储信息的任何方法或技术来被实现，信息诸如计算机可读指令、数据结构、程序模块或其它数据。计算机存储介质包括但不限于ram、rom、eeprom、闪存或其它存储技术，cd
‑
rom、数字多功能盘(dvd)或其他光盘存储装置，磁带盒、磁带、磁盘存储装置或其他磁存储设备，或者可以被用于存储所需信息并且能够由计算设备600访问的任何其他介质。计算机存储介质本身排除了信号。
[0112]
通信介质通常在经调制的数据信号中实施计算机可读指令、数据结构、程序模块或其它数据并且包括任何信息传递介质，经调制的数据信号诸如载波或其它传输机制。术语“经调制的数据信号”是指使其特性中的一个或多个特性以在信号中编码信息的方式来被设置或改变的信号。作为示例而非限制，通信介质包括诸如有线网络或直接有线连接的有线介质，以及诸如声学、rf、红外和其他无线介质的无线介质。上述任何组合也应被包括在计算机可读介质的范围内。
[0113]
存储器612包括易失性和/或非易失性存储器形式的计算机存储介质。存储器可以是可拆卸的、不可拆卸的或其组合。示例性硬件设备包括固态存储器、硬盘驱动器、光盘驱动器等。计算设备600包括从各种实体(诸如，存储器612或i/o组件620)读取数据的一个或多个处理器。呈现组件616向用户或其他设备呈现数据指示。示例性呈现组件包括显示设备、扬声器、打印组件、振动组件等。
[0114]
i/o端口618允许计算设备600在逻辑上被耦合至包括i/o组件620的其他设备，i/o
组件620中的一些可以是内置的。说明性组件包括麦克风、操纵杆、游戏垫、碟形卫星天线、扫描仪、打印机、无线设备等
[0115]
现在参照图7，图7示出了其中可以采用本公开的实现的示例性分布式计算环境700。特别地，图7示出了云计算平台710中的依赖管理系统(“系统”)的高级别体系结构，其中该系统支持软件组件的无缝修改。应该理解的是，本文描述的这个布置和其他布置仅作为示例被阐述。除了所示的那些之外或者替代所示的那些，可以使用其他布置和元件(例如，机器、接口、功能、顺序和功能分组等)，并且一些元件可以被完全省略。进一步地，本文描述的元件中的许多元件是功能实体，其可以被实现为离散或分布式组件或者与其他组件相结合来被实现，以及被实现在任何合适的组合和位置中。本文描述为由一个或多个实体执行的各种功能可以由硬件、固件和/或软件来执行。例如，各种功能可以由执行被存储在存储器中的指令的处理器来执行。
[0116]
数据中心可以支持分布式计算环境700，该分布式计算环境700包括云计算平台710、机架720和机架720中的节点730(例如，计算设备、处理单元或刀片)。该系统可以利用云计算平台710来被实现，云计算平台710跨不同的数据中心和地理区域来运行云服务。云计算平台710可以实现用于供应和管理云服务的资源分配、部署、升级和管理的结构控制器740组件。通常，云计算平台710作用为以分布式方式存储数据或运行服务应用。数据中心中的云计算基础设施710可以被配置为托管和支持特定服务应用的端点的操作。云计算基础设施710可以是公共云、私有云或者专用云。
[0117]
可以向节点730供应主机750(例如，操作系统或运行时环境)，其在节点730上运行定义的软件栈。节点730还可以被配置为在云计算平台710内执行专门的功能(例如，计算节点或存储节点)。节点730被分配以运行租户的服务应用的一个或多个部分。租户可以指代利用云计算平台710的资源的客户。支持特定租户的云计算平台710的服务应用组件可以被称为租户基础设施或租赁。术语服务应用、应用或服务在本文中可互换使用，并广义地指代任何软件或软件的部分，它们在计算中心之上运行、或者访问计算中心内的存储装置以及计算计算中心内的设备位置。
[0118]
当节点730正在支持多于一个单独的服务应用时，节点可以被划分成虚拟机(例如，虚拟机752和虚拟机754)。物理机器也可以并行地运行单独的服务应用。虚拟机或物理机器可以被配置作为由云计算平台710中的资源760(例如，硬件资源和软件资源)支持的个性化计算环境。所设想的是，资源可以被配置用于具体服务应用。此外，每个服务应用可以被分成功能部分，使得每个功能部分能够在单独的虚拟机上运行。在云计算平台710中，可以使用多个服务器来运行服务应用并且在集群中执行数据存储操作。特别地，服务器可以独立地执行数据操作，但被暴露为被称为集群的单个设备。集群中的每个服务器可以被实现为节点。
[0119]
客户端设备780可以被链接到云计算平台710中的服务应用。客户端设备780可以是任何类型的计算设备，例如其可以对应于参考图7描述的计算设备7。客户端设备780可以被配置为向云计算平台710发出命令。在实施例中，客户端设备780可以通过虚拟互联网协议(ip)与服务应用进行通信，以及将通信请求引导到云计算平台710中的指定端点的负载均衡器或其他装置。云计算平台710的组件可以在网络(未示出)上彼此通信，其可以包括但不限于一个或多个局域网(lan)和/或广域网(wan)。
[0120]
已经描述了分布式计算环境700和云计算平台710的各个方面，应该注意的是可以使用任意数量的组件以实现本公开内容的范围内的所需功能。尽管图7中的各种组件为了清楚起见用线条被示出，但实际上，描绘各种组件并不那么清楚，并且线条在比喻上更准确地是灰色和模糊的。此外，尽管图7的一些组件被描绘为单个组件，但是描述在本质上和数量上是示例性的，并且不被解释为针对本公开的所有实施方式进行限制。
[0121]
在下面的段落中描述的实施例可以与具体描述的替代方案中的一个或多个相结合。特别地，所要求保护的实施例可以包含引用，但是备选地，可以包含超过一个其他实施例。所要求保护的实施例可以指定所要求保护的主题的进一步限制。
[0122]
本发明的实施例的主题在本文中利用特异性被描述以满足法定要求。然而，描述本身并不意图限制本专利的范围。相反，发明人已经设想到，所要求保护的主题还可能与其他当前或未来的技术相结合以其他方式来被实施，以包括不同的步骤或与本文档中描述的步骤类似的步骤的组合。此外，尽管术语“步骤”和/或“框”可以在本文中被使用以暗示所采用的方法的不同元素，但是这些术语不应该被解释为暗示本文公开的各种步骤之中或之间的任何特定顺序，除非和除了当各个步骤的顺序被明确地描述时。
[0123]
出于本公开的目的，词语“包括(including)”具有与词语“包括(comprising)”相同宽的含义，并且词语“访问”包括“接收”、“参考”或“检索”。另外，除非另有相反指示，否则诸如“一”和“一个”的词语包括复数以及单数。因此，例如，在一个或多个特征存在情况下，“特征”的约束被满足。此外，术语“或”包括连接词、分隔词和两者(a或b因此包括a或b，以及a和b)。
[0124]
出于以上详细讨论的目的，本发明的实施例参照分布式计算环境来被描述；然而本文描绘的分布式计算环境仅仅是示例性的。组件可以被配置用于执行实施例的新颖方面，其中被配置为包括被编程为执行特定任务或使用代码实现特定抽象数据类型。此外，虽然本发明的实施例可能一般性地指代头戴式显示单元和本文描述的示意图，但是应该理解，所描述的技术可以被扩展到其他实现上下文。
[0125]
本发明的实施例已经关于其意在所有方面是说明性的而非限制性的特定实施例进行了描述。在不脱离本发明范围的情况下，备选实施例对于本发明所属领域的普通技术人员而言将变得显而易见。
[0126]
根据上述内容将看出，本发明很好地适用于达成以上与其他优点一起阐述的所有目的和目标，其是明显的并且是结构所固有的。
[0127]
应当理解的是，某些特征和子组合是有用的，并且可以不参考其他特征或子组合来被使用。这是权利要求所设想的并且在权利要求的范围内。