CN104508627B

CN104508627B - 混合云环境

Info

Publication number: CN104508627B
Application number: CN201280075050.5A
Authority: CN
Inventors: S.H.梅斯; R.巴拉赫瓦; J.拉巴; T.格佩尔
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2012-10-08
Filing date: 2012-10-08
Publication date: 2017-12-15
Anticipated expiration: 2032-10-08
Also published as: US20150180949A1; EP2880529A4; WO2014058411A1; CN104508627A; EP2880529A1

Abstract

一种混合云环境，包括处理资源以在多个云环境上部署和管理应用程序，存储资源以存储云中间件，云中间件包括服务和部署管理器以通过处理资源在混合云基础设施上部署应用程序，其中通过把可用的混合云基础设施能力与描述应用程序的资源需求、属性和特性的应用程序模型相匹配，将应用程序部署在混合云基础设施上，以及生命周期管理模块以管理应用程序和关联的混合云基础设施的生命周期。

Description

混合云环境

背景技术

使用作为服务交付的各种计算、存储和联网资源以及使用更高级别的服务（如作为服务提供的应用程序和平台）已被证明有利于多个用户。通过网络使用这些资源一般被称为云计算。使用云计算，用户也许能够基于他或她的服务在任何给定时间正在经历的流量动态并自发地发展他或她在一个或多个网络上的存在。此外，用户可以使用可用的资源来运行计算、存储数据并且分享这些资源或作为服务将这些资源提供给其他用户。然而，创建部署在基础设施上的应用程序，控制基础设施上的那些应用程序以及管理基础设施可能是昂贵且难以实现的。特别地，开发将在用户希望向其部署应用程序的云上使用的基础设施和平台上有效地执行的服务应用程序可能是困难的。更进一步，以安全的方式管理任何单个应用程序的生命周期、基础设施、域以及应用程序本身同时在云环境中实现可能是困难的。更进一步，促进支持或使用云环境的每个人（诸如应用程序开发者、用户、IT管理员、服务提供商和操作管理者）的工作可能是困难的。

附图说明

附图图示了本文所述原理的各种示例，并且为本说明书的一部分。所述示例不限制权利要求的范围。

图1是依据本文所述原理的一个示例的混合云环境的框图。

图2是依据本文所述原理的另一个示例的混合云环境的框图。

图3是依据本文所述原理的另一个示例的混合云环境的框图。

图4是依据本文所述原理的另一个示例的混合云环境的框图。

图5是依据本文所述原理的一个示例的描绘在混合云环境上部署和管理应用程序的方法的流程图。

在整个附图中，相同的附图标记指定类似的，但不一定相同的单元。

具体实施方式

为了给用户提供友好的环境，其中应用程序在云环境上可完全由多个履行不同角色的用户自我管理，本说明书公开了混合云环境，包括处理资源以在多个云环境上部署和管理应用程序、存储资源以存储云中间件。云中间件包括服务和部署管理器以通过处理资源在混合云基础设施上部署应用程序，其中通过把可用的混合云基础设施能力与描述应用程序的资源需求、属性和特性的应用程序模型相匹配，将应用程序部署在混合云基础设施上，以及生命周期管理模块以管理应用程序和关联的混合云基础设施的生命周期。

更进一步，本说明书公开了系统，包括存储在与混合云环境相关联的云服务器的存储资源上的服务生成环境（SCE）以接收来自用户的输入以通过处理资源为应用程序建立应用逻辑，以及多个存储在云服务器的存储资源上的服务执行环境（SEE）以通过处理资源执行由SCE创建的应用程序。应用逻辑包括使应用程序自我管理其生命周期而部署在混合云环境上的逻辑，以及应用程序依赖于由在整个混合云环境中分布的云中间件提供的API、事件和资源。

更进一步，本说明书公开了混合云上的事件驱动架构，包括存储在与混合云环境相关联的云服务器的存储资源上的消息代理以将消息发送到混合云环境中的多个云内和云间分布的单个资源并从其接收消息。每个资源可被分布在混合云环境中的多个云内和云间，被视为端点。

在下列描述中，为了便于解释，阐述了许多具体的细节以提供对本系统和方法的透彻理解。然而，本设备、系统和方法可以在没有这些具体细节的情况下实施对本领域技术人员来说将是显而易见的。在本说明书中引用“示例”或类似语言表明关于那个示例描述的特定特征、结构或特性包括在如述的那个示例中，但可以不被包括在其他示例中。

在本说明书和所附的权利要求中，术语“云”或“云环境”意指被广义地理解为通过任何计算机环境提供资源作为服务。这些资源除了其他的之外可以包括，但不限于物理计算硬件设备（诸如处理器、存储设备和网络设备）；形式为计算机可用程序代码的计算平台；形式为计算机可用程序代码的应用软件；作为服务提供的计算机数据存储；作为服务提供的网络平台；形式为计算机可用程序代码的应用程序编程接口；作为服务提供的生产、分期和测试环境，作为服务提供的安全平台和计算机可用程序代码。云的具体形式可包括公共云、私有云、管理云（托管或本地），以及其中以上类型的云的两个或多个结合在一起并提供所涉及的多个云类型的优点（例如混合云）的任何组合。

此外，在本说明书和所附的权利要求中，术语“中间件”意指被广义地理解为系统，在本说明书的一个示例中，其可以是促进在云环境上分布的应用程序的创建、部署、执行测试和生命周期管理的架构层。在另一个示例中，中间件促进云环境上现有云服务和现有云服务的组合的生命周期的管理（例如管理建立、配置和部署、执行、持续管理、报告、计量、退役等）。中间件可进一步提供另外的优点，如将在下面更详细地描述。

此外，在本说明书和所附的权利要求中，术语“应用程序”意指被广义地理解为组件的集合。此外，应用程序可以由一组工件（例如安装程序、代码、可执行文件、配置等）和一组被安装、执行和彼此交互的组件（例如可执行文件、中间件（MW）、数据库、操作系统（OS）等）来表征其每个组件。

回到图1，依据本文所述原理的一个示例的混合云环境（100）的框图。在图1的示例中，云环境可以是混合云，其中将多个不同的云环境结合在一起，给混合云结构提供包括的那些云环境的优势。为了便于解释，因此本说明书将在混合云环境中使用现有中间件方面进行描述。然而，这并不意味着限制该描述并且本说明书设想在任何数量和类型的云环境中使用中间件。

如上所讨论的，混合云环境（100）可包括任何类型的云资源和服务以及可进一步包括那些类型的云的任何数量或组合。因此，虽然图1描绘了混合云环境，但本说明书设想关于此处混合云（100）描述的中间件（105）可在任何数量和类型的混合云上被分布、存储和操作。此外，本说明书设想任何数量的中间件实例可存在于任何数量的云环境上，其中每个中间件实例都能够完成下面描述的任务以及能够在多个云环境上与其他中间件（105）实例通信。

如将在下面更详细地描述的，混合云环境（100）包括多个应用程序编程接口（140）。本文描述的中间件（105）用来帮助编排API（140）的使用以使多个应用程序和服务部署在混合云环境（100）上并且在整个混合云环境（100）中管理它们自己的生命周期。应用程序编程接口（140）可使用存储在混合云环境（100）的基础设施内的存储资源（175）上的数据以帮助应用程序管理它们的生命周期。此数据可以包括策略（135）、模板（130）、资源元数据（160）、应用程序模型（120）和蓝图（125）。更进一步，混合云环境（100）可进一步包括云基础设施（115），其可包括处理资源（165）和存储资源（175），其进一步允许云中间件（105）存储和执行与数据相关联的计算机可读程序代码。现在将更详细地描述混合云环境（100）。

云中间件（105）可以使用处理资源（165）来执行代码以完成如下描述的中间件（105）的计算目标。这些处理资源（165）作为混合云环境(100)的基础设施的一部分被包括。所述处理资源（165）可包括任何数量的可分布在混合云环境(100)的任何数量的云环境上的处理器。在一个示例中，处理资源（165）可包括多个在混合云环境（100）内的单一云环境上通信地耦合在一起的处理器。所述处理资源（165）通过中间件（105）的使用还可以促进用户创建、部署和管理多个在云基础设施（115）上部署的应用程序。

存储资源（175）还可以作为混合云环境（100）的基础设施的一部分被包括，以及可以由处理资源（165）和中间件（105）使用来存储数据以便由如下描述的用户和中间件（105）实现目标。此外，存储资源（175）可用来在混合云环境（100）内的多个云环境上存储中间件（105）的实例以及存储以上提到的数据作为数据即服务资源。存储资源（175）可以包括任何类型的存储设备，包括但不限于具有多条电线的电连接、便携式计算机软盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROP或闪存）、光纤、便携式光盘只读存储器（CD-ROM）、光存储设备、磁存储设备或任何前述的适当组合。更进一步，存储资源（175）可由任何数量和类型的可通信地耦合在一起的存储设备组成。更进一步，这些存储资源（175）可被集成在整个混合云环境（100）内的多个云环境中。

如所提到的，混合云（100）包括中间件（105）。中间件（105）通过确定基础设施硬件和混合云（100）内的基础设施（115）的能力来提供应用程序（170）的自动部署。中间件（105）还通过分析应用程序模型(120）来确定部署在基础设施（115）上的各种应用程序的应用需求。中间件（105）可使用服务和部署管理器（110）在混合云（100）的基础设施上服务和部署各种应用程序。服务和部署管理器（110）的功能和特征可至少部分地由在PCT专利申请号PCT/US2012/041625中描述的部署管理器来实现，其主题通过引用结合到本文中。如以上简要描述的，中间件（105）的多个实例可被存储在混合云环境（100）的多个云环境上，并且在整个混合云环境（100）的多个云环境中使用分布在混合云环境（100）的单个云环境上的存储资源（175）。在一个示例中，定义中间件和与中间件相关联的模块的计算机程序代码可以是中间件（105）的安装实例。在另一个示例中，定义中间件和与中间件相关联的模块的计算机程序代码可在云中间件（105）内作为安装包被提供。在这两个示例中，存储资源（175）可以是服务器存储，从中可下载安装包或者存储资源（175）可以是存储设备存储器，在其上安装计算机可读程序代码。

应用程序模型(120）可定义应用程序（170）的资源需求、属性和特性。在一个示例中，应用程序模型(120）可包括拓扑模型，其描述了对于给定的应用程序（170），哪些应用程序组件应该被部署以及如何部署那些应用程序组件（例如在云中的哪个位置部署什么组件）。应用程序模型(120）进一步定义在云上部署应用程序（170）所需要的资源。这里，拓扑可以描述应用程序（170）的组件之间的关系以及应用程序（170）和混合云（100）内的基础设施之间的关系。该拓扑可为以后的可包括在混合云（100）上部署的其他应用程序（170）的类似特性的应用程序所重用，并因此可被存储在存储资源（175）上以便以后使用。

该拓扑还可以保持实例化并在现有的基础设施资源（例如在选定的拓扑/模板（130）中）上跨多个应用程序重用（即当新的应用程序实例被部署并且撕去相同的基础设施）。以这种方式，所述中间件（105），并且更具体而言，服务和部署管理器（110）可以更容易地指导应用程序模型(120）和基础设施模板（130）或基础设施拓扑的匹配以在混合云（100）上部署应用程序（170）。

更进一步，应用程序模型(120）可以定义用于配置和管理应用程序（170）的生命周期的配方（例如配方描述如何且何时监控来自部署的应用程序的反馈，以及如何且何时基于这种反馈调整基础设施资源）。该配方可包括对用于执行配方的多个工件的引用，诸如安装脚本、编译配方的代码等。该配方还可以被存储在云基础设施（115）的存储资源（175）上。在一个示例中，拓扑可以用标准语言和模型来表达，诸如由Oasis®在云应用程序的拓扑和编制规范（TOSCA）中描述的那样。

模板（130）可描述与混合云（100）相关联的基础设施的能力和特征。特别地，模板可使用定义在整个混合云（100）中分布的硬件、软件和固件的资源元数据（160），以呈现为应用程序（170）可运行在其上的潜在资源。资源元数据（160）可存储在混合云环境（100）的存储资源（175）上并且可以随混合云环境（100）上的存储资源（175）和处理资源（165）以及其他资源改变而改变。

对于任何给定的应用程序来说，策略（135）可描述多个操作环境。例如，策略（135）可描述什么时候操作应用程序以及在地理上位于世界的什么服务器上将要操作该应用程序。策略（135）可进一步包含有关如何在其正在操作的服务器上保持负载平衡、应用程序将要被部署在哪一个网络域、监控需求（例如负载是否在服务器上指定的范围之间）、是否有任何安全问题以及确保在给定的时间段内没有即将到来的维护的信息。策略（135）可进一步描述如何决定把计算负载放到哪一个服务器上，基于在该服务器上操作的价格考虑。策略（135），当检测到监控或安全事件时，还可决定如何对监控或安全事件作出反应。

更进一步，策略（135）可描述关于在特定的云环境内把负载放在服务器上可出现的任何安全问题。在这个示例中，策略（135）可指示在哪种类型的云环境上操作哪部分应用程序以保护由正在执行的应用程序所提供的机密数据或任何后端服务。其他策略也可被定义：可进一步描述应用程序将在何时、何地以及如何操作。

应用程序模型(120）和模板（130）被匹配在一起（由用户手动或经由服务和部署管理器（110）以及使用多个算法的策略（135）自动）以描述应用程序应该运行在什么基础设施上，并且可用于动态地（或静态地）优化基础设施资源（特征在于元数据属性）并把其绑定到应用程序（170）。在一个示例中，策略（135）可用于帮助匹配应用程序模型(120）（其描述应用程序的需要）和模板（130）（其描述混合云（100）上的可用资源）。

在一个示例中，应用程序模型(120）和模板（130）可表达为拓扑。该拓扑可被实现以表达（与动作细节一起），其中一般的应用程序模型(120）可用来在混合云（100）上部署多个不同的应用程序（170）。这里，因为已经通过应用程序模型(120）的使用设计了应用程序（170），所以应用程序（170）可以在不重新编码应用程序来这样做的情况下转移到另一个云。在这种情况下，它在新背景下的新的环境上使用这样做所要求的拓扑被重新实例化。因此，应用程序（170）可以在异构云环境上移动（例如从一个操作系统到另一个或从一个管理程序到另一个等）。

此外，依据一个示例，公共门户（155）可以给用户提供即刻管理和保护在各种混合云（例如100）上部署的应用程序的能力。通过公共门户（155），用户可在一个共同的地方查看所有混合云（100）上的所有应用程序的活动。在一个示例中，用户还可以使用公共门户（155）手动地把应用程序模型(120）和模板（130）相匹配。

在另一个示例中，用户可以查看和潜在地编辑应用程序模型(120）和模板（130）（由中间件（105）引导）的自动匹配。因此，在操作中，中间件（105）可以执行处理资源（165）以处理定义应用程序模型(120）如何与模板（130）匹配以便部署应用程序（170）到混合云（100）上的策略（135）。中间件（105）可进一步处理描述了云（100）的云（100）资源以创建所使用的模板（130）的资源元数据（160）。中间件（105）还可以使应用程序模型(120）与模板（130）相匹配来为混合云（100）上的给定应用程序确定操作拓扑。应用程序模型(120）和混合云（100）上可用资源的匹配导致中间件（105）把这些资源绑定到应用程序（170）。如将在以后更详细地描述的，这些资源的绑定允许中间件（105）特别地在应用程序（170）的整个生命周期中为所述应用程序（170）留出那些资源。更进一步，中间件（105）可以基于确定的部署条件为云（100）部署给定的应用程序（170）。

在一个示例中，中间件（105）可进一步管理或监控（基于事件或通过查询监控/管理系统）来自给定应用程序（170）的反馈。例如，中间件（105）可监控从监控系统接收的反馈，监控系统连同应用程序（170）一起被建立（作为由应用程序模型或策略定义的配方的一部分）并且利用它来按比例扩大或缩减由应用程序（170）使用的资源；启动/停止应用程序（170）；移动应用程序（170）；启动修复（如果发生故障-恢复（例如，当基于会话时）或移动应用程序并重新定向流量）；或支持流以维修检测到的问题。生命周期管理模块（145）可与服务和部署管理器（110）一起使用来读取来自给定应用程序的反馈，并且使服务和部署管理器（110）能够调整给定程序的各方面或增加/减少为应用程序的操作所提供的基础设施资源。这例如可以经由策略（135）或描述如何处理事件以及使用中间件（105）执行必要的改变的其他逻辑来指定。

中间件（105）通过生命周期管理模块（145）及服务和部署管理器（110）可进一步提供和交付服务来为终端用户管理现有云服务和现有云服务的组合的生命周期（例如管理建立、配置和部署、执行、持续管理、报告、计量、退役等）。更具体而言，如本文所公开的，中间件（105）编排现有云服务的应用程序编程接口（API）(140)的使用，用于为使用蓝图（125）的用户终端系统的用户管理现有云服务和现有云服务的组合的生命周期。因此，服务和部署管理器（110）的功能和特征还可至少部分地由在PCT专利申请号PCT/US2012/045424中描述的服务交付模块来实现，其主题通过引用结合到本文中。

蓝图（125）可以阐述自动化动作的结构化计划用于实例化和配置可在云（100）中提供的云能力。因此，蓝图（125）可以是一组对应于特定的可经执行以编排适当的云资源的API（140）用于管理给定应用程序的生命周期目的的生命周期管理动作的工作流程/配方/脚本。在一个示例中，蓝图（125）可用来描述应用程序模型。此外，蓝图（125）可用来指导系统将如何行动（即按比例扩大/缩减和向内/向外扩展）。在这个示例中，一旦提供给应用程序的资源有改变，则网络流量可能需要相应地重路由。在另一个示例中，蓝图（125）可以描述混合云（100）如何访问混合云（100）内的各种数据库。

考虑到云（100）的各个组件之间的通信接口，可提供多个应用程序编程接口（API）（140）。每个API（140）可包括程序、数据结构、对象类和变量的规范。生命周期管理模块（145）可使用API（140）来帮助管理应用程序的生命周期。

用户可以使用设计者模块（150）来帮助设计将要在云（100）上实现的策略（135）、模板（130）、蓝图（125）和应用程序模型（120）。特别地，用户可以使用设计者模块（150）定义和配置用于在混合云（100）上部署和运行应用程序（170）的代码和元数据。用户可以使用公共门户（155）访问设计者模块（150）来为任何给定的应用程定义策略（135）、模板（130）和蓝图（125）。然而，在一个示例中，所述中间件（105）可为给定的应用程序自动地定义一些或全部的策略（135）、模板（130）和蓝图（125），从而使用户摆脱必须输入该信息并决定最好的策略（135）、模板（130）和蓝图（125）来使用。使用设计者模块（150），云服务生命周期管理可独立于实现它们所需要的资源定义。与要部署的应用程序相关联的应用程序模型(120）包含诸如通过使用设计者模块（150）选择并集成到应用程序模型（120）中的资源能力、需要的软件版本、服务质量和安全策略的信息。

如以上简要讨论的，生命周期管理模块（145）还可以被包括在中间件（105）上。生命周期管理模块（145）可使用蓝图（125）来编排混合云（100）中的服务的生命周期管理。在一个示例中，生命周期管理模块（145）可以安排生命周期操作，其中当前的应用程序部署由于生命周期操作已经从它们初始的部署状态改变了。例如，作为预定的生命周期操作的一部分，应用程序可被移动、复制或退役（或其关联的组件/工件可被移动、复制或退役），作为由生命周期管理模块（145）执行的生命周期操作的一部分。在一个示例中，在检测到事件后，应用程序可能被移动、复制或退役（或其关联的组件/工件可被移动、复制或退役）。可以通过生命周期管理模块（145）对事件进行监控，并且蓝图（125）可以包括关于如何应对这些检测到的事件的信息。生命周期管理模块（145）可以通过服务和部署管理器（110）并与之交互。再次，可以把如何应对这些检测到的事件的确定编码在策略（135）或也驱动中间件（105）作出反应的方式的逻辑中。

中间件（105）还可以提供工作负载管理（例如，基础设施资源的自动按比例扩大/缩减和向内/向外扩展以及在混合云（100）中提供最佳资源部署）。例如，基于任何给定服务器的负载或混合云（100）上的资源（或资源池/云），向外/向内扩展或把应用程序移动到另一个位置（另一个资源池/云或云的组合）的操作可基于策略准则操作执行。这可以响应于监控事件或由生命周期管理模块（145）接收到的反馈进行或者基于通过多个API对这种监控系统提出的请求进行。在一个示例中，应用程序模型（120）或蓝图（125）可以描述如何在一部分用于部署给定应用程序的云基础设施（115）中，部署（或拆卸/取消部署）应用程序。例如，应用程序模型（120）或蓝图（125）可以识别基础设施（115）资源以及从云基础设施（115）上需要什么用于给定应用程序的部署或退役。可允许用户或设计者为部署应用程序（170）而改变蓝图（125）和/或应用程序模型（120）。这种部署上的改变可在另一个云配置上实现（例如，从私有云到公共云）以为执行不同配置上的应用程序提供所需的信息，即使云是基于不同的API、网络资源等。在不同的部署上移动应用程序的示例原因例如可以包括负载平衡、从私有移动到公共配置或反之亦然、增加或减少用于应用程序的资源，以及在不同的基础设施资源上按比例扩大或缩减应用程序。再次，可以把如何应对这些检测到的事件的确定编码在策略（135）或也驱动中间件（105）作出反应的方式的逻辑中。

中间件（105）可进一步提供自动化测试管理、分期和应用程序的部署。特别地，中间件（105）可以经由服务和部署管理器（110）为任何给定的应用程序配置和启动应用程序部署的测试套件。中间件（105）可以将多个相关的测试配置成用于应用程序的多个不同的操作部署场景。配置和由此产生的应用程序部署可以在组织的云边界上进行管理以适应各种组织的需求。例如，开发可以具有一套需求并且生产可以具有一套单独的需求。在一些情况下，配置和启动应用程序的公共部署并在其他的情况下，启动私有部署。在其他情况下，如由中间件（105）配置和经由服务和部署管理器（110）部署的，启动公共和私有部署的组合。

中间件（105），例如，基于通过将应用程序模型（120）匹配到由资源元数据（160）指定的基础设施模型确定最好的匹配基础设施，使自动化开发测试、开发操作和应用程序安全开发成为可能。可以为特定的部署或测试指定应用程序模型（120）。选择使用哪一个模型（120）可以通过从一组模型中的不同模型进行选择来实现或者例如，经由把相关的标记与策略（135）中指定的不同模型类型相匹配来实现。在一个示例中，中间件（105）可以自动地选择哪一个应用程序模型（120）将与最适合的模板进行匹配并和应用程序（170）一起使用。在另一个示例中，用户可以经由公共门户（155）通过从应用程序模型（120）的列表中选择应用程序模型（120）来手动地选择要使用的应用程序模型（120）。

然后，所述匹配基础设施可用来支持测试或促进生产分期，同时也在不同的测试阶段运行各种测试套件和/或在生产阶段监控。对于开发测试，中间件（105）允许开发者在云（100）中将任何软件的开发跟随测试，其中他们可以在多个部署场景中部署和运行应用程序并且在没有通常的延迟和建立部署和测试的成本的情况下执行目标测试案例。在软件元素（例如应用程序组件）的开发和测试之后，就可以在生产（以及类似地监控）中部署和操作它们。因为安全也可以在安全的开发和生产环境中进行测试，所以这也使应用程序的安全方面测试成为可能。错误、安全漏洞和其他检测到的事件的反馈可被容易地监控并反馈给开发代表诸如用于通过公共门户（155）诊断和维修。当在生产中报告问题时，可带着错误/问题报告为开发者（或支持）重现部署条件和环境以诊断和纠正，然后可导致测试和打补丁/更新，其然后可被分期和/或测试。

此外，中间件（105）可以在给定应用程序的服务生命周期期间跟踪应用程序中的改变（例如检测版本改变）并基于检测到的改变，为云中应用程序的部署更新应用程序需求。例如，中间件（105）可以依据改变为给定应用程序更新应用程序模型（120）和/或策略（135）。可替代地，模型（120）和/或策略（135）的这种更新还可以手动地或者通过人或系统可以实现的工具/逻辑过程来执行。一般来说，应用程序经常迁移通过许多版本、部署选项、修改等。从而，应用程序、平台、服务和策略都形成服务生命周期的一部分。该服务生命周期可以随着时间的推移与组成服务的每个工件的版本一起改变。中间件（105）促进组件和应用程序的组件之间的依赖性在服务生命周期的过程中以切实可行的方式部署在云中。

中间件（105）可以模拟给定应用程序的工件和组件之间的依赖关系，然后基于给定应用程序中检测到的改变，在应用程序模型（120）或策略（135）中对其进行更新。更进一步，中间件（105）可用于开发、生产和/或操作的各个阶段，监控/跟踪版本以及在基于这种监控/跟踪的这种阶段期间实例化组件。这可包括经由闭环反馈监控阶段和监控部署实例，同时跟踪分期版本的改变以及基于这种监控启动自动部署。

此外，可对中间件（105）编程以指定可以更新策略（135）和/或应用程序模型（120）用于云（100）上给定应用程序的部署的可移植性指令。这里，中间件（105）可以命令服务和部署管理器（110）将应用程序从云（100）中的一个部署（诸如像私有云中的部署）移动到另一个部署（诸如像公共云中的部署）。可以将中间件（105）实现为包括应用程序编程接口（API）或图形用户接口（GUI），例如，以接收部署请求。如图所示，公共门户（155）可以监控云（100）中部署的反馈以为如工作负载管理（例如，按比例扩大或缩减应用程序环境和基础设施资源）的这种特征提供信息。

在一个示例中，服务和部署管理器（110）提供了多租户架构。在一个示例中，服务和部署管理器（110）可以提供多租户架构，其中服务和部署管理器（110）的应用程序（170）的单一实例为多个组织服务。服务和部署管理器（110）可以提供多租户架构，其中在不同的租户当中进行云服务分割，这意味着应用程序（170）交互作用并且数据在租户当中被安全地分开了。换言之，一个租户，一般来说，不能访问、使用、看到或影响另一个租户的数据、应用程序和/或影响其性能。策略（135）和蓝图（125）可以陈述是否且何时在混合云（100）上创建应用程序（170）的新实例。例如，如果一个租户的活动影响另一个租户的性能，那么策略（135）和蓝图（125）可以帮助确定是否应该在混合云（100）上作出应用程序（170）的另一个实例以及在何处并且采用应被实现的什么资源。一般来说，多租户混合云服务以安全的、可审计的、弹性的方式等进行提供。

蓝图（125）也可与多租户应用程序相关联以编排多个API来管理应用程序的生命周期。中间件（105）的功能和特征，例如，可由在PCT专利申请号PCT/US2012/045433中描述的系统来实现，其主题通过引用结合到本文中。

在另一个示例中，中间件（105）可以监视与混合云的构成云相关联的API的编排，以为了允许在两个或多个的构成云上执行至少一个云资源管理功能。更具体而言，可提供第一接口来管理由形成混合云的混合云资源提供的云服务。以这种方式，所述第一接口用于编排云服务，包括使用第一接口编排API以允许在至少两个云资源上执行至少一个云资源管理功能。API的编排为用户终端系统（台式机、便携式计算机、智能手机、客户端，瘦客户端、服务器等）的用户管理云服务上功能。中间件（105）的功能和特征可至少部分地由在PCT专利申请号PCT/US2012/048991中描述的系统来实现，其主题通过引用结合到本文中。

现在回到图2，依据本文所述原理的另一个示例示出了混合云（200）的框图。除了在图1中描述的云（100）的特征之外，混合云（200）可进一步包括在中间件（105）上运行并利用该中间件（105）提供的多个平台即服务（PaaS）功能（210）的服务执行环境（SEE）（或多个除其他外，用java, C#, Python, Rubby, PHP, Node.js编写的SEE的组合）（205）。在云（200）中还可以包括服务生成环境（SCE）（215）以在SEE中或跨SEE开发应用程序并利用PaaS功能。

在由本应用程序实现的优点之中，中间件（105）为SEE（205）提供作为允许部署在云（200）上的应用程序自我管理其生命周期的编程模型的一部分公开的能力。例如，应用程序（170）也许能够通过执行如上所讨论的影响其状态的修复任务（诸如扩缩、移动或调用蓝图（125）的API）来监听并对监控事件和采取生命周期管理决定（例如基于的策略或内部应用程序逻辑）作出反应。此外，采用公开的SEE（205），应用程序（170）可以对监控事件甚至关于注册和处理作出反应。更进一步，具有公开的SEE（205），应用程序可以对查询关于其本身的事件作出反应。

在图2的混合云（200）中，应用程序可以结合先前确定的策略（135）、模板（130）、应用程序模型（120）、拓扑和蓝图（125）以能够将应用程序的生命周期转变成其代码。以这种方式，应用程序可由使用策略（135）、模板（130）、应用程序模型（120）、拓扑和蓝图（125）的用户供给和部署，并且如果和当应用程序遇到生命周期管理问题（或监控事件）时，可将这些问题通知应用程序（170）。然而，应用程序（170）可以采取那些必要的措施以防止问题发生或当它们发生时修复它们。例如，如果应用程序（170）需要被按比例扩大或向外扩展以消耗另外的云资源，那么应用程序（170）可经由策略（135）简单地选择如何去做。模板（130）和蓝图（125）可进一步允许应用程序（170）选择云（200）上的哪个物理硬件要向外扩展或与之按比例扩大。

所述PaaS功能（210）以及SEE(205)和SCE（215）可作为编程模型。在这种情况下，用户，担任应用程序（170）的开发者，可在任何程度上确定何时以及如何应对如上所述的特定的监控事件。此外，PaaS功能（210）可在任何和所有类型的应用程序有权对其进行访问的云上实现。正因如此，应用程序（170）开发者可以利用在任何数量的云环境上的任何资源。

图3是依据本文所述原理的另一个示例的表示为框图的另一个混合云（300）。此处的混合云（300）可进一步包括云消息代理（305）。如上所讨论的，本说明书描述了其中中间件（105）可涉及在多个例如可以是公共、管理或私有云的混合云上操作的多个云服务的情况。云消息代理（305）在这种情况下允许消息在应用程序的单个组件或在这些云环境上散布的资源之间进行传递。

在一个示例中，事件驱动架构可用来促进某些事件的产生、检测、消耗以及对其作出反应。在这个示例中，简单通知服务（例如SNS）和简单队列服务（例如SQS）可结合API（140）使用，诸如由W3C ® 和 IETF®开发的Websocket® 。这里，代替纯粹基于http语言的云消息代理，在所述消息代理（305）中使用Websocket®。关于混合云（300）中的改变的通知可通过首先将通知发送在简单通知服务（SNS）上被发送在不同的云上。该通知可表明消息是可用于查看的。然后，该消息在简单队列服务（SQS）中排队，然后可在其中被检索。在一个示例中，定义Websocket®应用程序的编程代码可具有添加到其中的附加代码，其允许SQS添加数字到消息分组。然后，通知可被发送给预期接收者。因为每个中间件（105）组件都可在消息代理（305）上作为端点进行部署，每个组件都可使用消息代理给其他组件提供关于由于应用程序（170）管理其生命周期而在云基础设施（115）内作出的改变的信息。该扩展还可以提供在WebSocket®内请求具有与之相关联的一定数量的分组重新发送的能力。在一个示例中，如果消息旨在用于多个收件人，则可为每个收件人创建单独的队列。

在上面的示例中，因为云消息代理（305）使用Websocket®，所以可以实现云之间的双向连接。此外，Websocket®的此特征，可以保证通知的传递以及消息将被发送和接收。进一步，消息可使用SNS、SQS和Websocket®进行实时传递。

因为中间件（105）包括多个组件，可允许这些组件通过在混合云（100、200、300）上经由消息代理（305）发送消息来相互通信。正因如此，中间件（105）可被设置为促进事件的产生、检测、消耗以及对事件作出反应的事件驱动架构。在一个示例中并如先前所提到的，中间件（105）SCE（215）可为允许分布在混合云（100、200、300、400）上的应用程序及其组件自我管理其生命周期的应用程序产生代码。因此，当事件发生时，例如当应用程序确定有必要向外扩展时，应用程序可使用云消息代理（305）来通知用户、中间件（105）和应用程序的其他组件：向外扩展过程将要发生以及某些资源现在将要由应用程序消耗。在一个示例中，这允许用户看到什么资源已经被应用程序以及在整个混合云（100、200、300、400）上消耗了。这进一步允许应用程序的其他组件依据其策略（135）、模板（130）和应用程序模型（120）适当地作出反应。

图4是依据本文所述原理的另一个示例的混合云（400）的框图。在这个示例中，混合云（400）可以包括多个用于安全地操作该云（400）的附加模块。混合云（400）可以包括防火墙（405）、应用程序检查模块（410）、数据挖掘器（415）、记录器（420）、风险标识符（425）和代码漏洞扫描器以及数据中心浏览器（430）。现在将更详细地描述这些中的每一个。

防火墙（405）可检查进入到云（400）的每个分组（例如深度分组检测）。因此，到中间件（105）内的任何模块的所有通信被提升检查以便知道安全问题。现有防火墙的一个示例可以是惠普公司®的TippingPoint®。任何通信的过滤的特定结果经由公共门户（155）被通知给用户。此外，防火墙可作为蓝图（125）和/或模板（130）的一部分进行部署。

数据挖掘器（415）可以为了指示云（400）内问题的数据挖掘由中间件（105）创建的任何类型的日志。在这种情况下，中间件（105）可使多个操作并与中间件（105）相关联的模块经由例如记录器（420）（例如HP记录器®）输出日志到数据挖掘器（415）。该日志可以特定的格式输出以便数据挖掘器（415）可以读取这些日志。在一个示例中，所述格式可以是通用事件格式（CEF）。这些日志和数据挖掘器（415）的输出还可以在公共的门户（155）上显示以便管理员或用户查看。在一个示例中，数据挖掘器（415）可以是由惠普公司®开发的称为ArcSight®的产品的形式。

风险标识符（425）可以给云环境和基础设施提供实时图形和基于报告的风险识别。数据可从与中间件（105）相关联的其他模块聚合并经由公共门户（155）呈现给用户或管理员。

应用程序检查模块（410）可以搜索与由中间件（105）操作或与其相关联的代码和应用程序相关联的已知问题。这里，代码被搜索已知安全问题并且在一个示例中；应用程序检查模块（410）在应用程序被部署在云（400）上之前检查单个应用程序的代码。这样做将确保与应用程序相关联的代码没有可使它不运行或使云（400）以不期望的方式运行的行业已知问题。再次，通过公共门户（155）将警报呈现给用户或开发者，通知他或她需要对与已开发应用程序相关联的代码进行检查。在一个示例中，应用程序检查模块（410）可以是由惠普公司®开发的称为Fortify® 的产品的形式。应用程序检查模块（410）还可以监控应用程序攻击行为或缺陷模式并作为结果返回事件到中间件（105）或可通过调整策略或分别自我管理其行为（例如通过关闭端口、防止通信、移动到另一个地址、隔离本身）作出反应的应用程序（170）。

中间件（105）可进一步包括数据中心浏览器（430）。数据中心浏览器（430）允许用户或管理员经由公共门户（155）看到所有可用的资源和资源池以及任何可能的新资源。在这种情况下，数据中心浏览器（430）跟踪云（400）上部署的硬件、软件和固件的每个实例以及所有管理实例的状态和多个云环境上的所有资源和资源池的安全状态。因此，作为示例，用户通过数据中心浏览器（430）可以看到：因为他们的云（400）延伸到公共云中，如果或当那些服务需要从它们当前的状态向外/向内扩展时，有可用于他们的服务的附加资源（例如数据存储、数据处理、数据应用）供使用。

图5是依据本文所述原理的一个示例的描绘在混合云（100）上部署和管理应用程序的方法（500）的流程图。方法（500）可从中间件（105）处理（505）开始，通过处理资源（165）处理与应用程序（170）相关联的策略（135）、蓝图（125）、模板（130）、拓扑和应用程序模型（120）。然后，处理（510）与混合云（100、200、300、400）的资源相关联的元数据。在处理（510）期间，中间件（105）可以确定哪些资源可用于部署应用程序到云（100、200、300、400）上以及描述模板（130）中的那些资源。

然后，将模板（130）与应用程序模型（120）匹配（515）以为混合云（100、200、300、400）上的应用程序（170）确定拓扑。这里，可用于应用程序部署在云（100、200、300、400）上的那些资源被绑定到应用程序（170）以给在部署的应用程序（170）提供基础设施。

然后，应用程序可基于被绑定到应用程序（170）的确定为可用的拓扑被部署（520）在混合云（100、200、300、400）上。在部署之后，该应用程序的生命周期就可被监控（525）。在一个示例中，生命周期管理模块（145）可以监控（520）如上所述的应用程序的生命周期。在另一个示例中，策略（135）、蓝图（125）和模板（130）可以为应用程序定义应用程序如何监控本身。因此，如上所述，与策略（135）、蓝图（125）和模板（130）相关联的代码允许应用程序，当面对问题时，解决所述问题，而不必依赖于中间件（105）来修复这些问题。再次，如上所述，应用程序（170）也许能够通过执行如上所讨论的影响其状态的修复任务（诸如扩缩、移动或调用蓝图（125）的API）来监听并对监控事件和采取生命周期管理决定（例如基于的策略或内部应用程序逻辑）作出反应。此外，采用公开的SEE（205），应用程序（170）可以对监控事件甚至关于注册和处理作出反应。更进一步，具有公开的SEE（205），应用程序可以对查询关于其本身的事件作出反应。

本说明书进一步为在混合云（100、200、300、400）上部署和管理应用程序设想计算机程序产品。该计算机程序产品包括包含以其体现的计算机可用程序代码的计算机可读存储介质。计算机可用程序代码可包括，当由处理资源（165）执行时，处理（505）与应用程序（170）相关联的策略（135）、蓝图（125）、模板（130）和应用程序模型（120）的计算机可用程序代码。计算机可用程序代码可进一步包括，当由处理资源（165）执行时，处理与混合云（100、200、300、400）的资源相关联的元数据的计算机可用程序代码。计算机可用程序代码还可包括，当由处理资源（165）执行时，确定哪些资源可用于部署应用程序到云（100、200、300、400）上以及描述模板（130）中的那些资源的计算机可用程序代码。更进一步，计算机可用程序代码可包括，当由处理资源（165）执行时，将多个模板（130）与应用程序模型（120）匹配以为混合云（100、200、300、400）上的应用程序确定拓扑的计算机可用程序代码。更进一步，计算机可用程序代码可包括，当由处理资源（165）执行时，将混合云（100、200、300、400）上可用的资源绑定到应用程序（170）以给在部署的应用程序（170）提供基础设施的计算机可用程序代码。

计算机可用程序代码可包括，当由处理资源（165）执行时，基于被绑定到应用程序（170）的确定为可用的拓扑将应用程序（170）部署在混合云（100、200、300、400）上的计算机可用程序代码。计算机可用程序代码还可包括，当由处理资源（165）执行时，监控应用程序（170）的生命周期的计算机可用程序代码。

本说明书和附图描述了在云上操作的云中间件。云中间件可包括服务和部署管理器以及生命周期管理模块以提供应用程序在混合云上的创建、部署和生命周期管理。该云中间件可具有多个优点，包括提供自动化和编排环境，其中部署在混合云上的应用程序被配置使得其一旦部署就将管理自己的生命周期，从而允许云管理员测试和变更定义应用程序的代码以便应用程序可以适当的方式动态地对云内的事件作出反应。此外，本云中间件提供应用程序到混合云上的安全开发和部署。更进一步，该云中间件允许用户在一个视图中查看整个混合云，从而给用户知道什么资源将被应用程序消耗以及如何在整个混合云上最好地分布应用程序的组件或部分的能力。该云中间件进一步提供更便捷的应用程序设计过程，如用于引导应用程序组件如何并在何种程度上被分布在混合云上的信息可稍后用于开发和部署其他应用程序到混合云上。

为说明和描述所述原理的示例，已呈现了前面的描述。该描述并不意在详尽或将这些原理限制在公开的任何精确的形式。根据以上教导，许多修改和变化是可能的。

Claims

1.一种混合云环境，包括：

处理资源，用于在多个云环境上部署和管理应用程序；

存储资源，用于存储云中间件，所述云中间件包括：

服务和部署管理器，用于通过处理资源在混合云基础设施上部署应用程序，其中通过把可用的混合云基础设施能力与描述应用程序的资源需求、属性和特性的应用程序模型相匹配，将应用程序部署在混合云基础设施上；以及

生命周期管理模块，用于管理应用程序和关联的混合云基础设施的生命周期。

2.如权利要求1所述的混合云环境，其中生命周期管理模块公开了多个应用程序编程接口(API)以管理混合云上的应用程序的生命周期。

3.如权利要求1所述的混合云环境，进一步包括云消息代理以将消息发送到混合云中的多个云内和云间分布的中间件服务或单个资源并从其接收消息；

其中，每个资源被视为端点。

4.如权利要求3所述的混合云环境，其中云消息代理使用导致收件人从简单队列服务(SQS)接收消息的简单通知服务(SNS)交换消息；

其中简单通知服务(SNS)和简单队列服务(SQS)两者都使用应用程序编程接口(API)作为双向消息传输以确保消息的实时传递。

5.如权利要求4所述的混合云环境，其中所述简单队列服务(SQS)使用分组编号扩展将数字添加到消息并且其中该数字用于允许收件人请求消息的重传以确保可靠传递。

6.如权利要求1所述的混合云环境，其中所述生命周期管理模块将策略和应用程序相关联以使应用程序自我管理其生命周期，所述策略描述：

应用程序如何对多个监控，管理，或安全事件，或多个发送到云中间件中的管理，监控或安全模块的请求的结果作出反应；

自我管理的应用程序如何在对多个监控事件作出反应时实现或更新策略；

中间件如何对多个监控，管理或安全事件，或多个发送到云中间件中的管理，监控或安全模块的请求的结果作出反应，通过：

调用多个由中间件作为中间件服务提供的应用程序编程接口(API)；或

触发多个在混合云上管理多个云资源的生命周期的蓝图；蓝图的触发导致应用程序如何自我管理其生命周期、应用程序如何使用资源、以及资源的生命周期的改变。

7.如权利要求1所述的混合云环境，进一步包括：

防火墙，用于检查进入混合云的多个数据分组；

应用程序检查模块，用于搜索与和中间件相关联的代码和应用程序相关联的已知问题；

数据挖掘器，用于挖掘由中间件创建的和从记录器输出的日志文件，其中数据挖掘器搜索指示混合云内问题的数据；

风险标识符，用于给混合云和基础设施提供实时图形和基于报告的风险识别；

数据中心浏览器，用于允许用户经由用户接口看到混合云上的所有可用资源；或

其组合。

8.一种用于混合云环境的系统，包括：

存储在与混合云环境相关联的云服务器的存储资源上的服务生成环境(SCE)，用于接收来自用户的输入以通过处理资源为应用程序建立应用逻辑；以及

多个存储在云服务器的存储资源上的服务执行环境(SEE)，用于通过处理资源执行由服务生成环境(SCE)创建的应用程序；

其中，应用逻辑包括使应用程序自我管理其生命周期同时部署在混合云环境上的逻辑；以及

其中，应用程序依赖于由在整个混合云环境上分布的云中间件提供的应用程序编程接口(API)、事件和资源。

9.如权利要求8所述的系统，进一步包括生命周期管理模块，其中生命周期管理模块将策略和应用程序相关联，一旦由服务执行环境(SEE)执行，使应用程序自我管理其生命周期，所述策略描述：

应用程序如何对多个监控，管理或安全事件，或多个发送到云中间件中的管理，监控或安全模块的请求的结果作出反应；

自我管理的应用程序如何在对多个监控事件作出反应时实现或更新策略；以及

触发多个在混合云上管理多个云服务的生命周期的蓝图；蓝图的触发导致应用程序如何自我管理其生命周期、应用程序如何使用资源、以及资源的生命周期的改变。

10.如权利要求8所述的系统，其中所述云中间件进一步包括云消息代理，其中云消息代理将消息同步或异步发送到在混合云环境中的多个云内和云间分布的应用程序的单个组件并且从其接收消息。

11.如权利要求10所述的系统，其中所述云消息代理进一步包括：

简单通知服务(SNS)和简单队列服务(SQS)，用于促进资源之间的消息的交换；以及

应用程序编程接口(API)，其中简单通知服务(SNS)和简单队列服务(SQS)两者都使用应用程序编程接口(API)作为双向消息传输以确保消息的实时传递；

其中，关于在混合云中发生的事件的通知由多个端点接收并由简单队列服务(SQS)排队；

其中，每个通知都接收消息分组，其中消息分组具有由简单队列服务(SQS)关联到它的分组编号；以及

其中，消息的通知被发送到预期收件人。

12.一种混合云上的事件驱动架构，包括：

存储在与混合云环境相关联的云服务器的存储资源上的消息代理，用于将消息发送到混合云环境中的多个云内和云间分布的单个资源并从其接收消息；

其中，在混合云环境中的多个云内和云间分布的每个资源被视为端点，

其中所述消息代理在混合云中的多个云内和云间执行和存储在存储资源上的中间件上运行，

其中所述中间件进一步包括由用户通过公共门户可访问的服务生成环境(SCE)，其中服务生成环境(SCE)接收来自用户的输入，以通过处理资源为应用程序建立应用逻辑；以及

多个服务执行环境(SEE)，用于执行由服务生成环境(SCE)创建的应用程序；

其中，所述消息代理使通知在检测到混合云上发生的事件时被发送到受影响的单个资源。

13.如权利要求12所述的事件驱动架构，其中所述消息代理进一步包括：

其中，每个通知都接收消息分组，其中消息分组具有由简单队列服务(SQS)关联到消息分组的分组编号；以及

其中，消息的通知被发送到预期收件人。