数据中心编程模型的制作方法

专利名称：数据中心编程模型的制作方法
数据中心编程模型背景大规模数据中心是相对较新的人类产物，而其组织和结构随着其提供的商业机会 的增加而快速地进化。典型的现代数据中心是运行标准软件包集合的硬件群集的有组织的 集合，诸如由高速联网、路由器和防火墙互连的web服务器数据库服务器等等。组织这些机 器、优化它们的配置、调试它们配置中的差错以及在构成机器上安装和卸载软件的任务在 很大程度上留给了操作人员。数据中心所支持的web服务(例如，作为服务的软件“Mas”)也正在快速地进化 (例如，公司可能首先提供搜索服务，随后提供电子邮件服务，然后提供地图服务等等)。这 些服务依赖于被分发到一个或多个数据中心且由一个或多个数据中心托管的应用。服务运 营者和数据中心运营者通常加入对具体硬件资源(例如，处理器的数量、盘空间、存储器、 带宽等等)的协议。典型的安排按照提供服务的应用“存活”在专用服务器上的方式来将 特定数量的服务器和盘空间贡献给服务。当条件改变时，这种类型的安排招致数据中心和 服务运营者的大量管理开销。例如，数据中心运营者可以升级影响服务的应用的执行的各 种硬件组件。在该示例中，硬件改变可以生成迫使服务运营者修订或重新开发其应用来解 决这些改变从而向服务的最终用户确保可接受的服务水平的连锁效应。本文描述了关于可以便于应用开发、托管和执行的体系结构和编程模型的各种示 例性技术。概述一种示例性方法包括在数据中心处托管服务，该服务依赖于根据编程模型而开发 的至少一个软件组件，并且该数据中心包括抽象该数据中心的资源的相应的编程模型抽象 层；接收对该服务的请求；以及响应于该请求，将数据中心的至少某些资源分配给该服务 来允许履行该请求，其中该编程模型抽象层至少部分地基于对至少一个软件组件中的资源 类的引用来执行分配，可以修改该资源类来解决数据中心的一个或多个资源的改变。还描 述了各种其他设备、系统和方法。附图描述参考以下附图描述非限制性和非穷尽的示例

图1是应用开发、部署和托管的常规方法以及包括编程模型和用于抽象数据中心 的资源的相应的抽象层的示例性方法的框图；图2是编程模型以及用于抽象数据中心的资源的相应的抽象层的示例性体系结 构的框图；图3是示例性编程模型抽象层和实际的物理资源以及表示数据中心内的虚拟资 源的虚拟化层的框图；图4是用于部分地基于例如在接收请求时资源的可用性来分配资源以履行对服 务的请求的示例性技术的框图；图5是包括多个服务、服务级协定和事件跟踪的示例性方案的框图；图6是应用代码和引用资源类和事件跟踪的编程模型抽象层的近似逻辑的表示的框图；图7是其中编程模型抽象层可以例如部分地基于应用中的语句或引用来分发组 件和/或提供组件的并行执行的示例性方案的框图；以及图8是示例性计算设备的框图。详细描述示例性编程模型允许开发者开发以数据中心的编程模型抽象层为目标的应用 (例如，Web服务的应用)。该编程模型抽象层可以使用数据中心资源来监督应用的执行。 因此，开发者可以在不必知道关于数据中心的服务器、存储设备等某些具体细节的情况下 开发要由数据中心托管的应用。如此处所描述的，示例性编程模型和相关联的抽象层抽象数据中心资源，从而将 应用开发者与数据中心资源及其操作、维护等各方面隔离。该系统还可便于服务和数据中 心运营者之间的协商、增强服务的质量并降低成本。图1示出用于托管服务的常规方法101和示例性方法201。这些方法中的每一个 参考应用开发阶段103、应用部署阶段105、应用托管阶段107和应用使用阶段109来描述。对于常规方法101，在开发阶段103，开发者根据编程模型110来选择和开发应用 120。如图所示，编程模型110包括可被依赖来执行所发开的应用120中的特定功能的各个 类115。类115可以将操作计算机140的操作系统(OS) 130作为目标。作为替换，类115可 以将运行时引擎或虚拟机作为目标，该运行时引擎或虚拟机可以是可存在于应用120和OS 130之间的软件层。在部署阶段105，服务运营者将所开发的应用120部署到数据中心150。如图所示， 数据中心150包括各资源152-1，152-2，. . .，152_n。在部署阶段105期间，数据中心运营 者通常将应用120分配给具体资源。如所指示的，在托管阶段107，专用资源152-2托管应 用 120。一旦被托管，在使用阶段109，用户可以经由用户计算机160来请求使用应用(即， 服务)。在数据中心150接收到请求之后，该请求通过在专用资源152-2上执行应用120来
两足。如“托管成本”框所指示的，在常规方法101中，服务运营者对为该服务独占地保 留的资源152-2的使用记账。在常规方法101中，如果数据中心运营者执行影响资源152-2的硬件升级，则服务 运营者可以感受到这一改变的影响。例如，如果数据中心运营者升级服务器硬件和/或软 件，则应用120可能无法正确地执行或尽可能高效地执行。在这种情形中，数据中心运营者 可能无法直接通知服务运营者提供给最终用户的服务中的故障或延迟。相反，服务运营者 可能接收到来自不满的最终用户的投诉。进而，服务运营者可能向数据中心运营者投诉并 从而对关系施加压力，甚至要求托管成本的重新协商或主张违反合同的判断。虽然服务运 营者和数据中心运营者之间的服务级协定可以解决由于升级而导致的服务中断，但最终双 方的目标是提供可接受的服务。相反，示例性方法201依赖于将各种角色和责任转移给数据中心运营者且对服务 提供者施加附随义务的示例性编程模型210和相关联的编程模型抽象层255。如图1所示， 在开发阶段103，开发者使用示例性编程模型210来开发示例性应用220，而在部署、托管和使用阶段105、107和109，示例性数据中心250依赖于编程模型抽象层255来管理应用220 的资源。在示例性方法201中，编程模型210包括可被适当地放在应用220的应用代码中 的类215。类215包括编程模型抽象层255的资源管理专用的各个类。例如，类215可以包 括限制每单位时间的成本的成本类，设置每一请求的CPU功率的最小量的CPU类，设置每一 请求的RAM的最小量的存储器类，等等。因此，编程模型210可以包括在每一请求的基础上 设置某些要求的类215之中的一个或多个类。因为请求的数量可以改变或可以是未知的， 所以这种方法允许服务运营者和数据中心运营者在协商时具有某种灵活性，即，这种方法 可以减轻将资源专用于服务运营者的需求。如此处所描述的，可以将专用于数据中心250中的应用220的管理的类集中(例 如，表现为特定代码部分)在应用220的代码中或分布在整个应用220的代码中。此外，可 以一次(例如，在抽象层255的初始评估期间)或多次(例如，周期性地或只要数据中心 250中的条件发生改变时)依赖这些类。例如，应用220的一部分代码可以要求之后是引用 一组类215中的资源类的语句的具体功能，该资源类例如在给定典型的用户请求的情况下 为该功能指定合适的存储器。在部署阶段105，在接收到应用220之后，编程模型抽象层255可以执行资源类的 所有语句来确定或估计响应于每一用户请求所需的资源要求和资源特性。这种分析还可以 帮助数据中心运营者确定托管应用220的成本，如“托管成本”框所指示的，它指的是“基于 模型”的成本方法。在托管阶段107，编程模型抽象层255可以依赖资源类来将托管特征赋予应用 220。在使用阶段109，因为可能不存在将应用220托管在数据中心250内的具体专用资源 上的要求，所以在数据中心250接收到请求时，可以依赖托管特征从而为应用220的执行提 供“可用”资源来满足该请求。取决于托管特征，“可用”资源可以是满足服务运营者的预期 的低成本、高成本等资源(例如，如在开发阶段103期间被直接编程到代码中)。在该示例 中，“可用”资源可由允许在管理资源时具有更多灵活性的数据中心运营者来确定(例如，为 了最低成本、为了维护等等)。在使用阶段109，在应用220的实际执行期间，可以针对实际资源需求忽略资源语 句或偶尔对资源语句进行标记和定基准。编程模型抽象层255可以将这种信息存储在日志 中以供在管理应用220或管理一个或多个其他应用时使用。总体上，示例性方法201允许数据中心运营者在不必受到常规的、不灵活的专用 资源方法101绑定的情况下管理其对于服务的义务。图2示出图1的编程模型210和抽象层255的示例性体系结构观0。编程模型210 包括类215，类215进一步包括常规类216和资源类217。在构建或开发步骤观3中，根据 编程模型210来构建应用220，并且应用220包括常规类221的语句和资源类223的语句。 在部署步骤观5中，将应用220部署到包括数据中心资源252的数据中心，在那里至少某些 资源支持编程模型抽象层255。如图2的示例所示，编程模型抽象层255包括类库模块256、 数据中心信息模块257和托管成本模块258。在传播步骤286中，数据中心信息模块257行 动来将重要的数据中心信息传播给类库模块256和/或托管成本模块258。进而，如果类库 模块256确定需要对编程模块210中的类215升级(例如，修订、添加等等)，则作出这些改变来确保编程模型210保持对编程模型抽象层252及其底层数据中心资源有效。如此处所描述的，一种示例性方法可以包括在数据中心处托管服务，该服务依赖 于根据编程模型而开发的至少一个软件组件，并且该数据中心包括抽象该数据中心的资源 的相应的编程模型抽象层(参见，例如，图1的编程模型210、应用220、数据中心250和抽 象层25 ；接收对该服务的请求(参见，例如，图1的使用阶段109)；以及，响应于该请求， 将数据中心的至少某些资源分配给该服务来允许履行该请求，其中编程模型抽象层部分地 基于对至少一个软件组件中的资源类的引用来执行分配，可以修改该资源类来解决数据中 心的一个或多个资源的改变(参见，例如图1的编程模型210的类215)。例如，资源类可以 是处理器资源类、存储器资源类、带宽资源类或另一类型的资源类。如以下更详细地描述的，编程模型抽象层在分配资源以履行请求时，可以考虑在 接收到请求时数据中心内的可用资源。在各示例中，响应于对服务的第一请求所分配的至 少某些资源可以与响应于对服务的第二请求所分配的资源不同。例如，这种差异可以取决 于在第一时刻和第二时刻数据中心内的资源利用。此外，这种差异可以是实际资源、虚拟资 源或实际和虚拟资源的差异。如上所述，示例性编程模型和编程模型抽象层可以将服务与资源的改变隔离。例 如，代替修订服务的代码，数据中心运营者可以改为基于数据中心的硬件资源或其他资源 的改变来修改资源类。以此方式，服务的代码(例如，服务的软件组件)可以在不需要任何 修改的情况下部分地使用所改变的硬件资源或其他资源来执行。这种方法可以有效地减轻 服务运营者必须处理数据中心资源的改变的负担。例如，一种示例性编程模型和编程模型 抽象层可以将服务的软件组件与数据中心内的服务器的数量的变化隔离、与数据中心内的 处理器的类型的变化隔离，等等。如此处所描述的，一种示例性方法可以包括响应于对服务的请求提供资源类以供 在将一种类型的物理资源分配给数据中心所托管的服务时使用；使用该类型的物理资源来 执行软件组件；改变该类型的物理资源的特征；修改资源类；以及使用所改变的类型的物 理资源来执行软件组件，其中修改资源类将软件组件与改变隔离。如以下进一步描述的，服务可以依赖数据中心所托管的或甚至外部托管的另一服 务。在这些情形中，可以存在用于其他服务的服务级协定。一种示例性方法可以包括在其 他服务的执行期间执行事件跟踪来收集足够的信息以确定其他服务是否符合服务级协定 中的一个或多个条款。虽然参考服务级协定来描述事件跟踪，但还可以在一个或多个其他 上下文(例如，根据服务的软件组件中的一个或多个语句)中使用事件跟踪。图1的示例性方法201可以被认为是服务的一种体系结构，其中该体系结构包括 供数据中心实现的编程模型和相应的编程模型抽象层；以及根据编程模型而开发并由数据 中心托管的服务，其中编程模型抽象层响应于对服务的请求，例如，部分地基于对服务的至 少一个软件组件中的资源类的引用将数据中心的至少某些资源分配给该服务，可以修改资 源类来解决数据中心的一个或多个资源的改变。图3示出编程模型抽象层355可以藉由其来与实际资源352和/或依赖于实际资 源的虚拟化层3M进行接口的示例性安排300。虚拟化层3M可以操作一个或多个虚拟机 或依赖于实际资源352中的一个或多个的其他虚拟资源。例如，编程模型抽象层355可以 实例化一个或多个虚拟机来响应于请求来执行应用。在另一示例中，编程模型抽象层355可以通过直接管理至少某些实际资源352或者通过经由虚拟化层3M来间接地另外管理实 际资源352来满足请求。图4示出带有对资源的需求的波动的示例性数据中心450。在图4的示例中，曲线 451示出对CPU和RAM资源的随时间变化的需求，这两者不一定按照对于时间相似的方式来 变化。曲线451标识了两个时刻时刻A和时刻B。在时刻A，CPU需求是高的而RAM需求 中等，而在时刻B，CPU需求是低的而RAM需求相对较高。数据中心450的一种示例性编程 模型抽象层455可以按照解决当前的资源需求的方式来将资源分配给请求。考虑用户计算 机460发出对数据中心450所托管的应用420的请求。如分配框490所示，在时刻A，编程 模型抽象层455向应用420分配了刀片452-4和虚拟机454-4 ；而在时刻B，编程模型抽象 层455向应用420分配了三个刀片452-2、452-3和452-4。因此，在RAM使用是低的情况 下，编程模型抽象层451可以决定更多地依赖虚拟化层454 ；而当RAM使用较高而CPU使用 低的情况下，编程模型模型抽象层451可以决定更多地依赖实际硬件(例如，刀片)。图5示出其中应用520依赖另一应用或服务525的示例性场景。在该示例中，应 用520包括客户机侧组件521，服务器侧组件522和依赖应用525的服务器侧组件523。如 所指示的，应用520的开发者(例如，应用520所提供的服务的所有者)和应用525的开发 者(例如，应用525所提供的服务的所有者)之间存在服务级协定570。服务级协定570通 常指定应用525对于某些条件的最小标准以及使用应用525的特许权。应用525可以被认 为是提供其他应用可以集成到服务包中的某种功能(例如，GPS信息)的按需应用或服务。如图5的示例所示，应用520的两个服务器侧组件522和523由数据中心550托 管并且向编程模型抽象层555注册。此外，应用525由数据中心550托管并且向编程模型 抽象层555注册。因此，编程模型抽象层555可能已经知道了应用520和应用525之间的 关系。数据中心550内还包括事件跟踪(ET)模块595，该模块可以依赖各种硬件和/或 软件来跟踪数据中心550内的事件。例如，ET模块595可以与资源552和/或虚拟化层554 进行通信来收集关于给定请求的事件次序的信息。考虑用户经由用户设备560从应用520 的客户机侧组件521发出请求。在编程模型抽象层555接收到所发出的请求之后，分配资 源来允许组件522和523以及应用525的执行。编程模型抽象层555可以知道应用525的 服务级协定，并且在分配资源时将其考虑在内(例如，来确保遵从SLA 570)。如组件/应用对时间的事件曲线所指示的，基于事件跟踪模块595所收集的数据， 首先使用所分配的虚拟层资源5M-2来执行组件522，接着使用所分配的实际资源552-1来 执行应用525，然后使用所分配的虚拟层资源5M-3来执行组件523。这些执行中的每一个 之间，存在表示或至少包括传递(例如，从一个组件/应用到另一组件/应用)信息的通信 时间的时间间隙。由于应用525所提供的服务与组件522和523相比可能被更频繁地请求，所以编 程模型抽象层555可以与组件522和523不同地对待应用525所提供的服务。例如，应用 525可以被认为具有将其分配偏向更持久的实际资源552而非虚拟层资源M4的特性，这可 以在按需的基础上创建和毁坏。在应用525依赖诸如卫星系统等外部输入的情况下，可以 永久地将某些实际资源552链接到外部输入并形成可以执行应用525的一组资源。如可以理解的，在应用(组件)互相依赖的情况下，编程模型抽象层555可以解决这种互相依赖性并且使用一个或多个事件跟踪模块595来要求事件跟踪。还可以使用事 件跟踪信息来确定是否满足服务级协定。在一个示例性编程模型中，类可任选地包括要求 事件跟踪的一个或多个类。这种事件跟踪可以独立于编程模型抽象层发生，或者可以由编 程模型抽象层管理。虽然事件跟踪引入了某些开销，但出于各种有利目的中的任何一个，可 以使用所收集的信息来改进系统(例如，改进性能、故障诊断、较低的成本、确认服务级等
寸J ο图6示出示例性应用代码620和相应的编程模型抽象层(PMAL)655。代码620是 可用于实现诸如类似图5的设备560的移动计算设备的地图服务之类的服务的某种代码的 近似逻辑的表示。代码620包括依赖于一般与数据中心内的或者原本可以经由数据中心访 问的资源(参见，例如，图2的资源类217)有关的编程模型类的PMAL部分。在图6的示例 中，代码620引用类PMAL.Comps，该类指示组件的数量(如果已知的话)；类PMAL.Ext，该 类指示代码620所依赖的外部应用或服务的数量；类PMAL. SLA,该类指示代码620至少部 分地根据服务级协定来操作，以及 ’类PMAL. Advertising,该类指示应用代码620可以包括 广告。如此处所描述的，广告可以帮助抵消与在使用PMAL 655来操作的数据中心处托管并 执行代码620相关联的成本。代码620包括两个组件622和623。组件622解析经由可能安装了客户机侧组件 621的用户设备从用户接收的地图请求。组件622执行包括调用外部应用625在内的各种 任务。由于服务级协定(SLA) (ID 34256)涉及外部应用625的使用，所以应用代码620的 开发者已经插入了调用数据中心的事件跟踪的PMAL. ET语句。可以使用事件跟踪来收集关 于外部应用625 (可由数据中心托管)的执行的信息来确定是否满足SLA的一个或多个条 款(即，来确定所提供的实际服务级是否满足服务级协定中指定的服务级)。组件623生成供传输给用户的设备的客户机侧组件612的图形。另外，它能够将 广告插入到所生成的图形中。如此处所描述的，代码620对PMAL. Advertising的引用可以 使得PMAL 655将组件623与广告投放服务相关联。因此，在响应于用户的请求来执行代码 620期间，PMAL 655确保广告被组件623接收。关于图形的生成，组件623需要特定量的存储器和CPU资源。为了帮助PMAL 655 管理资源并将资源分配给应用组件623，代码620引用与一个或多个存储器和CPU密集语句 (例如，“生成位图”)相关联的PAML. Mem类和PMAL. CPU类。虽然存在分析应用代码来确定执行所需的资源量的常规技术，但这种事后技术实 现起来很麻烦。相反，组件623中引用的资源类可以肯定地引导PMAL655以合适的水平来 分配资源，如应用代码620的开发者所估计的。实质上，这使得将负担转移到服务(应用代 码620所提供的)运营者，借此运营者声明“为了执行这一任务，我想要大约X的存储器 和Y的CPU资源”。进而，PMAL655可以用它认为合适的无论什么方式来分配资源以管理服 务运营者的需要(例如，关于用户)以及数据中心的运营需要(例如，为了优化数据中心效 率)。给定代码620及其资源引用，PMAL 655可以估计每一请求的成本并将这一估计发 送给操作经由应用代码620的执行而提供的服务的服务运营者。这种方法便于数据中心管 理并且可以减轻协商资源成本和资源专用的需要。这种方法提供了用于部署、托管和使用 服务并且甚至可以集成广告和对广告收入进行记账(例如，对服务运营者的支付、保存支持广告的服务的折扣等等)的商业模型。图7示出其中托管应用720的数据中心750接收复杂查询701来为这些查询提供 服务的示例性场景。在该示例中，编程模型抽象层755接收查询并确定可以通过分配应用 资源752-1、752-2和752-3来满足该查询。例如，编程模型抽象层755可以允许应用720 至少部分地并行操作来快速处理复杂查询701。进而，应用720用分布式的方式来操作以处 理查询701的部分，并且随后合并结果来生成查询结果703。应用720的开发者可以允许通 过引用一个或多个资源类来允许这种并行处理，该一个或多个资源类引导编程模型抽象层 755按照允许对应用720的至少某些组件的并行执行的方式来分配资源。在图7的示例中，开发者可以引用关于来自应用720的用户的输入的特定类。例 如，如果X > 3 (其中X等于项)，则分配资源来执行应用720的组件的多个副本。如此处所 描述的，存在便于使用并行处理的各种机会。这种方法对服务运营者和数据中心运营者两 者可以都有利，因为数据中心运营者通常想要维持可用资源的完全使用并且这么做通常会 加速服务时间。例如，在存在机会窗口的情况下，在接收到用户要使用例如四个可用刀片的 请求之后，数据中心随后应该充分利用这一机会。如此处所描述的，一种示例性编程模型和相关联的编程模型抽象层可以动态地操 作来增强用户体验和数据中心性能和利用两者。在服务具有通常过度指定的专用资源的情 况下，常规的方法受到了限制。进而，资源常常处于等待中。与这种常规方法相关联的成本 被传递给一方或多方-通常以混淆解决方案的方式。此处描述的示例性方法合并数据中心 和服务运营的各个方面，进而通过对编程模型和/或编程模型抽象层作出调整方便了相互 促进的解决方案。如上所述，这种方法可以帮助将用户和服务运营者与日常数据中心基础 结构维护和升级进行分离。在数据中心包括事件跟踪技术的情况下，经由事件跟踪所收集的信息可以便于资 源的获取和借出获取(例如，预配任务)。此外，事件跟踪可以允许关于是否满足服务级协 定的更准确的成本评估、基准确定和决定。虽然参考单个数据中心来示出各个示例，但服务运营者可以将应用部署到多个数 据中心。如此处所描述的，对于服务运营者和多个数据中心的一个或多个运营者有利的是 在本质上依赖同一个编程模型，且在编程模型抽象层中出现合适的变形来结局数据中心之 间的物理差异。以此方式，开发者不会有数据中心之间的差异的负担。对于旨在经由某种互相关应用或组件来扩展服务的服务运营者而言，一种示例性 编程模型抽象层可以便于这种扩展，因为总的方法固有地比需要协商资源增加的常规方法 更加可伸缩，无论资源的增加是由运营者对服务的改变所驱动的还是由对服务的用户需求 的提升所驱动的。图8示出了可用于实现各示例性组件并形成示例性系统的示例性计算设备800。 例如，图1的数据中心150或250的计算设备可以包括设备800的各种特征。在非常基本的配置中，计算设备800通常包括至少一个处理单元802和系统存储 器804。取决于计算设备的确切配置和类型，系统存储器804可以是易失性的(诸如RAM)、 非易失性的(诸如ROM、闪存等)或是两者的某种组合。系统存储器804通常包括操作系统 805、一个或多个程序模块806，且可以包括程序数据807。操作系统805包括基于组件的框 架820，其支持组件(包括属性和事件)、对象、继承、多态性、反射，并且提供面向对象的基于组件的应用程序编程接口(API)，诸如由华盛顿州雷蒙德市的微软公司制造的.NETTM框 架的API。计算设备800具有由虚线808划分的非常基本的配置。同样，一终端可具有更少 的组件，但将与可具有这一基本配置的计算设备交互。计算设备800可具有附加特征或功能。例如，计算设备800还可包括附加数据存 储设备(可移动和/或不可移动)，诸如例如磁盘、光盘或磁带。这样的附加存储在图8中 由可移动存储809和不可移动存储810例示。计算机存储介质可包括以用于存储诸如计算 机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非 易失性、可移动和不可移动介质。系统存储器804、可移动存储809和不可移动存储810都 是计算机存储介质的示例。计算机存储介质包括，但不限于，RAM、R0M、EEPR0M、闪存或其他 存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁带盒、磁带、磁盘存储或其他 磁性存储设备、或能用于存储所需信息且可以由计算设备800访问的任何其他介质。任何 这样的计算机存储介质都可以是设备800的一部分。计算设备800也可具有诸如键盘、鼠 标、笔、语音输入设备、触摸输入设备等的输入设备812。也可包括输出设备814，如显示器、 扬声器、打印机等等。这些设备在本领域中是已知的，这里就不再对它们进行详细讨论。计算设备800还可包含允许该设备诸如通过网络来与其他计算设备818进行通信 的通信连接816。通信连接816是通信介质的一个示例。通信介质通常可以具体化为计算 机可读指令、数据结构、程序模块等。通信可以经由有线(例如，有线网络、直连线连接等 等)或无线(例如，声学、RF、红外和其他无线传输)来发生。尽管用结构特征和/或方法动作专用的语言描述了本主题，但可以理解，所附权 利要求书中定义的主题不必限于上述具体特征或动作。相反，上述具体特征和动作是作为 实现权利要求的示例形式公开的。
权利要求
1.一种方法，包括在数据中心处托管服务，所述服务依赖于根据编程模型而开发的至少一个软件组件， 并且所述数据中心包括经由硬件和软件实现的、抽象所述数据中心的资源的相应的编程模 型抽象层；经由网络接收对在所述数据中心处托管的所述服务的请求；以及响应于接收到所述请求，将所述数据中心的至少某些资源分配给所述服务来允许履行 所述请求，其中所述编程模型抽象层部分地基于对所述至少一个软件组件中的资源类的引 用来执行所述分配，可以修改所述资源类来解决所述数据中心的一个或多个资源的改变。
2.如权利要求1所述的方法，其特征在于，所述数据中心的资源包括硬件资源、依赖硬 件资源的虚拟资源、或硬件资源和虚拟资源的组合。
3.如权利要求1所述的方法，其特征在于，所述资源类包括处理器资源类、存储器资源 类和带宽资源类中的一个或多个。
4.如权利要求1所述的方法，其特征在于，所述分配考虑在接收到所述请求的时刻所 述数据中心内的可用资源。
5.如权利要求1所述的方法，其特征在于，所述请求包括在第一时刻接收的第一请求， 并且所述方法还包括重复在第二时刻接收第二请求，其中所述分配将至少某些资源分配给 所述第一请求并且将至少某些资源分配给所述第二请求。
6.如权利要求5所述的方法，其特征在于，响应于所述第一请求分配的至少某些资源 与响应于所述第二请求分配的至少某些资源不同，其中差异取决于在所述第一时刻和所述 第二时刻所述数据中心内的资源利用，并且可任选地其中差异包括实际资源、虚拟资源、或 实际和虚拟资源的差异。
7.如权利要求1所述的方法，其特征在于，还包括基于所述数据中心的硬件资源的改 变来修改所述资源类，可任选地其中所述至少一个软件组件在不需要对其代码的任何修改 的情况下部分地使用所改变的硬件资源来执行。
8.如权利要求1所述的方法，其特征在于，所述编程模型和所述编程模型抽象层将所 述至少一个软件组件与所述数据中心内的服务器的数量的改变、所述数据中心内的处理器 的类型的改变、或所述数据中心内的服务器的数量和处理器的类型的改变隔离。
9.如权利要求1所述的方法，其特征在于，所述服务依赖所述数据中心所托管的另一 服务，并且可任选地其中存在用于所述数据中心所托管的其他服务的服务级协定，并且可 任选地所述方法还包括在所述其他服务的执行期间执行事件跟踪来收集足够的信息以确 定所述其他服务是否符合所述服务级协定的一个或多个条款。
10.一种用于在数据中心处托管服务的体系结构，所述体系结构包括供经由数据中心的硬件和软件来实现的编程模型和相应的编程模型抽象层；以及根据所述编程模型来开发的并由所述数据中心托管的服务，其中所述编程模型抽象层 响应于对所述服务的请求，并且部分地基于对所述服务的至少一个软件组件中的资源类的 引用来将所述数据中心的至少某些资源分配给所述服务，可以修改所述资源类来解决所述 数据中心的一个或多个硬件资源、软件资源、或硬件和软件资源的改变。
全文摘要
一种示例性方法包括在数据中心处托管服务，该服务依赖于根据编程模型来开发的至少一个软件组件，并且该数据中心包括抽象该数据中心的资源的相应的编程模型抽象层；接收对该服务的请求；以及响应于该请求，将数据中心的至少某些资源分配给该服务来允许履行该请求，其中该编程模型抽象层部分地基于对至少一个软件组件中的资源类的引用来执行分配，可以修改该资源类来解决数据中心的一个或多个资源的改变。还描述了各种其他设备、系统和方法。
文档编号G06F15/16GK102132268SQ200980134130
公开日2011年7月20日 申请日期2009年7月28日 优先权日2008年8月26日
发明者B·J·史密斯, J·R·汉米尔顿 申请人:微软公司