CN105516233A

CN105516233A - 用于在一个或多个云系统上便携部署应用的方法和系统

Info

Publication number: CN105516233A
Application number: CN201510612411.0A
Authority: CN
Inventors: J.约翰斯顿; S.P.亨利
Original assignee: Sony Computer Entertainment America LLC
Current assignee: Sony Interactive Entertainment LLC
Priority date: 2014-09-30
Filing date: 2015-09-23
Publication date: 2016-04-20
Anticipated expiration: 2035-09-23
Also published as: US10171383B2; WO2016053518A1; JP2017529633A; CN105516233B; EP3201772A1; KR20170051471A; US20160094483A1; JP6346377B2; US20180077084A1; US9825881B2; KR101891506B1

Abstract

用于在云服务上供应服务或资源以成功地执行应用的方法和系统包括检测用于在云服务上执行应用的请求。响应于所述请求，从描述符文件检索所述应用的描述符记录。所述描述符记录专用于所述云服务且提供执行所述应用所要的环境资源或服务的详情。将资源和服务要求转化成将在所述云服务环境中采取的动作以供应所述应用所要的所述资源或服务。所述将采取的动作被代理来基于在所述应用的所述描述符记录中所提供的详情而以预定义序列发生。提供所述采取的动作的状态。所述状态用来确定所述所要资源或服务是否已被供应来在所述云服务中成功地执行所述应用。

Description

用于在一个或多个云系统上便携部署应用的方法和系统

技术领域

本发明涉及使得能够有效地部署要求将服务和便携性供应给一个或多个云服务基础设施的应用的方法和系统。

背景技术

相关技术描述

计算行业的爆炸性增长已导致要求供应以使得能够在一个或多个环境(例如，云服务)中发动的应用的数量的上升。这些应用包括可以被设计用于不同硬件/软件平台的商业应用、社交媒体应用、游戏应用等。有时，最初被供应来在一个特定环境中发动的应用可能需要在不同环境中发动。为了使在另一或不同环境中成功地发动应用，将要求应用开发者识别/指定在每个环境中成功地执行应用和其它重新供应所要的必需的且最少的硬件、软件资源。

不幸地，非常常见的是设计原始发动要求的开发者/供应工程师可能不再为相同实体工作或可以确定最初指派的资源可能随时间推移而过期或被取代。因此，通常非常难以维持较旧应用和将应用迁移到可具有完全不同的资源、供应规则和其它操作要求的不同发动环境。

应用的迁移例如可以包括从具有第一资源集的一个云服务切换到具有不同于第一资源集的第二资源集的第二云服务。切换需要可以受成本、性能、使用、资源可用性等所驱使，且变化可以是使应用执行环境更划算同时使环境资源最优地且有效地使用所必需的。为了在新环境中成功地运行应用，必须进行诸多重组工程以确保在新环境内满足最低资源要求且资源/服务依赖性是恰当的并被明确地定义。通常，手动地实行应用环境的这些变化。不幸但非常常见的是，手动核对可以导致非期望结果和过多重组工程，因为除不划算外详情被忽视或遗失的概率更高。

在这个背景下，出现本发明的实施方案。

发明内容

本发明的实施方案提供一种允许在一个云服务/平台上或跨多个云服务/平台部署应用实例的多云部署机构。部署机构包括使用在应用中所提供的规范以在其中例示应用的云服务/平台中的任何一个中管理服务、资源和服务状态的工作流程。部署机构提供被应用开发者用来指定资源要求以在云服务的环境中成功地执行应用的框架，且部署机构将在所述环境中自动地供应必需资源/服务。为了完成供应必需资源/服务的任务，部署机构将确定将需要采取的动作、通过各自工作流程调度动作、监控动作、和提供采取的动作的日志以便确定是否已供应所要或足够的服务/资源和提供环境状态以成功地执行应用。

在一个实施方案中，框架可以提供一种使得部署工程师能够指定应用所需的资源而无须具体地识别和供应特定服务的描述符方法。在一种实施方式中，描述符方法可以按JSON描述符文档的形式。JSON描述符文档包括其中应用被设计来执行的每个环境的记录。JSON记录用来概述执行应用所需的所有服务和资源的细节，包括将需要在将执行的应用的环境内供应的云服务、网络、存储装置、处理器类型或任何其它种类的技术资源。接着，部署机构将要求转化成将需要采取的特定动作。在例示时，在转化中所识别的动作中的每个与被设计来供应所要资源或服务的工作流程相关联。因此，部署机构为共生服务的复杂的且可扩展的系统，所述共生服务通过集中消息代理彼此进行通信以得到信息和协调工作流程任务的复杂的且时间依赖的编排。部署机构包括用来提供可靠环境平台以托管应用的松散耦合的且分布式的服务组件和后端服务。部署机构提供在开发、测试、生产和维护应用(诸如游戏应用、娱乐应用、商业服务应用、互联网应用、网站分配等)期间供应、增添、配置、使用、监控、故障排解、扩展和关闭服务/资源的能力。

在一个实施方案中，提供一种方法。所述方法包括检测用于在云服务的环境中执行应用的请求。响应于请求，访问来自存储库的描述符文件。描述符文件包括针对在一个或多个云服务上执行的每个应用定义的一个或多个描述符记录。响应于请求，从描述符文件检索应用的描述符记录。描述符记录专用于云服务环境且提供在云服务上执行应用所要的环境资源或服务的详情。将在描述符记录中所定义的资源和服务要求转化成将需要在云服务环境中采取的一个或多个动作以供应服务和资源来执行应用。响应于请求，提供采取的动作的状态。状态用于确定所要资源和服务是否已被供应来在云服务中成功地执行应用。

在另一实施方案中，公开一种方法。所述方法包括接收在云系统上执行应用所要的一个或多个资源和一个或多个服务的属性。使用接收的属性生成应用的描述符记录。描述符记录定义专用于云系统的环境配置文件。通过将资源和服务要求转化成将需要采取的一个或多个动作以在云系统中供应所要资源和服务以成功地执行应用来生成描述符记录。将描述符记录存储在维持在部署系统数据库中的描述符文件中以在于云系统中后续地执行应用期间进行检索。检索造成触发在描述符记录中所识别的动作以在云系统上供应所要服务和资源以使得能够成功地执行应用。

从结合附图所作、通过举例说明本发明原理的下文详述，本发明的其它方面将变得显而易见。

附图说明

通过参考结合附图所作的下文描述，可以最好地了解本发明。

图1示出根据本发明的实施方案的其中提供部署机构的系统的概述图。

图1A示出根据本发明的实施方案的部署在云系统中的服务(即，应用)的使用周期。

图1B示出根据本发明的实施方案的部署机构的简化概述图。

图2示出根据本发明的不同实施方案的识别部署机构的各种核心服务模块和服务组件的服务架构。

图3示出根据本发明的实施方案的示例性发布环境视图。图3A示出根据本发明的实施方案的用于发布环境的示例性预览视窗屏幕演示。

图4示出在本发明的一个实施方案中的指定从环境历史页面内的特定工作流程执行的示例性工作流程步骤的日志(识别工作流程动作/活动)的示例性视图。

图5示出根据本发明的一个实施方案的示例性环境动作(工作流程执行)预览视窗。

图6示出根据本发明的实施方案的示例性环境动作(工作流程执行)状态视窗。

图7示出根据本发明的实施方案的演示环境历史概况的示例性屏幕。

图8示出根据本发明的实施方案的演示环境历史概况内的工作流程错误的示例性屏幕。

图9示出根据本发明的实施方案的演示环境历史中的请求者详情的示例性屏幕。

图10示出根据本发明的实施方案的用于执行应用的用户配置文件的示例性屏幕。

图11示出根据本发明的实施方案的个人请求访问部署机构的一般工作流程。

图12示出根据本发明的实施方案的如在部署机构中所提供的访问的级别之间的层级关系。

图13示出根据本发明的实施方案的部署系统环境描述符工作流程。

图14示出根据本发明的实施方案的捕捉应用服务状态的示例性屏幕演示。

图15示出根据本发明的实施方案的部署系统的示例性发布模型。

图16示出根据本发明的实施方案的进程流程图，其示出由部署机构所遵循的方法。

图17示出根据本发明的替代实施方案的进程流程图，其示出由部署机构所遵循的方法。

具体实施方式

本发明的实施方案提供一个或多个云部署机构，其允许在一个或多个云服务/平台中部署应用实例和自动地供应必需资源/服务以在部署的云服务/平台中成功地执行应用实例。部署机构为彼此进行通信且协调工作流程任务的复杂编排的可扩展共生服务系统。工作流程任务以有序时间或循序方式操作，因为部署机构框架追踪哪个任务已完成和哪个任务需要在其它任务之前处理以维持协调的且共生的执行。部署机构包括核心服务组件的集中集、后端服务集和服务层。核心服务组件被配置来与终端用户进行交互，以管理操作工作流程和协调核心服务组件与托管在环境内的环境资源之间的通信。核心服务组件被配置来供应资源(诸如服务器/处理器、存储器等)、配置服务/应用、部署软件、配置域名系统、自动扩展资源/服务、监控应用和资源状态、管理存储装置等。核心服务组件通过充当核心服务组件与后端服务之间的联络器的服务层与后端服务进行通信。分布式服务层提供抽象层以使核心服务组件可使用基于消息的通信相互操作且可容易随着技术进步而被取代。可扩展框架允许新技术包装在服务层内且整合到云服务中而不影响核心服务组件集。可扩展框架还允许终端用户基于随时间推移伴随的变化需要和/或技术进步更新现有服务，改变或移除旧服务和整合新服务。

在一个实施方案中，以JSON(JavaScript对象标注)的形式提供框架。用于定义要求的JSON描述符的使用是示例性的且不应被视为限制性，因为可以使用其它程序语言、或其它语法或文件形式或数据结构。描述符文件表示名称/值对的树结构且包括多个记录，其中描述符文件中的每个记录指定用于在特定云服务或服务器计算系统的环境中执行应用的服务/资源要求。每个记录例如指定需要被供应以便在特定环境中执行应用的存储装置、网络、处理资源、云服务和其它种类的技术资源要求。

图1示出在一个实施方案中的用来将应用部署到云服务的特定环境上的部署机构的简化概述图。在这个实施方案中，开发应用110的应用开发者可通过应用编程界面(API)访问部署机构以指定成功地执行应用110所要的资源/服务。部署机构在图1中表示为云生态系统(ECO)核心模块120且用来访问ECO的API表示为ECOAPI。部署机构120允许开发者描述在其中将执行应用110的环境122。例如，部署机构可以提供工具(诸如通过图形用户界面或命令行界面访问的API)，以允许开发者指定在环境中所要的最少资源和/或服务使得可执行应用110。前述工具是示例性的且不应被视为详尽性的。其它工具或方式可以被提供来使得开发者能够指定用于执行他/她已开发的应用的环境。由开发者指定的环境描述122提供为更新到描述符文件124(诸如JSON描述符文件)的描述符记录。在替代实施方案中，开发者可以将应用代码提供给部署机构120。部署机构120可以分析应用代码以确定在特定环境中成功地执行应用所要的资源/服务。资源/服务要求信息用来定义更新到描述符文件且在执行应用期间用于在特定环境中供应服务/资源的描述符记录。

顾名思义，JSON(JavaScript在线标注)描述符使用JavaScript脚本语言来定义以属性名称-值对的形式的数据对象，且用来传输应用与服务组件之间的数据。应明白，JSON为另一示例性代码语言且只要提供功能，就可以使用其它语言。在这个实例中，JSON描述符124采取由开发者提供的规范或由机构识别的要求，并生成将服务/资源要求(即，属性名称-值对中的属性名称)映射到需要被执行来针对云服务的每个环境(在其上应用被托管来执行)供应必需服务/资源(即，属性名称-值对的值)的动作的记录(例如，描述符或ECO记录126)。描述符记录与应用实例相关联使得在以后需要在环境中执行应用时，可以快速地识别应用的正确描述符记录且适当资源和服务被提供来在环境中成功地执行应用实例。在一个实施方案中，生成的记录126中的每个例如识别在各自环境中成功地执行应用所要的最少资源/服务，诸如数据库/存储装置124a、处理器124b、网络124c、密钥管理124d、其它资源124e、其它服务124f等。使用在ECO描述符记录(即，描述符记录)中所提供的信息，ECO核心(即，部署机构)识别需要被采取来供应服务/资源的必需动作128。针对在ECO描述符记录中所识别的每个动作例示工作流程128a使得在各自环境中供应必需服务和资源。识别的动作可以包括需要在执行应用实例之前采取的动作、需要在执行应用实例期间采取的动作和需要在完成应用实例之后采取的动作。因此，动作可以包括供应所要资源、检查供应的资源的资源依赖性、迁移一个或多个资源或服务、停止服务、例示应用和/或资源/服务、核对应用的成功完成、检查错误日志以确定是否成功地执行应用等。

一旦识别工作流程128a，那么通过工作流程服务工作者进程集执行工作流程128a以允许工作流程采取在适当云服务130中供应资源/服务的必需动作、例示应用、生成关于服务/资源的采取/未采取的动作的状态的日志和传回采取/未采取的动作的状态。动作状态可以用于将应用执行更新提供给开发者。其中资源/服务被提供来执行应用的云服务环境可以是私人或公共的可用云服务/环境。

基于在映射到应用的一个或多个资源/服务处所检测到的变化周期性地更新ECO记录。例如，在一个实施方案中，可以移除旧资源和添加新资源，可以归因于故障、例行维护等对资源进行移除、改变、取代和/或升级，且ECO核心允许在背景中进行无缝资源转变，使得执行应用而没有显著的停机时间。在一个实施方案中，在移除旧资源和添加新资源时，ECO核心自动地编排数据从旧资源到新资源的迁移且在特定环境中更新应用的ECO记录以反映变化。在替代实例中，现有资源可以升级为例行维护的部分。例如，额外存储装置可以添加到现有存储资源提供者。在这个实施方案中，可以在背景中无缝地执行升级而不影响在服务器或云服务上执行的应用的性能，且归因于升级的资源变化可以实质上实时地更新到ECO记录。在一个实施方案中，一个或多个资源的升级可以是暂时升级且可以被完成来允许最优地执行应用。在这个实施方案中，ECO记录可以不被更新来反映归因于升级的变化。在替代实施方案中，资源升级可以是永久性的且这个升级信息可以更新到ECO记录。相似地，在服务升级时，ECO记录可以被更新来包括升级信息。部署机构内的服务层提供采取核心服务/资源要求并将其映射到可在云服务内使用的实际服务/资源的抽象层。

在另一实施方案中，应用可以从一个云服务迁移到不同云服务。可以基于应用所期望的性能的类型执行这个迁移。例如，可以由ECO核心基于资源可用性自动地开始迁移以便降低成本，增大性能等。在一些实施方案中，可以针对应用定义预定义规则集，且迁移服务和/或资源的决定可以基于预定义规则自动进行。可以由开发者定义预定义规则，且由开发者或由部署机构基于在环境中检测到的变化周期性地更新预定义规则。例如，预定义规则中的一个可以指示基于成本选择环境和/或资源/服务。在另一实例中，预定义规则可以指示基于性能选择环境和/或资源/服务。在两个实例中，ECO核心可以周期性地(a)收集并分析从在云中被供应来基于预定义规则执行应用实例的各种资源接收的数据；(b)确定应用的资源或性能的价格；(c)生成各种资源/环境的配置文件；和(d)确定何时在相同云服务上或不同云服务上将资源中的特定者迁移到不同资源，何时将应用从一个云服务迁移到另一云服务，何时继续结合现有资源，何时继续使用现有云服务等。基于分析和确定，ECO核心可以继续结合云服务和云服务的现有资源/服务或可以执行应用从旧云服务到新云服务的迁移。迁移包括识别需要在新云服务中供应的资源/服务，触发适当工作流程以在新云服务中供应资源/服务，和例示应用以使用新云服务中供应的服务/资源。迁移可能需要将应用实例重新映射在ECO记录内以反映一个或多个资源/服务的变化或云服务的变化。

在一个实施方案中，预定义规则可以基于以下项指示开始迁移：应用的时间和/或地理需求；资源可用性；或在不同地理位置处在不同时段资源的历史使用的预测分析。在应用的元数据中所提供的历史使用数据被检验来确定在不同时段期间和在不同地理位置中资源的使用模式，识别在不同时段期间在不同地理位置中应用的需求，确定在不同时段的资源/服务可用性、可用资源/服务的成本、满足需求的资源/服务的容量、针对如由预定义规则定义的应用预期的性能的类型(即，基于成本、基于性能、基于资源最优性等)等。基于检验，作出保持现有环境或迁移到不同环境的决定。

继续参考图1，用于供应资源和服务以执行应用的工作流程可以部署到在其中应用被部署来执行的私人或公共云中的任何一个(130-a到130-n)。在应用迁移到新云服务时，在新云服务中识别并部署对应工作流程。在一个实施方案中，应用迁移将导致对新云服务提供新应用实例且生成将新应用实例映射到与迁移的云服务相关联的资源/服务的新ECO记录。在这个实施方案中，原始ECO记录可以继续映射到与旧云服务相关联的资源/服务使得如果应用被选择来在旧云服务中执行，那么现有应用实例可以执行并使用供应给且映射到旧云服务上的应用实例的资源/服务。在替代实施方案中，重新映射可以导致更新现有ECO记录以将应用实例映射到新云服务的资源/服务而非来自旧云服务的资源/服务，使得在任何时候执行应用时将在新云服务上使用新云服务的资源/服务执行重新映射。

图1A示出在一个实施方案中的被部署来在选定环境中执行的应用110的示例性使用周期。作为部署的部分，可以使用命令行界面132或图形用户界面134以通过API(诸如ECOAPI131)访问JSON描述符文件124。JSON描述符文件124可以维持在环境数据库中且由ECO核心120管理。JSON描述符文件识别针对应用定义的每个服务环境(130-a到130-n)的服务描述符记录(126-1到126-n)。例如，如图1A中所示，服务描述符记录1(126-1)概述云服务1(130-a)的资源/服务要求，服务描述符记录2(126-2)专用于云服务2(130-b)，以此类推。在JSON描述符文件124中所指定的一个或多个服务描述符记录可以用于在不同云服务上执行的相同应用。服务描述符记录指定需要被委任来成功地执行应用的各种资源/服务的最低要求。应用可以是商业应用、视频游戏应用、社交媒体应用等。ECO机构提供允许应用代码接收到系统中的框架、被生成用于各种环境的应用的可执行实例、执行应用所要的所供应资源/服务、被识别并部署用于特定环境的应用的适当实例和部署结果，包括应用状态和供应的资源/服务的状态、汇报。

在一个实施方案中，应用的开发者可以将应用代码提供给ECO机构。ECO机构内的逻辑可以分析应用代码以识别在每个环境中执行游戏实例所需的资源。ECO机构可以将所要资源信息更新到JSON描述符文件上并对开发者呈现信息进行核对和/或更新。开发者可以编辑JSON描述符文件以更新所要资源/服务。在替代实施方案中，由开发者更新JSON描述符文件中的所有资源信息。

在应用被部署来供特定云服务执行时，ECO核心识别与特定云服务相关联的应用的适当描述符记录且分析识别的服务描述符记录以确定需要执行的动作，并对终端用户呈现所述服务描述符记录进行查看。在用户批准/接受/核对之后，ECO核心开始用于在云服务中供应所要资源以成功地发动应用的适当工作流程。记载采取或未采取的动作的结果，且生成提供动作状态的周期性报告。基于各种动作状态，ECO核心可以委任额外资源，对一个或多个供应的资源升级，迁移一个或多个资源等。ECO机构有效地管理整个应用的使用周期，包括使应用加速(如果有需要的话)。

图1B示出部署机构的简化方框图。如先前所述，部署机构包括在云服务上所要的核心服务组件集、可用后端服务和资源、和充当核心服务组件要求与可用后端服务之间的联络器的服务层。服务层提供抽象层以使核心服务组件可进一步相互操作且又可取代。具体来说，服务层包括用来提取要求、解译要求、映射到可用服务和资源、和连接到服务和资源的逻辑组件。为此目的，ECO服务层内的提取器组件识别由被调度来在特定云服务上执行的应用针对特定云服务定义的云服务要求规范124a。云服务要求规范124a提供在描述符文件内的描述符记录中。要求规范可通过应用的开发者手动地上传到维持在ECO机构中的描述符记录。描述符记录中的规范124a被检验来确定哪些特定资源和服务需要用于执行应用。在一些实施方案中，可以非常具体地定义要求(例如，特定品牌或特定容量的SDRAM存储器的量等)且在一些其它实施方案中，可以按更一般方式定义要求(例如，定义所要的最低存储器要求等)。

使用由提取器组件120a提供的信息，ECO服务层内的映射器组件120b可以检验可用后端服务和资源以识别满足应用要求的服务和资源中的特定者。一旦识别服务和资源中的特定者，那么ECO服务层内的连接器组件120c将识别的服务和资源映射到应用。在一个实施方案中，映射包括确定需要被执行来进行以下操作的动作：供应识别的服务和资源以成功地执行应用；识别用于执行这些动作的适当工作流程；和将识别的工作流程映射到应用使得在将执行应用实例时，触发映射的工作流程且供应适当服务和资源用于应用。

在初始供应之后，ECO服务层内的映射器组件可以继续监控可用于客户端服务的资源和服务以确定在客户端服务中指派的资源和/或服务是否存在因添加、删除、升级、改变等造成的变化。基于监控，额外工作流程可能需要被例示来适应变化。这可以包括例如运行一个或多个工作流程以停止服务、删除资源、添加新资源等。映射器组件可以针对应用更新工作流程映射以包括额外工作流程。

因此，ECO服务层通过转化针对应用定义的要求规范并将其映射到用于供应特定资源和服务的工作流程来提供转化服务。在一些实施方案中，转化服务可以识别并映射到供应在描述符记录中所指定的确切资源/服务的工作流程，且在其它实施方案中，转化服务可以映射到供应等效于但兼容于在规范中所要的资源/服务的资源/服务的工作流程，因此在将规范要求映射到实际服务/资源中提供一种层次的抽象。

图2示出部署机构的服务架构的简化方框图。部署机构为完整的多云托管管理解决方案。在部署机构中央为共生服务的复杂的且可扩展的系统，所述共生服务通过集中消息代理彼此进行通信以交换信息和协调工作流程任务的复杂编排以执行部署在云服务上的应用。部署机构内的核心服务组件的集中集负责与终端用户进行交互，管理操作工作流程和协调使用部署机构托管的服务、应用与环境之间的通信。现将参考图2中所示的示例性组件详细地描述部署机构内的服务组件中的一些的功能。本文中应注意，图2中所示的组件是示例性的且更少或更多数量的组件可包括在核心服务架构内。由于服务要求随时间推移而变化，所以可以弃用组件中的一些且可以添加新组件以使得能够供应由应用的服务要求定义的必需服务/资源。核心服务架构提供这个灵活性以容易地且动态地适于这些变化的服务要求。

代理管理服务2.2通过对应API提供用来进行消息传递代理管理的消息传递界面。

消息传递代理2.1充当通信集线器，在ECO系统中所提供的部署机构的不同模块/组件通过其而彼此进行通信以进行以下操作：传输服务请求；供应服务；更新描述符记录；配置服务/资源；例示应用；识别动作；例示工作流程；接收状态信息和在定义的环境(即，云服务基础设施)中成功地执行应用所要的其它操作。消息传递代理2.1例如可以促进不同组件与工作流程服务2.14之间的交互，所述工作流程服务2.14包括用来基于应用要求和服务/资源共生性智能地预测不同任务的序列的逻辑。消息传递代理2.1有效地允许关于不同供应的资源/服务的消息的交换以便搜集涉及供应的资源/服务的信息和对应性能状态信息，其接着用来确定供应的资源/服务是否满足针对应用定义的所要性能准则。为此目的，消息传递代理2.1可以促进监控服务2.20与供应服务2.9周期性地交换消息，以请求并获得涉及对应用供应以确定是否以最优方式执行资源/服务的各种资源/服务的信息。

消息传递代理2.1例如提供用于以下装置协调与彼此进行的消息交换的管道：基础设施管理服务2.28；配置管理服务2.17；环境服务2.7；计帐服务2.19；供应服务2.9；监控服务2.20；Sensu^TM组件2.30等。在一个实施方案中，Sensu^TM组件2.30可以监控用于应用的资源和/或服务的所有实例的健康状况，且如果达到任何预定义阈值，那么将生成用来向ECO机构通知采取适当动作的信号。接着，ECO系统将执行预定义规则集以确定资源/服务的实例是否需要被取代(例如，作为自动愈合的部分)，或是放大还是缩小(例如，作为自动扩展的部分)。因此，可以交换消息以获得涉及不同云服务环境中的可用资源/服务和其成本和/或性能的信息，以便确定更划算和/或更具性能效率的等效资源/服务是否可用于所期望云服务环境。这个信息可以用来实现资源/服务切换(如果有需要的话)，以对应用执行提供最优环境。通过消息传递代理促进的与各种服务模块(诸如监控服务模块2.20、供应服务模块2.9等)的消息交换可以用来确定供应的服务/资源是否足以使得能够在云服务环境中最优地执行应用或是否需要供应额外/替代资源/服务以允许应用的最优执行。在一些实施方案中，基于涉及资源和/或服务的性能的信息，消息传递代理2.1可以协调基础设施管理服务2.28、代理管理服务2.2、环境服务2.7之间的消息交换，以使得能够动态地切换/供应相关资源/服务以最优化应用的执行。可以在执行应用之前、在执行应用期间和/或在已完成执行应用之后完成这个状态检查和切换，同时供应资源/服务。在一些实施方案中，可以因在环境内供应的资源/服务中检测到的变化造成切换。可以因现有资源/服务的升级、供应的资源/服务的移除、具有改善性能的更新的进一步兼容资源/服务的添加等造成变化。当在环境中检测到这些变化时，对应服务模块可以生成适当信号并以消息的形式将所述信号传输到消息传递代理2.1，且消息传递代理2.1将这些信号引导到相关服务模组以允许相关服务模组采取预动步骤来解决可以因变化造成的任何潜在问题和/或资源/服务差异。在一个实施方案中，通过来自消息传递代理的适当资源/服务获取/拉取消息。在其它实施方案中，消息传递代理将消息递送到被订阅来接收消息的适当资源/服务。拉取/递送的消息包括由ECO系统的各种组件提供的数据且包括涉及将供应的服务/资源的信息。

在一个实施方案中，由监控和工作流程服务组件提供的自动扩展或自动愈合功能可以结合规则集供应服务或资源。可以通过用户经由描述符记录管理规则。可以根据自动愈合或自动扩展功能以基于来自消息传递代理(有时以重复方式)评估规则。在评估期间，在规则与适当准则匹配时，可以执行选定工作流程。

规则集对用户提供将商业逻辑直接建置到用户期望执行应用的环境中的能力。规则引擎提供尤其在需要修改/取代组件时在与采取动作的工作流程操作分离的服务中检测和发信号的能力。在一些实施方案中，消息传递代理2.1可以将涉及需要修改/取代的组件的消息发送到监控服务逻辑2.20。监控服务逻辑2.20包括从ECO系统的消息传递代理接收消息传递事件的多种方法，且逻辑地确定需要采取的适当动作并将适当消息发出到工作流程服务模块2.14以实施所述动作。采取的动作可以是不同类型，包括进程动作类型和状态动作类型。一些示例性进程动作类型包括诸如创建、读取、更新、删除(CRUD)动作的动作。本文中所列的动作类型是示例性的且不应被视为详尽性。还可以根据规则考虑其它动作类型。可以分析对采取的动作的响应/状态并将其解译成可以引导到ECO系统内的不同组件的消息。消息传递代理从工作流程服务2.14接收这些消息且根据在引擎中所指定的规则作出关于何处、何时和如何发送消息进行进一步处理的决定。

除由监控服务2.20提供的标准监控外，还可以结合增强型监控服务。与Sensu^TM组件2.30协调的监控服务可以被配置来生成旨在创建/编辑/删除一些对象/测试/阈值/警报的消息，且包括接收指示警报识别符和阈值事件的信号。监控服务可以与标准监控服务2.20整合在一起，以允许ECO系统管理对其环境的监控且以编程方式响应于监控事件(诸如阈值)。

在一个实施方案中，监控服务提供在自动扩展和自动愈合工作流程中将监控机构用作“检测”机构的能力。在另一实施方案中，ECO系统使用用于供应共同应用有关监控对象的脚本。监控服务被配置来移除对ECO系统的依赖性且取代以自然ECO功能嵌入脚本中的逻辑/规则集，使得可以统一地实施使用多个监控服务的监控。监控服务还标准化ECO供应任何当前或未来服务/管理其监控的方式，从而使增强型监控更易预测且可更适于变化。

用来提供自动愈合/自动扩展功能的组件中的一个为负载平衡器服务组件。可以编程方式控制这个ECO支持负载平衡器。可以通过与应用相关联的描述符记录参考单独负载平衡器(LB)记录，且可以对用户提供适当用户界面以填入必需参数以在云中供应/管理基于软件的负载平衡器。LB记录可以识别多个组件，包括通过ECO系统的工作流程和规则引擎编排的负载平衡器组件、API等。通过添加负载平衡器作为描述符记录中的服务类型，可以由用户直接管理诸多配置点。通过允许负载平衡器组件的API控制，ECO系统可例示基于编程事件使应用栈扩展和愈合的简单的且高级的工作流程。为了允许高级配置便于重用，可以使用模板来描述目标负载平衡器所附的显式配置文件。此外，负载平衡器服务组件被配置来将状态信号发送到内部监控服务和外部监控服务两者。

在一些实施方案中，工作流程服务2.14可以结合服务以通过管理所有现有公共域的内部应用栈和DNS记录来管理用于ECO系统的域名系统(DNS)资源。

在一些实施方案中，自动愈合和自动扩展有关模块可以结合工作流程服务2.14以在执行应用期间对于特定地理位置和/或在不同时间追踪资源/服务的使用模式，且使用从使用模式收集的信息来对于地理位置或特定时段智能地预测应用的需求。基于预测，自动愈合/自动扩展有关模块可以结合供应服务2.9以代理适当资源/服务以使其划算和/或具性能效率，且及时供应其用于服务后续请求以在环境中执行应用。在一些实施方案中，自动愈合/自动扩展有关模块甚至可以代理来自不同于现有环境的环境的适当资源/服务来征用所要资源/服务以使得能够成功地执行应用。在一些实施方案中，一旦识别所要资源和/或服务，自动愈合/自动扩展有关模块连同供应服务2.9和工作流程服务2.14可以确定可以关于成功地执行应用所要的不同资源和/或服务存在的任何共生性，且定义用于供应所要资源/服务的序列。消息传递代理2.1在ECO环境的集中集线器中充当流量控制器，以控制往返ECO系统内的不同服务模块的消息以便履行不同资源/服务请求和需要，且开始所要序列的工作流程以服务请求。应注意，在各种组件/服务之间通过ECO系统的消息传递代理2.1交换的消息可以包括涉及状态、标记(包括成功标记和失败标记)、评注、错误、请求和供应用于成功地执行应用的服务/资源所要的其它相关信息的数据。

命令行界面(CLI)2.3和图形用户界面(GUI)2.4提供到ECOAPI2.5的替代前端用户界面以允许终端用户交互。ECOAPI2.5为将超文本传送协议(HTTP)请求转化成适当消息以作出服务操作请求的服务，且这些消息可以遵循关于格式和传输的特定协议。CLI2.3通过ECOAPI2.5、消息传递代理2.1动态地查询服务目录2.11，且基于哪些服务操作可用建置其命令。GUI2.4基本上为进行以下操作的图形编辑器：与ECOAPI2.5进行交互，显示不同环境描述符字段，和通过允许终端用户定义每个现有环境描述符字段的元数据值而允许终端用户管理环境描述符，以添加新字段且支持工作流程服务脚本。

数据字典服务2.6管理描述在环境描述符内所使用的各种字段的元数据。数据字典服务2.6的目的中的一个为支持图形用户界面2.4中的环境描述符字段的动态显示且允许终端用户定义每个字段的元数据和添加新字段。元数据定义在GUI中如何显示、验证和改变字段并且定义初始默认数据的来源、转化字段标签。

ECOAPI2.5提供用于代理对由ECO机构(即，ECO服务)支持的服务的HTTP(超文本传送协议-包括私有协议和非私有协议)请求的界面。其基本目的为采取请求URL和将每个请求转化成用于指定服务操作的适当消息传递请求。通过应用某些商业逻辑和以消息响应的形式传回HTTP响应来执行每次请求转化。允许终端用户经由CLI2.3或GUI2.4以使用ECOAPI2.5查询服务目录2.11以查看哪些服务可用、支持哪些操作、可使用哪些参数、和预期终端用户可传回哪些信息。

终端用户与GUI或CLI进行交互以将请求提交给ECOAPI2.5。ECOAPI2.5转化这些请求且结合ECO消息传递代理2.1以将请求转递到各自ECO服务/资源。在一个实施方案中，服务可以包括云服务或在云服务内所提供的任何其它服务。在一个实施方案中，ECOAPI的消息传递代理2.1具有能够了解由不同云服务使用的多种不同“语言”(API)的内建逻辑，且适当地转化旨在特定目标云服务的请求。因此，ECOAPI允许终端用户通过结合充当转化器和管理者以允许与多个服务进行交互的消息传递代理2.1来管理使用单一API的不同服务。例如，如果在ECOAPI处接收涉及单一云服务的请求，那么ECO内的供应服务2.9将仅把请求转换成目标云服务将能够解译的API请求。接着，供应服务2.9将转化的API请求传输到适当目标云服务进行处理。如果请求更复杂且要求多个云服务之间的协调，那么工作流程服务2.14将应用商业逻辑以确切地确定需要采取哪些步骤和以什么次序进行步骤且结合不同服务/资源以根据在应用的商业逻辑中所定义的次序实施步骤。

工作流程服务2.14存储预定义规则集和工作流程信息且能够将复杂请求分成必须以特定次序采取的详细步骤。例如，请求可以是简单的“使第二生产环境旋转加速”请求。尽管请求可能似乎为简单请求，但可能要求多个小步骤来使这个请求发生。例如，给出生产环境可以由多个机器(包括虚拟机)组成。作为简单实例，生产环境可以具有10个虚拟机。工作流程服务2.14内的商业逻辑可以将请求分成更小请求且建立实行请求需要遵循的序列。在这个实例中，请求分成10个单独请求(其中每个请求在生产环境内供应不同虚拟机)，接着分成10个单独的额外请求(其中每个额外请求在每个虚拟机上部署正确软件)。

环境服务2.7用来创建并更新环境定义(也称为“环境描述符”)且实施商业逻辑以在管理环境数据时维持一致性和版本控制。版本控制在数据(环境数据和其它数据)保存和还原期间特别有帮助。环境描述符数据包括用来识别环境、环境试运行的云租户、结合的机器和服务的数量、结合的每个机器的配置数据等的必需信息。环境数据信息存储和/或备份到数据库。

身份管理服务2.8对于来自部署机构内的每个服务管理用户、角色和组织有关信息。这是在系统内保护具有授权权限和访问级别的适当用户对服务操作、应用和其环境的访问权的治理的基础。

供应服务2.9提供到不同云服务提供者以及不同后端基础设施服务的前端服务层。供应服务2.9提供用于创建来自多个云的虚拟机的统一界面。在一个实施方案中，DNS服务2.10a和开栈API2.10b为供应服务2.9的部分。在这个实施方案中，供应服务2.9用来提供到一个或多个云服务提供者的前端服务层，DNS服务API2.10a和开栈API2.10b提供用来对后端基础设施服务进行重定向的界面。DNS服务2.10a用来将DNS主机名称指派给在ECO系统中所托管的环境且管理多个系统内的所有DNS修改需要。

服务目录2.11在请求时提供可用ECO服务的动态索引。服务目录2.11的目的为有效地提供服务寄存器，且可以编程方式显示可用于调用到ECO服务定向架构(SOA)内的其它服务的服务以及其结合方法。CLI2.3查询服务目录2.11以确定哪些服务和操作可用于用户且服务目录响应于查询，传回服务连同其服务操作、选项和其它详情。当在ECO架构内实施服务时，将服务中的每个寄存在服务目录2.11中使得可发现所述服务并响应于从CLI2.3接收的任何请求，传回所述服务。

租户消息传递服务2.12提供通过由ECO管理的主机查询、传达和执行的功能。这些主机可为最初通过ECO系统提供在云中的机器，或已进入ECO系统中的现有基于云的或物理的机器。

交易记载服务2.13用来记载在ECO系统内的ECO之间发生的所有交易且主机通常因为运行异步工作流程而管理其。

工作流程服务2.14提供针对由从CLI/GUI接收的请求定义的特定动作编排任务集(诸如下载软件，配置软件，启动软件，部署服务等)的功能。工作流程服务2.14包括可引起作业工作者从其同时管理作业的多个工作者队列。在通过ECOAPI2.5开始时，工作流程服务2.14可从环境服务2.7检索环境数据且通过租户消息传递服务2.12发出命令/动作以在由ECO管理的主机上执行所要动作(例如，复制环境、供应服务器、开始/停止服务、部署服务等)。当然，可以通过消息传递代理2.1将命令/动作从工作流程服务2.14传输到租户消息传递服务2.12。将所得信息(诸如状态、软件和版本、IP地址等)传达回到环境服务2.7以用正确值(如果有的话)更新环境配置数据。作为运行工作流程的部分，工作流程服务2.14进行的最后一个步骤为更新环境配置数据以匹配当前发布的版本，因为发布的版本将因供应和服务启动而变化。

在一个实施方案中，工作流程服务2.14可以通过内部ECO服务门面联系ECO机构外的服务(诸如云服务)并与其进行通信以根据需要使用来自所述服务的资源。例如，这个特征允许创建可从ECO机构内控制的混合托管解决方案。在这个实例中，可以从第一云服务利用计算资源，同时可以从第二云服务利用存储装置等。在另一实例中，这个特征协助支持突发使用案例，其中在重负载下，对于额外资源，由ECO在一个云提供者(或云服务)中所供应的环境可突发到另一云提供者上达处置更重负载所需的暂时时段，且接着在负载回降到名义水平时释放所述资源。

工作流程服务2.14提供用来执行开始动作的命令的工作流程语法。随着应用配置脚本保留执行这些命令所要的多数编程，工作流程服务2.14根据需要提供允许应用控制自身配置和定义自定义工作流程的最终目的。

分布式修订版控制和源代码存储库2.16用作用于终端用户应用配置管理(ACM)脚本连同用来执行脚本的核心服务集和框架的源代码管理系统。

租户消息传递服务2.12提供用于在管理的主机服务器上执行平行作业执行系统的框架。框架使用用于在服务器群集上执行动作的分布式、基于代理人的架构。在一个实施方案中，客户端内的命令结构与底层输送机构分离。可由输送机构利用由客户端使用的消息传递协议。

客户端2.15从租户消息传递服务2.12接收命令集(通过消息传递代理2.1)以执行一个或多个命令且作为响应，将消息发送到远程主机服务器，每个主机服务器包括ECO代理人2.15a。命令可以涉及复制环境、开始/停止服务、部署服务等。尽管单一参考数字2.15a用来识别不同主机服务器(诸如游戏服务服务器、网络服务VM服务器、“NiceJob”VM服务器等)中的ECO代理人，但应了解，部署在不同服务器上的客户端代理人2.15a可以专用于各自服务器。ECO代理人负责在各自服务器内进行所有本地工作，而工作流程服务用于跨所有服务器/客户端服务编排任务和跨本地主机协调动作。客户端代理人2.15a听取来自租户消息传递服务2.12的命令，执行一个或多个动作，且接着在任务/动作完成时进行汇报。

消息传递代理2.1为使得能够在各种ECO服务之间通过发送和接收数据作为二进制消息进行通信的消息传递协议的实施方式。消息可以一对一或一对多且支持在消息负载内使用不同协议以在系统组件之间进行通信。在服务定向架构(SOA)的核心处使用消息传递允许系统松散耦合且随时间推移而扩展，但具有系统的其余部分所要的最小变化。

消息传递协议使得客户端应用能够与消息传递中介软件代理进行通信以请求来自服务提供者应用的服务。其还允许服务服务于通信且允许发布事件消息进行异步处理。消息传递代理2.1(对于例如生产方应用)从发布用来请求服务的消息的应用接收消息，并(例如对于消费者应用)将其路由到消费这些消息且提供所述服务的服务应用。在一个实施方案中，消息传递代理2.1将消息递送到对队列订阅的消费者。在替代实施方案中，消息传递代理2.1允许消费者从队列按需地获取/拉取消息。

消息传递协议提供建有交换机的抽象层，使得可单独地路由消息。消息发布到交换机。基于在消息标头中所包括的路由模式，消息从交换机路由到各种队列。队列存储由应用消费的消息。以此方式，交换机充当邮局且队列充当邮箱。服务工作者跨队列分布以接收消息且可按需地放大或缩小。队列备份到磁盘且用于灾难恢复。例如，在灾难案例中，用户可在系统还原时离开之处继续操作。消息递送知识还帮助防止消息故障。

单独服务交换机(未示出)和事件交换机(未示出)用于分离消息传递与对安全性和流量整形的考虑。不同交换机可以容易地被管理来处置负载平衡、最优化性能、改善延时、和增大可用带宽。服务交换机为客户端发送意在用于ECO服务的其服务请求消息之处。在一个实施方案中，交换机定义为由代理维持和管理的队列的逻辑分组。服务交换机为服务操作请求消息的分组，且事件交换机为目标为发送到系统内的各种组件的异步信号的分组。

环境特定交换机提供安全性和应用环境隔离。这确保正确消息路由到构成环境的主机的正确集。用户可相似地隔离可能包括敏感环境数据的用户消息所通往之处且防止其它环境听取这些消息。

数据库2.25提供数据存储的非SQL解决方案，其中以本质上为密钥值对集合的文档对象(似JSON的区块)的形式管理环境数据。在一个实施方案中，数据库2.25被配置来存储涉及在其中应用被设计来执行的不同环境的数据。在一个实施方案中，其目的为收集并存储来自交易记载服务2.13、工作流程服务2.14和环境服务2.7的数据。涉及环境和应用的其它信息还可以存储在数据库2.25中。

外部数据服务2.26为与其它系统进行通信以交换数据(诸如来自主产品管理系统(未示出)的标题信息)的服务组件。在一个实施方案中，外部数据服务2.26将随着根据需要与其它系统交换数据而生长。

数据库服务2.27提供数据库作为允许应用管理自身数据库的服务功能。相似地，监控服务2.20将通过与负责监控由ECO管理的主机系统的外部系统(如同Traverse^TM2.29和Sensu^TM2.30)整合来提供监控作为服务功能。Sensu^TM2.30为监控服务2.20的部分，且包括被配置来使用“检查”脚本监控应用执行和系统服务、以不同格式收集度量和以不同格式发送不同事件(包括服务失败)的通知的路由代理人和介质。监控路由代理人内的API提供对各种事件和代理人有关数据的访问权，以便检查执行和跨各种系统服务解决事件。在由ECO系统内的Sensu^TM提供的功能逻辑内包装额外逻辑和商业规则以便提供和管理自动愈合和自动扩展功能。

部署机构的核心服务组件通过ECO门面服务层与后端服务进行通信。门面服务充当核心服务与后端服务之间的联络器，且提供抽象层以允许后端服务可相互操作、可取代，且可根据需要对ECO系统提供ECO特定商业逻辑。门面服务整合在部署机构(也称为“ECO核心”)内且响应于相同于其它ECO核心服务的类型的基于消息的服务请求。如前文所提及，可扩展框架允许新技术通过门面服务抽象化并整合到云ECO系统中而不影响ECO服务的核心集。在部署机构中所提供的服务中的一些包含电子邮件服务2.18、计帐服务2.19、监控服务2.20、存储服务2.21、配置管理服务2.17等。

出于消息传递目的，电子邮件服务2.18用来插入到现有电子邮件基础设施中。

计帐服务2.19运行将用来捕捉现有计帐系统2.24的环境资源使用的现场计帐馈送，包括示例性开机时间、处理器使用、存储器使用等。计帐服务2.19包括用于检索使用数据的收集代理人和用于将使用数据发送到现有计帐系统的计帐API。

计帐服务代理人以定期调度的间隔发送消息以查询使用数据。随着接收使用数据，将使用数据发送到专业数据库(未示出)。接着，将使用数据从专业数据库拉取到操作数据存储区(未示出)。由此，ETL(提取、变换和加载)进程将数据拉取到数据仓库中进行计帐和报告。

在一个实施方案中，计帐服务2.19可以被ECO机构用来比较服务成本，生成性能和成本度量，追踪每个资源的成本，和改变各种服务的传动或浮动进行成本最优化。服务浮动包括从一个服务环境迁移到其它服务环境中的一个或多个以最优地执行应用。为了追踪成本和完成成本最优化，ECO系统可以周期性地收集并分析各种计帐和计量数据，且在一个实施方案中可以查询并接收来自不同云服务的反馈以确定资源成本，且在后端中自动地确定应用的环境配置文件。应用的环境配置文件可以分类为昂贵配置文件、廉价配置文件、平价配置文件等。基于环境配置文件且基于预定义规则集(对于例如与性能、成本、资源使用等相关联的规则)，ECO系统可以确定使用哪个(哪些)服务来获得成本和性能最优化。

监控服务2.20将用来监控在托管在部署机构平台中的环境中运行的服务的健康状况和性能作为集中关于相关于服务栈监控的警报、升级和通信的信息的方式。例如，监控服务2.20可以监控服务的健康状况且在特定地理位置处或在特定时段(例如，每天、每周等)检测环境内的应用的流量的尖峰。基于监控，ECO系统可以确定单一应用实例可能不足以处置流量，且可以智能地添加一个或多个额外应用实例以处置流量。ECO系统可以从监控服务2.20接收消息且响应于接收的消息，可以通过例示额外应用实例、将这些应用实例添加到描述符文件和映射所要资源以最优地执行应用来执行这个操作。提供额外应用实例为一种最优化应用性能的方式。最优化应用性能的其它方式可以是在将使用的应用的环境内提供额外资源，对资源升级，改变资源，迁移资源等。在一个实施方案中，在组织层处完成监控。在另一实施方案中，在应用层处完成监控。监控服务2.20基于在环境描述符中所提供的信息建置动态文档，且将所述信息馈送到资源管理模块以便供应/解除供应监控规则、警报等。换句话来说，来自监控服务2.20的数据被ECO系统用来有效地管理整个应用/服务的使用周期，包括使应用/服务加速(如果有需要的话)。ECO系统通过应用/服务的连续监控和应用/服务的有效资源管理来完成这个操作。

配置管理系统(CMS)服务2.17用于基于集中规范自动化管理任务和配置管理，且对由ECO核心定标的主机具体地管理操作系统和应用前提。CMS实施为执行可由某些核心用户组编辑和利用的基于策略的配置管理的方式，诸如信息技术和信息安全人员。在一个实施方案中，CMS使用一系列层级密钥清单来将指令递送到个别主机。在一个实施方案中，CMS整合到私人云中，诸如开栈私人云。

在一个实施方案中，存储服务2.21提供到一个或多个云存储服务2.22和本地存储后端服务2.23的前端服务层。存储服务2.21为用来解译来自环境描述符的所述存储需要和对多个存储后端递送结果的策略引擎和门面服务的组合。存储服务2.21不仅提供供应存储装置的能力，而且维持描述应用如何随时间推移处置数据存储装置的策略/规则。在这个实施方案中，存储服务2.21为ECO核心内的不同独立服务组件。在另一实施方案中，存储服务2.21与基础设施管理服务2.28整合在一起。策略引擎馈送到环境描述符以操控工作流程和存储端点以使系统实现匹配策略规则的变化。

应注意，参考图2所述的服务是示例性的且不应被视为限制性。在一些实施方案中，服务/资源中的一个或多个可以与其它服务/资源整合在一起以定义整合的服务/资源。因此，可以组合这些整合的服务/资源的功能或属性。此外，应注意，不需要对应用提供所有服务/资源。一个或多个服务/资源可以被调整或配置来添加额外功能，或额外资源/服务可以被引进来提供ECO系统内的额外功能。因为ECO机构提供可扩展框架，所以可以容易地且无缝地完成这些配置变化而不影响应用的性能或系统的核心功能。

在ECO系统内可用和应用所要的各种服务/资源被描述为在位于维持在ECO系统内的环境描述符文件内的环境描述符记录中。环境描述符文件为提供用于ECO系统内的应用软件管理的界面的JSON格式化文件。环境描述符文件内的环境描述符记录为要求配置在远程云租户或物理主机中以在租户环境中成功地执行应用的内容的表示。

在一个实施方案中，环境描述符记录包括运行应用所需的参数清单。描述符记录包括用于特定环境的资源/服务的定义和规范，包括数据库、虚拟机、服务和软件、存储位置、ACM(应用配置管理)配置、CMS(配置管理服务)配置和其它环境元数据。

ECOGUI2.4能够基于在环境描述符内所指定和存储的动作动态地配置可用菜单动作。例如，当在GUI中点击“开始”按钮时，“开始”动作通过ECOAPI调用。作为响应，将执行被寄存来处置“开始”的ECO工作流程，其最终将包括用来对一个或多个主机实例进行ACM的“开始”功能的调用，其中ACM开始并执行动作。环境描述符充当ECO系统与ACM之间的界面。通过指定环境描述符中的适当ACM，ECO系统感知在何处获得指定ACM，将ACM放置在环境内的不同机器上的何处，和哪些ACM命令可供使用。在环境描述符中所指定的动作触发环境内的特定工作流程以允许供应必需资源、服务和/或应用。

在一个实施方案中，ACM包括用于将应用部署到ECO系统内的适当环境的管理脚本逻辑。ACM脚本为使应用知道如何开始/停止/更新/重启/检查环境状态的界面。ECO系统提供在ECO系统内且将编排这些动作的默认泛化工作流程。开发者针对特定应用定义工作流程的详情，其涉及应用ACM与环境描述符之间的协调。

ACM脚本还可以指定后端任务。在给出ECO工作流程期间运行的后端任务部分地取决于在环境描述符中所定义的内容。例如，在“发布”工作流程中，ECO系统将取决于在环境描述符中已变化的内容运行任务中的特定者。如果环境描述符已被编辑来添加新机器，那么ECO系统将识别并执行用于经由供应服务2.9发动新机器的任务/动作。如果环境描述符已被编辑来改变CMS存储库信息和/或分布式修订版控制和源代码存储库2.16且机器已在环境中运行，那么ECO系统将跳过用于开始供应进程的动作，识别并开始用来仅对环境内的受影响服务更新软件的动作。

ACM部署在每个机器上且执行安装和配置应用所需的所有步骤。ECO工作流程将调用适当ACM用于其中应用将被执行且与给出动作相关联的环境。ACM参考环境信息的环境描述符，基于其内定义的逻辑作出关于在所述特定主机上需要完成什么内容的决定。逻辑指定哪些配置文件需要变化，文件如何变化，哪些资源可用于主机，每个主机需要多少服务等。

在一个实施方案中，在供应机器时，用户可以指定是使用GUI2.4还是CLI2.3，识别机器将供应在其上的云服务，和将用来基于从环境描述符获得的关于机器的信息创建机器的指令提供给云服务。在替代实施方案中，在供应机器时，ECO系统内的逻辑可以通过来自用户的一些交互识别机器将供应在其上的云服务，识别适当环境描述符记录，和将用来根据来自环境描述符记录的信息创建机器的指令提供给云服务。信息馈送转化成从云服务发动的机器。作为供应进程的部分，ACM基于环境描述符中的规范安装在发动的机器上。接着，配置管理服务(CMS)2.17被运行来增添机器。CMS扮演系统配置管理的角色。具体来说，CMS(在云中)通过确保首要软件、设置和权限的所有者是适当的且与讨论中的实例的特定数据中心/位置相关而准备结合ECO使用的实例。可用配置管理软件中的任何一个可以用于这个角色。根据这个角色，增添涉及安装与所述机器的角色相关联的包(软件和其它包)的所有者。在完成增添之后，ACM被指示来解析环境描述符以检查代码基，核实是否满足依赖性，和执行关于应用的所有详情。

换句话来说，ACM使用建置在其内的逻辑转化由ECO系统发出的命令。如果命令将在机器上开始服务，那么ACM的内建逻辑知道需要哪些引数来运行命令，对于服务指定通过引数运行命令的方式(每个服务可以具有运行命令的不同方式)，定义运行与命令相关联的各种任务的序列等。ACM识别环境(在其上通过参考特定环境的环境描述符开始服务)的类型且使用配置文件建置服务。

环境描述符文件为提供用于在ECO系统中进行应用软件管理的界面的JSON格式化文件。环境描述符文件为已配置在远程云租户中用于执行应用的内容的表示。

环境描述符文件包括具有运行应用所需的一系列参数的描述符记录。例如，描述符记录可以包括特定环境的定义和规范，包括数据库、虚拟机、服务和软件、存储位置、ACM配置、CMS配置和其它环境元数据。描述描述符记录需要是适当的且ACM管理在可创建ACM之前在环境描述符记录的“eco”区块中所定义的脚本。这使得ACM可使用在环境描述符记录中指定用于配置环境的配置信息。因此，环境描述符记录包括配置环境所需且定义在应用ACM中所支持的动作的关于所有服务的所有信息。eco区块提供关于何处获得应用ACM，如何运行ACM和应在ECO工作流程期间执行的ACM支持的动作的信息。在执行时，ECO工作流程调用/开始ACM以便停止/开始/更新/检查等。工作流程将联系ACM需要在其上运行的机器，运行ACM管理脚本和提供用来运行ACM的必需引数。下文提供简单eco区块伪代码。

下文提供用于定义云服务的环境中的虚拟主机的简单eco区块伪代码。机器区块可以包括由云服务提供者提供的信息、来自服务的信息、每个服务的机器特定元数据和其它配置属性。

下文提供用于定义每个应用栈的每种类型的服务和存储库信息的简单eco区块伪代码。ACM可以使用存储库信息来获得最新应用代码。一个或多个属性特征可用来在一个以上服务具有相同名称时区别环境内的一个服务与另一服务。

下文提供用于定义应用的远程存储信息的简单eco区块伪代码。

上文被提供来包括在eco区块中以供应服务/资源的伪代码是示例性的且不应被视为限制性。可以使用在eco区块内供应服务/资源的其它方式。应用的软件源代码可以存储在云提供者租户中的网络服务器上，存储在源代码存储库中或存储在可供将在其上下载代码的机器访问的任何位置中。ACM被更新来识别位置。

在一个实施方案中，在环境描述符中的任何字段变化时，可以使用“发布环境”选项发布变化。或者，更新可以被运行来在环境中部署不同服务的变化。在选择更新选项时，更新软件用最新修订版更新应用软件，更新环境描述符以反映变化，推出所有机器上的更新的环境描述符，且最终更新ACM。

在选择发布选项时，发布预览视窗(即，GUI)显示当前环境版本与更新的环境版本之间已变化的内容的详情。此外，执行“发布环境”工作流程。工作流程识别并运行包括更新应用软件的一系列动作。例如，在一个实施方案中，可以由发布环境工作流程执行以下动作：1.提交环境草稿版本；2.在环境中记载当前服务状态和部署的修订版；3.检查机器以终止和检查所有DNS记录是否有效；4.供应新机器和核实现有机器是否运行；5.在机器上更新新DNS记录和检查/添加浮动IP地址；6.在机器上更新ACM；7.更新应用软件；和8.设置最新发布的环境版本。前文所提及的一系列动作是示例性的且可以基于更新执行更少或额外动作。在一些实施方案中，可以平行于完成识别的动作部署多个工作流程。

图3示出在一个实施方案中的发布环境的示例性屏幕截图。发布环境工作流程提供较少选择选项。例如，在打开由气泡1所示的“迫使发布”选项时，重启/更新整个环境。在关闭“迫使发布”时，仅重启/更新变化的服务。图3A示出当在迫使发布选项处检测到输入动作时(诸如光标悬停在字段上)迫使发布关闭与迫使发布打开之间的区别。ECO机构具有用来识别已变化的服务和更新具有或使用所述服务的机器的内建智能。

继续参考图3，由气泡2所示的“跳过软件更新”选项可以被打开或关闭来控制是否运行全部应用软件更新。“复查变化”选项可以用来查看将在触发工作流程时运行的单独活动。活动经由工作流程预处理器发送到ECO工作流程服务且还呈现在可折叠区段中，如由气泡3所示。预处理器使用在环境描述符中所指定的逻辑来以由环境描述符定义的次序执行各种活动。

图4示出在本发明的一个实施方案中的用来向用户通知执行的各种活动的环境历史视窗的简单屏幕截图。在环境历史中的“运行历史”区段下所列的活动为图4中所示的预览视窗中的可折叠区段中所列的活动的相同集。

图5示出在一个实施方案中的将被调度来采取的ECO“工作流程”动作的示例性屏幕截图。在一个实施方案中，所有ECO工作流程动作演示为预览视窗中的可折叠选项。在一个实施方案中，预览视窗可以演示进程条或使用任何其它状态指示符机构来识别当前采取的动作或已采取的动作的状态。如参考图3所指示，可折叠区段表示将在执行工作流程期间运行的活动，且在一个实施方案中，视窗中的活动的次序可以表示其中运行活动的次序。所列活动相似于图3的“环境历史”视窗和图4的“运行历史”区段中所示的活动。

图6示出在一个实施方案中的由工作流程开始的动作的“当前动作状态”视窗的示例性屏幕截图。当前动作状态视窗在开始工作流程动作时打开。在完成工作流程动作时，消息或指示符可以显示在视窗中所演示的页面的顶部或底部处。当前动作状态视窗提供由气泡1所指示的进程指示符以提供工作流程动作的当前状态。工作流程详情提供在由气泡2所表示的区段中，其中提供工作流程动作识别符、工作流程动作的状态、记载的最新交易消息的时间戳和运行历史详情。提供用来刷新工作流程动作的日志的选项，如由气泡3所示。在选择刷新选项时，详述工作流程动作的日志呈现在由气泡4所示的子视窗中。可以在任何时间使用“取消工作流程”选项取消工作流程动作，如由气泡5所示。“关闭”选项可以用来关闭视窗，如由气泡6所示。在一个实施方案中，关闭选项可以仅关闭视窗且不取消工作流程选项。在替代实施方案中，关闭选项可以取消工作流程操作且关闭视窗。

ECO机构提供所有记载的环境交易的详情。环境历史数据库可以存储不同环境交易的历史且填入“环境历史”视窗，如图7中所示。图7的环境历史视窗提供不同于图4的环境历史视窗的信息。例如，图4的环境历史视窗在工作流程详情区段内呈现触发的每个工作流程的运行历史详情。然而，在图7的环境历史视窗中所呈现的日志表示被采取来供应环境的动作、工作流程和事件的ECO服务消息。交易清单记录环境活动的详情，包括交易时间戳(即，日期)、开始动作的用户名称(请求者名称)、ECO交易消息、在执行动作时所使用的参数等。可以在活动日志中的每个处提供一个或多个链接以允许一人查看所述活动的在线交易详情，如由图7中的箭头所示。在选择链接时，相似于图4中所示的在线交易详情的在线交易详情将呈现在单独视窗中或取代现有视窗。

对于归因于错误未完成的事件，可选链接可以被提供来查看错误的详情。图8示出当在工作流程活动中的一个中遭遇错误时捕捉环境历史视图的示例性屏幕。可选链接可以被选择来查看错误的追踪日志。视需要，链接可以被选择来向用户通知开始遭遇的错误的请求。在一个实施方案中，可以通过电子邮件向用户通知错误且电子邮件可以包括错误日志。在替代实施方案中，可以生成信息消息并以用户所期望的格式和消息工具向用户呈现信息消息。

在一个实施方案中，可以在视窗中通过用来在错误日志中所提供的详情的必需链接向用户呈现错误日志。图9示出用于向用户提供用来访问错误日志的选项的示例性视窗。在这个实施方案中，在电子邮件的链接内向用户提供错误日志。在一个实施方案中，在访问链接时，错误日志识别详述在执行工作流程活动期间遭遇的不同错误的多个条目，且可以基于错误的严重性组织条目。在替代实施方案中，可以按时间次序排列条目。链接提供用户和用来向用户通知遭遇的错误的模式的另外详情。

可以基于一个或多个属性搜索并识别特定环境。搜索选项可以被提供来使得用户能够输入属性值，且搜索工具可以使用属性和其值来搜索环境描述符文件以识别并传回匹配的环境的详情。

在一个实施方案中，可以管理实体且由一个或多个用户基于其已在每个环境中指派的角色指派云实体。实体管理可以包括添加用户角色以控制对ECO系统中的资源的访问权，添加组织使得可以在组织内创建应用和环境，添加租户使得其可与组织相关联，添加云提供者使得其可与组织内的租户相关联，和添加安全性密钥使得其可与组织内的租户相关联。一旦添加用户，那么将用户指派给组织使得用户具有对所述组织内的资源的访问权。向用户指派角色使得用户具有定义的角色和具有对ECO系统中的资源的受控制访问权的适当权限。基于用户的指派角色将对应用的访问权指派给用户使得用户可访问其组织内的应用。在这个实施方案中，云提供者(或任何资源/服务提供者)可以配置为提供服务(诸如计算服务、存储服务、数据库服务等)的系统提供者。接着，将这些服务“寄存”在服务的系统目录中且通过位置来组织。服务的系统目录可以维持在集中云服务中心以及云数据中心中的不同地理位置或地理区域处，其可以包括一个以上地理位置。组织通过与每个系统提供者维持的组织帐户的关联性与特定系统提供者相关联。组织内的应用的环境将具有对由系统提供者在所期望地理位置处所提供的服务/资源的访问权。如此，将由环境根据在某个环境中所定义的将由其它环境使用的规范或规定消费资源(存储装置、数据库架构、固定IP等)。

图10示出表示用户配置文件的示例性屏幕。用户配置文件可以包括用户的个人信息(由气泡1所示)(诸如用户名称、登录识别符等)、组织信息(由气泡2所示)(诸如用户的指派组织等)、用户角色和权限信息(由气泡3所示)(诸如用户的指派角色、访问级别、权限清单等)、用户时区偏好(由气泡3所示)。身份管理服务(图2中的2.8)可以用来定义用户配置文件且用户配置文件信息可以保存到数据库且在环境和/或应用要求时由身份管理服务加以参考。

图11示出在一个实施方案中的个人请求访问ECO系统的一般工作流程。在个人想要使用ECOGUI开始时，首先请求个人使用外部管理的轻量目录访问协议(LDAP)登录到ECO系统中。凭证允许请求者的名称记录在ECO系统中。将具有用来将请求发送到托管管理服务(HMS)的指令的“未授权”消息发送到请求者，如操作11.1中所示。在HMS处以电子邮件的方式接收从请求者到指定请求者所属且请求访问的组织的HMS的请求，如操作11.2中所示。接着，HMS的管理员(也称为“管理用户”)将向请求者(即，新用户)指派用户角色。为此，管理员首先进行检查以查看用户角色是否存在，如决定框11.3中所示。如果角色不存在(如由决定框11.3中的“否”分支所示)，管理员在ECO系统中创建用户角色，如操作11.4中所示。通常，默认用户角色集已定义为具有必需权限且可用于ECO系统。在创建用户角色时或在识别来自现有默认用户角色的适当用户角色时，管理用户将再次向请求者指派新创建或识别的用户角色，如操作11.5中所示。

接着，管理用户将请求者指派给组织。管理用户首先将确定组织是否存在，如决定框11.6中所示。如果组织不存在于ECO系统中，那么管理用户将组织添加到ECO系统，如操作11.7中所示。对于现有组织，一个或多个相关联地理位置应已存在且每个地理位置应已具有指派给其的相关联云和安全性密钥。管理用户进行核实以查看组织是否存在特定地理位置(如决定框11.8中所示)且如果否，那么管理用户创建地理位置(如操作11.9中所示)，且将组织指派给地理位置(如操作11.10中所示)。

一旦创建租户，那么管理用户确定地理位置是否存在云，如决定框11.11中所示。如果云不存在(如决定框11.11的“否”分支所示)，那么管理员创建云(如操作11.12中所示)。管理员将新创建的地理位置指派给新云，如操作11.13中所示。接着，管理用户确定是否存在安全性密钥，如决定框11.14中所示。如果安全性密钥不存在(如决定框11.14的“否”分支所示)，那么管理用户创建安全性密钥(如操作11.15中所示)，且新创建的安全性密钥指派给地理位置(如操作11.16中所示)。

另一方面，如果组织存在(如决定框11.16中的“是”分支所示)，那么管理用户将请求者指派给组织(如操作11.17中所示)。接着，管理用户确定请求者的角色是“开发者”还是“生产者”，如决定框11.18中所示。如果请求者的角色不是开发者或生产者(如决定框11.18中的“否”分支所示)，那么允许请求者登录到ECO系统中且被授权(如操作11.22中所示)。如果请求者的角色为开发者或生产者，那么管理用户将需要指派应用访问权给请求者。在一个实施方案中，将组织内的所有现有应用指派给请求者。为了指派应用访问权，管理用户需要确定应用是否存在，如由决定框11.19所示。如果应用不存在(如决定框11.19中的“否”分支所示)，那么管理用户创建应用(如操作11.20中所示)。另一方面，如果应用存在(如决定框11.19中的“是”分支所示)，那么管理用户针对应用向请求者指派“生产者”和/或“开发者”角色(如操作11.21中所示)且允许请求者登录到ECO系统中并被授权来访问应用，如操作11.22中所示。在一个实施方案中，尽管管理用户的角色似乎为手动进程，但角色可以是自动的。在这个实施方案中，足够多的安全性措施可以内建到自动进程中以确保在对用户授予角色或权限之前完成适当用户授权。

向用户指派的角色确定服务操作和GUI特征的访问权。角色确定哪些GUI元件可用于用户和创建/读取/更新/删除(CRUD)权限中的哪些可用于用户。用户角色确定访问级别之间的层级关系。图12示出在一个实施方案中的基于向用户指派的角色的在访问级别之间的示例性层级关系。例如，以ECO级别的用户(诸如超级管理用户或管理者)具备对所有数据、组织、应用和环境的全系统访问权。具有组织级别的用户(诸如组织管理者和组织管理员)具备对自身组织、应用和环境的访问权。具有应用级别的用户(诸如开发者和生产者)具备对自身组织标题/应用内的应用和环境的访问权。具有环境级别的用户(诸如顾客和贡献者)具备对自身组织应用内的环境的访问权。

在一个实施方案中，可以通过结合环境描述符工作流程创建并管理新环境，如图13中所示。环境描述符工作流程识别在环境内所需的资源/服务且触发额外工作流程以供应这些资源/服务。在这个实施方案中，在创建新环境时，用版本号指定环境且在对这个环境作出变化时，将新版本号指派给具有变化的环境。环境描述符工作流程帮助创建和管理多个版本的环境配置，其中每个后续版本具有相同于先前版本的一般功能，但加以改善、升级或自定义。多个版本防止错误地删除或覆写版本，且允许版本归档使得其可在任何时间加以检索。

图13示出其中环境描述符工作流程被结合来创建新环境的实施方案。在最初使用环境描述符工作流程创建新环境时，生成“草稿”环境13.1。在发布环境时，将草稿环境转换成“现场”环境13.2。在归因于升级或自定义需要对环境作出变化时，通常对“草稿”版本作出变化且不对“现场”发布的环境版本作出变化，如图13中所示。在发布变化时，生成新版本的“现场”环境。在保存变化时，将具有变化的当前“现场”环境版本保存在先前环境版本13.3旁边且版本号递增。自动地创建“现场”环境版本的新草稿且对草稿版本作出已对环境所作的任何后续变化。在一个实施方案中，环境的版本号仅用于现场版本且在成功的“发布环境”动作之后递增。维持较旧版本的环境且可从数据库(例如，在数据库2.25中)检索较旧版本的环境，且来自较旧版本的的环境配置用于定义环境(如果有需要的话)。

在一个实施方案中，在环境变化时，触发环境描述符工作流程，从而造成环境描述符文件内的环境的环境描述符记录被更新来反映变化。在需要发布环境时(即，变化需要部署到环境)，环境描述符工作流程开始“发布环境”工作流程。环境描述符工作流程运行一系列动作，包括更新应用，更新必需服务/资源，和甚至在一个或多个机器不具有在变化内检测到的变化时将更新的环境描述符记录推出到环境内的所有机器。在一个实施方案中，环境描述符工作流程运行多个动作，包括：

1.提交环境草稿版本；

2.在环境中记载当前服务状态和部署的修订版；

3.检查机器以便终止和检查所有DNS记录是否有效；

4.供应新机器和核实任何现有机器是否运行；

5.在机器上更新新DNS记录和检查/添加浮动IP地址；

6.在机器上更新ACM；

7.更新应用栈软件；和

8.在存储装置中设置最新发布的环境版本。

在一个实施方案中，发布环境工作流程提供用来检查经由所述工作流程执行的各种动作的最新状态的选项。图14示出状态预览视窗的示例性屏幕视图。屏幕视图示出由部署机构提供用于检查环境服务的状态(包括哪些服务在环境中运行和每个服务的修订版信息)的“快照”视窗。视窗提供关于举例来说机器名称、在每个机器上运行的服务的名称、每个服务的服务状态和服务的版本号的信息。在视窗中所提供的字段的清单是示例性的且更少或更多字段可以被包括来提供各种动作的最新状态。

图15示出在一个实施方案中的概述用来对应用供应资源/服务的部署机构的进程流程的模型。应用(标题A15.1)被更新到ECO系统15.2以在ECO系统支持的环境中执行。图形用户界面15.3或命令行界面15.4用来提供环境的轮廓，其指定应用15.1在环境中成功地执行所需的所有服务/资源。通过GUI15.3或CLI15.4输入的信息用来定义环境描述符记录15.5。来自描述符记录的信息被处理来生成描述符可执行文件15.6。如果其中将执行应用的特定环境不存在记录，那么描述符可执行文件在JSON描述符文件15.7内创建JSON描述符记录。或者，如果特定环境存在记录，那么描述符可执行文件用从GUI或CLI接收的信息更新现有JSON描述符记录。JSON描述符定义存在用于执行应用的以便环境消费所需的服务/资源的层级清单。

在应用被选择来执行时，JSON描述符文件15.7被读取来识别成功地执行应用所要的资源/服务，且适当工作流程被运行来创建环境和供应所要服务/资源15.8。工作流程造成定义环境15.9且在环境15.10内例示资源/服务。一旦定义环境且供应服务/资源，那么在环境中执行应用且管理应用、资源/服务和用户的状态15.11。

管理应用、资源/服务可以包括监控服务/资源以及其中执行应用以确定环境是否被配置来最优地执行应用的环境。因此，服务日志、动作日志、用户日志、对话日志、系统日志等被分析来确定是否需要例示额外应用实例，供应的资源/服务是否足以且最优地执行应用以满足需求、成本、性能等。在一个实施方案中，部署机构可以是指用来确定是否最优地执行应用的预定义规则集。在一个实施方案中，基于分析，可以确定一个或多个资源或服务可能需要从相同云服务内或不同云服务上的一个服务器迁移到另一服务器，更新、删除、添加或改变一个或多个资源或服务，或环境需要从一个服务器迁移到另一服务器。在确定需要进行变化时，保存涉及在环境内执行应用的各种状态；执行环境变化；更新适当环境描述符记录；发布变化；和使用新环境或具有变化的现有环境中的环境描述符记录中的信息、使用各种保存的环境状态重启应用。各种状态可以包括用户状态、服务状态、应用状态等。

如从各种实施方案可见，部署机构提供用于将应用部署到云中的多云编排平台。概述在环境中执行的应用的所有要求的环境描述文件维持在中央且分布到环境内的不同机器。在执行应用时，读取环境描述符文件，对需要采取哪些动作作出决定，执行动作，记载动作状态和向用户汇报采取/未采取的动作的状态。单一内建API被配置来允许ECO系统与使用多种格式的各种服务/资源、机器和多种云系统服务之间的通信。

通过各种实施方案的详述，现将参考图16描述方法。图16示出在一个实施方案中的用于在云系统内供应用于成功地执行应用的服务/资源的方法操作。所述方法开始于操作1610，其中检测用于在云服务上执行应用的请求。应用可以是任何类型的应用，包括被设计来在不同硬件/软件平台执行的商业应用、社交媒体应用、游戏应用等。响应于请求，访问描述符文件，如操作1620中所示。描述符文件为存储库且包括将在一个或多个云服务上执行的每个应用的多个描述符记录。从描述符文件检索应用的描述符记录，如操作1630中所示。检索的描述符记录专用于云服务且提供在云服务环境中成功地执行应用所要的环境资源和/或服务的详细规范。

将在描述符记录中所提供的资源和服务要求转化成在云服务环境中被采取来供应所要资源或服务所需的一个或多个动作，如操作1640中所示。资源或服务可以包括技术资源(诸如存储资源、存储器、网络资源、处理资源等)和/或服务以满足在应用中所指定的任何依赖性。可以执行的与服务相关联的一些示例性动作包括涉及下载软件、配置软件、启动软件、部署服务等的动作。可以执行的与环境相关联的一些示例性动作包括涉及复制环境、供应服务器、开始/停止服务、部署服务等的动作。响应于请求，提供采取的(和未采取的)动作的状态，如操作1650中所示。可以通过在环境描述符记录中更新各种动作字段/子记录的状态以便提供环境配置数据的当前状态(即，状态、软件和版本、IP地址等)来提供动作状态。状态用来确定应用的所要资源和服务是否已被供应来在云服务中成功地执行应用。应注意，在描述符记录中所定义的环境配置可以导致混合托管解决方案，其中从一个以上云服务利用资源。部署机构允许应用控制自身环境配置(包括混合托管解决方案)，且定义自身工作流程集，从而使这个解决方案为真实的多云托管管理解决方案。

图17示出用于供应资源/服务以在云服务中成功地执行应用的方法的替代实施方案。所述方法开始于操作1710，其中接收在云系统上成功地执行应用所要的一个或多个资源或服务的属性。属性可以识别所要资源或服务的类型、所要资源或服务的量/级别/版本等。使用接收的资源或服务的属性生成应用的描述符记录，如操作1720中所示。描述符记录定义专用于云系统且通过将资源和服务要求转化成被采取来在云系统中供应所要资源和服务的一个或多个动作的环境配置文件。将生成的描述符记录存储在维持在部署系统数据库中的描述符文件中。在接收应用的后续执行请求时，从描述符文件检索描述符记录。检索造成自动触发识别的动作，如操作1730中所示。动作触发可以导致一个或多个工作流程的例示，从而造成供应服务或资源用于云系统以使得能够在云系统执行应用。

可以通过各种计算机系统配置(包括手持型装置、微处理器系统、基于微处理器或可编程消费者电子装置、迷你计算机、大型计算机等)实行本发明的实施方案。还可在分布式计算环境中实行本发明，其中由通过基于有线或无线的网络链接的远程处理装置执行任务。

基于上述实施方案，应了解，本发明可采用涉及存储在计算机系统中的数据的各种计算机实施操作。这些操作为要求物理量的物理操控的操作。形成本发明的部分的本文中所述的操作中的任何一个为可用机器操作。本发明还涉及一种用于执行这些操作的装置或设备。可出于所要目的具体地建构设备，或设备可为通过存储在计算机中的计算机程序选择性地启动或配置的通用计算机。特定来说，可结合根据本文教学内容写入的计算机程序使用各种通用机器，或可以更方便地建构更专业设备以执行所要操作。

本发明还可体现为计算机可读介质上的计算机可读代码。计算机可读介质为可存储随后可由计算机系统读取的数据的任何数据存储装置。计算机可读介质的实例包括硬盘驱动器、网络附接存储装置(NAS)、只读存储器、随机访问存储器、CD-ROM、CD-R、CD-RW、磁带、和其它光学和非光学数据存储装置。计算机可读介质可包括分布在网络耦合计算机系统上使得以分布式方式存储和执行计算机可读代码的计算机可读有形介质。

尽管以特定次序描述方法操作，但应了解，可以在操作之间执行其它内务处理操作，或可以调整操作使得其以稍微不同的次序发生，或可分布在系统中以允许按与处理相关联的各种间隔发生处理操作，只要以所期望方式执行覆盖操作的处理。

尽管已出于清楚理解的目的相当详细地描述先前发明，但将明白，可在所附权利要求书的范围内实行某些变化和修改。因此，本发明实施方案应被视为说明性而非限制性，且本发明不限于本文中所给出的详情，但可以在所附权利要求书的范围和等效物内进行修改。

Claims

1.一种方法，其包括：

检测用于在云服务的环境中执行应用的请求；

响应于所述请求，访问来自存储库的描述符文件，所述描述符文件具有将在一个或多个云服务上执行的每个应用的一个或多个描述符记录；

从所述描述符文件检索所述应用的描述符记录，所述检索的描述符记录专用于所述云服务环境且提供在所述云服务环境中执行所述应用所需的资源和服务要求的详情；

将所述资源和服务要求转化成将在所述云服务环境中采取的一个或多个动作以对所述应用供应所述服务和资源，其中所述将采取的任务被代理来基于在所述应用的所述描述符记录中所提供的所述资源和服务要求的详情以预定义序列发生；和

响应于所述请求，提供采取的动作的状态，所述状态用于确定所述所要资源和服务是否已被供应来在所述云服务中成功地执行所述应用，

其中由处理器执行方法操作。

2.根据权利要求1所述的方法，其中所述将采取的动作包括：

识别和例示在所述转化中所识别的动作中的每个的工作流程，所述工作流程用于对所述应用供应所述服务和资源。

3.根据权利要求2所述的方法，其中根据在所述一个或多个动作中所提供的细节，在不同云服务中例示所述工作流程，所述不同云服务中的每个包括满足在所述应用的所述描述符记录中所指定的所述资源或服务要求的不同服务或资源。

4.根据权利要求1所述的方法，其中提供状态还包括提供未采取的动作的状态。

5.根据权利要求1所述的方法，其还包括提供应用编程界面(API)以在所述云服务的所述环境中与所述服务和资源进行交互以获得所述动作状态。

6.根据权利要求5所述的方法，其中所述API还被配置来获得执行所述应用所需的资源和服务要求的所述详情，由所述API获得的所述详情用于生成所述描述符记录。

7.根据权利要求5所述的方法，其中通过命令行界面或图形用户界面访问所述API。

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

检测可用于所述应用的所述资源或服务中的一个或多个的变化；和

根据所述检测到的变化，实质上实时地针对所述应用自动地更新与所述云服务相关联的所述描述符记录，以便使得能够供应适当资源和服务以后续地执行所述应用，

其中所述一个或多个资源或服务的所述变化包括添加、删除、变化、升级或其组合。

9.根据权利要求1所述的方法，其还包括监控所述应用的性能和动态地调整对所述应用供应的所述资源和服务中的一个或多个以使得能够最优地执行所述应用，所述动态调整还包括针对所述云服务，在所述应用的对应描述符记录中自动地更新所述一个或多个资源和服务的详情，

其中所述动态调整包括供应额外资源或服务。

10.根据权利要求9所述的方法，其中所述动态调整基于所述应用所期望的性能的类型。

11.根据权利要求9所述的方法，其中来自所述监控的信息用于预测所述应用的使用配置文件，且用于基于所述预测的使用配置文件动态地调整所述资源和服务。

12.根据权利要求11所述的方法，其中预测所述使用配置文件还包括：

确定由所述应用在所述应用的不同执行时间期间所使用的资源和服务的历史使用，从所述应用的元数据获得的所述历史使用；和

基于在所述元数据中所提供的所述资源和服务的所述历史使用，针对所述云服务的所述环境定义所述使用配置文件。

13.根据权利要求11所述的方法，其中动态地调整所述资源和服务包括基于所述应用的所述预测的使用配置文件，将所述应用迁移到新云服务，所述新云服务具有所述所要资源和服务以最优地执行所述应用。

14.根据权利要求13所述的方法，其中迁移所述应用还包括：

存储与所述应用有关的用户状态、应用状态、重启点和其它数据；

通过采取在所述描述符记录中所定义的适当动作，在所述新云服务中供应所述资源和服务；

基于所述动作的所述状态，更新所述应用的所述描述符记录以定义在所述新云服务内所供应的所述资源和服务的详情；和

在所述新云服务中执行所述应用的实例，所述应用在执行期间使用所述存储的应用状态、所述用户状态、所述重启点和所述其它数据，

其中实质上实时地完成所述存储、供应、更新和执行。

15.一种方法，其包括：

接收在云系统上用于执行应用所要的一个或多个资源和服务的属性；

使用所述接收的属性生成所述应用的描述符记录，所述描述符记录定义专用于所述云系统的环境配置文件，其中通过将所述资源和服务要求转化成将采取的一个或多个动作以在所述云系统中供应所述所要资源和服务以成功地执行所述应用来生成所述描述符记录，其中所述生成的描述符记录基于所述接收的属性识别所述将采取的动作的预定义序列；和

将所述描述符记录存储在维持在部署系统数据库中的描述符文件中用于在所述云系统中后续地执行所述应用期间进行检索，所述检索造成自动触发在所述描述符记录中所识别的动作，从而导致在所述云系统上供应所述所要服务和资源以使得能够成功地执行所述应用，

其中由处理器执行方法操作。

16.根据权利要求15所述的方法，其中使用命令行界面或图形用户界面以通过应用编程界面(API)接收所述属性。

17.根据权利要求15所述的方法，其中基于所述应用的代码的检验接收所述资源和服务的所述属性。

18.根据权利要求15所述的方法，其中所述将采取的动作还包括：

识别和例示在所述描述符记录中所识别的所述动作中的每个的工作流程。

19.根据权利要求15所述的方法，其还包括：

在所述云系统中监控所述应用的性能；

动态地调整所述资源和服务中的一个或多个以实现所述应用的最优性能；和

根据对所述一个或多个资源和服务执行的所述调整，自动地更新所述应用的所述描述符记录，所述描述符记录定义所述云系统的当前环境配置文件。

20.根据权利要求19所述的方法，其中所述动态调整包括将所述应用迁移到新云系统，所述新云服务具有针对所述应用的最优性能的所述所要资源和服务，

其中基于所述应用所期望的性能的类型识别所述新云系统。

21.根据权利要求20所述的方法，其中迁移所述应用还包括：

在所述新云系统中供应所述资源和服务；

更新所述应用的所述描述符记录以定义在所述新云系统内所供应的所述资源和服务的详情；和

在所述新云系统中执行所述应用的实例，所述应用在执行期间使用所述存储的应用状态、所述用户状态、所述重启点和所述其它数据，

其中实质上实时地完成所述存储、供应、更新和执行。

22.根据权利要求15所述的方法，其还包括：

检测可用于所述应用的一个或多个资源和服务的变化；和

根据所述检测到的变化，实质上实时地更新与所述应用相关联的所述描述符记录，以便使得能够供应适当资源以后续地执行所述应用，

其中所述一个或多个资源和服务的所述变化包括添加、变化、删除、升级或其组合，所述更新的描述符记录定义用于所述应用的所述执行的当前环境配置文件。