CN108139940B - 对于计算能力的周期性请求的管理 - Google Patents

Abstract

提供一种用于监视传入代码执行请求并且调度对应代码执行的系统。所述系统可以被配置为保持多个虚拟机实例。所述系统还可以被配置为确定所述传入代码执行请求中的至少一些是否呈现周期性，并且致使在所述虚拟计算系统上保持减少量的闲置计算能力。所述系统还可以被配置为在预期将要接收代码执行请求之前不久致使添加另外的计算能力。

Description

对于计算能力的周期性请求的管理

本申请的申请人先前在2014年9月30日提交了以下美国专利申请：

上述申请的公开内容通过引用整体并入本文。

背景

一般来说，计算设备利用通信网络或一系列通信网络进行数据交换。公司和组织操作互连许多计算设备的计算机网络来支持运营或者向第三方提供服务。计算系统可位于单一地理位置或者位于多个不同地理位置中(例如，通过私有或公共通信网络互连)。具体来说，数据中心或数据处理中心(本文中统称为“数据中心”)可以包括多个互连的计算系统以向数据中心的用户提供计算资源。数据中心可以是代表某一组织运作的私有数据中心或者代表公众或为了公众利益运作的公共数据中心。

为了促进对数据中心资源的加大利用，虚拟化技术可允许单个物理计算设备托管虚拟机的一个或多个实例，所述虚拟机作为独立计算设备向数据中心的用户展现并操作。利用虚拟化，单个物理计算设备可以动态方式创建、维护、删除或以其他方式来管理虚拟机。反过来，用户可以从数据中心请求计算机资源，包括单个计算设备或联网计算设备的配置，并且可以被提供不同数量的虚拟机资源。

在一些情况下，可以根据多个虚拟机实例类型来配置虚拟机实例以提供特定的功能。例如，各种计算设备可以与操作系统或操作系统配置、虚拟化硬件资源和软件应用程序的不同组合相关联，以使得计算设备能够提供不同的所需功能性，或者更高效地提供类似功能性。这些虚拟机实例类型配置通常包含在设备映像中，所述设备映像包括含有虚拟机一旦启动就运行的软件的静态数据(例如，OS和应用程序及其配置和数据文件等)。设备映像通常存储在用于创建或初始化实例的磁盘上。因此，计算设备可以处理设备映像以便实现期望的软件配置。

附图简述

由于通过参阅结合附图进行的以下详细描述，可更好地理解本公开的上述方面和许多伴随的优点，因此将更易于了解所述方面和优点，在附图中：

图1是描绘根据示例性方面的用于提供低延时计算能力的说明性环境的框图；

图2是描绘根据示例性方面的预热池的说明性配置的框图；

图3是描绘根据示例性方面的活动池的说明性配置的框图；

图4描绘了根据示例性方面的提供用于监视和调度代码执行请求的调度管理器的计算设备的通用架构；

图5是示出根据示例性方面的由调度管理器实现的周期性作业管理例程的流程图；

图6是示出根据示例性方面的由调度管理器实现的作业调度例程的流程图；并且

图7是示出根据示例性方面的由调度管理器实现的另一个作业调度例程的流程图。

详述

公司和组织不再需要为了执行计算操作(例如，执行代码，包括线程、程序、功能、软件、例程、子例程、进程等)而获取和管理它们自己的数据中心。随着云计算的出现，传统上由硬件计算设备提供的存储空间和计算能力现在可以通过互联网在几分钟内获得并配置。因此，开发人员可以快速购买所需数量的计算资源，而不必操心获取物理机器。这些计算资源通常以虚拟计算资源或虚拟机实例的形式购买。虚拟机的这些实例是托管在物理计算设备上的物理机器(例如，计算机)的软件实现，并且可以包含传统上在物理机器上提供的操作系统和应用程序。这些虚拟机实例配置有一组计算资源(例如，存储器、CPU、磁盘、网络等)，在虚拟机实例上运行的应用程序可以与物理计算机相同的方式请求这些计算资源并且可以使用这些计算资源。

然而，即使购买了虚拟计算资源，开发人员仍然需要决定要购买多少虚拟机实例以及要购买什么类型的虚拟机实例，以及要保留多久。例如，使用虚拟机实例的成本可能因类型和租用的小时数而异。另外，虚拟机可租用的最短时间通常为几小时。此外，开发人员必须指定安装在虚拟机上的硬件和软件资源(例如，操作系统的类型和语言运行时等)。他们可能会遇到的其他问题包括过度使用(例如，获取太少的计算资源和遭受性能问题)，利用不足(例如，获取比运行代码所需的更多的计算资源并因此过度支付)，预测流量的变化(例如，使得他们知道何时按比例放大或缩小)以及实例和语言运行时启动延迟，这种延迟可能耗费3-10分钟或更长时间，即使用户可能需要几秒或甚至几毫秒的计算能力也是这样。

在某些情况下，可能会有虚拟计算系统获取并管理这些虚拟计算资源，并根据请求为用户提供计算能力。然而，取决于这些用户的需求，虚拟计算系统接收的工作负载的数量和时间可能是无法预测的。不可预测性可能要求虚拟计算系统保持大量的计算能力(这可能是昂贵的)，这种计算能力从未仅仅为了能够处理最坏情况(例如，一次传入大量请求)而得到充分利用。如果虚拟计算系统没有足够的能力备用以便处理大量的同时请求，则用户可能会遇到延迟增加、错误率增加或其他与性能相关的问题。因此，需要一种减少必需保持的闲置能力的量的改进方法。

根据本公开的各方面，通过维持一旦接收到用户请求即随时可用的预先初始化的虚拟机实例池，并自动管理池中可用于为传入请求提供服务的能力的量，与执行用户代码相关联的延迟(有时称为延时)(例如，实例和语言运行时启动时间)可以显著减少，并且可以提高利用率。

一般来说，本公开的各方面涉及对虚拟机实例和其中创建的容器的管理。具体而言，公开了便于管理虚拟计算系统中的虚拟机实例的系统和方法。虚拟计算系统维护具有加载在其上的一个或多个软件部件(例如，操作系统、语言运行时、存储库等)的虚拟机实例池。维护虚拟机实例池可涉及创建新实例，从外部实例供应服务获取新实例，销毁实例，向用户分配/重新分配实例，修改实例(例如其中的容器或资源)等。可以指定池中的虚拟机实例来为执行程序代码的用户请求提供服务。在本公开中，短语“程序代码”、“用户代码”和“云函数”有时可以互换使用。程序代码可以在虚拟机实例上创建的独立容器中执行。由于池中的虚拟机实例在接收请求时已经启动并加载了特定的操作系统和语言运行时，因此与寻找可处理请求(例如，通过在虚拟机实例上创建的一个或多个容器中执行用户代码)的计算能力相关的延迟显著减少。

在另一方面，虚拟计算系统可以监视在虚拟计算系统上执行用户代码的传入请求，并且识别请求中的趋势(例如，请求的时间、请求的数量、请求的周期性等)。鉴于已确定的趋势，虚拟计算系统可能会预测某些代码执行请求。而且，虚拟计算系统可以允许用户指定他们希望运行其代码的更灵活的时间范围，使得虚拟计算系统可以分散代码执行并且减少虚拟计算系统预计将能够处理的突发能力的量。由虚拟计算系统维护的计算能力可以包括具有加载在其上的一个或多个软件部件并等待用于处理传入请求的虚拟机实例的预热池以及当前正在用于处理一个或多个请求的虚拟机实例的活动池。

通过知道(或预计)何时会收到新的代码执行请求，虚拟计算系统可忽视预热池或减少预热池中的闲置能力。另外，虚拟计算系统可以通过在接收到执行用户功能的请求时(或之前不久)将虚拟机实例预先配置并且准备执行用户功能来降低用户所感觉到的延时。此外，通过了解虚拟机实例和/或容器的数量/大小以及使用/需要它们的持续时间，虚拟计算系统可以实现改进的编队级管理和负载平衡。

现在将参考附图描述本公开的具体实施方案和示例性应用。这些实施方案和示例性应用旨在说明而不是限制本公开。

包括虚拟计算系统的说明性环境

参考图1，将描述示出虚拟环境100的实施方案的框图。如图1所示的示例包括虚拟环境100，其中用户计算设备102的用户(例如开发人员等)可以使用由虚拟计算系统110提供的虚拟计算资源来运行各种程序代码。

作为说明，示出与虚拟计算系统110通信的各种示例性用户计算设备102，包括台式计算机、膝上型计算机和移动电话。通常，用户计算设备102可以是任何计算设备，诸如台式机、膝上型计算机、移动电话(或智能手机)、平板计算机、自助服务终端、无线设备和其他电子设备。另外，用户计算设备102可以包括在相同或不同数据中心上运行的web服务，其中例如，不同web服务可以程序化彼此通信以执行本文描述的一种或多种技术。此外，用户计算设备102可以包括物联网(IoT)设备，诸如互联网电器和连接的设备。虚拟计算系统110可以向用户计算设备102提供一个或多个用户界面、命令行界面(CLI)、应用编程界面(API)和/或其他编程界面，用于生成和上载用户代码，调用用户代码(例如，提交在虚拟计算系统110上执行用户代码的请求)，调度基于事件的作业或定时作业，跟踪用户代码，和/或查看与其请求和/或用户代码有关的其他记录或监视信息。尽管在此可以将一个或多个实施方案描述为使用用户界面，但应理解，此类实施方案可以另外地或替代地使用任何CLI、API或其他编程界面。

用户计算设备102通过网络104访问虚拟计算系统110。网络104可以是任何有线网络、无线网络或其组合。此外，网络104可以是个人区域网、局域网、广域网、无线电广播网络(例如，用于广播或电视)、电缆网络、卫星网络、蜂窝电话网络或其组合。网络104可以是例如可能由各种不同参与方操作的链接网络的公共可访问网络，诸如互联网。在一些实施方案中，网络104可以是私有或半私有网络，诸如公司或大学内联网。网络104可以包括一个或多个无线网络，诸如全球移动通信系统(GSM)网络、码分多址(CDMA)网络、长期演进(LTE)网络或任何其他类型的无线网络。网络104可以使用协议和部件来经由互联网或任何其他上述类型的网络进行通信。例如，网络104使用的协议可以包括超文本传输协议(HTTP)、安全HTTP(HTTPS)、消息队列遥测传输(MQTT)、约束应用协议(CoAP)等。用于经由互联网或任何其他前述类型的通信网络进行通信的协议和部件对于本领域技术人员来说是众所周知的，并且因此不在本文中更详细地进行描述。

图1中描绘了虚拟计算系统110在分布式计算环境中操作，所述环境包括使用一个或多个计算机网络来互连的若干计算机系统。虚拟计算系统110还可以在具有比图1中所示的更少或更多数量的设备的计算环境内操作。因此，图1中的虚拟计算系统110的描述应被视为说明性的而不是对本公开的限制。例如，虚拟计算系统110或其各种组成部分可以实现各种Web服务部件，托管或“云”计算环境和/或对等网络配置，以实现本文描述的过程的至少一部分。

此外，虚拟计算系统110可以用硬件和/或软件来实现，并且可以例如包括在物理计算机硬件上实现的一个或多个物理或虚拟服务器，所述物理计算机硬件被配置为执行用于执行本文描述的各种特征的计算机可执行指令。一个或多个服务器可以在地理上分散或地理上共定位于例如一个或多个数据中心中。

在如图1所示的环境中，虚拟环境100包括虚拟计算系统110，所述虚拟计算系统110包括前端120、预热池管理器130、工作者管理器140和调度管理器150。在所描述的示例中，虚拟机实例(“实例”)152、154显示在由预热池管理器130管理的预热池130A中，并且实例156、157、158、159显示在由工作者管理器140管理的活动池140A中。虚拟计算系统110内的各种部件的示出本质上是有逻辑性的，并且一个或多个部件可以由单个计算设备或多个计算设备来实现。例如，实例152、154、156、157、158、159可以在各种不同的地理区域中的一个或多个物理计算设备上实现。类似地，可以在多个物理计算设备上实现前端120、预热池管理器130、工作者管理器140和调度管理器150中的每一个。或者，可以在单个物理计算设备上实现前端120、预热池管理器130、工作者管理器140和调度管理器150中的一个或多个。在一些实施方案中，虚拟计算系统110可以包括多个前端、多个预热池管理器、多个工作者管理器和/或多个能力管理器。尽管在图1的示例中示出了六个虚拟机实例，本文描述的实施方案不限于此，并且本领域技术人员将认识到，虚拟计算系统110可以包括使用任何数量的物理计算设备实现的任何数量的虚拟机实例。类似地，尽管在图1的示例中示出了单个预热池和单个活动池，本文描述的实施方案不限于此，并且本领域技术人员将认识到，虚拟计算系统110可以包括任何数量的预热池和活动池。

在图1的示例中，虚拟计算系统110示出为连接到网络104。在一些实施方案中，虚拟计算系统110内的任何部件可以经由网络104与虚拟环境100的其他部件(例如，用户计算设备102和辅助服务106，其可以包括监视/记录/账单结算服务107，存储服务108，实例供应服务109和/或可以与虚拟计算系统110通信的其他服务)进行通信。在其他实施方案中，并非虚拟计算系统110的所有部件都能够与虚拟环境100的其他部件进行通信。在一个示例中，只有前端120可以连接到网络104，并且虚拟计算系统110的其他部件可以经由前端120与虚拟环境100的其他部件进行通信。

用户可以使用虚拟计算系统110以便在其上执行用户代码。例如，用户可能希望运行与用户开发的web或移动应用程序相关的一段代码。运行代码的一种方式是从提供基础设施即服务的服务提供商处获得虚拟机实例，配置虚拟机实例以满足用户需求，并使用配置的虚拟机实例来运行代码。或者，用户可以向虚拟计算系统110发送代码执行请求。虚拟计算系统110可以基于代码执行请求来处理计算能力(例如，容器、实例等，其在下面更详细描述)的获取和配置，并且使用计算能力来执行代码。虚拟计算系统110可以基于数据量来自动按比例放大和缩小，由此减轻用户必须操心过度使用(例如获取太少的计算资源和遭受性能问题)或利用不足(例如，获取比运行代码所需的更多的计算资源，且因此导致过度支付)的负担。

前端

前端120处理在虚拟计算系统110上执行用户代码的所有请求。在一个实施方案中，前端120充当由虚拟计算系统110提供的所有其他服务的前门。前端120处理请求并确保请求得到适当的授权。例如，前端120可以确定与请求相关联的用户是否被授权来访问请求中指定的用户代码。

本文使用的用户代码可以指代以特定程序语言编写的任何程序代码(例如，程序、例程、子例程、线程等)。在本公开中，术语“代码”、“用户代码”和“程序代码”可以互换使用。可以执行此用户代码以实现例如与由用户开发的特定web应用或移动应用有关的特定任务。例如，用户代码可以用JavaScript(node.js)、Java、Python和/或Ruby编写。所述请求可以包括用户代码(或其位置)以及将要用于执行用户代码的一个或多个参数。例如，用户可以提供用户代码以及执行用户代码的请求。在另一示例中，所述请求可以通过先前上载的程序代码的名称或其唯一ID来识别先前上载的程序代码(例如，使用用于上载所述代码的API)。在又一示例中，代码可以包括在请求中，也可以在虚拟计算机系统110接收请求之前在分开的位置(例如，存储服务108或虚拟计算系统110内部的存储系统)中上载。虚拟计算系统110可以基于处理请求时代码可用的位置来改变其代码执行策略。

响应于来自用户的安全超文本传输协议(HTTPS)请求，前端120可以接收执行这些用户代码的请求。而且，包括在HTTPS请求中的任何信息(例如，标头和参数)也可以在执行用户代码时加以处理和利用。如上所述，包括例如HTTP、MQTT和CoAP的任何其他协议可用于将包含代码执行请求的消息传送到前端120。当检测到事件时，前端120也可以接收执行这些用户代码的请求，所述事件诸如用户已经注册以触发自动请求生成的事件。例如，用户可能已经用辅助服务106注册了用户代码并且指定每当特定事件发生(例如，上载新文件)时，将执行用户代码的请求发送到前端120。或者，用户可能已经注册了定时作业(例如，每24小时执行一次用户代码)。在这样的示例中，当定时作业的计划时间到来时，执行用户代码的请求可以被发送到前端120。在又一示例中，前端120可具有传入代码执行请求的队列，并且当用户的成批作业从虚拟计算系统的工作队列中移除时，前端120可处理用户请求。在又一示例中，所述请求可以源自虚拟计算系统110内的另一个部件或者未在图1中示出的其他服务器或服务。

用户请求可以指定一个或多个第三方存储库(包括本地存储库)与用户代码一起使用。在一个实施方案中，用户请求是包含用户代码和任何存储库(和/或其存储位置的标识)的ZIP文件。在一些实施方案中，用户请求包括指示要执行的程序代码、编写程序代码的语言、与请求相关联的用户和/或被保留用于执行程序代码的计算资源(例如，存储器等)的元数据。例如，程序代码可以与请求一起提供，先前由用户上载，由虚拟计算系统110提供(例如，标准例程)和/或由第三方提供。在一些实施方案中，针对特定用户代码指定了这些资源级约束条件(例如，将分配多少内存来执行特定用户代码)，并且这些约束条件可能不会随着用户代码的每次执行而变化。在这样的情况下，虚拟计算系统110可以在接收每个单独的请求之前访问这些资源级约束条件，并且单独的请求可以不指定这些资源级约束条件。在一些实施方案中，用户请求可以指定其他约束条件，诸如权限数据，其指示这个请求具有执行用户代码的什么类型的权限。虚拟计算系统110可以使用这种权限数据来访问私有资源(例如，在私有网络上)。

在一些实施方案中，用户请求可以指定为了处理用户请求而应该采取的行为。在这样的实施方案中，用户请求可以包括用于启用一个或多个执行模式的指示符，与用户请求相关联的用户代码将以所述执行模式来执行。例如，所述请求可以包括用于指示用户代码是否应当以调试模式执行的标志或标头，在所述调试模式中，将可能与执行用户代码有关而生成的调试和/或记录输出提供回到用户(例如，通过控制台用户界面)。在这样的示例中，虚拟计算系统110可以检查请求并查找标志或标头，并且如果所述标志或标头存在，则虚拟计算系统110可以修改用户代码得以在其中执行的容器的行为(例如，记录设施)，并且致使输出数据被提供回到用户。在一些实施方案中，通过由虚拟计算系统110向用户提供的用户界面将行为/模式指示符添加到请求中。根据在请求中提供的指示，还可以启用或禁用其他功能，例如源代码分析、远程调试等。

在一些实施方案中，虚拟计算系统110可以包括多个前端120。在这样的实施方案中，可以提供负载平衡器以例如以循环方式将传入请求分配到多个前端120。在一些实施方案中，负载平衡器将传入请求分配给多个前端120的方式可以基于预热池130A和/或活动池140A的状态。例如，如果预热池130A中的能力被认为是足够的，则可以基于前端120的各个能力(例如，基于一个或多个负载平衡限制)将请求分配给多个前端120。另一方面，如果预热池130A中的能力小于阈限量，则可以移除一个或多个这样的负载平衡限制，使得可以减少或最小化从预热池130A获取的虚拟机实例的数量的方式将请求分配给多个前端120。例如，即使根据负载平衡限制，请求将要路由到前端A，如果前端A需要从预热池130A中取出一个实例来为请求提供服务，但前端B可以使用其活动池中的一个实例来为同一个请求提供服务，那么可以将所述请求路由到前端B。

预热池管理器

当虚拟计算系统110接收到在虚拟计算系统110上执行用户代码的请求时，预热池管理器130确保虚拟机实例准备好供工作者管理器140使用。在如图1示出的示例中，预热池管理器130管理预热池130A，所述预热池130A是可用于为传入用户代码执行请求提供服务的预先初始化和预先配置的虚拟机实例的组(有时被称为池)。在一些实施方案中，预热池管理器130使得虚拟机实例在虚拟计算系统110内的一个或多个物理计算机上启动并被添加到预热池130A。在其他实施方案中，预热池管理器130与辅助虚拟机实例服务(例如，图1的实例供应服务109)通信以创建新的实例并将其添加到预热池130A。在一些实施方案中，预热池管理器130可以利用虚拟计算系统110内的物理计算设备和一个或多个虚拟机实例服务来获取和维护可用于为由前端120接收的代码执行请求提供服务的计算能力。在一些实施方案中，虚拟计算系统110可以包括用于控制(例如增大或减小)预热池130A中的可用能力的一个或多个逻辑旋钮或开关。例如，系统管理员可以使用这种旋钮或开关来在高峰时段增加预热池130A中的可用能力(例如，预启动实例的数量)。在一些实施方案中，可以基于与执行用户代码的特定用户请求无关的预定的一组配置来配置预热池130A中的虚拟机实例。预定的一组配置可以对应于执行用户代码的各种类型的虚拟机实例。预热池管理器130可以基于与当前或先前的用户代码执行相关的一个或多个度量来优化预热池130A中的虚拟机实例的类型和数量。

如图1所示，实例可以具有加载在其上的操作系统(OS)和/或语言运行时。例如，由预热池管理器130管理的预热池130A包括实例152、154。实例152包括OS 152A和运行时152B。实例154包括OS 154A。在一些实施方案中，预热池130A中的实例还可以包括容器(其还可以包含操作系统、运行时、用户代码等的副本)，其将在下面更详细地描述。尽管实例152在图1中示出为包括单个运行时，但在其他实施方案中，图1中描绘的实例可以包括两个或更多个运行时，其中的每一个可以用于运行不同的用户代码。在一些实施方案中，预热池管理器130可维护在预热池130A中的实例的列表。实例的列表还可以指定实例的配置(例如，OS、运行时、容器等)。

在一些实施方案中，预热池130A中的虚拟机实例可以用于为任何用户的请求提供服务。在一个实施方案中，预热池130A中的所有虚拟机实例都以相同或基本类似的方式配置。在另一个实施方案中，预热池130A中的虚拟机实例可以被不同地配置为适应不同用户的需求。例如，虚拟机实例可以具有加载在其上的不同的操作系统、不同的语言运行时和/或不同的存储库。在又一个实施方案中，预热池130A中的虚拟机实例可以相同或基本相似的方式(例如，使用相同的OS、语言运行时和/或存储库)来配置，但这些实例中的一些可能具有不同的容器配置。例如，两个实例可能具有Python和Ruby的运行时，但一个实例可能具有配置为运行Python代码的容器，而另一个实例可能具有配置为运行Ruby代码的容器。在一些实施方案中，提供多个预热池130A，每个具有相同配置的虚拟机实例。

预热池管理器130可以预先配置预热池130A中的虚拟机实例，使得每个虚拟机实例被配置为满足至少一个操作条件，所述操作条件可由在虚拟计算系统110上执行程序代码的用户请求来请求或指定。在一个实施方案中，操作条件可以包括可以编写潜在用户代码的程序语言。例如，这样的语言可以包括Java、JavaScript、Python、Ruby等等。在一些实施方案中，可以编写用户代码的一组语言可以限于预定的集合(例如，4种语言的集合，尽管在一些实施方案中提供多于或少于四种语言的集合)以便于将可以满足执行用户代码的请求的虚拟机实例预先初始化。例如，当用户正在通过由虚拟计算系统110提供的用户界面来配置请求时，用户界面可以提示用户指定用于执行用户代码的预定操作条件之一。在另一个示例中，用于利用由虚拟计算系统110提供的服务的服务级别协议(SLA)可以指定用户请求应当满足的一组条件(例如，编程语言、计算资源等)，并且虚拟计算系统110在处理请求时可以假设请求满足这一组条件。在另一示例中，请求中指定的操作条件可以包括：要用于处理请求的计算能力的量；请求的类型(例如HTTP与触发事件)；请求的超时(例如，阈值时间，在此时间之后，可能终止请求)；安全策略(例如，可以控制预热池130A中的哪些实例可由哪个用户使用)；调度信息(例如，请求虚拟计算系统等到什么时间执行程序代码，请求虚拟计算系统在什么时间之后执行程序代码，请求虚拟计算系统执行程序代码的时间窗等)等。

工作者管理器

工作者管理器140管理用于为传入代码执行请求提供服务的实例。在图1所示的示例中，工作者管理器140管理活动池140A，所述活动池140A是当前分配给一个或多个用户的虚拟机实例的组(有时被称为池)。虽然这里将虚拟机实例描述为分配给特定用户，但在一些实施方案中，可以将实例分配给一组用户，使得实例与这一组用户绑定，并且这个组的任何成员可以利用实例上的资源。例如，同一组中的用户可以属于同一个安全组(例如，基于他们的安全凭证)，使得已经在特定实例上的容器中执行一个成员的代码之后，在同一个实例上的另一个容器中执行另一个成员的代码不会带来安全风险。类似地，工作者管理器140可以根据一个或多个策略分配实例和容器，所述一个或多个策略规定哪些请求可以在哪些容器中执行以及哪些实例可以分配给哪些用户。示例性策略可以指定将实例分配给共享相同账户(例如，访问由虚拟计算系统110提供的服务的账户)的用户集合。在一些实施方案中，与同一用户组相关联的请求可共享相同的容器(例如，如果与其相关联的用户代码相同)。在一些实施方案中，所述请求不区分所述组的不同用户并且仅指示与请求相关联的用户所属的组。

在图1示出的示例中，用户代码在被称为容器的独立计算系统中执行。容器是使用这个实例上的可用资源在虚拟机实例内创建的逻辑单元。例如，工作者管理器140可以基于在执行用户代码的请求中指定的信息，创建新的容器或查找活动池140A中的一个实例中的现有容器，并将所述容器分配给所述请求，以便处理与请求相关的用户代码的执行。在一个实施方案中，将这样的容器实现为Linux容器。活动池140A中的虚拟机实例可以具有在其上创建的一个或多个容器，并且具有加载在其上的与用户相关联的一个或多个程序代码(例如，在一个容器中或在这个实例的本地高速缓存中)。

如图1所示，实例可能具有操作系统(OS)、语言运行时和容器。这些容器可以具有加载在其上的OS以及语言运行时和用户代码的单独的副本。在图1的示例中，由工作者管理器140管理的活动池140A包括实例156、157、158、159。实例156具有容器156A、156B。容器156A具有加载在其中的OS 156A-1、运行时156A-2和代码156A-3。在所描述的示例中，容器156A具有加载在其中的其自己的OS、运行时和代码。在一个实施方案中，在容器156A、156B(以及图1中未示出的任何其他容器)之间共享OS 156A-1(例如其内核)、运行时156A-2和/或代码156A-3。在另一个实施方案中，OS 156A-1(例如，在内核之外运行的任何代码)、运行时156A-2和/或代码156A-3是为容器156A创建并且不与实例156上的其他容器共享的独立副本。在又一个实施方案中，OS 156A-1、运行时156A-2和/或代码156A-3的一些部分在实例156上的容器之间共享，并且所述OS 156A-1、运行时156A-2和/或代码156A-3的其他部分是专用于容器156A的独立副本。实例157包括容器157A、157B、157C。实例158包括容器158A、158B。实例159包括容器159A。

在图1的示例中，图1所示的容器的尺寸可能与容器的实际尺寸成正比。例如，容器156A占据比实例156上的容器156B更多的空间。类似地，容器157A、157B、157C可以具有相同的尺寸，并且容器158A、158B、159A可以具有相同的尺寸。实例158、159中示出的标记为“C”的虚线框指示这些实例上剩余的可用于创建新实例的空间。在一些实施方案中，容器的尺寸可以是64MB或其任何倍数。在其他实施方案中，容器的尺寸可以是小于或等于容器得以在其中创建的实例的尺寸的任何任意尺寸。在一些实施方案中，容器的尺寸可以是小于、等于或大于容器得以在其中创建的实例的尺寸的任何任意尺寸。容器的尺寸可以超过实例的尺寸的程度可以基于可能利用这些容器超出实例提供的能力的可能性来确定。

尽管容器156B、157A、157B、157C、158A、158B、159A内的部件未在图1的示例中示出，但这些容器中的每一个可以具有各种操作系统、语言运行时、存储库和/或用户代码。在一些实施方案中，实例可以具有加载在其上的用户代码(例如，在实例级高速缓存中)，并且这些实例内的容器也可以具有加载在其中的用户代码。在一些实施方案中，工作者管理器140可以维护活动池140A中的实例的列表。实例的列表还可以指定实例的配置(例如，OS、运行时、容器等)。在一些实施方案中，工作者管理器140可以访问预热池130A中的实例的列表(例如，包括实例的数量和类型)。在其他实施方案中，工作者管理器140在不知道预热池130A中的虚拟机实例的情况下请求来自预热池管理器130的计算能力。

在请求已被前端120成功处理之后，工作者管理器140找到能力来为在虚拟计算系统110上执行用户代码的请求提供服务。例如，如果在活动池140A中存在一个特定虚拟机实例，这个实例的一个容器具有加载在其中的相同用户代码(例如，容器156A中示出的代码156A-3)，则工作者管理器140可以将这个容器分配给请求并使得用户代码在容器中执行。或者，如果用户代码在一个虚拟机实例的本地高速缓存中可用(例如，存储在实例158上但不属于任何单独的容器)，则工作者管理器140可以在这个实例上创建新的容器，将容器分配给请求，并使得用户代码在容器中加载并执行。

如果工作者管理器140确定与请求相关联的用户代码未在活动池140A中的任何实例上(例如，在容器或实例的本地高速缓存中)找到，则工作者管理器140可以确定是否活动池140A中的任何实例当前被分配给与请求相关联的用户并且具有处理当前请求的计算能力。如果存在这样的实例，则工作者管理器140可以在这个实例上创建新的容器并将所述容器分配给所述请求。替代地，工作者管理器140还可以在分配给用户的实例上配置现有容器，并将所述容器分配给所述请求。例如，工作者管理器140可确定现有容器可用于执行用户代码，只要当前用户请求所要求的特定存储库加载在其上。在这种情况下，工作者管理器140可以将特定的存储库和用户代码加载到容器上并使用容器来执行用户代码。

如果活动池140A不包含当前分配给用户的任何实例，则工作者管理器140从预热池130A中提取新的虚拟机实例，将所述实例分配给与所述请求相关联的用户，在所述实例上创建新的容器，将容器分配给请求，并使得用户代码被下载并在容器上执行。

在一些实施方案中，虚拟计算系统110适于在用户代码被接收(例如，由前端120)之后不久开始执行用户代码。可以将时间段确定为开始执行用户代码(例如，在与用户相关联的虚拟机实例上的容器中)与接收执行用户代码的请求(例如由前端接收)之间的时间差。虚拟计算系统110适于在小于预定持续时间的时间段内开始执行用户代码。在一个实施方案中，预定持续时间是500ms。在另一个实施方案中，预定持续时间是300ms。在另一个实施方案中，预定持续时间是100ms。在另一个实施方案中，预定持续时间是50ms。在另一个实施方案中，预定持续时间是10ms。在另一个实施方案中，预定持续时间可以是从10ms到500ms的范围中选择的任何值。在一些实施方案中，如果满足一个或多个条件，则虚拟计算系统110适于在小于预定持续时间的时间段内开始执行用户代码。例如，一个或多个条件可以包括以下中的任何一个：(1)在接收到请求时，用户代码被加载到活动池140A中的容器上；(2)在接收到请求时，用户代码被存储在活动池140A中的实例的代码高速缓存中；(3)在接收到请求时，活动池140A包含分配给与请求相关联的用户的实例；或(4)在接收到请求时，预热池130A具有处理请求的能力。在一些实施方案中，代替一旦接收到代码执行请求，就开始执行所请求的代码，虚拟计算系统110可以根据请求提供的调度信息来调度代码执行。例如，所述请求可以指定请求虚拟计算系统110执行代码执行的时间窗(例如，在下周一凌晨3:00与凌晨4:00之间)，并且虚拟计算系统110可以基于某些性能考虑(例如工作负载、延迟等)来调度代码执行。下面参考图6和7更详细地描述调度过程。

用户代码可以从诸如图1的存储服务108的辅助服务106下载。图1所示的数据108A可以包括由一个或多个用户上载的用户代码，与这样的用户代码相关联的元数据或由虚拟计算系统110用来执行本文描述的一种或多种技术的任何其他数据。尽管在图1的示例中仅示出存储服务108，虚拟环境100可以包括可以从其下载用户代码的其他级别的存储系统。例如，每个实例可以具有一个或多个存储系统，所述存储系统在物理上(例如，驻留在运行实例的物理计算系统上的本地存储)或逻辑上(例如与所述实例网络通信并且在虚拟计算系统110内部或外部提供的网络附加存储系统)与创建容器的实例相关联。或者，代码可以从由存储服务108提供的基于web的数据存储区来下载。

一旦工作者管理器140查找到可用于为用户代码执行请求提供服务的预热池130A中的虚拟机实例中的一个，预热池管理器130或工作者管理器140从预热池130A中取出所述实例并将它分配给与请求相关的用户。将分配的虚拟机实例从预热池130A中取出并放置在活动池140A中。在一些实施方案中，一旦虚拟机实例已经被分配给特定用户，则同一个虚拟机实例不能用于为任何其他用户的请求提供服务。这通过防止可能的用户资源混合来为用户提供安全益处。替代地，在一些实施方案中，属于不同用户(或分配给与不同用户相关联的请求)的多个容器可以共存于单个虚拟机实例上。这种方法可以提高可用计算能力的利用率。在一些实施方案中，虚拟计算系统110可以维护单独的高速缓存，其中存储用户代码以用作虚拟机实例的本地高速缓存与基于web的网络存储(例如，可通过网络104来访问)之间的中间级别的高速缓存系统。

在已经执行用户代码之后，工作者管理器140可以拆除用于执行用户代码的容器以释放其占用的资源以用于实例中的其他容器。或者，工作者管理器140可保持容器运行以使用它来为来自同一用户的另外请求提供服务。例如，如果接收到与已经加载在容器中的相同用户代码相关联的另一个请求，则可以将所述请求分配给同一容器，从而消除与创建新容器和将用户代码加载到容器中相关联的延迟。在一些实施方案中，工作者管理器140可以拆除用于执行用户代码的容器得以在其中创建的实例。或者，工作者管理器140可保持容器运行以使用它来为来自同一用户的另外请求提供服务。在用户代码完成执行之后是否保持容器和/或实例运行的确定可以基于阈值时间、用户的类型、用户的平均请求量、周期性信息(例如，(i)如果周期性信息指示预期另外请求很快到来，那么在活动池140A中当前未执行用户代码的容器/实例可以保持在运行中或(ii)如果周期性信息指示另外请求不可能足够快地到来，以证明将容器/实例保持在运行中是正确的，那么这些容器/实例可以终止)和/或其他操作条件。例如，在没有任何活动(例如，运行代码)的阈值时间(例如，5分钟、30分钟、1小时、24小时、30天等)过去之后，将容器和/或虚拟机实例关闭(例如，删除、终止等)，并且分配给它的资源得以释放。在一些实施方案中，在将容器拆除之前经过的阈值时间短于在将实例拆除之前经过的阈值时间。

在一些实施方案中，虚拟计算系统110可以在为传入代码执行请求提供服务时将数据提供给一个或多个辅助服务106。例如，虚拟计算系统110可以与监视/记录/账单结算服务107进行通信。监视/记录/账单结算服务107可以包括：监视服务，其用于管理从虚拟计算系统110接收的监视信息，诸如虚拟计算系统110上的容器和实例的状态；记录服务，其用于管理从虚拟计算系统110接收的记录信息，诸如由虚拟计算系统110上的容器和实例执行的活动；以及账单结算服务，其用于生成与在虚拟计算系统110上执行用户代码相关联的账单结算信息(例如，基于由监视服务和记录服务管理的监视信息和/或记录信息)。除了如上所述可以由监视/记录/账单结算服务107(例如，代表虚拟计算系统110)执行的系统级活动之外，监视/记录/账单结算服务107可以代表在虚拟计算系统110上执行的用户代码来提供应用程序级服务。例如，监视/记录/账单结算服务107可以代表在虚拟计算系统110上执行的用户代码来监视和/或记录各种输入、输出或其他数据和参数。尽管显示为单个框，但监视、记录和账单结算服务107可以作为单独的服务来提供。

在一些实施方案中，工作者管理器140可以对由工作者管理器140管理的实例和容器(例如，活动池140A中的那些实例和容器)执行健康检查。例如，由工作者管理器140执行的健康检查可以包括确定由工作者管理器140管理的实例和容器是否具有以下问题：(1)错误配置的网络和/或启动配置，(2)内存耗尽，(3)损坏的文件系统，(4)不兼容的内核和/或可能损害实例和容器的性能的任何其他问题。在一个实施方案中，工作者管理器140周期性地执行健康检查(例如，每5分钟、每30分钟、每小时、每24小时等)。在一些实施方案中，可以基于健康检查的结果自动调整健康检查的频率。在其他实施方案中，可以基于用户请求来调整健康检查的频率。在一些实施方案中，工作者管理器140可以对预热池130A中的实例和/或容器执行类似的健康检查。预热池130A中的实例和/或容器可以与活动池140A中的那些实例和容器一起或单独管理。在一些实施方案中，在预热池130A中的实例和/或容器的健康状况与活动池140A分开管理的情况下，预热池管理器130而不是工作者管理器140可以执行如上所述关于预热池130A中的实例和/或容器的健康检查。

调度管理器

调度管理器150监视由虚拟计算系统110接收的代码执行请求(例如，通过前端120)并且调度对应的代码执行。例如，调度管理器150可以与前端120、预热池管理器130和/或工作者管理器140通信以调度作业(例如，在虚拟计算系统110上执行用户代码)和/或管理预热池130A和/或活动池140A中的计算能力。虽然调度管理器150被示为虚拟计算系统110内的不同部件，但调度管理器150的部分或全部功能可由前端120、预热池管理器130和/或工作者管理器140执行。例如，调度管理器150可以完全在虚拟计算系统110的其他部件中的一个部件内或以在虚拟计算系统110的其他部件上的分布式方式来实现。在图1的示例中，如图1所示，调度管理器150包括调度管理数据150A。调度管理数据150A可以包括关于以下各项的数据：传入请求的历史，预热池130A中的能力，活动池140A中的能力，与特定程序代码和/或用户账户相关联的周期性以及可以由调度管理器150用来预测、调度和重新调度请求在虚拟计算系统上执行的作业，并相应地调整和/或优化由虚拟计算系统110维护和使用的能力。调度管理数据150A还可以包括由用户指定的任何管理策略(例如，提供给调度管理器150的灵活量，用于调度与给定用户相关联的作业)，或由调度管理器150确定的管理策略，用于调度和管理由虚拟计算系统110接收到的传入请求。调度管理数据150A可以存储在虚拟计算系统110内部的存储设备中，或者存储在外部存储设备(例如，存储服务108)中并周期性地备份。

调度管理器150监视由虚拟计算系统110接收的代码执行请求，并识别由传入代码执行请求表现的任何周期性。例如，调度管理器150可以在接收到与特定用户账户或用户功能相关联的代码执行请求的特定时间中查找模式。例如，调度管理器150可以确定仅在凌晨3:00与凌晨3:15之间接收与特定用户账户相关联的请求(例如，这样的请求可以包括日常维护操作)。在另一个示例中，调度管理器150可以确定仅在星期日接收到与特定程序代码相关联的请求(例如，这样的请求可以包括每周备份操作)。在另一个示例中，调度管理器150可以确定系统范围的流量通常从晚上7:00到晚上9:00是最高的。在一些情况下，与特定用户账户或用户功能相关联的传入代码执行请求可以全天或者在未展示任何可识别的周期性的情况下接收。

在一些实施方案中，调度管理器150使用输入流量模式的回归模型来检测周期性。在其他实施方案中，调度管理器150可以基于与传入代码执行请求相关联的参数(例如，接收时间、相关联的用户账户、相关联的用户功能、最大持续时间、将要分配的资源量等)，从调度管理器150生成的日志数据(例如，调度管理数据150A)来对周期性进行逆向工程分析。例如，调度管理器150可周期性地分析调度管理数据150A(例如，每日、每周、每月、每年等)以识别由传入代码执行请求表现的周期性。在一些实施方案中，操作人员可以注意到传入代码执行请求中的周期性并且将某些周期性参数输入到虚拟计算系统110中(例如，预期的接收时间、关联的用户账户、关联的用户功能等)。基于所识别的周期性，调度管理器150可调整在虚拟计算系统110上维护的能力。下面参照图5更详细地描述识别周期性和调整在虚拟计算系统110上维持的能力的过程。

调度管理器150还可以调度和管理虚拟计算系统110上的代码执行。如果请求同时或在较短时间跨度内执行一批代码执行，则调度管理器150可根据由用于执行用户代码的指定时间范围提供的灵活度来重新调度一些代码执行。获得执行时间的灵活性的一种方式是在请求中设定一个范围，使得调度云功能在特定时间执行的任何请求实际上意味着云功能将在指定时间之前和之后的时间段内执行。例如，如果请求在下午3:00执行程序代码，则虚拟计算系统110可以默认地具有在下午2:50和下午3:10之间的任何时间执行代码的灵活性。可以向虚拟计算系统110的用户通知这个范围。范围可能会取决于实现方式而有所不同。

在一些实施方案中，与在虚拟计算系统110上执行用户功能相关联的成本可以根据请求所指定的时间灵活度而变化。例如，如果用户请求在下午11:00与凌晨1:00之间运行程序代码，则每次执行的成本可能为0.01美分。如果用户请求程序代码在下午11:55与凌晨1:05之间运行，则每次执行的成本可能为0.02美分。如果用户请求程序代码恰好在上午12:00运行，则每次执行的成本可能为0.05美分。为虚拟计算系统110提供很大灵活性的另一个示例是允许用户指定可以如由请求到达率、正在处理的并行作业的数量或其他机制所确定，在流量较低时运行用户功能(可能比指定一个窗更低廉)。

计算系统110可以向用户呈现(例如，经由允许用户调度代码执行的图形用户界面)与可以针对代码执行请求来指定的各种范围相关联的成本。开始时间的灵活性为虚拟计算系统110提供了在输入流量较低时调度执行代码的能力，由此减少虚拟计算系统110需要提供的突发能力的量。

在一些实施方案中，不是使用范围来获得灵活性，用户可以指定时间点，请求虚拟计算系统110在这个时间点之前或之后运行程序。例如，请求可以指定虚拟计算系统110应该在10月10日之后的某个时间(例如，在指定的日期或之后)运行程序代码。在另一示例中，请求可以指定虚拟计算系统110应该在10月8日之前某个时间完成运行程序代码(例如，在10月8日或之前完成运行程序代码)。在这样的示例中，虚拟计算系统110可以确保至少在等于指定期限之前的最大持续时间的时间量内启动代码执行。在又一示例中，所述请求可以指定虚拟计算系统110应该在10月8日之前的某个时间开始运行程序代码(例如，在10月8日或之前启动程序代码的执行，但不必在10月8日或之前完成)。在一些实施方案中，每个代码执行请求指定了最大持续时间，在所述最大持续时间之后，应该认为程序代码的执行已经超时。在这样的实施方案中，虚拟计算系统110可利用指定的最大持续时间来分散工作负载，使得虚拟计算系统110在任何给定时间点都不会过载。下面参考图6更详细地描述以灵活方式调度代码执行的过程。

调度管理器150可以包括用于监视由虚拟计算系统110接收的请求的请求和能力监视单元以及用于在虚拟计算系统110上调度和管理代码执行和能力的调度和能力调整单元。以下参考图4更详细地描述调度管理器150的示例性配置。

处理周期性作业的说明性示例

参考图2，将描述具有(右)和不具有(左)调度管理器150的虚拟计算系统110中的预热池管理器130。在图2的示例中，虚拟计算系统110接收周期性请求210。

图2左侧的示例示出了可能不识别周期性请求210的周期性的系统。在图2的示例中，周期性请求210的五个箭头可以各自表示在指定时间(例如，X+T，X+2T，X+3T，X+4T和X+5T，其中T是周期)接收的代码执行请求。在这个示例中，虚拟计算系统110包括预热池130A，所述预热池130A包括虚拟机实例220、230、240和250(每个虚拟机实例具有加载在其上的适当的OS和运行时)。在不知道何时将接收到代码执行请求的情况下，虚拟计算系统110可能需要在其预热池130A中保持大量的计算能力以适应例如考虑到所有这些作业并行运行所导致的任何突发流量。

图2右侧的示例示出了已经识别周期性请求210的周期性的系统。在这个示例中，虚拟计算系统110包括预热池130A，其包括虚拟机实例220(其上加载有OS 220A和运行时220B)。在知道什么时候将接收到周期性请求210的情况下，虚拟计算系统110可以在其预热池130A中维持减少量的能力，并且可以在接收到周期性请求210之前不久获取处理周期性请求210所需的计算能力。例如，知道5个作业是周期性的并且因此不重叠可以将超额能力的量减少80％(与维持足以并行执行5个作业的能力相比)。在另一个示例中，如果虚拟计算系统110平均每天接收10个请求，则知道它们中的5个的周期性(例如，这些请求分别在每天下午1:00、下午2:00、下午3:00、下午4:00PM和下午5:00接收到)可以允许虚拟计算系统110忽略这些请求(因为知道它们何时将到达，可以在它们的预计到达时间之前增加能力)，以便确定在预热池130A中维持多少能力，这将使预热池能力减少一半。因此，通过识别并跟踪传入代码执行请求中的周期性，虚拟计算系统110可以实现与其必须在其预热池130A中维持的虚拟机实例的数量的减少相关联的成本节约。

调度作业的说明性示例

参考图3，将描述在调度管理器150已调度(或重新调度)作业之前(右)和之后(左)的虚拟计算系统110中的工作者管理器140。在图3的示例中，作业301-304由虚拟计算系统110的用户请求并且由例如虚拟计算系统110的调度管理器150调度。

图3左侧的示例示出了计划在上午12:00开始的所有作业301-304。为了运行所有作业301-304，活动池140A可能需要运行4个虚拟机实例(例如，实例310、320、330和340，每个虚拟机实例加载有适当的OS、运行时和代码)或容器。如果在调度作业301-304中不具有灵活性，则虚拟计算系统110可能需要同时运行大量的虚拟机实例，并且因此可能会遇到延迟增加和/或任何其他问题。

图3右侧的示例示出了其中调度管理器150已经分散了所调度作业301-304的系统，使得在任何给定时间仅执行单个作业。通过在调度作业中具有灵活性并且基于灵活性来分散工作负载，虚拟计算系统110可能能够使用更少数量的虚拟机实例进行操作，并且防止其本身由于必须处理大量的同时作业而负担过重或能够节省成本。

调度管理器的通用架构

图4描绘了管理虚拟计算系统110中的虚拟机实例的计算系统(称为调度管理器150)的通用架构。图4中所示的调度管理器150的通用架构包括可用于实现本公开的各方面的计算机硬件和软件模块的布置。调度管理器150可以包括比图4所示更多(或更少)的元件。然而，没有必要为了提供可行的公开内容而显示所有这些通常常规元件。如图所示，调度管理器150包括处理单元190、网络接口192、计算机可读介质驱动器194、输入/输出设备接口196，所有这些都可以通过通信总线彼此通信。网络接口192可以提供到一个或多个网络或计算系统的连接。因此，处理单元190可以经由网络104从其他计算系统或服务接收信息和指令。处理单元190还可以传达发送到存储器180和来自存储器180的数据，并且还经由输入/输出设备接口196来提供用于可选显示器(未示出)的输出信息。输入/输出设备接口196还可以接受来自可选输入设备(未示出)的输入。

存储器180可以包含为了实现本公开的一个或多个方面而由处理单元190执行的计算机程序指令(在一些实施方案中被分组为模块)。存储器180大体包括RAM、ROM和/或其他持久、辅助或非暂时性计算机可读介质。存储器180可以存储操作系统184，所述操作系统184提供计算机程序指令供处理单元190在调度管理器150的一般管理和操作中使用。存储器180可以还包括用于实现本公开的各方面的计算机程序指令和其他信息。例如，在一个实施方案中，存储器180包括用户界面单元182，所述用户界面单元182例如经由安装在计算设备上的导航和/或浏览界面(例如浏览器或应用程序)产生用于在计算设备上显示的用户界面(和/或其指令)。另外，存储器180可以包括一个或多个数据储存库(未示出)和/或与这些储存库通信，以例如访问用户程序代码和/或存储库。

除了用户界面单元182结合之外和/或与用户界面单元182组合，存储器180可以包括可以由处理单元190执行的请求和能力监视单元186以及调度和能力调整单元188。在一个实施方案中，用户界面单元182、请求和能力监视单元186以及调度和能力调整单元188单独地或共同地实现本公开的各个方面，例如监视传入代码执行请求，确定传入代码执行请求是否表现出任何周期性，致使在预热池130A中维持减少量的闲置能力，恰好在接收到传入代码执行请求之前，获取用于处理这些传入代码执行请求的计算能力(例如，基于它们的周期性)，调度多个作业使得它们彼此不重叠等，如下面进一步描述。

请求和能力监视单元186监视传入代码执行请求。例如，请求和能力监视单元186监视传入代码执行请求并且识别由一些或全部传入代码执行请求表现出的任何周期性，这种周期性可以用于更好地管理虚拟计算系统110上的能力(例如，减少预热池130A中保持的能力数量)。请求和能力监视单元186可以跟踪接收到每个传入代码执行请求的时间以及与这些请求相关联的用户账户和/或用户功能以及所请求和实际持续时间或其他资源消耗，诸如存储器。

调度和能力调整单元188调度作业并调整预热池130A和/或活动池140A中的能力。例如，基于由请求和能力监视单元186识别的周期性，调度和能力调整单元188可以使得在预热池130A中维持的能力的量减少。此外，在被识别为具有周期性的代码执行请求预期将要被虚拟计算系统110接收的时间之前不久，调度能力调整单元188可以致使将另外能力添加到活动池140A，或者基于周期性分析/预测，为了对预计的将来请求提供服务，致使活动池140A中的能力比通常情况下保留更长时间。

虽然请求和能力监视单元186以及调度和能力调整单元188在图4中示出为调度管理器150的一部分，但在其他实施方案中，请求和能力监视单元186以及调度和能力调整单元188的全部或一部分可以由虚拟计算系统110的其他部件和/或另一计算设备来实现。例如，在本公开的某些实施方案中，与虚拟计算系统110通信的另一个计算设备可以包括与示出为调度管理器150的一部分的模块和部件类似地操作的若干模块或部件。

用于管理调度代码执行请求的示例性例程

现在转到图5，将描述由虚拟计算系统110的一个或多个部件(例如，调度管理器150)实现的例程500。尽管相对于通过调度管理器150的实现方式来描述了例程500，但相关领域的技术人员将认识到，替代性部件可以实现例程500或者一个或多个方框可以由不同部件或以分布式方式来实现。

在说明性例程500的方框502处，调度管理器150监视由虚拟计算系统110接收的传入代码执行请求，例如以识别传入请求所呈现的任何周期性(例如，至少一些传入请求本质上是周期性的)。调度管理器150可以在数据库(例如，调度管理数据150A)中记录以下各项：虚拟计算系统110接收到每个请求的时间连同与所述请求相关联的程序代码的身份，与所述请求相关联的用户账户，与所述请求相关联的最大持续时间，和/或与所述请求相关联的任何其他参数，以及实际资源消耗，包括运行时间(持续时间)、存储器使用、应用的节流、已通过或失败的安全测试等。

接下来，在方框504处，调度管理器150确定虚拟计算系统110接收的传入代码执行请求中的至少一些是否呈现任何周期性。例如，调度管理器150可以确定仅在凌晨3:00与凌晨3:15之间接收与特定用户账户相关联的请求(例如，这样的请求可以包括日常维护操作)。在另一个示例中，调度管理器150可以确定仅在星期日接收到与特定程序代码相关联的请求(例如，这样的请求可以包括每周备份操作)。在另一个示例中，调度管理器150可以确定系统范围的流量通常从晚上7:00到晚上9:00是最高的。在一些情况下，与特定用户账户或用户功能相关联的传入代码执行请求可以全天或者在未展示任何可识别的周期性的情况下接收。即使在这样的情况下，通过识别至少一些展现出可识别的周期性的代码执行请求，虚拟计算系统110可能能够将这样的代码执行请求视为计划请求。对于虚拟计算系统110来说，这样的周期性的或计划的请求导致成本节约，因为如果虚拟计算系统110何时将接收到请求，则虚拟计算系统110不需要仅仅为了能够处理不可预知的突发流量而维持闲置计算能力(其可能代价高昂)；它可以仅在请求到达虚拟计算系统110时(或刚好在请求到达之前)获取计算能力。在一些实施方案中，调度管理器150可以处理由虚拟计算系统110基于传入代码执行请求来生成的日志和/或度量以确定是否任何这样的代码执行请求表现出任何周期性。

如果调度管理器150确定由虚拟计算系统110接收的至少一些代码执行请求表现出一定程度的周期性，则例程500进行至方框506，其中调度管理器150致使减少量的闲置计算能力(或未分配给特定用户账户或处在各个作业之间的未分配计算能力)得以保持(例如，在预热池130A中)。例如，减少的量可以与被识别为周期性的代码执行请求的数量成比例。如果没有任何代码执行请求被识别为周期性的，则在预热池130A中保持的闲置计算能力可能根本不会被减少。另一方面，如果所有代码执行请求都被识别为周期性的，则可以移除预热池130A中保持的所有闲置计算能力。类似地，如果一半的代码执行请求被识别为周期性的，则在预热池130A中保持的闲置计算能力的量可以减少到通常在预热池130A中保持的量的一半。如果调度管理器150确定没有任何代码执行请求表现出任何周期性，则例程500进行到方框502，并且调度管理器150继续监视传入代码执行请求。在一些实施方案中，调度管理器150(或虚拟计算系统110的其他部件，诸如预热池管理器130)通过避免将另外虚拟机实例添加到预热池130A直到预热池130A中的虚拟机实例的数量达到对应于减少量的数量，致使维持减少量的闲置计算能力。例如，如果调度管理器150基于传入代码执行请求所呈现的周期性确定在预热池130A中维持的闲置能力应该减半，则调度管理器150可以避免将另外的能力添加到预热池直到预热池130A中的能力的量变成先前在预热池130A中维持的量的一半。在一些情况下，调度管理器150可主动关闭预热池130A中的一些虚拟机实例以达到减少的数量。在其他情况下，调度管理器150可以使实例更加自由地(或主动地)从预热池130A移动到活动池140A。在一些实施方案中，闲置计算能力的量的减少可能源自活动池140A。例如，基于在方框504处检测到的周期性(例如，确定预期没有使用活动池140A中的当前闲置实例的请求很快到来)，放置在活动池140A中但当前不执行用户代码的虚拟机实例可以关闭，否则所述虚拟机实例在活动池140A中在闲置状态下将保持在运行中(例如，在没有周期性信息的情况下)。

在方框508处，在预计的接收时间，调度管理器150致使获取用于处理传入代码执行请求(或者展示与被确定为呈现某种程度的周期性的传入代码执行请求相同的周期性的下一个请求)的另外计算能力，所述传入代码执行请求被识别为周期性的。例如，如果基于所识别的周期性，虚拟计算系统110预期在下午3:00接收到一批代码执行请求，则在这批请求的时间预期到来之前的某个时间(例如，下午2:59，或者在允许虚拟计算系统110配置计算能力以便到下午3:00可处理这批请求的时间)，调度管理器150可以致使获取足以处理这批代码执行请求的另外计算能力(例如，一个或多个虚拟机实例)(例如，通过向实例供应服务109发送请求或者通过指示虚拟计算系统110的另一个部件这样做)。例如，提前获取并预先初始化另外计算能力的阈值时间量可能会根据程序代码、用户账户或请求而有所不同。在一些情况下，所获得的计算能力可以被直接添加到活动池140A。例如，如果一批代码执行请求与其执行设置已知的用户相关联，则所获取的计算能力可以预先初始化并且放置在活动池140中，从而一旦请求到来，就可以使用计算能力。在一些实施方案中，在预计被识别为周期性的代码执行请求的情况下，可以通过将放置在活动池140A中但当前不在其上执行用户代码的一个或多个虚拟机实例保持在运行中来添加另外的计算能力，否则所述虚拟机实例在活动池140A中在闲置状态下得以终止(例如，在没有周期性信息的情况下)。在其他情况下，所获取的计算能力可以添加到预热池130A。例如，如果调度管理器150确定在10分钟内预期传入代码执行请求出现系统范围的增加，则调度管理器150可以获取另外的能力并将所述能力添加到预热池130A，从而可以使用所增加的能力以处理更多不同的请求。在一些实施方案中，调度管理器150(或诸如工作者管理器140的虚拟计算系统110的其他部件)可以在所获取的用于执行与这批请求相关联的用户功能的(多个)虚拟机实例上创建一个或多个容器并且在虚拟计算系统110接收到这批请求之前将用户功能加载到容器上。通过这样做，调度管理器150允许一旦接收到这批请求就执行用户功能，而不必首先获取虚拟机实例，在其上创建一个或多个容器，并将一个或多个用户功能加载到容器上，从而减少与在虚拟计算系统110上执行用户功能相关联的延迟。

虽然图5的例程500已经在上面参考方框502-508进行了描述，但本文描述的实施方案不限于此，并且在不脱离本公开的精神的情况下可以省略、修改或改变一个或多个方框。

基于时间准则来调度代码执行请求的示例性例程

现在转到图6，将描述由虚拟计算系统110的一个或多个部件(例如，调度管理器150)实现的例程600。尽管相对于通过调度管理器150的实现方式来描述了例程600，但相关领域的技术人员将认识到，替代性部件可以实现例程600或者一个或多个方框可以由不同部件或以分布式方式来实现。

在说明性例程600的方框602处，调度管理器150接收具有用于执行第一程序代码的第一时间范围的第一作业请求。例如，第一作业请求可能会请求在明天凌晨3点执行备份例程。在一些实施方案中，由请求指定的时间范围可以是以下各项中的一者：(i)请求虚拟计算系统在此之前执行第一程序代码的时间(例如，“到凌晨3:00执行备份例程，但可以在此之前的任何时间开始”)，(ii)请求虚拟计算系统在此之后执行第一程序代码的时间(例如，“在凌晨3:00之后执行备份例程，但在你启动备份例程之前你可以花费无论多长时间”)，或(iii)请求虚拟计算系统在此之内执行第一程序代码的时间窗(例如，“在凌晨2:30与凌晨3:30之间执行备份例程”或“在凌晨3:00加上或减去30分钟，执行备份例程”)。在一些实施方案中，时间范围可以在请求本身中提供。在其他实施方案中，调度管理器150可以通过使用与请求相关联的用户账户或与请求相关联的程序代码或通过使用系统范围设置或公布的系统范围、按账户或按功能的SLA来查找时间范围，从而确定与请求相关联的时间范围。在一些实施方案中，将调度管理器150配置为经由用户界面来提供在各种时间灵活度(例如，上面列出的选项(i)-(iii))中进行选择的选项。在一些实施方案中，不同的时间灵活度可以与在虚拟计算系统110上执行用户功能相关联的不同成本量相关联。例如，如果用户指定要执行所请求的用户功能的2小时范围，则每次执行可能花费用户0.01美分，但如果用户指定执行所请求的用户功能的确切时间点，则每次执行导致花费用户0.1美分。

在方框604处，调度管理器150接收具有用于执行第二程序代码的第二时间范围的第二作业请求。例如，第二作业请求可以请求在明天凌晨3:00执行文件压缩例程。如上所述，由请求指定的时间范围可以是以下各项中的一者：(i)请求虚拟计算系统在此之前执行第一程序代码的时间(例如，“到凌晨3:00执行文件压缩例程，但可以在此之前的任何时间开始”)，(ii)请求虚拟计算系统在此之后执行第一程序代码的时间(例如，“在凌晨3:00之后执行文件压缩例程，但在你启动文件压缩之前你可以花费无论多长时间”)，或(iii)请求虚拟计算系统在此之内执行第一程序代码的时间窗(例如，“在凌晨2:30与凌晨3:30之间执行文件压缩例程”或“在凌晨3:00加上或减去30分钟，执行文件压缩例程”)。尽管在此使用备份例程和文件压缩例程作为示例，但可以使用任何其他程序代码、用户功能等。在一些实施方案中，请求还指定了最大持续时间，在此之后对应的代码执行应被视为超时。例如，这样的最大持续时间可以向调度管理器150提供如下保证，即从开始用户功能的执行的时间起，在等于最大持续时间的一段时间过去之后，用户功能将不会继续运行。

在方框606处，调度管理器150调度第一和第二作业，使得第一和第二作业彼此不重叠。在上面的示例中，即使第一和第二作业请求中的每个请求的指定时间范围都可能指向凌晨3:00，但在调度作业时可能会有一定的灵活性。如果两个作业请求都指定对应的例程应该在凌晨3:00或之后的某个时间执行，则调度管理器150可以调度备份例程在凌晨3:00执行并且文件压缩例程在凌晨3:10执行。如果两个作业请求指定对应的例程应该在凌晨3:00或之前的某个时间完成执行，则调度管理器150可以调度在凌晨2:40执行备份例程，并且在凌晨2:50执行文件压缩例程。如果两个作业请求都指定对应的例程应该在凌晨2:30与凌晨3:30之间执行，则调度管理器150可以调度在凌晨2:50执行备份例程并且在凌晨3:00执行文件压缩例程。在一些实施方案中，如果两个作业请求都指定对应的例程必须在凌晨3:00之前完成执行，则在(凌晨3:00-(相应作业的最大持续时间))之后，两个作业都不能被调度。

虽然图6的例程600已经在上面参考方框602-606进行了描述，但本文描述的实施方案不限于此，并且在不脱离本公开的精神的情况下可以省略、修改或改变一个或多个方框。

基于执行要求来调度作业的示例性例程

现在转到图7，将描述由虚拟计算系统110的一个或多个部件(例如，调度管理器150)实现的例程700。尽管相对于通过调度管理器150的实现方式来描述了例程700，但相关领域的技术人员将认识到，替代性部件可以实现例程700或者一个或多个方框可以由不同部件或以分布式方式来实现。

在说明性例程700的方框702处，调度管理器150接收执行具有第一组执行要求的第一作业的请求。例如，第一组执行要求可以包括用于执行第一作业的计算资源(例如，存储器、CPU、网络等)的数量。在另一个示例中，第一组执行要求可以包括时间或空间资源，例如执行第一作业需要多少时间，以及执行第一作业需要多少计算能力等等。例如，第一作业可能是使用128MB内存的文件压缩例程。

在方框704处，调度管理器150调度管理器150接收执行具有第二组执行要求的第二作业的请求。例如，第二组执行要求可以包括用于执行第二作业的计算资源(例如，存储器、CPU、网络等)的数量。在另一个示例中，第二组执行要求可以包括时间或空间资源，例如执行第二作业需要多少时间，以及执行第二作业需要多少计算能力等等。例如，第二作业可能是使用512MB内存的图像处理例程。

在方框706处，调度管理器150基于第一组和第二组执行要求来确定一个或多个调度准则。例如，调度管理器150在确定第一作业使用128MB的内存并且第二作业使用512MB的内存的情况下还可以确定对于要同时执行的第一作业和第二作业(或者执行使得作业在时间上重叠)，需要至少640MB的内存。换句话说，调度准则可以是(i)只要虚拟计算系统110具有至少128MB的闲置内存，就可以调度执行第一作业，(ii)只要虚拟计算系统110具有至少512MB的闲置内存，就可以调度执行第二作业，并且(iii)只要虚拟计算系统110至少具有640MB的闲置内存，就可以时间重叠方式调度执行第一和第二作业。

在方框708处，调度管理器150调度第一和第二作业，使得满足调度准则。在上面讨论的示例中，如果虚拟计算系统在要执行第一和第二作业时具有1GB的内存，则调度管理器150可以调度第一和第二作业以同时执行。如果虚拟计算系统110仅具有600MB可用内存，则调度管理器150可以调度第一和第二作业，使得执行不重叠。虽然内存用于说明第一和第二作业之间的资源争用，但这些技术可以扩展到第一和第二作业都可以使用的任何其他资源。

虽然图7的例程700已经在上面参考方框702-708进行了描述，但本文描述的实施方案不限于此，并且在不脱离本公开的精神的情况下可以省略、修改或改变一个或多个方框。

其他考虑因素

本领域中技术人员应理解，本公开中描述的所有功能可以在由所公开部件和移动通信设备的一个或多个物理处理器执行的软件中实施。所述软件可以永久地存储在任何类型的非易失性存储装置中。

除非另外特别说明，或者在所用上下文中不同地理解，否则诸如“能够”、“可以”、“可能”或者“也许”等等的条件语言通常意图表示，尽管其他实施方案不包括，但某些实施方案包括特定的特征、元件和/或步骤。因此，这种条件性语言通常并不意图暗示特征、元件和/或步骤是一个或多个实施方案以任何方式所要求的，或一个或多个实施方案必定包括用于在有或没有用户输入或提示的情况下决定这些特征、元件和/或步骤被包括在任何特定实施方案中或将要在任何特定实施方案中进行的逻辑。

鉴于下列条款，可更好理解上述说明：

1.一种用于提供来自虚拟计算编队的低延时计算能力的系统，所述系统包括：

电子数据存储区，其被配置为存储用户的至少一个程序代码；和

虚拟计算系统，其包括执行特定计算机可执行指令的一个或多个硬件计算设备，所述虚拟计算系统与所述数据存储区通信并且被配置为至少：

在一个或多个物理计算设备上保持多个虚拟机实例，其中所述多个虚拟机实例包括：

预热池，所述预热池包括虚拟机实例，所述虚拟机实例具有加载在其上的一个或多个软件部件并且等待分配给用户；和

活动池，所述活动池包括当前分配给一个或多个用户的虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求，所述传入代码执行请求中的至少一些呈现一定程度的周期性；

确定与所述传入代码执行请求中的所述至少一些相关联的所述一定程度的周期性，所确定的一定程度的周期性指示所述传入代码执行请求中的所述至少一些预期将要由所述虚拟计算系统接收的时间段；

响应于确定与所述传入代码执行请求中的所述至少一些相关联的所述一定程度的周期性，致使在所述预热池中保持减少数量的虚拟机实例，其中所述减少数量是基于所述传入代码执行请求中的所述至少一些的数量和所确定的一定程度的周期性来确定；

在所述时间段之前，致使将至少一个虚拟机实例添加到所述活动池，并且致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述至少一个虚拟机实例上；和

响应于接收到与所述传入代码执行请求中的所述至少一些相关联的请求，致使加载在所述至少一个虚拟机上的程序代码被执行。

2.根据条款1所述的系统，其中所述虚拟计算系统还被配置为：

在第一时间段接收执行第一程序代码的第一请求；

在第二时间段接收执行第二程序代码的第二请求，其中所述第二时间段至少部分地与所述第一时间段重叠；和

调度所述第一程序代码的第一执行和所述第二程序代码的第二执行，使得所述第一和第二执行不重叠。

3.根据条款2所述的系统，其中所述第一时间段包括以下各项中的一者：(i)请求所述虚拟计算系统在此之前执行所述第一程序代码的时间，(ii)请求所述虚拟计算系统在此之后执行所述第一程序代码的时间，或(iii)请求所述虚拟计算系统在此之内执行所述第一程序代码的时间窗。

4.一种系统，其包括：

虚拟计算系统，其包括执行特定计算机可执行指令的一个或多个硬件计算设备，并且被配置为至少：

在一个或多个物理计算设备上保持多个虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求；

确定所述传入代码执行请求中的至少一些是否呈现周期性，所述传入代码执行请求中的所述至少一些与一个或多个执行参数相关联；

响应于确定所述传入代码执行请求中的所述至少一些呈现周期性，致使在所述虚拟计算系统上保持减少量的闲置计算能力，所述减少量基于所述周期性来确定；和

在所述虚拟计算系统接收到呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求之前，致使基于所述一个或多个执行参数来预初始化另外虚拟机实例。

5.根据条款4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的活动池，其中所述虚拟计算系统被配置为通过从所述活动池移除先前用来执行程序代码但目前没有执行程序代码的实例来致使所述减少量的闲置计算能力。

6.根据条款4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述活动池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

7.根据条款4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的预热池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到预热池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

8.根据条款4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

在所述活动池中查找未填充的虚拟机实例，其中所述未填充的虚拟机实例没有被充分利用；和

在所述未填充的虚拟机实例上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

9.根据条款4所述的系统，其中所述多个虚拟机实例包括具有加载在其上的一个或多个软件部件并且等待分配给用户的虚拟机实例的预热池，并且其中所述虚拟计算系统被配置为通过避免将另外虚拟机实例添加到所述预热池直到所述预热池中的虚拟机实例的数量达到对应于减少量的数量，致使在所述虚拟计算系统上保持所述减少量的闲置计算能力。

10.根据条款4所述的系统，其中所述虚拟计算系统还被配置为响应于接收到所述另外周期性请求而致使与所述另外周期性请求相关联的程序代码在所述另外虚拟机实例上创建的容器中执行，其中在所述虚拟计算系统接收到所述另外周期性请求之前，将所述程序代码加载到所述容器中。

11.根据条款4所述的系统，其中所述虚拟计算系统还被配置为：

接收与第一程序代码相关联的第一作业请求，用于执行所述第一程序代码的第一最大持续时间以及用于执行所述第一程序代码的第一时间范围；

接收与第二程序代码相关联的第二作业请求和用于执行所述第二程序代码的第二时间范围，所述第二时间范围至少部分地与所述第一时间范围重叠；和

确定执行所述第一程序代码的第一执行时间和执行所述第二程序代码的第二执行时间，使得所述第一执行时间至少按照所述第一最大持续时间先于所述第二执行时间。

12.根据条款11所述的系统，其中所述虚拟计算系统还被配置为经由用户界面提供在与第一成本相关联的第一时间灵活度与大于所述第一时间灵活度并且与第二成本相关联的第二时间灵活度之间进行选择的选项，其中所述第一成本大于所述第二成本。

13.根据条款4所述的系统，其中所述虚拟计算系统被配置为通过周期性地分析基于所述传入代码执行请求生成的日志数据来确定所述传入代码执行请求中的至少一些是否呈现周期性。

14.一种计算机实现的方法，其包括：

当由被配置有特定可执行指令的一个或多个计算设备实现时，

在一个或多个物理计算设备上保持多个虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求；

确定所述传入代码执行请求中的至少一些是否呈现周期性，所述传入代码执行请求中的所述至少一些与一个或多个执行参数相关联；

响应于确定所述传入代码执行请求中的所述至少一些呈现周期性，致使在所述虚拟计算系统上保持减少量的未分配计算能力，所述减少量基于所述周期性来确定；

确定所述传入代码执行请求中的所述至少一些预期在阈值时间量内被接收；和

在所述虚拟计算系统接收到呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求之前，致使基于所述一个或多个执行参数来配置另外虚拟机实例。

15.根据条款14所述的计算机实现的方法，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述活动池；和

在所述另外虚拟机上创建容器并且致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述容器中。

16.根据条款14所述的计算机实现的方法，其中所述多个虚拟机实例包括虚拟机实例的预热池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述预热池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

17.根据条款14所述的计算机实现的方法，其还包括：

接收执行与第一组执行要求相关联的第一作业的请求；

接收执行与第二组执行要求相关联的第二作业的请求；

基于所述第一组和第二组执行要求来确定一个或多个调度准则；和

确定用于执行所述第一作业的第一执行时间和用于执行所述第二作业的第二执行时间，使得满足所述一个或多个调度准则。

18.包括指令的非暂时性物理计算机存储装置，所述指令在由一个或多个计算设备执行时将所述一个或多个计算设备配置为：

在一个或多个物理计算设备上保持多个虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求；

确定所述传入代码执行请求中的至少一些是否呈现周期性，所述传入代码执行请求中的所述至少一些与一个或多个执行参数相关联；

响应于确定所述传入代码执行请求中的所述至少一些呈现周期性，致使在所述虚拟计算系统上保持减少量的未分配计算能力，所述减少量基于所述周期性来确定；

确定所述传入代码执行请求中的所述至少一些预期在阈值时间量内被接收；和

在所述虚拟计算系统接收到呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求之前，致使基于所述一个或多个执行参数来配置另外虚拟机实例。

19.根据条款18所述的非暂时性物理计算机存储装置，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述活动池；和

在所述另外虚拟机上创建容器，并且致使将与呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求相关联的程序代码加载到所述容器中。

20.根据条款18所述的非暂时性物理计算机存储装置，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

在所述活动池中查找未填充的虚拟机实例，其中所述未填充的虚拟机实例没有被充分利用；和

在所述未填充的虚拟机实例上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

21.根据条款18所述的非暂时性物理计算机存储装置，其中所述指令还配置所述一个或多个计算设备以：

接收执行与第一组执行要求相关联的第一作业的请求；

接收执行与第二组执行要求相关联的第二作业的请求；

基于所述第一组和第二组执行要求来确定一个或多个调度准则；和

确定用于执行所述第一作业的第一执行时间和用于执行所述第二作业的第二执行时间，使得满足所述一个或多个调度准则。

本文所描述和/或附图所描绘的流程图中的任何过程说明、元件或方框应理解成潜在地表示包括用于实施过程中的特定逻辑功能或步骤的一个或多个可执行指令的模块、片段或代码部分。替代实现方式包括在本文描述的实施方案的范围内，其中元件或功能可以删除，不按所展示或所讨论的顺序来执行，包括基本上同时地或以相反的顺序来执行，这取决于所涉及的功能，如本领域技术人员所了解。还应理解，可以将数据和/或部件存储在计算机可读介质上并且使用与存储计算机可执行部件的计算机可读存储介质相关联的驱动机构将其加载到计算设备的存储器中，所述计算机可读存储介质例如CD-ROM、DVD-ROM或网络接口。此外，部件和/或数据可以包括在单个设备中或以任何方式分布。因此，通用计算设备可以被配置为使用上述各种数据和/或部件的处理和/或执行来实现本公开的过程、算法和方法。

应强调，可以对上述实施方案作出许多改变和修改，这些改变和修改的要素应被理解为包含在其他可接受的示例当中。在本文中，所有这类修改和变化意图被包括在本公开的范围内，并且受所附权利要求书保护。

Claims (15)

1.一种用于提供来自虚拟计算编队的低延时计算能力的系统，所述系统包括：

电子数据存储区，其被配置为存储用户的至少一个程序代码；和

虚拟计算系统，其包括执行特定计算机可执行指令的一个或多个硬件计算设备，所述虚拟计算系统与所述数据存储区通信并且被配置为至少：

在一个或多个物理计算设备上保持多个虚拟机实例，其中所述多个虚拟机实例包括：

预热池，所述预热池包括虚拟机实例，所述虚拟机实例具有加载在其上的一个或多个软件部件并且等待分配给用户；和

活动池，所述活动池包括当前分配给一个或多个用户的虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求，所述传入代码执行请求中的至少一些呈现一定程度的周期性；

确定与所述传入代码执行请求中的所述至少一些相关联的所述一定程度的周期性，所确定的一定程度的周期性指示所述传入代码执行请求中的所述至少一些预期将要由所述虚拟计算系统接收的时间段；

响应于确定与所述传入代码执行请求中的所述至少一些相关联的所述一定程度的周期性，致使通过所述虚拟计算系统保持减少数量的虚拟机实例，其中所述减少数量是基于所述传入代码执行请求中的所述至少一些的数量和所确定的一定程度的周期性来确定；

在所述预期接收到所述传入代码执行请求的时间段之前，致使将至少一个虚拟机实例添加到所述活动池；

在致使保持所述减少数量的虚拟机实例之后，并且在所述预期接收到所述传入代码执行请求的时间段之前，致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述至少一个虚拟机实例上；和响应于接收到与所述传入代码执行请求中的所述至少一些相关联的请求，致使加载在所述至少一个虚拟机上的所述程序代码被执行。

2.根据权利要求1所述的系统，其中所述虚拟计算系统还被配置为：

在第一时间段接收执行第一程序代码的第一请求；

在第二时间段接收执行第二程序代码的第二请求，其中所述第二时间段至少部分地与所述第一时间段重叠；和

调度所述第一程序代码的第一执行和所述第二程序代码的第二执行，使得所述第一和第二执行不重叠。

3.根据权利要求2所述的系统，其中所述第一时间段包括以下各项中的一者：(i)请求所述虚拟计算系统在此之前执行所述第一程序代码的时间，(ii)请求所述虚拟计算系统在此之后执行所述第一程序代码的时间，或(iii)请求所述虚拟计算系统在此之内执行所述第一程序代码的时间窗。

4.一种计算机实现的 系统，其包括：

虚拟计算系统，其包括执行特定计算机可执行指令的一个或多个硬件计算设备，并且被配置为至少：

在一个或多个物理计算设备上保持多个虚拟机实例；

监视在所述虚拟计算系统上执行程序代码的传入代码执行请求；

确定所述传入代码执行请求中的至少一些是否呈现周期性，所述传入代码执行请求中的所述至少一些与一个或多个执行参数相关联；

响应于确定所述传入代码执行请求中的所述至少一些呈现周期性，致使在所述虚拟计算系统上保持减少量的虚拟机实例，所述减少量基于所述周期性来确定；和

在所述虚拟计算系统接收到呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求之前，致使基于所述一个或多个执行参数来配置另外虚拟机实例，

在所述虚拟计算系统上保持减少量的虚拟机实例之后，并且在所述虚拟计算系统接收到另外周期性请求之前，致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述另外虚拟机实例上；以及

响应于接收到另外周期性请求，致使加载在所述另外虚拟机实例上的所述程序代码被执行。

5.根据权利要求4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述活动池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

6.根据权利要求4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的预热池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述预热池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

7.根据权利要求4所述的系统，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中所述虚拟计算系统被配置为致使通过以下步骤基于所述一个或多个执行参数来预初始化另外虚拟机实例：

在所述活动池中查找未填充的虚拟机实例，其中所述未填充的虚拟机实例没有被充分利用；和

在所述未填充的虚拟机实例上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

8.根据权利要求4所述的系统，其中所述多个虚拟机实例包括具有加载在其上的一个或多个软件部件并且等待分配给用户的虚拟机实例的预热池，并且其中所述虚拟计算系统被配置为通过避免将另外虚拟机实例添加到所述预热池直到所述预热池中的虚拟机实例的数量达到对应于减少量的数量，致使在所述虚拟计算系统上保持所述减少量的闲置计算能力。

9.根据权利要求4所述的系统，其中所述虚拟计算系统还被配置为响应于接收到所述另外周期性请求而致使与所述另外周期性请求相关联的程序代码在所述另外虚拟机实例上创建的容器中执行，其中在所述虚拟计算系统接收到所述另外周期性请求之前，将所述程序代码加载到所述容器中。

10.根据权利要求4所述的系统，其中所述虚拟计算系统还被配置为：

接收与第一程序代码相关联的第一作业请求，用于执行所述第一程序代码的第一最大持续时间以及用于执行所述第一程序代码的第一时间范围；

接收与第二程序代码相关联的第二作业请求和用于执行所述第二程序代码的第二时间范围，所述第二时间范围至少部分地与所述第一时间范围重叠；和

确定执行所述第一程序代码的第一执行时间和执行所述第二程序代码的第二执行时间，使得所述第一执行时间至少按照所述第一最大持续时间先于所述第二执行时间。

11.根据权利要求10所述的系统，其中所述虚拟计算系统还被配置为经由用户界面来提供在与第一成本相关联的第一时间灵活度与大于所述第一时间灵活度并且与第二成本相关联的第二时间灵活度之间进行选择的选项，其中所述第一成本大于所述第二成本。

12.一种计算机实现的方法，其包括：

当由被配置有特定可执行指令的一个或多个计算设备实现时，

在一个或多个物理计算设备上保持多个虚拟机实例；

监视在虚拟计算系统上执行程序代码的传入代码执行请求；

确定所述传入代码执行请求中的至少一些是否呈现周期性，所述传入代码执行请求中的所述至少一些与一个或多个执行参数相关联；

响应于确定所述传入代码执行请求中的所述至少一些呈现周期性，致使在所述虚拟计算系统上保持减少量的虚拟机实例，所述减少量基于所述周期性来确定；

确定所述传入代码执行请求中的所述至少一些预期在阈值时间量内被接收；和

在所述虚拟计算系统接收到呈现与所述传入代码执行请求中的所述至少一些相同的周期性的另外周期性请求之前，致使基于所述一个或多个执行参数来配置另外虚拟机实例，

在所述虚拟计算系统上保持减少量的虚拟机实例之后，并且在所述虚拟计算系统接收到另外周期性请求之前，致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述另外虚拟机实例上；以及

响应于接收到另外周期性请求，致使加载在所述另外虚拟机实例上的所述程序代码被执行。

13.根据权利要求12所述的计算机实现的方法，其中所述多个虚拟机实例包括虚拟机实例的活动池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述活动池；和

在所述另外虚拟机上创建容器并且致使将与所述传入代码执行请求中的所述至少一些相关联的程序代码加载到所述容器中。

14.根据权利要求12所述的计算机实现的方法，其中所述多个虚拟机实例包括虚拟机实例的预热池，并且其中致使基于所述一个或多个执行参数来配置另外虚拟机实例包括：

从与所述虚拟计算系统网络通信的实例供应服务来请求所述另外虚拟机实例；

致使将所述另外虚拟机实例添加到所述预热池；和

在所述另外虚拟机上创建容器并且致使将与所述另外周期性请求相关联的程序代码加载到所述容器中。

15.根据权利要求12所述的计算机实现的方法，其还包括：

接收执行与第一组执行要求相关联的第一作业的请求；

接收执行与第二组执行要求相关联的第二作业的请求；

基于所述第一组和第二组执行要求来确定一个或多个调度准则；和

确定用于执行所述第一作业的第一执行时间和用于执行所述第二作业的第二执行时间，使得满足所述一个或多个调度准则。

Images