相关申请的交叉引用
本申请要求于2017年9月30日提交的美国临时申请no.62/566,351的权益，该申请通过引用并入本文。本申请还涉及与本申请在同一天提交的以下共同受让的申请，这些申请中的每个申请也通过引用并入本文：
·于2018年9月__日提交的美国专利申请no.__/___，___，题为“apiregistryinacontainerplatformforautomaticallygeneratingclientcodelibraries”(代理人案号088325-1090745)；
·于2018年9月__日提交的美国专利申请no.__/___，___，题为“apiregistryinacontainerplatformprovidingproperty-basedapifunctionality”(代理人案号088325-1090746)；
·于2018年9月__日提交的美国专利申请no.__/___，___，题为“dynamicnoderebalancingbetweencontainerplatforms”(代理人案号088325-1090747)；
·于2018年9月__日提交的美国专利申请no.__/___，___，题为“optimizingredeploymentoffunctionsandservicesacrossmultiplecontainerplatformsandinstallations”(代理人案号088325-1090748)。
背景技术：
概括地说，任何形式的容器都表示包装和与信息交互的标准化方法。容器可以彼此隔离并可以并行使用，而没有交叉污染的风险。在现代软件世界中，“容器”一词具有特定的含义。软件容器，诸如
现代的面向服务的体系架构和云计算平台将大任务分解成许多小的具体任务。容器可以被实例化以专注于各个具体任务，然后多个容器可以协同工作以实现复杂的应用。这可以被称为微服务体系架构，并且每个容器可以使用可以独立升级的不同版本的编程语言和库。与将要对更大、更整体的体系架构进行的改变相比，容器内处理的隔离性质允许它们以很小的工作或风险进行升级或更换。虽然虚拟机可以被用于运行容器平台，但是容器平台在运行这种微服务体系架构方面比传统虚拟机效率高得多。
技术实现要素：
在一些实施例中，一种为容器环境中的容器化的服务提供运行时调试的方法可以包括接收对在容器环境处的服务的请求。容器环境可以包括服务网格和封装在多个容器中的多个服务。服务可以被封装在第一一个或多个容器中。该方法还可以包括确定该请求应当被路由到服务的调试实例；以及实例化服务的调试实例。调试实例可以被封装在第二一个或多个容器中，并且可以包括实现服务的代码和一个或多个调试实用程序。该方法可以附加地包括通过服务网格将请求路由到调试实例。
在一些实施例中，一种非暂态计算机可读介质可以包括指令，这些指令在由一个或多个处理器执行时使一个或多个处理器执行包括接收对在容器环境处的服务的请求的操作。容器环境可以包括服务网格和封装在多个容器中的多个服务。服务可以被封装在第一一个或多个容器中。操作还可以包括确定该请求应当被路由到服务的调试实例；以及实例化服务的调试实例。调试实例可以被封装在第二一个或多个容器中，并且可以包括实现服务的代码和一个或多个调试实用程序。操作可以附加地包括通过服务网格将请求路由到调试实例。
在一些实施例中，一种系统可以包括一个或多个处理器以及包括指令的一个或多个存储器设备，这些指令在由一个或多个处理器执行时使一个或多个处理器执行包括接收对在容器环境处的服务的请求的操作。容器环境可以包括服务网格和封装在多个容器中的多个服务。服务可以被封装在第一一个或多个容器中。操作还可以包括确定该请求应当被路由到服务的调试实例；以及实例化服务的调试实例。调试实例可以被封装在第二一个或多个容器中，并且可以包括实现服务的代码和一个或多个调试实用程序。操作可以附加地包括通过服务网格将请求路由到调试实例。
在任何实施例中，以下特征中的任何一个或全部可以以任何组合被包括并且没有限制。可以将第一一个或多个容器组织到容器舱中。容器环境可以包括包含容器调度器的经编排的容器平台。容器调度器可以使得服务的调试实例被实例化。容器环境可以包括使得服务的调试实例被实例化的应用编程接口(api)注册器。api注册器可以接收服务的调试实例的注册，并通过api函数调用使服务的调试实例的http端点可用。api注册器可以接收服务的注册，该注册包括指示服务的调试实例应当被实例化的特性。服务可以被封装在单个容器中。单个容器还可以包括一个或多个调试实用程序。可以将一个或多个调试实用程序封装在除单个容器之外的至少一个容器中。一个或多个调试实用程序可以包括用于监视存储器使用情况或处理器使用情况的进程。一个或多个调试实用程序可以包括调试守护进程。实现服务的代码可以包括服务的调试版本。服务的调试实例可以在接收请求之前被实例化。服务的调试实例可以响应于接收到请求而被实例化。确定应当将请求路由到服务的调试实例可以包括识别请求的源。确定请求应当被路由到服务的调试实例可以包括识别请求中将该请求指定为调试请求的报头。可以将请求转发到服务的调试实例，而不中断其它请求到服务的路由。
附图说明
通过参考本说明书的其余部分和附图，可以实现对本发明的本质和优点的进一步理解，其中，贯穿若干附图使用了相似的附图标记指代相似的部件。在一些情况下，子标签与附图标记相关联以表示多个相似部件中的一个部件。当在没有指定现有子标签的情况下参考附图标记时，意在指代所有这样的多个相似部件。
图1图示了根据一些实施例的用于容器平台中的服务的开发和运行时环境的软件结构和逻辑布置。
图2图示了专门设计为运行本文所述实施例的专用计算机硬件系统。
图3图示了可以特定于由本文所述的实施例中的一些实施例使用的容器平台的数据组织。
图4图示了根据一些实施例的可以被部署到ide和生产/运行时环境的api注册器。
图5图示了根据一些实施例的用于在运行时与容器平台一起使用的api注册器的部署。
图6a图示了根据一些实施例的用于部署api注册器的方法的流程图。
图6b图示了根据一些实施例的当使用图6a中的流程图来部署api注册器时的容器平台的软件结构。
图7a图示了根据一些实施例的用于向api注册器注册服务的方法的流程图。
图7b图示了根据一些实施例的用于向api注册器注册api的步骤的硬件/软件示意图。
图8图示了根据一些实施例的用于浏览和选择向api注册器注册的api的图形界面和命令行界面的示例。
图9图示了根据一些实施例的用于使用向api注册器注册的服务及其对应功能的方法的流程图。
图10图示了api注册器可以如何通过createuser()函数的图形界面接收选择。
图11图示了根据一些实施例的由api注册器自动为服务生成的客户端库的示例。
图12图示了根据一些实施例的适应(accommodate)服务端点与api函数之间的动态绑定的客户端库的实施例。
图13图示了根据一些实施例的可以整理(marshal)附加数据以完成用于服务调用的输入数据集的客户端库的实施例。
图14图示了根据一些实施例的在调用服务时可以处置(handle)重试的客户端库。
图15a图示了根据一些实施例的向api注册器提供api特性的方法。
图15b图示了根据一些实施例的服务可以如何向api注册器提供api特性的硬件/软件示意图。
图16图示了根据一些实施例的硬件/软件示意图，其中api注册器使用特性来部署具有高可用性的服务。
图17图示了根据一些实施例的通过api注册器强制实施端到端加密的特性的硬件/软件示意图。
图18图示了根据一些实施例的用于实现服务1808的使用情况日志记录的api注册器的特性。
图19图示了根据一些实施例的可以对服务强制实施认证协议的特性的硬件/软件示意图。
图20图示了根据一些实施例的用于启用服务的运行时实例化的特性的硬件/软件示意图。
图21图示了根据一些实施例的实现用于服务的速率限制功能的特性的硬件/软件示意图。
图22图示了根据一些实施例的用于接收服务请求的云计算平台的一部分的框图。
图23图示了根据一些实施例的封装在舱中的服务的调试版本。
图24图示了根据一些实施例的用于服务的调试版本的替代舱。
图25图示了根据一些实施例的用于实例化服务的调试实例的系统的框图。
图26图示了根据一些实施例的将调试请求路由到服务的调试实例的容器平台的框图。
图27图示了根据一些实施例的克隆请求的云计算平台的框图。
图28图示了根据一些实施例的克隆的请求被转发到服务的调试实例的框图。
图29图示了用于为容器环境中的容器化的服务提供运行时调试的方法的流程图。
图30图示了用于实现实施例中的一些实施例的分布式系统的简化框图。
图31图示了系统环境的部件的简化框图，通过该系统环境，由实施例系统的部件提供的服务可以作为云服务提供。
图32图示了其中可以实现各种实施例的示例性计算机系统。
具体实施方式
本文描述的是应用编程接口(api)注册器的实施例，该api注册器是允许开发人员在开发期间注册服务并使那些服务在部署期间和部署之后对其它服务可用的集成开发环境(ide)的一部分。api注册器可以作为编排的容器平台的一部分进行部署，从而在容器平台上作为容器化的应用操作。随着服务或微服务被开发并部署到容器平台上的容器中，api注册器可以执行在容器平台内定位与可用服务对应的可用端点(例如，ip地址和端口号)的发现过程。api注册器还可以接受api定义文件的上传，该api定义文件可以被用于将原始服务端点转换成通过api注册器可用的api函数。api注册器可以动态地将发现的端点绑定到api函数，该api函数可以保持最新状态并可以对容器平台中的其它服务可用。这提供了其它服务可以静态调用的稳定端点，而api注册器管理服务端点中api函数之间的绑定的任何改变。这也简化了在容器平台中使用服务的过程。代替为http调用编写代码，新服务可以仅使用api接口来访问已注册的服务。
在一些实施例中，ide可以为开发人员提供导航/浏览界面，以定位容器平台中可用并向api注册器注册的服务。当api注册器为正在开发的新服务创建对现有服务的调用时，api注册器可以自动生成包括与已注册的服务进行交互的所有必要功能的客户端库的集合。例如，一些实施例可以生成包括与api调用对应的成员函数的对象类。在开发期间，新服务可以简单地实例化这些对象和/或使用其成员函数来调用对应的api。客户端库中的代码管理调用服务与已注册的服务的端点之间的直接连接，并且可以包括处置这种交互所必需的所有功能的代码。例如，自动生成的客户端库可以包括：用于将来自api调用的参数打包和格式化为对服务端点的http调用的代码、用于整理数据以完成用于该调用的参数集的代码、用于将信息打包到兼容分组(json、xml等)中的代码、用于接收和解析结果分组的代码、用于处置重试和错误状况的代码等。从调用服务的角度来看，用于处置所有这种功能的代码由api注册器自动生成，并且因此将服务调用的细节抽象并封装到客户端库对象中。调用服务所需要的只是执行由api注册器创建的客户端库对象的成员函数。
在一些实施例中，api注册器也可以接受可以定义已注册的服务的运行时执行的特性集合的上传。这个特性集合可以在开发期间与api定义文件一起上传。这些特性可以定义运行时特点，诸如端到端加密、使用/日志记录要求、用户认证、按需服务实例化、用于高可用性的多个服务部署实例、速率/使用情况限制以及其它运行时特点。api注册器可以通过在开发期间、在部署期间以及在运行时期间与容器环境进行交互来确保满足这些特性。在开发期间，用于调用服务的自动生成的客户端库可以包括执行这些特性所需的代码，诸如加密代码、使用情况日志记录代码和/或与用户认证服务的交互。当部署已注册的服务时，api注册器可以指示容器平台实例化服务的多个实例和/或其它负载平衡模块，以确保服务在运行时期间具有高可靠性。在运行时期间当服务被调用时，api注册器可以使服务被实例化以进行按需实例化、限制可以进行的api调用的次数以调节使用情况，以及执行其它运行时功能。
图1图示了根据一些实施例的用于容器平台中的服务的开发和运行时环境的软件结构和逻辑布置。这些环境可以包括ide102，其可以被用于开发要部署在容器平台上的服务和微服务。ide是软件套件，其合并以及提供服务开发人员可以用来编写和测试新服务的所有基本工具。ide102可以包括具有图形用户界面(gui)、代码完成功能以及导航/浏览界面的源代码编辑器106，其允许开发人员编写、导航、集成和可视化源代码编写过程。ide102还可以包括调试器110，该调试器110包括变量接口、立即(immediate)变量接口、表达式评估接口、存储器内容接口、断点可视化和功能以及其它调试功能。ide102还可以包括用于编译和运行经编译的机器代码或经解释的字节代码的编译器和/或解释器108。编译器/解释器108可以包括允许开发人员使用/生成另一个构建自动化构造的makefile(制作文件)的构建工具。ide102的一些实施例可以包括代码库112，其包括可以链接到正在开发的服务中并且跨多个开发重用的通用代码函数、对象、接口和/或其它结构。
可以在ide102内开发服务并对服务进行彻底的测试，直到准备好进行部署为止。然后可以将服务部署到生产/部署环境104。生产/开发环境104可以包括许多不同的硬件和/或软件结构，包括专用硬件、虚拟机和容器化的平台。在本公开之前，当将服务114部署到生产/部署环境104中时，服务114将不再具有对在ide102中使用的工具中的许多工具的运行时访问。服务114在生产/开发环境104中运行所需的任何功能都需要从代码库112中打包，并与服务114一起部署到生产/部署环境104中。此外，通常服务114将被部署为没有调试器110的任何功能或来自源代码编辑器106的源代码的副本。本质上，服务114将被部署到生产/部署环境104，其具有运行时操作所需的所有功能，但是将被剥离仅在开发期间使用的信息。
图2图示了专门设计用于运行本文所述的实施例的专用计算机硬件系统。举例来说，服务114可以被部署到基础设施即服务(iaas)云计算环境202中。这是云计算的形式，云计算通过网络提供虚拟化或共享的计算资源。iaas云计算环境202还可以包括被布置为软件即服务(saas)和/或平台即服务(paas)体系架构的其它云计算环境，或与其它云计算环境耦合。在这种环境中，云提供商可以托管传统上存在于内部部署的数据中心中的硬件和/或软件部件的基础设施。这种硬件可以包括服务器、存储装置、联网硬件、盘阵列、软件库和虚拟化实用程序(诸如管理程序层)。iaas环境202可以由商业源(诸如
不管云环境的类型如何，都可以将服务114部署到多种不同类型的硬件/软件系统上。例如，服务114可以被部署到专用硬件206。专用硬件206可以包括专门指派给服务114的硬件资源，诸如服务器、盘、操作系统、软件包等。例如，特定服务器可以被分配为处置流入和流出服务114的业务。
在另一个示例中，服务114可以被部署到作为一个或多个虚拟机208操作的硬件/软件。虚拟机是提供专用计算机硬件206的功能的计算机系统的模拟。但是，作为专用于特定功能的代替，物理硬件可以由多个不同的虚拟机共享。每个虚拟机可以提供执行所需的所有功能，包括完整的操作系统。这允许具有不同操作系统的虚拟机在同一个物理硬件上运行并允许多个服务共享单个硬件。
在另一个示例中，服务114可以被部署到容器平台210。容器平台在多个重要方面与虚拟机208不同。首先，容器平台210将各个服务打包到容器中，如下面在图3中更详细描述的。每个容器共享主机操作系统内核，并且它们还共享二进制文件、库和其它只读组件。这使容器非常轻量级–常常只有几兆字节的大小。此外，轻量级容器非常高效，起动仅需几秒钟，而引导虚拟机则需要几分钟。容器还通过共享可以为容器平台210中的整个容器集合一起维护的操作系统和其它库来减少管理开销。尽管容器共享同一个操作系统，但它们提供隔离的平台，因为操作系统为隔离提供虚拟存储器支持。容器技术可以包括
不管在其上部署了服务114的平台206、208、210，平台206、208、210中的每一个都可以提供为调用服务114提供公共访问的服务端点212、214、216。一般而言，这些端点可以通过http调用进行访问并与ip地址和端口号相关联。通过连接到正确的ip地址和端口号，当其它服务公开可用时，这些其它服务可以调用部署到平台206、208、210中的任何一个的服务。每个服务(诸如服务114)可以包括其自己的用于调用该服务的专有格式和数据要求。类似地，每个服务可以返回在格式和数据类型方面特定于该服务114的结果。除了特定于服务的要求之外，特定的部署平台206、208、210还可以包括与服务114交互的附加要求，诸如编程语言、需要符合以便与服务正确交互的数据包格式(json、xml等)等。
虽然以上示例允许将服务114部署到所述平台206、208、210中的任何一个，但是本文所述的实施例是专门为上述容器平台210设计的。因此，可以将专门记载为要部署在“容器平台”中的实施例与专门记载为要部署在虚拟机平台中、部署在服务器或专用硬件平台上或一般而言部署在iaas环境中的其它实施例区分开。
图3图示了可以特定于由本文所述的实施例中的一些实施例使用的容器平台210的数据组织。一般而言，服务到容器平台的任何部署都将被部署到舱304、306。舱是表示一组一个或多个应用容器(例如docker或rkt)的抽象。舱还可以包括通常可用于该舱内的所有容器的一些共享资源。例如，舱304包括容器310和容器312。舱304还包括共享资源308。资源可以包括存储卷或关于容器如何在舱304内运行或连接的其它信息。舱304可以对包含相对紧密耦合的不同服务容器310、312的专用逻辑主机进行建模。例如，容器310中的服务326可以利用资源308并调用容器312中的服务320。服务320还可以调用服务322，服务322进而调用服务324，每个服务都部署到容器312。服务324的输出可以被提供给网络ip地址和端口318，这是由舱304共享的另一个公共资源。因此，服务320、322、324、326全部与共享资源308一起工作以提供单个服务，该单个服务可以由在其它容器中运行的服务通过ip地址和端口号318访问。服务还可以由容器平台外部的计算机系统(诸如工作站、膝上型计算机、智能电话或不属于容器平台或iaas环境的一部分的其它计算设备)通过ip地址和端口318访问。
在最简单的部署中，每个容器可以包括单个服务，并且每个舱可以包括封装服务的单个容器。例如，舱306仅包括具有单个服务328的单个容器314。可以通过舱306的ip地址和端口号316访问该单个服务。通常，当将服务部署到容器平台时，将实例化容器和舱以保持服务。可以将许多不同的舱部署到容器节点302。一般而言，舱在节点内运行。节点表示容器平台中的工作者机器(虚拟的或者物理的)。每个节点由“主设备”管理，该“主设备”自动处置在每个节点内调度舱。每个节点可以运行负责主设备和该节点之间的通信并负责管理该节点表示的机器上的容器中的舱的过程。每个节点还可以包括负责从注册器中拉取容器映像、对容器进行解包并运行服务的容器运行时。
图4图示了根据一些实施例的可以被部署到ide102和生产/运行时环境104的api注册器404。如上所述，存在技术问题，其中当将服务114从ide102部署到生产/部署环境104时，服务114失去对仅仅在ide102中可用的信息的运行时访问。当api注册器404在生产/开发环境104中在运行时期间部署和操作时，api注册器404可由服务114访问。通过在开发期间向api注册器404注册服务并将api定义和/或api特性提供给api注册器404，api注册器404克服了开发功能与运行时功能隔离的以前的技术问题。定义api的信息可以由ide102中正在开发的新服务以及已部署到生产/部署环境104的服务使用。在完成这个注册过程之后，服务114可以使用在运行时期间访问api注册器404的客户端库进行操作，以确保api函数正确绑定到对应服务的当前ip地址和端口号。api注册器404表示专门设计用于解决这些技术问题的新的数据结构和处理单元。
现有技术中存在的另一个技术问题是在将服务特性部署到生产/开发环境104时实现服务特性。例如，如果要部署具有高可用性的服务，那么开发人员将需要构建专门实例化容器平台中的服务的多个实例并以服务始终可用的方式平衡业务的容器部署文件。服务开发人员并不总是拥有这种专业知识，他们也常常无法管理他们的服务的部署。如下所述，api注册器404允许服务简单地选择特性(诸如高可用性)，特性然后可以由api注册器404自动实现。这种技术解决方案是可行的，因为api注册器404消除了ide102与生产/部署环境104之间的隔阂。
图5图示了根据一些实施例的在运行时与容器平台210一起使用的api注册器404的部署。由api注册器404提供的技术解决方案和对现有技术的改进之一是维护用于服务调用的稳定端点，以及用于访问服务调用的简化和自动代码生成。在本公开之前，服务之间的调用是例如使用对ip地址和端口号的http调用的点对点连接。随着服务在容器平台210中被更新、替换、重定位和重新部署，ip地址和端口号可能频繁地改变。这要求调用更新后的服务的所有服务都必须在调用该服务的实际代码中更新它们的ip地址和端口号。api注册器404通过在服务的ip地址和端口号与通过api注册器可用的api函数之间提供动态绑定来解决这个技术问题。由api注册器404自动生成的客户端库可以包括访问api注册器404以检索和/或核实用于特定服务的当前ip地址和端口号的功能。因此，连接到第二服务的第一服务仅需要执行一次客户端库生成，以提供到第二服务的生命周期内稳定的连接。
api注册器404解决的另一个技术问题是客户端库的自动生成。在本公开之前，第一服务访问第二服务要求开发人员编写用于访问第二服务的自定义代码。因为这种代码可能随时间改变，所以第一服务与第二服务之间的不兼容性可能增加，这要求对这两个服务进行更新。api注册器404通过上传用于自动生成用于调用服务的客户端库的api定义文件来解决这个技术问题。因此，服务可以具体指定任何其它服务中的调用代码应当如何操作，从而保证兼容性。这些客户端库还大大地简化和封装了用于调用服务的代码。如下所述，可以用特定于调用服务的语言(例如，java、c#等)的简单的成员函数调用来替换使用ip地址和端口号的复杂http调用。这允许调用服务从api注册器404中选择api函数，并且可以将实现该函数的代码作为客户端库下载到调用服务。
图6a图示了根据一些实施例的用于部署api注册器404的方法的流程图。该方法可以包括将api注册器服务部署到容器环境(601)。可以将api注册器实现为在容器内的容器环境中操作的服务。因此，在将服务部署到容器环境中之后，api注册器可以主动运行，使得它可以在运行时被访问。api注册器还可以链接到上述现有的ide。该方法还可以包括在容器平台中发现用于可用服务的端口(603)。在将服务部署到容器平台时，api注册器可以启动发现过程，该发现过程顺序地遍历部署到容器平台的每个服务。对于每个服务，api注册器都可以检测并记录ip地址和端口号。通过这个过程发现的ip地址和端口号的列表可以被存储在数据结构中，诸如存储在与api注册器相关联的表中。每个ip地址和端口号还可以与服务的名称或在容器平台上唯一识别服务的其它标识符一起存储。图6a中的流程图中所示的这些初始步骤为api注册器提供了开始在容器平台的运行时环境中操作并可供ide中正在开发的服务使用的起点。
图6b图示了根据一些实施例的当使用图6a中的流程图来部署api注册器时的容器平台210的软件结构。如上所述，api注册器404可以被部署到容器平台210中的容器620。容器620可以在一个或多个舱内以及在节点内操作，如上文在图3中所述。可以使api注册器404专用于容器平台210中的其它容器中的任何一个。在一些实施例中，也可以使api注册器404公开可用于不是容器平台210的一部分的其它设备。作为容器化的服务，api注册器404可以具有可用于其它服务的ip地址和端口号。但是，api注册器404的ip地址和端口号将仅由在客户端库中自动生成的代码使用，因此一些实施例不需要公布api注册器404的ip地址和端口号。代替地，ide本身中的客户端库可以维护api注册器404的ip地址和端口号的最新列表，使得可以在其它服务的开发、部署和运行时期间与它联系。
在将api注册器404部署到容器620之后，api注册器404可以执行发现过程。发现过程可以使用容器平台中节点的目录列表来利用ip地址和端口号识别实现服务的舱。api注册器404然后可以访问唯一标识符(诸如每个可用服务的号码或名称)，并且将具有每个ip地址和端口号的标识符存储在容器平台210中。可以周期性地执行这个发现过程，以检测添加到容器平台210的新服务，以及识别从容器平台210移除的现有服务。如下所述，这个发现过程还可以被用于检测现有服务的ip地址和端口号何时改变。例如，api注册器404可以发现具有端点602、604、606、608的服务。在下面描述的过程中，api注册器404可以将这些端点602、604、606、608中的每一个绑定到向api注册器404注册的api函数。在这个初始发现之后的某个点，当与端点602相关联的服务被替换、更新或修订时，端点602的ip地址和/或端口号可以改变。api注册器404可以检测对端点602的这种改变，并更新到由api注册器44提供的现有api函数的绑定。
类似地，api注册器404可以使用发现过程来检测何时端点不再可用，然后移除与服务相关联的api函数。在一些实施例中，当服务已经向api注册器404注册，但是对应的api函数当前未绑定到有效端点时，api注册器404可以向调用对应api函数的任何服务提供虚拟(mock)响应。例如，如果已经为与端点604对应的服务注册了api，但是端点604当前不可用，那么api注册器404可以拦截对端点604的调用并提供默认或伪数据作为响应。这允许调用与端点604相关联的服务的服务在不“断开”与这个特定服务的连接的情况下维护功能和/或继续设计过程。虚拟/测试数据场景将在下面更详细地描述。
图7a图示了根据一些实施例的用于向api注册器404注册服务的方法的流程图。该方法可以包括接收api定义的上传(701)。api定义可以以数据分组、文件或到信息储存库的链接的形式提供。api定义可以包括可以被用于识别和定义应当绑定到与服务相关联的端点的api函数的任何信息。例如，api定义的一些实施例可以包括以下数据：服务名称或其它唯一标识符；与服务端点和调用对应的函数名称；调用服务所需的数据输入以及对应的描述和数据类型；结果数据格式和数据类型；当前的ip地址和/或端口号；描述将与端点相关联的api函数的功能的文档；在虚拟/测试场景期间应当返回的默认或伪数据值；以及可以被api注册器404用于将端点接收的http请求翻译成使用类数据对象的api函数调用的客户端库的任何其它信息。
该方法还可以包括基于上传的api定义创建对应的api函数(703)。这些api函数可以基于api定义自动生成。服务的每个端点可以与多个不同的api函数相关联。例如，实现restful接口的端点可以在相同的ip地址和端口号处接收对post、get、put和delete函数的http调用。例如，这可能导致不同的api函数。例如，如果接口表示用户的列表，那么这个列表可以与至少四个不同的api函数对应，诸如getuser()、adduser()、removeuser()和updateuser()。此外，每个api函数可以包括多个不同的参数列表，诸如updateuser(id)、updateuser(name)、updateuser(firstname,lastname)等。这些api函数可以被生成并通过api注册器对其它服务可用。如下面将更详细描述的，应当注意的是，不要求服务通过api注册器来调用这些函数。代替地，这些函数可用于在api注册器中浏览，并且在被选择时，api注册器可以生成在调用服务中实现这些函数的客户端库。
该方法可以附加地包括在api注册器中在api函数和服务的对应端点之间创建绑定(705)。基于上述发现过程和步骤701的注册过程，api注册器现在可以在容器平台中服务的端点和由api注册器创建的api函数之间创建动态绑定。在上面发现可用端点和服务时形成的数据结构中，api注册器现在可以为每个端点存储对应的函数或函数集。如上所述，可以在发现过程确定服务何时被更新、移动、替换或添加到容器平台时不断地更新这个绑定。这允许在调用服务中创建的客户端库首先检查api注册器，以核实或接收用于该服务的当前ip地址和端口号。
图7b图示了根据一些实施例的用于向api注册器404注册api的步骤的硬件/软件示意图。如上所述，可以在容器平台210中的容器620中实例化并运行api注册器404。即使容器平台210表示生产/部署环境，api注册器404仍可以由用于开发服务的ide102访问。因此，ide102可以提供用于将api定义文件702上传到api注册器404的机制。具体而言，ide102的用户界面可以包括允许开发人员定义和/或填充用于api定义文件702的字段的窗口或界面。上面描述的这种信息可以包括函数名称、参数列表、数据类型、字段长度、对象类定义、ip地址和端口号、服务名称或其它唯一标识符等。这种信息可以被上传到api注册器404，并以动态绑定方式链接到端点602的特定ip地址和端口号。最后，api注册器404可以生成可以通过api注册器404可用的一个或多个api函数704。
在向api注册器404注册服务并生成一个或多个api函数之后，api注册器可以在开发人员设计服务时使这些函数对开发人员可用。图8图示了根据一些实施例的用于浏览和选择向api注册器804注册的api的图形界面802和命令行界面804的示例。在为容器平台编程和开发新服务时，开发人员可以访问图形界面802以浏览和选择可在他们的服务中使用的api函数。这个图形界面802仅仅是示例，并且不意味着限制可以用于浏览和选择api函数的图形界面的类型。
在这个实施例中，ide102可以召唤(summon)图形界面802以提供向api注册器注册的api的列表。在这个实施例中，基于端点对api进行分类。例如，与服务对应的一个端点可以提供用于存储用户记录的restful接口(例如，“userstorage”)。图形界面802可以显示通过所选择的端点可用的所有api函数(例如，“createuser”、“deleteuser”、“updateuser”等)。在服务提供多个端点的情况下，其它实施例可以基于整个服务对函数进行分组。图形界面802可以接收将在调用服务时使用的一个或多个api函数的选择。然后，api注册器可以提供说明如何使用api函数的文档，包括必需的参数和返回值。本领域普通技术人员将理解的是，命令行界面804可以提供与图形界面802类似的信息并且可以接收类似的输入。
图8中所示的界面802、804提供了多个技术优点。首先，这些界面802、804提供向api注册器注册的所有api的最新列表。这与容器平台中当前可用的所有服务的列表对应。服务开发人员可以实时地检索和显示这种信息，而不是需要查找文档、联系服务开发人员和/或执行其它低效任务来定位可用服务的列表。此外，随着服务被更新，api定义文件可以以对应的方式被更新。然后，这更新图8中所示的显示，以提供针对每个api函数的最新可用性信息。
图9图示了根据一些实施例的用于使用向api注册器注册的服务及其对应函数的方法的流程图。该方法可以包括提供已注册的api的列表(901)。在期望的服务已知的情况下，可以省略这个步骤。但是，一般而言可以使用上面图8中所述的界面来显示服务以进行浏览和导航。该方法还可以包括接收对api函数的选择(901)。api注册器可以从服务的开发人员接收此选择。例如，开发人员可以决定使用上述的createuser()函数来更新用户记录的数据库。图10图示了api注册器可以如何通过用于createuser()函数的图形界面802来接收选择1002。其它实施例可以通过命令行界面或通过由ide提供的其它输入方法来接收选择。
返回参考图9，一旦接收到对api函数的选择，api注册器就可以为调用服务生成一个或多个客户端库(905)。生成客户端库可以向调用服务提供动态绑定到api函数的服务端点。具体而言，ide可以在ide中生成类对象的集合，类对象封装了直接与容器平台中的服务端点进行接口连接所需的功能。在一些实施例中，客户端库可以包括可以被实例化或用于调用实施与服务进行通信所需的代码的成员函数的对象类。这些客户端库的示例将在下面更详细地描述。
该方法可以附加地包括提供测试数据(907)。当向api注册器注册服务时，它无需是完整的。代替地，服务可以向api注册器指示它尚未准备好提供对调用服务的函数响应。在一些实施例中，上传到api注册器的api定义文件可以包括在服务起作用之前应当返回的信息类型的规范。当调用服务调用api函数时，由api注册器生成的客户端库可以将请求路由到api注册器，而不是服务端点。然后，api注册器可以使用伪值、空值或默认值提供响应。可替代地，客户端库内的代码本身可以生成要返回给调用服务的默认数据。
应当认识到的是，图9中所示的具体步骤提供了根据本发明各种实施例的使用api注册器的特定方法。根据替代实施例，也可以执行其它步骤顺序。例如，本发明的替代实施例可以以不同的次序执行上面概述的步骤。而且，图9中所示的各个步骤可以包括多个子步骤，这些子步骤可以以适合于各个步骤的各种顺序执行。此外，取决于特定应用，可以添加或移除附加步骤。本领域普通技术人员将认识到许多变化、修改和替代方案。
图11图示了根据一些实施例的由api注册器自动为服务生成的客户端库的示例。这个客户端库1102可以与存储用户记录的服务对应。这个客户端库1102以及对应的类和服务仅通过示例的方式提供，并且不意味着限制。如上所述，每个api函数和服务都可以指定应当如何通过上传到api注册器的api定义文件来生成客户端库。因此，以下关于“user(用户)”服务描述的原理可以应用于其它服务。
为了表示“user”服务，api注册器可以为user生成类。当调用服务请求api注册器生成客户端库时，调用服务可以指定该调用服务使用的编程语言。例如，如果调用服务是在ide中用java编写的，那么api注册器可以以java编程语言生成类库。可替代地，如果调用服务是用c#编写的，那么api注册器可以以c#编程语言生成类库。user类可以被生成，以具有与可以通过服务端点执行的不同操作对应的成员函数。这些成员函数可以是静态的，使得它们不要求user类的实例化的实例，或者它们可以与实例化的user对象一起使用。
在这个示例中，user服务可以使用restful接口编辑由该服务存储的各个用户记录。例如，api注册器可以生成createuser()函数以实现对user服务的post调用。类库可以执行的功能之一是解析、过滤和格式化作为参数被提供给api函数的数据，以作为数据分组被直接发送给服务。在这个示例中，createuser()函数可以接受为了方便调用服务而被格式化的参数。例如，调用服务可以分别存储用户名字和用户姓氏的字符串。但是，post命令可能要求名字和姓氏一起的级联的字符串。为了适应用户友好的参数集，客户端库1102可以执行设置操作，该设置操作将作为函数的参数接收的数据格式化为与服务端点兼容的格式。这可以包括生成报头信息、更改某些数据字段的格式、级联数据字段、从其它源请求附加数据、执行计算或数据变换等。这还可以包括将重新格式化的参数打包为诸如json、xml等之类的格式。
一旦参数被正确地格式化到用于服务端点的包中，则客户端库1102还可以处置对服务的post调用。当生成客户端库时，可以将服务的ip地址和端口号插入createuser()函数中，以在对服务的http请求中使用。注意的是，http请求的细节被封装在createuser()函数中。当调用服务的开发人员想要使用通过该服务可用的post函数而不是自己在库1102中编写代码时，他们可以代替地从api注册器中选择“user”服务。api注册器然后将自动生成包括user类的客户端库1102。然后，为了使用post函数，服务开发人员可以简单地使用user.createuser(“john”，“smith”，2112)函数来将用户johnsmith添加到服务。
图12图示了根据一些实施例的适应服务端点和api函数之间的动态绑定的客户端库1202的实施例。在这个示例中，当api注册器生成客户端库1202时，createuser()函数可以包括动态地检索服务的ip地址和端口号的代码1204。当调用服务114在生产/部署环境104(诸如容器平台)中操作时，调用服务114可以使用getipport()函数在运行时向api注册器404发送请求。api注册器404可以访问其内部表，该内部表被一致地更新以维持api函数和服务端点之间的最新绑定。api注册器404然后可以将当前的ip地址和端口号返回给调用服务114。客户端库1202然后可以将ip地址和端口号插入连接到服务的httppost代码中。因为可以在运行时通过容器平台中的任何调用服务访问api注册器404，所以当被调用的服务的ip地址或端口号改变时，无需更新或修补这些服务。代替地，每次当服务被调用时，api注册器404都可以提供最新信息。在一些实施例中，假设服务端点在生产环境中不会频繁改变，则getipport()函数可以仅需要每小时一次、每天一次、每周一次等调用api注册器404，以最小化在容器外为服务114进行的函数调用的次数。
图13图示了根据一些实施例的客户端库1302的实施例，该客户端库1302可以整理附加数据以完成用于服务调用的输入数据集。为了简化客户端库1302的使用，客户端库1302可以最小化服务开发人员所需的参数的数量。进行服务调用所需的附加数据可以从其它源检索，并且因此可以从参数列表中被省略。替代地，客户端库1302可以直接从这些其它源检索这些附加参数。例如，创建新用户可以包括为该用户指定用户角色。代替要求服务开发人员提供用户角色作为参数之一，客户端库1302可以代替地包括自动地从某个其它源检索用户的角色的代码1304。在这个示例中，可以从数据库、从容器平台中的另一个服务或从调用服务内存储用户角色的另一个类检索用户角色。在这些情况中的任何一种情况下，代码1304可以自动检索用户角色并将它打包为发送到服务的httppost命令的输入数据的一部分。
除了对用于输入到服务的数据进行整理和格式化之外，客户端库1302还可以解析并返回从服务接收的数据以及处置错误状况。在这个示例中，post命令可以将数据分组返回到result变量中。服务常常可以返回包括的信息比调用服务所需的信息更多的数据分组。因此，客户端库1302可以解析result变量中的数据字段，并提取、格式化来自result变量的数据，以及将来自result变量的数据打包成为user类更可用和期望的格式。在这个示例中，代码1306可以从result变量中提取字段，并使用它们来创建从api函数返回的新的user对象。在另一个使用get命令的示例中，可以在user类中生成各个api函数，这些api函数从来自get命令的result变量中提取不同的字段。例如，user类可以提供getfirstname(id)函数、getlastname(id)函数、getrole(id)函数等。这些函数中的每一个可以包括非常相似的代码，同时返回来自result变量的不同的字段。
除了解析结果之外，客户端库1302还可以生成处置与使用服务相关联的错误状况的代码1308。在这个示例中，代码1308可以测试result变量中的status字段，以确定post命令是否成功。如果命令成功，那么createuser()函数可以返回新的user对象。在post命令失败的情况下，该函数可以代替地返回空对象和/或重试对服务的调用。
图14图示了根据一些实施例的在调用服务时可以处置重试的客户端库1402。就像图13的示例一样，客户端库1402使用由posthttp调用填充的result变量中的status来确定该调用是否成功。当结果不成功时，客户端库1402可以继续重试，直到调用成功为止。一些实施例可以使用计数器或其它机制来限制重试的次数或在重试之间添加等待时间。
如上所述，一些实施例还可以将api特性的集合连同api定义一起上传到api注册器。图15a图示了根据一些实施例的向api注册器提供api特性的方法。该方法可以包括接收api定义的上传(1501)。该方法还可以包括接收api特性的上传(1503)。特性的上传可以是与api定义的上传相同的传输的一部分。在一些实施例中，api特性可以是api定义的一部分。在一些实施例中，api特性可以是一个或多个标志或预定义的数据字段，该一个或多个标志或预定义的数据字段被检查以指示特性应当由api注册器设置。在一些实施例中，api特性不需要符合任何预先结构化的格式，而是可以代替地由使api注册器实现下述特征(诸如认证、加密等)的指令代码表示。可以将api特性与用于每个服务的api定义一起存储。
该方法可以附加地包括在服务和api之间创建api绑定(1505)。可以如上面详细描述的那样执行这个操作。此外，该方法可以包括使用api特性来执行与服务相关联的一个或多个操作(1507)。api特性可以在服务的生命周期期间的不同阶段使用。一般而言，这可以被描述为在服务部署期间、在为服务生成客户端库时和/或在调用服务时使用api特性来实现与该特性关联的函数。这些函数中的每一个的示例将在下面更详细地描述。
应当认识到的是，图15a中所示的具体步骤提供了根据本发明各种实施例的向api注册器提供api特性的特定方法。根据替代实施例，也可以执行其它步骤顺序。例如，本发明的替代实施例可以以不同的次序执行上面概述的步骤。而且，图15a中所示的各个步骤可以包括多个子步骤，这些子步骤可以以适合于各个步骤的各种顺序执行。此外，取决于特定应用，可以添加或移除附加步骤。本领域普通技术人员将认识到许多变化、修改和替代方案。
图15b图示了根据一些实施例的服务可以如何向api注册器提供api特性的硬件/软件示意图。在ide102中开发服务时，服务开发人员可以向api注册器404提供api定义文件1502和一个或多个特性1504。因为在运行时在ide102和容器平台两者中api注册器404都是可访问的，所以api注册器404可以存储特性1504并使用它们来影响在开发和运行时场景期间如何部署、调用和/或使用服务来生成客户端库。
图16图示了根据一些实施例的硬件/软件示意图，其中api注册器使用特性来部署具有高可用性的服务。除了用于特定服务的api定义文件1505之外，api注册器404还可以接收指示应当将服务部署为非常有弹性或具有高可用性的特性1602。可以接收这个特性1602作为由api注册器404执行以将服务部署为具有高可用性的指令集。这个选项允许开发人员定义对于这个服务“高可用性”意味着什么。例如，特性1602可以包括使api注册器404将服务的多个实例602、604部署到容器平台210的指令。通过执行这些指令，api注册器404不需要自己做出任何决定或确定，而是可以代替地仅执行作为特性1602的一部分提供的部署代码。
特性1602也可以作为标志或设置被接收，该标志或设置向api注册器404指示在api注册器404处执行用于部署具有高可用性的服务的现有指令的选项。使用这个选项，api注册器404不需要接收要作为特性1602执行的任何代码。相反，api注册器404可以识别高可用性特性1602并执行在api注册器404中维护的代码以部署服务的多个实例602、604。这允许api注册器404定义对于向api注册器404注册的任何服务的部署而言“高可用性”意味着什么。
因为api注册器404连接到容器平台210的运行时环境，所以api注册器404可以与容器平台210交互以部署确定服务的运行时可用性的实例602、604。注意的是，图16中所示的服务的两个实例602、604仅作为示例提供，并且不意味着限制。高可用性服务可以包括部署到容器平台的服务的多于两个冗余实例。
一些实施例可以在api注册器404中包括可以默认执行的代码。如果特性602仅包括期望高可用性的简单指示，那么api注册器404可以执行其自己的代码。如果特性602包括用于部署服务的部署代码，那么api注册器404可以代替地执行特性1602的代码。在一些情况下，特性1602可以仅仅包括部署具有高可用性的服务所需的代码的部分。api注册器404可以执行由特性1602提供的代码的部分，然后使用api注册器404处的代码来执行特性1602未提供的任何代码。这允许开发人员覆写在api注册器404处如何执行特性(诸如高可用性)的现有定义，同时仍允许api注册器404提供用于执行可被已注册的服务使用的特性的统一定义。
在一些实施例中，高可用性特性还可以使容器平台210部署负载平衡服务606，该负载平衡服务606将请求分发给该服务的多个实例602、604。负载平衡服务606的端点可以向api注册器404注册，并且对其它服务可用。可替代地或附加地，服务602、604的多个实例中的每一个可以作为服务端点向api注册器404注册。
在下面描述的每个示例中，可以应用关于图16讨论的相同原理。例如，以下描述的任何特性都可以附带有可以由api注册器404接收并用于推翻否则将由api注册器404执行的代码的代码。在本公开之前，不存在用于创建用于执行特性的统一默认值、同时允许服务开发人员在需要时推翻那些特性的方法。因此，api注册器404通过允许默认情况下执行在api注册器404处的代码、同时仍允许该代码被从开发人员接收的特性1602推翻来解决技术问题。
图17图示了根据一些实施例的通过api注册器强制实施端到端加密的特性的硬件/软件示意图。与api定义文件1505一起，api注册器404可以接收特性1704，该特性指示用于调用服务1708的端到端加密或包括生成用于调用服务1708的端到端加密的代码。在开发期间，服务1708可以包括其自己的使得由服务1708接收的分组被解密并且使由服务1708返回的分组被加密的解密/加密代码1710。在本公开之前，开发人员将需要提供指示服务1708的用户需要提供加密以与服务1708兼容的规范。这个实施例通过允许服务1708指示在调用服务1706中如何生成客户端库来解决技术问题，这确保了与服务1708的加密的兼容性。
在一些实施例中，服务1708的开发人员不需要在服务1708中包括加密/解密代码1710。代替地，特性1704可以简单地指示api注册器404强制实施对服务1708的端到端加密。当服务1708被部署到容器平台210时，api注册器404可以使加密/解密代码1710在服务1708被部署时被插入到服务1708中。这允许开发人员基于特性1704在不同的加密方案之间进行选择和/或允许api注册器404选择优选的加密方案作为默认方案。
端到端加密不仅要求在部署服务时或在开发期间将加密/解密代码1710插入到服务1708中，而且还要求调用服务1706还包括兼容的加密/解密代码。如上所述，当调用服务1706需要使用服务1708时，api注册器404可以生成一个或多个客户端库1702，该一个或多个客户端库1702以简单且高效的方式完全实现与服务1708交互所需的代码。当生成这个客户端库1702时，api注册器404可以分析特性1704以确定由服务1708使用的加密方案。然后，基于该特性1704，api注册器404可以使兼容的加密/解密代码被添加到用于调用服务1706的客户端库1702。因此，当调用服务1706向服务1708发送请求时，信息可以在调用服务1706处被加密，并且一旦被服务1708接收，就被解密。类似地，服务1708可以在将响应发送到调用服务1706之前对响应进行加密，然后调用服务1706可以在将该响应传递到客户端库1702外部之前对该响应进行解密。这使得整个加密过程对于调用服务1706的开发人员是完全透明的。特性1704可以确保api注册器404已经在客户端库1702中生成了加密/解密代码以便兼容以及实现端到端加密特性，而不是要求在调用服务1706时实现兼容的加密/解密方案。
图18图示了根据一些实施例的用于让api注册器实现服务1808的使用情况日志记录的特性1804。在本公开之前，为了监视和日志记录对服务的请求的频率、源、成功率等，服务本身必须日志记录这种信息。可替代地，容器环境必须监视服务并日志记录其使用情况信息。在服务1808本身处对信息进行日志记录效率非常低，并且减慢了由服务处置的每个请求的吞吐量。类似地，要求容器平台监视和日志记录对特定服务的所有调用的开销也向容器服务的调度和编排带来巨大开销。这个实施例通过将代码直接插入到用于调用服务1808的服务的客户端库中来解决这个技术问题。这允许日志记录和监视服务1808的使用情况，而在存储器使用情况或cpu使用情况方面完全不影响服务1808的性能。
除了api定义文件1505之外，api注册器404还可以接收指示使用情况日志记录1804或包括实现使用情况日志记录1804的代码的特性1804。当调用服务1806的开发人员期望向服务1808提交请求时，api注册器404可以自动生成客户端库1802，该客户端库1802包括用于日志记录与服务1808相关的活动的代码。如上所述，这种代码可以基于由api注册器404维护和执行的默认代码来生成，或者可以由利用特性1804接收并由api注册器404执行的代码来生成。
用于在客户端库1802中日志记录活动的代码可以包括在服务1808每次被调用时递增的计数器、在服务1808被调用时使得活动被日志记录到日志文件中的函数以及监视和记录发送到服务1808的请求和从服务1808接收的响应的特点的其它函数。取决于特定的实施例，这种代码可以监视与关于服务1808做出的请求相关联的许多不同类型的特点。例如，一些实施例可以日志记录对服务1808进行的调用的总数。一些实施例可以日志记录从服务1808接收的响应的成功率。一些实施例可以日志记录在对服务1808的请求中发送的数据的类型。一些实施例可以日志记录当服务1808被调用时的一天中的时间或其它外部信息。一些实施例可以日志记录可以被用于调试服务1808的去往/来自服务1808的输入和输出分组。一些实施例可以以任何组合日志记录这些特征中的任何特性或所有特性而没有限制。
图19图示了根据一些实施例的可以对服务1908强制实施认证协议的特性1904的硬件/软件示意图。一些服务可以要求对用户身份进行认证，并要求用户在对请求做出响应之前被授权以使用该服务。在本公开之前，在服务1908本身处进行认证和授权过程的情况下存在技术问题。对于由服务1908接收的每个调用，这在存储器使用情况和cpu使用情况方面增加了开销，并且增加了响应时服务的延迟。这进而降低了吞吐量，并限制了在任何给定时间间隔期间服务1908可以处理的请求数量。这些实施例通过将认证/授权代码移到由api注册器1404自动生成的客户端库1902来解决这个技术问题。
当调用服务1906想要使用服务1908时，api注册器404可以生成包括用于执行授权和/或认证的代码的客户端库1902。在一些实施例中，这可以包括联系具体地核实用户身份和/或确定用户是否被授权使用服务1908的外部认证/授权服务1920。外部认证/授权服务1920可以包括访问管理器、轻量级目录访问协议(ldap)管理器、访问控制列表(acl)、网络认证协议管理器等。然后，当认证/授权过程成功时，客户端库1902中的代码可以将调用发送到服务1908。
通过将认证/授权强制实施卸载到api注册器404和客户端库1902，可以从服务1908中完全消除这种代码。因为与外部认证/授权服务1920交互常常附带显著的延迟，所以可以从服务1908中移除这种延迟以增加吞吐量。此外，不是将认证/授权强制实施硬编码到服务1908中，而是服务1908的开发人员可以代替地使用发送到api注册器404的特性1904简单地选择预定义的认证/授权方案。api注册器404可以维护带有用于客户端库1902的附带实现代码的授权/认证的预定义列表。这也防止调用服务1906向服务1908发送不能被授权和/或认证的请求。代替地，如果认证和/或授权例程不成功，那么可以在客户端库1902处终止该调用。这确保服务1908仅接收经过认证和/或授权的请求。
api注册器404提供的另一个技术改进是升级由特性1904提供的任何功能而无需改变任何已注册的服务的任何代码的能力。例如，因为认证/授权代码已经被卸载到由api注册器1404生成的客户端库1902，所以客户端库1902可以被更新以改变认证/授权方案。调用服务1906或服务1908中的代码均不需要修改。因为仅在单个位置改变代码，所以这大大降低了代码集成错误的概率，否则这些代码集成错误将伴随着发送到每个单独服务的分布式补丁。
图20图示了根据一些实施例的用于启用服务的运行时实例化的特性2004的硬件/软件示意图。一些服务可能很少被使用或仅在预定义的时间间隔内被使用。因此，将服务部署到容器平台并不一定总会导致实际上实例化立即可用的容器中的服务实例。与虚拟机相比，可以非常快速地实例化和激活容器。因此，服务开发人员可能期望仅在调用服务时才实例化该服务。服务开发人员可能还期望仅在预定义的时间间隔内实例化该服务。类似地，服务开发人员可以指定应当在预定义的不活动时间间隔之后删除服务实例。
除了接收api定义文件1505之外，api注册器404还可以接收指定运行时实例化或其它实例化参数的特性2004。例如，特性可以包括在部署之后对应当实例化服务2008的一个或多个时间间隔的指定。在另一个示例中，特性可以包括仅应当按需实例化服务2008的指示。在另一个示例中，特性可以指定超时间隔，在该超时间隔之后，应当从容器平台删除实例化服务2008。
当调用服务2006想要使用服务2008时，api注册器404可以在客户端库2002中生成处置服务2008的运行时实例的代码。例如，客户端库2002中的createinstance()函数调用可以创建对api注册器404的调用。api注册器然后可以与容器平台210交互以确定服务2008的操作实例是否可用。如果不可用，那么api注册器404可以指示容器平台210在容器平台2010中的容器中实例化服务2008的实例。容器平台210然后可以将端点(例如，ip地址和端口号)返回给api注册器404。然后，api注册器404可以在该端点和在客户端库2002中创建的api函数调用之间创建绑定。api注册器404然后可以将端点返回到客户端库2002，该客户端库2002可以被用于在调用服务2006和新实例化的服务2008之间创建直接连接。
对于仅应当在预定义时间间隔期间被实例化的服务，api注册器404可以为某些服务建立实例化和删除时间的表。基于这些存储的实例化/删除时间，api注册器404可以指示容器平台210实例化或删除服务2008的实例。api注册器404还可以指定在这些预定义间隔期间应当被实例化的多个实例。例如，从5:00pm到10:00pm，特性2004可以指定服务2008的至少10个实例在容器平台210上处于活动状态。当这个时间间隔发生时，api注册器404可以指示容器平台210创建附加实例。
图21图示了根据一些实施例的实现用于服务2108的速率限制功能的特性2104的硬件/软件示意图。一些服务可能需要限制接收请求的速率。其它服务可能需要限制来自某些发件人或服务的类型的请求。在本公开之前，这个功能必须由服务本身通过确定每个请求的源、将源与白名单/黑名单进行比较、并调节它服务于这些请求的速率执行。与上述大多数示例一样，将这个开销放在服务本身中会增加该服务使用的存储器和cpu能力的量，并限制该服务的吞吐量。这些实施例通过在由api注册器生成的客户端库中自动生成速率限制代码来解决这个技术问题。这允许服务借助于特性2104来指定速率限制，而无需服务2108利用其所有相关联的开销来实现该功能。
当调用服务2106想要向服务2108发送请求时，api注册器404可以自动生成包括速率限制代码的客户端库2102。当生成客户端库2102时，api注册器404可以确定特定服务2106是否应当受到速率限制。如果不是，那么可以照常生成客户端库2102。如果api注册器404确定调用服务2106应当受到速率限制(例如，通过与白名单/黑名单进行比较)，那么api注册器404可以在客户端库2102中插入添加延迟、添加计数器和/或以其它方式实现速率限制功能的代码，以确保由调用服务2106根据预定义速率在任何给定时间间隔内进行预定义的最大数量的请求。这种代码还可以实现速率限制功能将处于活动状态的时间窗口。这允许服务2108在高业务间隔期间自动实行速率限制。
如上所述，系统可以包括ide102和生产/部署环境104。生产/部署环境104可以包括云计算平台202。应用和服务可以在ide102中开发，并被部署到云计算平台202。通常，ide102将包括调试器110。调试器110是专门设计用于测试错误并在服务或应用被开发时定位其中的错误(bug)的软件程序。调试器可以使用指令集模拟器，或者可以直接在底层硬件/处理器上运行程序，以实现对程序指令执行的高级控制。最重要的是，调试器允许开发人员根据由断点表示的特定条件停止或中止程序执行。在程序执行被停止时，开发人员可以检查变量值、程序执行流程和/或应用或服务的状态的其它特点。
虽然调试器110在ide102中的开发过程中特别有用，但它通常不随服务一起部署到云计算平台202中。部署服务的调试版本将引入技术问题，这些技术问题将阻止云计算平台202的高效使用。例如，在本文中称为“调试版本(build)”的与调试器兼容的服务的版本通常包括与调试器110的兼容性所需的、但对于常规执行而言并非必需的不必要的开销和附加指令。这些附加指令/开销使得服务的调试版本花费更长的时间运行，这增加延迟、降低吞吐量，并使用云计算平台202的更多处理资源。此外，将需要与调试器110软件一起部署调试版本。为服务的每个实例部署调试器110的版本将为服务的每个实例添加大量的附加存储器使用，这进而可能减少云计算平台202的可用存储器资源。
因为调试器110没有部署到生产/部署环境104中，所以对于在部署之后发现的错误进行故障排除特别困难。在本公开之前，将使用伪数据或预配置的输入在ide中运行具有调试器110的服务的调试版本，以尝试并模拟服务在生产/部署环境104中接收到的请求业务的真实流。但是，这会阻止服务使用实时的实况数据，这些数据对于重新创建错误以及确定针对这些错误的修复/补丁是否在不干扰服务的预期操作的情况下适当工作而言可以是最优的。
本文所述的实施例对云计算平台202进行了改变，使得可以在生产/部署环境104中与调试器一起部署服务的调试版本，以从实际请求业务中接收实时的实况数据。在一些实施例中，调试客户端可以发送特定的调试请求，该调试请求通过负载平衡器被路由并且由服务网格指引到服务的调试实例。这允许来自其它客户端的请求通过相同的负载平衡器和服务网格，同时继续直接被路由到服务的正常实例。在一些实施例中，服务网格可以从任何客户端接收请求，并克隆要发送到服务的调试实例的请求。这些实施例允许服务的调试实例与服务的正常实例一起在生产/部署环境104的云计算平台202中操作。这些实施例还通过将实时的实况请求路由到服务的调试实例来解决上述技术问题，而不中断其它服务实例的正常操作。
图22图示了根据一些实施例的用于接收服务请求的云计算平台202的一部分的框图。如上所述，一些实施例可以包括可以控制如何在云计算平台202内部署和操作服务的api注册器404。api注册器404可以通信耦合到服务网格2210。服务网格2210是用于微服务或面向服务的环境的可配置基础设施层，其允许服务实例之间的通信是灵活、可靠和快速的。在一些实施例中，服务网格2210可以提供服务发现、负载平衡、加密、认证/授权以及其它能力。在云计算平台202中，随着更多的容器被添加到基础设施，服务网格2210将来自客户端的请求路由到每个服务的特定实例。注意的是，并非在所有实施例中都要求api注册器404。在一些实施例中，下面描述的功能还可以由容器编排层的调度器或其它部件执行。
在一些实施例中，服务网格2210可以提供其自己的负载平衡操作。为了清楚起见，图22专门图示了负载平衡器2208，负载平衡器2208可以是服务网格2210的一部分或可以是单独的部件。负载平衡器2208可以被用于将来自多个客户端2202、2204、2206的请求路由到不同的服务实例。不同的服务实例可以驻留在不同的操作环境、不同的容器节点和/或不同的硬件设备上。此外，负载平衡器2212可以与特定服务相关联。单个服务可以具有可用于服务请求的多个服务实例2214、2216、2218。负载平衡器2212可以接收来自服务网格的请求，并将请求业务路由到特定服务实例2214、2016、2218，以使得服务请求均匀地分布在服务实例2214、2016、2218之间。
在图22的示例中，服务实例2214、2016、2218中的每一个已经作为服务的生产版本部署到云计算平台202。这些在本文中可以被称为“生产服务”或“正常服务”，并且它们可以与服务的调试实例区分开，因为用于服务实例2214、2016、2218的容器/舱不包括调试器或服务的调试版本。代替地，这些“正常”服务实例2214、2016、2218已经以简化格式进行编译和部署，这允许它们快速且高效地服务于请求，而无需与调试操作相关联的开销。
图23图示了根据一些实施例的封装在舱2300中的服务的调试版本。舱2300类似于图3中所示的舱。例如，整个服务可通过端点318可用，并且服务是使用多个微服务或服务320、322、324、326构建的。这些服务可以被打包在多个容器310、312中，并且可以利用公共资源308，诸如存储卷、查找表、数据库或其它资源。
但是，与图3中的舱304相比，封装在舱2300中的服务的这个调试版本包括附加的调试实用程序。例如，舱2300包括附加的容器2302，该附加的容器2302包括调试守护进程2304。一般而言，守护进程是一种计算机程序，它作为后台进程运行，而不是在交互用户的直接控制下运行。在这个特定的容器环境中，调试守护进程2304包括在服务本身的控制之外运行并且被配置为与服务实例对接的后台进程。除了调试守护进程之外，容器2302还可以包括调试登录服务2308，调试登录服务2308允许管理员登录到舱2300并在它操作的同时执行调试操作。容器2302还可以包括附加的调试实用程序2006，诸如在服务接收实时的实况数据请求时跟踪存储器使用情况、处理器使用情况、带宽使用情况和其它计算特点的实用程序。
除了容器2302之外，舱2300还可以包括服务本身的特定调试版本。例如，可以使用调试配置来构建或编译服务320、322、324、326中的一个或多个，以使服务320、322、324、326的源代码包括用于调试器进程2310与服务的调试版本一起操作的接口。服务320、322、324、326中的一个或多个将因此能够基于与调试器2310的交互来提供变量值并暂停执行。服务本身的操作可以被认为是来自图22的服务的其它正常实例2214、2216、2218的克隆。因此，图23的舱2300中所示的服务的调试版本可以被用于可靠地调试来自图22的服务的正常实例2214、2216、2218。
图24图示了根据一些实施例的用于服务的调试版本的替代舱2400。舱2400类似于图3中的舱306。具体而言，舱2400包括具有通过端点316提供的服务328的单个容器314。但是，容器314也可以加载有提供整体服务的调试版本所需的调试实用程序。具体而言，服务328可以使用调试配置来编译，并被加载到容器314中。此外，调试守护进程2304、调试登录2308、调试器2310和/或附加调试实用程序2306也可以以任何组合且没有限制地包括在容器314中。将理解的是，这些调试实用程序中没有一个是特定实施例要求的，因此一些实施例可以省略上述调试实用程序中的任何一个。
在下面的描述中，可以在操作期间在生产/部署环境104中实例化图24中的上面在图23中描述的服务的调试实例。例如，在正常服务实例2214、2016、2218已经被实例化并且在云计算平台202中操作之后，该服务的调试实例也可以被实例化并加载到云计算平台202中。服务的调试实例可以以类似于正常服务实例2214、2216、2218的方式接收常规和/或专用请求业务。这允许在生产环境中实时地调试真实事务，而不中断正常服务实例2214、2216、2218的常规操作。
图25图示了根据一些实施例的用于实例化服务的调试实例2502的系统的框图。云计算平台202可以从常规客户端2204、2206接收正常请求。这些正常请求可以通过负载平衡器2208和服务网格2210被路由到特定服务。该服务可以具有多个实例2214、2216、2218，并且用于该服务的负载平衡器2212可以路由请求，使得每个服务实例处的负载被平衡。
除了从常规客户端2204、2206接收正常请求之外，一些实施例还可以从调试客户端2504接收调试请求2506。调试客户端2504可以与常规客户端2204、2206完全相同，因此可以包括台式计算机、便携式计算机、工作站、服务器、移动计算设备、智能电话、pda、平板计算机、膝上型计算机、智能手表等。但是，调试客户端2504可以被具体地识别为向云计算平台202提供调试消息的客户端设备。调试请求2506可以与从常规客户端2204、2206发送的正常请求完全相同。但是，调试请求2506可以由调试客户端2504专门提供，以转到服务的调试实例，而不是服务的正常实例2214、2216、2218。
当服务网格2210接收到调试请求2506时，它可以确定服务的调试实例当前是否在容器平台210中运行。如果当前没有在容器平台210上操作的服务的调试实例，那么服务网格2210可以向api注册器404发送消息以进行生成，可替代地，服务网格2210可以向用于云计算平台202的调度器发起消息，以在不使用api注册器404的实施例中生成服务的调试实例。
如上所述，可以通过为服务提供api定义文件1505来完成向api注册器404注册服务。api定义文件1505还可以附带有一个或多个特性，该一个或多个特性表征应如何部署服务和/或应当如何生成用于调用服务的客户端库。在这种情况下，一个或多个特性可以包括动态调试特性2510，该动态调试特性2510向api注册器404指定当服务网格2210辨别或识别出调试请求2506时应当按需生成服务的调试实例。可以部署服务的正常实例2214、2216、2218，而不受动态调试特性2510的影响。在接收调试请求2506之前，不需要在容器平台210上实例化或操作服务的调试实例。
在部署服务的正常实例2214、2216、2218之后，并且响应于接收到调试请求2506，api注册器404可以使服务的调试实例2502被部署在云计算平台202中。调试实例2502可以是如图24中所示的单容器实例，或者可以是如图23中所示的多容器实例。在任一实施例中，调试实例都可以包括以任何组合且不加限制的服务的调试版本、调试器、调试登录、调试守护进程和/或任何其它调试实用程序。
如同部署到云计算平台202的任何服务一样，服务的调试实例2502可以向api注册器404注册。这可以包括向api注册器404提供端点(例如，ip地址和端口号)。然后，api注册器404可以提供api函数的集合，如上所述，api函数可以被用于调用服务的调试实例2502。可替代地或附加地，由于api注册器404已经部署了服务的调试实例2502，因此服务的调试实例2502不需要向api注册器404提供其自己的api定义文件或特性。代替地，api注册器404可以向服务网格2210提供端点。然后，服务网格2210可以使用端点将调试消息2506路由到服务的调试实例2502。这个端点不需要被发布，因为仅服务网格2210需要向调试实例发送任何消息。但是，一些实施例可以使这个端点可用于在运行时期间访问调试信息的其它服务。
图26图示了根据一些实施例的将调试请求路由到服务的调试实例2502的容器平台210的框图。当服务网格2210接收到调试请求2506时，服务网格2210可以识别调试请求2506。可以以多种不同方式将调试请求2506与来自常规客户端2204、2206的正常请求区分开。例如，服务网格2210可以借助于发送者(即，调试客户端2504)来识别调试请求2506。当服务网格2210识别出调试客户端2504的地址时，服务网格2210可以将该请求指定为调试请求2506。这允许服务网格2210凭借调试请求的源来识别调试请求。
在一些实施例中，服务网格2210可以使用嵌入在调试请求2506内的任何信息来识别调试请求2506。例如，调试请求2506可以在调试请求2506内具有将其识别为调试请求的唯一的报头信息或一个或多个标志设置。在另一个示例中，调试请求2506可以在请求内包括有效载荷，该有效载荷包括仅由调试请求使用的预定值。
当服务网格识别出调试请求2506时，它可以改变调试请求的正常路由。正常请求可以被发送到负载平衡器2212和/或服务的正常实例2214、2216、2218，而调试请求2506可以专门被路由到服务的调试实例2502。例如，可以首先使用来自图25的调试请求2506来触发服务的调试实例2502的实例化。当服务网格2210从api注册器404接收到服务的调试实例2502可操作的通知时，服务网格2210然后可以将调试请求2506路由到服务的调试实例2502。当从调试客户端2504或其它指定为调试客户端的客户端接收到将来的调试请求时，服务网格2210还可以将这些请求路由到服务的调试实例2502。因为服务的调试实例2502已经在操作，所以可以路由请求而无需来自api注册器404的额外参与。
在一些实施例中，服务的调试实例2502可以保持实例化达预定的时间限制。例如，服务的调试实例2502可以包括默认时间限制(例如，24小时)，之后，api注册器404和/或调度器可以删除服务的调试实例2502。在一些实施例中，动态调试特性2510还可以指定专门为该服务定制的时间间隔。例如，服务开发人员可以确定一周是特定服务的更合适的调试间隔，然后可以将七天的间隔作为动态调试特性2510的一部分被提供，以覆盖否则将由api注册器404应用的任何默认时间间隔。在一些实施例中，时间限制可以是绝对的，使得它从实例化开始。在一些实施例中，时间限制可以是相对的，使得每当服务的调试实例2502接收到新的调试请求2506时，就将它重置。
图27图示了根据一些实施例的克隆请求的云计算平台202的框图。与上述实施例相反，这些实施例不需要特殊的请求源来向服务的调试实例提供调试请求。代替地，服务网格210可以从常规客户端2202、2204、2206接收正常请求。代替将特殊调试消息与实况数据一起实时地路由到服务的调试实例，这些实施例可以使用实况数据本身并将请求的克隆的副本路由到调试服务，而不会中断服务的正常实例2214、2216、2218的正常操作。
如上所述，服务本身可以通过上传api定义文件1505向api注册器404注册。api注册器404可以与api定义文件1505一起接收克隆调试特性2710的上传。克隆调试特性2710可以向api注册器404指示应当在云计算平台202中实例化服务的调试实例2502。当部署服务的正常实例2214、2216、2218时，api注册器404和/或调度器可以部署服务的调试实例2502。可替代地或附加地，可以响应于从客户端接收到被发送到服务的请求而部署服务的调试实例2502。对于使用api注册器404的实施例，api注册器可以将服务的调试实例2502的端点提供给服务网格2210。
api注册器404和/或调度器还可以向服务网格2210提供指示发送到服务的请求应当被克隆并且还应当被发送到服务的调试实例2502的指示2702。指示2702可以指示所有请求应当被克隆并被发送到服务的调试实例2502。在一些实施例中，指示2702可以指示应当为服务的调试实例2502克隆一定百分比的请求(例如，每隔一个请求、每第三个请求等等)。
图28图示了根据一些实施例的克隆的请求被转发到服务的调试实例2502的框图。当从常规客户端2202发送正常请求2806时，正常请求2806可以经过负载均衡器2208并由服务网格2210识别。服务网格2210可以将正常请求2806识别为被寻址到服务。然后，基于指示2702和/或这种识别，服务网格2010然后可以生成克隆的请求2808。在一些实施例中，克隆的请求2808可以是正常请求2006的完整副本。在一些实施例中，克隆的请求2808可以包括由服务网格2210插入的在调试过程中可能有用的附加信息(例如，时间戳或在调试场景中可能有用的其它诊断信息)。
然后，可以将克隆的请求2808转发到服务的调试实例2502。这可以与将正常请求2806转发到服务的正常实例2214、2216、2218并行地完成。因此，这个克隆过程可以在不影响服务的正常实例2214、2016、2218的吞吐量的情况下操作。这还允许服务的调试实例2502将实时的实况数据用于调试过程。因此，在服务的正常实例2214、2216、2218中发生的任何错误也将被服务的调试实例2502的输出捕获。这提供了独特的技术优势，其允许使用实况调试数据在问题发生时实时地隔离它们，而不会产生仅由服务的调试实例处理正常请求2806通常所附带的开销。
图29图示了用于为容器环境中的容器化的服务提供运行时调试的方法的流程图。该方法可以包括接收对在容器环境处的服务的请求(2902)。容器环境可以包括服务网格和封装在多个容器中的多个服务。服务也可以封装在容器环境中的第一一个或多个容器中。容器环境可以包括上述的容器平台210。请求可以是来自常规客户端设备的调试请求或正常请求。可以将第一一个或多个容器组织到容器舱中，该容器舱可以包括形成服务的一个或多个微服务。容器环境可以包括带有容器调度器的编排的容器平台。容器环境还可以包括api注册器。
该方法还可以包括确定应当将请求路由到服务的调试实例(2904)。可以基于许多不同的因素(包括请求的源、请求中的报头、请求的有效载荷中的值、请求中的标志、接收请求的定时和/或请求的任何其它特点)做出这个确定。如果请求不是调试请求，那么该方法可以包括将请求路由到服务的正常实例(2908)。
如果该请求被识别为调试请求，那么该方法还可以包括确定服务的调试实例是否可用(2906)。如果调试实例可用，那么该方法可以包括将请求路由到服务的调试实例(2912)。如果调试实例不可用，那么该方法还可以包括实例化服务的调试实例(2910)，以及将请求路由到新实例化的服务的调试实例(2912)。
应当认识到的是，根据本发明的各种实施例，图29中所示的特定步骤提供了在容器环境中实现实况调试的特定方法。根据替代实施例，也可以执行其它步骤顺序。例如，本发明的替代实施例可以以不同的次序执行上面概述的步骤。而且，图29中所示的各个步骤可以包括多个子步骤，这些子步骤可以按照适合于各个步骤的各种顺序来执行。此外，取决于特定应用，可以添加或移除附加步骤。本领域普通技术人员将认识到许多变化、修改和替代。
本文描述的每个方法可以由专用计算机系统来实现。这些方法的每个步骤可以由计算机系统自动执行，和/或可以被提供有涉及用户的输入/输出。例如，用户可以为方法中的每个步骤提供输入，并且这些输入中的每一个可以响应于请求这种输入的具体输出，其中输出由计算机系统生成。每个输入可以响应于对应的请求输出而被接收。此外，输入可以从用户接收、作为数据流从另一个计算机系统接收、从存储器位置检索、通过网络检索、从web服务请求等。同样，输出可以提供给用户、作为数据流提供给另一个计算机系统、保存在存储器位置中、通过网络发送、被提供给web服务等。简而言之，本文描述的方法的每个步骤可以由计算机系统执行，并且可以涉及到计算机系统和来自计算机系统的任何数量的输入、输出和/或请求，这些输入、输出和/或请求可以涉及或可以不涉及用户。可以被称为不涉及用户的那些步骤是由计算机系统自动执行的而无需人为干预。因此，根据本公开将理解的是，可以更改本文描述的每个方法的每个步骤以包括到用户和来自用户的输入和输出，或者可以由计算机系统自动完成而无需人为干预，其中任何确定由处理器产生。此外，本文描述的每个方法的一些实施例可以被实现为存储在有形的、非瞬态存储介质上的指令集合，以形成有形的软件产品。
图30描绘了可以与上述任何实施例进行交互的分布式系统3000的简化图。在所示实施例中，分布式系统3000包括一个或多个客户端计算设备3002、3004、3006和3008，该一个或多个客户端计算设备可以被配置为通过一个或多个网络3010执行和操作客户端应用，诸如web浏览器、专有客户端(例如，oracleforms)等。服务器3012可以经由网络3010与远程客户端计算设备3002、3004、3006和3008通信地耦合。
在各种实施例中，服务器3012可以适于运行由系统的一个或多个部件提供的一个或多个服务或软件应用。在一些实施例中，这些服务可以作为基于web的服务或云服务被提供，或者在软件即服务(saas)模型下被提供给客户端计算设备3002、3004、3006和/或3008的用户。操作客户端计算设备3002、3004、3006和/或3008的用户又可以利用一个或多个客户端应用来与服务器3012交互以利用由这些部件提供的服务。
在图中绘出的配置中，系统3000的软件部件3018、3020和3022被示出为在服务器3012上实现。在其它实施例中，系统3000的一个或多个部件和/或由这些部件提供的服务也可以由客户端计算设备3002、3004、3006和/或3008中的一个或多个来实现。然后，操作客户端计算设备的用户可以利用一个或多个客户端应用来使用由这些部件提供的服务。这些部件可以用硬件、固件、软件或其组合来实现。应该认识到的是，各种不同的系统配置是可能的，这些系统配置可能与分布式系统3000不同。图中所示的实施例因此是用于实现实施例系统的分布式系统的一个示例，而不旨在进行限制。
客户端计算设备3002、3004、3006和/或3008可以是便携式手持设备(例如，
虽然示例性分布式系统3000被示出为具有四个客户端计算设备，但是可以支持任何数量的客户端计算设备。其它设备(诸如具有传感器的设备等)可以与服务器3012交互。
分布式系统3000中的(一个或多个)网络3010可以是本领域技术人员熟悉的、可以利用各种可商业获得的协议中的任何协议支持数据通信的任何类型的网络，其中协议包括但不限于tcp/ip(传输控制协议/互联网协议)、sna(系统网络体系架构)、ipx(互联网分组交换)、appletalk，等等。仅仅作为示例，(一个或多个)网络3010可以是局域网(lan)，诸如基于以太网、令牌环等的lan。(一个或多个)网络3010可以是广域网和互联网。它可以包括虚拟网络，包括但不限于虚拟专用网(vpn)、内联网、外联网、公共交换电话网(pstn)、红外网络、无线网络(例如，依据电子电气学会(ieee)802.11协议套件、
服务器3012可以包括一个或多个通用计算机、专用服务器计算机(作为示例，包括pc(个人计算机)服务器、
服务器3012可以运行包括以上讨论的操作系统当中任意一种的操作系统，以及任何可商业获得的服务器操作系统。服务器3012还可以运行各种附加的服务器应用和/或中间层应用中的任何服务器应用和/或中间层应用，包括http(超文本传输协议)服务器、ftp(文件传输协议)服务器、cgi(公共网关接口)服务器、
在一些实施方式中，服务器3012可以包括一个或多个应用，以分析和整合从客户端计算设备3002、3004、3006和3008的用户接收到的数据馈送和/或事件更新。作为示例，数据馈送和/或事件更新可以包括但不限于
分布式系统3000还可以包括一个或多个数据库3014和3016。数据库3014和3016可以驻留在各种位置中。作为示例，数据库3014和3016中的一个或多个可以驻留在服务器3012本地的(和/或驻留在服务器3012中的)非瞬态存储介质上。替代地，数据库3014和3016可以远离服务器3012，并且经由基于网络的连接或专用的连接与服务器3012通信。在一组实施例中，数据库3014和3016可以驻留在存储区域网络(san)中。类似地，用于执行服务器3012所具有的功能的任何必要的文件都可以适当地本地存储在服务器3012上和/或远程存储。在一组实施例中，数据库3014和3016可以包括适于响应于sql格式的命令而存储、更新和检索数据的关系数据库，诸如由oracle提供的数据库。
图31是根据本公开的实施例的系统环境3100的一个或多个部件的简化框图，通过该系统环境3100，由实施例系统的一个或多个部件提供的服务可以作为云服务提供。在所示实施例中，系统环境3100包括可以由用户使用以与提供云服务的云基础设施系统3102交互的一个或多个客户端计算设备3104、3106和3108。客户端计算设备可以被配置为操作客户端应用，诸如web浏览器、专有客户端应用(例如，oracleforms)或某种其它应用，客户端应用可以由客户端计算设备的用户用来与云基础设施系统3102交互以使用由云基础设施系统3102提供的服务。
应该认识到的是，图中描绘的云基础设施系统3102可以具有除了所描绘的部件之外的其它部件。另外，图中所示的实施例仅是可以结合本发明的实施例的云基础设施系统的一个示例。在一些其它实施例中，云基础设施系统3102可以具有比图中所示更多或更少的部件、可以组合两个或更多个部件、或者可以具有不同的部件配置或布置。
客户端计算设备3104、3106和3108可以是与上面针对3002、3004、3006和3008所描述的设备类似的设备。
虽然示例性系统环境3100被示出具有三个客户端计算设备，但是任何数量的客户端计算设备可以被支持。诸如具有传感器的设备等之类的其它设备可以与云基础设施系统3102交互。
(一个或多个)网络3110可以促进客户端3104、3106和3108与云基础设施系统3102之间的数据通信和交换。每个网络可以是本领域技术人员所熟悉的可以使用各种商业上可获得的协议(包括上面针对(一个或多个)网络3010所描述的协议)中的任何一种支持数据通信的任何类型的网络。
云基础设施系统3102可以包括一个或多个计算机和/或服务器，其可以包括上面针对服务器3012所描述的那些计算机和/或服务器。
在某些实施例中，由云基础设施系统提供的服务可以包括按需对云基础设施系统的用户可用的许多服务，诸如在线数据存储和备份解决方案、基于web的电子邮件服务、被托管的办公套件和文档协作服务、数据库处理、受管理的技术支持服务等。由云基础设施系统提供的服务可以动态缩放以满足云基础设施系统的用户的需要。由云基础设施系统提供的服务的具体实例化在本文中被称为“服务实例”。一般而言，从云服务提供商的系统经由通信网络(诸如互联网)对用户可用的任何服务被称为“云服务”。通常，在公共云环境中，构成云服务提供商的系统的服务器和系统与客户自己的内部部署的服务器和系统不同。例如，云服务提供商的系统可以托管应用，并且用户可以经由诸如互联网之类的通信网络按需订购和使用应用。
在一些示例中，计算机网络云基础设施中的服务可以包括对存储装置、被托管的数据库、被托管的web服务器、软件应用或由云供应商向用户提供的其它服务的受保护的计算机网络访问，或者如本领域中另外已知的那样。例如，服务可以包括通过互联网对云上的远程存储装置进行密码保护的访问。作为另一个示例，服务可以包括基于web服务的被托管的关系数据库和脚本语言中间件引擎，以供联网的开发人员私有使用。作为另一个示例，服务可以包括对在云供应商的网站上托管的电子邮件软件应用的访问。
在某些实施例中，云基础设施系统3102可以包括以自助服务、基于订阅、弹性可扩展、可靠、高度可用和安全的方式交付给客户的应用、中间件和数据库服务产品的套件。这种云基础设施系统的示例是由本受让人提供的oracle公共云。
在各种实施例中，云基础设施系统3102可以适于自动供应、管理和跟踪客户对由云基础设施系统3102供给的服务的订阅。云基础设施系统3102可以经由不同的部署模型来提供云服务。例如，可以依据公共云模型提供服务，在公共云模型中云基础设施系统3102被销售云服务的组织拥有(例如，被oracle拥有)，并且服务对一般公众或不同行业的企业可用。作为另一个示例，可以依据私有云模型来提供服务，在私有云模型中云基础设施系统3102仅针对单个组织操作，并且可以为该组织内的一个或多个实体提供服务。还可以依据社区云模型来提供云服务，在社区云模型中云基础设施系统3102和由云基础设施系统3102提供的服务由相关社区中的若干组织共享。云服务还可以依据混合云模型被提供，该混合云模型是两个或更多个不同模型的组合。
在一些实施例中，由云基础设施系统3102提供的服务可以包括在软件即服务(saas)类别、平台即服务(paas)类别、基础设施即服务(iaas)类别或包括混合服务的其它服务类别下提供的一个或多个服务。客户经由订阅订单可以订购由云基础设施系统3102提供的一个或多个服务。云基础设施系统3102然后执行处理以提供客户的订阅订单中的服务。
在一些实施例中，由云基础设施系统3102提供的服务可以包括但不限于应用服务、平台服务和基础设施服务。在一些示例中，应用服务可以由云基础设施系统经由saas平台提供。saas平台可以被配置为提供落入saas类别的云服务。例如，saas平台可以提供在集成开发和部署平台上构建和交付按需应用套件的能力。saas平台可以管理和控制用于提供saas服务的底层软件和基础设施。通过利用由saas平台提供的服务，客户可以利用在云基础设施系统上执行的应用。客户可以获取应用服务，而无需客户购买单独的许可和支持。可以提供各种不同的saas服务。示例包括但不限于为大型组织提供销售业绩管理、企业集成和业务灵活性的解决方案的服务。
在一些实施例中，平台服务可以由云基础设施系统经由paas平台提供。paas平台可以被配置为提供落入paas类别的云服务。平台服务的示例可以包括但不限于使组织(诸如oracle)能够在共享的公共体系架构上整合现有应用以及充分利用平台提供的共享服务来构建新应用的能力的服务。paas平台可以管理和控制用于提供paas服务的底层软件和基础设施。客户可以获取由云基础架构系统提供的paas服务，而无需客户购买单独的许可和支持。平台服务的示例包括但不限于oraclejava云服务(jcs)、oracle数据库云服务(dbcs)等。
通过利用由paas平台提供的服务，客户可以采用由云基础设施系统支持的编程语言和工具，并且还可以控制所部署的服务。在一些实施例中，由云基础设施系统提供的平台服务可以包括数据库云服务、中间件云服务(例如，oracle融合中间件服务)和java云服务。在一个实施例中，数据库云服务可以支持共享服务部署模型，该模型使得组织能够汇集数据库资源并且以数据库云的形式向客户供应数据库即服务。在云基础设施系统中，中间件云服务可以为客户提供开发和部署各种业务应用的平台，并且java云服务可以为客户提供部署java应用的平台。
各种不同的基础设施服务可以由云基础设施系统中的iaas平台提供。基础设施服务促进底层计算资源(诸如存储装置、网络和其它基础计算资源)的管理和控制，以供客户利用由saas平台和paas平台提供的服务。
在某些实施例中，云基础设施系统3102还可以包括基础设施资源3130，用于向云基础设施系统的客户提供用于提供各种服务的资源。在一个实施例中，基础设施资源3130可以包括预先集成和优化的硬件(诸如服务器、存储装置和联网资源)的组合，以执行由paas平台和saas平台提供的服务。
在一些实施例中，云基础设施系统3102中的资源可以由多个用户共享并且根据需要动态重新分配。此外，可以将资源分配给在不同时区的用户。例如，云基础设施系统3130可以使在第一时区中的第一组用户能够在指定的小时数内利用云基础设施系统的资源，并且然后使相同资源能够被重新分配给位于不同时区的另一组用户，从而使资源的利用率最大化。
在某些实施例中，可以提供由云基础设施系统3102的不同部件或模块以及由云基础设施系统3102提供的服务共享的多个内部共享服务3132。这些内部共享服务可以包括但不限于：安全和身份服务、集成服务、企业储存库服务、企业管理器服务、病毒扫描和白名单服务、高可用性、备份和恢复服务、启用云支持的服务、电子邮件服务、通知服务、文件传输服务等。
在某些实施例中，云基础设施系统3102可以提供云基础设施系统中的云服务(例如，saas、paas和iaas服务)的综合管理。在一个实施例中，云管理功能可以包括用于供应、管理和跟踪由云基础设施系统3102接收到的客户订阅等的能力。
在一个实施例中，如图中所绘出的，云管理功能可以由一个或多个模块提供，诸如订单管理模块3120、订单编排模块3122、订单供应模块3124、订单管理和监视模块3126，以及身份管理模块3128。这些模块可以包括一个或多个计算机和/或服务器或者使用一个或多个计算机和/或服务器来提供，该一个或多个计算机和/或服务器可以是通用计算机、专用服务器计算机、服务器场、服务器集群或任何其它适当的布置和/或组合。
在示例性操作3134中，使用客户端设备(诸如客户端设备3104、3106或3108)的客户可以通过请求由云基础设施系统3102提供的一个或多个服务并且对由云基础设施系统3102供应的一个或多个服务下订阅订单来与云基础设施系统3102交互。在某些实施例中，客户可以访问云用户界面(ui)(云ui3112、云ui3114和/或云ui3116)并经由这些ui下订阅订单。云基础设施系统3102响应于客户下订单而接收到的订单信息可以包括识别客户以及客户想要订阅的云基础设施系统3102供应的一个或多个服务的信息。
在客户下订单之后，经由云ui3112、3114和/或3116接收订单信息。
在操作3136处，订单存储在订单数据库3118中。订单数据库3118可以是由云基础设施系统3118操作和与其它系统元件一起操作的若干数据库之一。
在操作3138处，订单信息被转发到订单管理模块3120。在一些情况下，订单管理模块3120可以被配置为执行与订单相关的计费和记账功能，诸如验证订单、以及在验证后预订订单。
在操作3140处，将关于订单的信息传送到订单编排模块3122。订单编排模块3122可以利用订单信息为客户下的订单编排服务和资源的供应。在一些情况下，订单编排模块3122可以使用订单供应模块3124的服务来编排资源的供应以支持所订阅的服务。
在某些实施例中，订单编排模块3122使得能够管理与每个订单相关联的业务过程并应用业务逻辑来确定订单是否应该继续供应。在操作3142处，在接收到新订阅的订单时，订单编排模块3122向订单供应模块3124发送分配资源并配置履行订阅订单所需的那些资源的请求。订单供应模块3124使得能够为客户订购的服务分配资源。订单供应模块3124提供在由云基础设施系统3100提供的云服务和用于供应用于提供所请求的服务的资源的物理实现层之间的抽象层。因此，订单编排模块3122可以与实现细节(诸如服务和资源是实际上即时供应还是预先供应并仅在请求后才分配/指派)隔离。
在操作3144处，一旦供应了服务和资源，就可以通过云基础设施系统3102的订单供应模块3124向客户端设备3104、3106和/或3108上的客户发送所提供的服务的通知。
在操作3146处，订单管理和监视模块3126可以管理和跟踪客户的订阅订单。在一些情况下，订单管理和监视模块3126可以被配置为收集订阅订单中的服务的使用统计信息，诸如，所使用的存储量、传输的数据量、用户的数量以及系统运行时间量和系统停机时间量。
在某些实施例中，云基础设施系统3100可以包括身份管理模块3128。身份管理模块3128可以被配置为提供身份服务，诸如云基础设施系统3100中的访问管理和授权服务。在一些实施例中，身份管理模块3128可以控制关于希望利用由云基础设施系统3102提供的服务的客户的信息。这样的信息可以包括认证这些客户的身份的信息以及描述这些客户被授权相对于各种系统资源(例如，文件、目录、应用、通信端口、存储器段等)执行哪些动作的信息。身份管理模块3128还可以包括对关于每个客户的描述性信息以及关于可以如何和由谁来访问和修改该描述性信息的管理。
图32示出了其中可以实现本发明的各种实施例的示例性计算机系统3200。系统3200可以用于实现上述任何计算机系统。如图所示，计算机系统3200包括经由总线子系统3202与多个外围子系统通信的处理单元3204。这些外围子系统可以包括处理加速单元3206、i/o子系统3208、存储子系统3218和通信子系统3224。存储子系统3218包括有形计算机可读存储介质3222和系统存储器3210。
总线子系统3202提供用于让计算机系统3200的各种部件和子系统按意图彼此通信的机制。虽然总线子系统3202被示意性地示出为单条总线，但是总线子系统的替代实施例可以利用多条总线。总线子系统3202可以是使用各种总线体系架构中的任何总线体系架构的若干种类型的总线结构中的任何一种，包括存储器总线或存储器控制器、外围总线、以及局部总线。例如，这种体系架构可以包括工业标准体系架构(isa)总线、微通道体系架构(mca)总线、增强型isa(eisa)总线、视频电子标准协会(vesa)局部总线和外围部件互连(pci)总线，其可以被实现为按ieeep1386.1标准制造的mezzanine总线。
可以被实现为一个或多个集成电路(例如，常规微处理器或微控制器)的处理单元3204控制计算机系统3200的操作。一个或多个处理器可以被包括在处理单元3204中。这些处理器可以包括单核或多核处理器。在某些实施例中，处理单元3204可以被实现为一个或多个独立的处理单元3232和/或3234，其中在每个处理单元中包括单核或多核处理器。在其它实施例中，处理单元3204还可以被实现为通过将两个双核处理器集成到单个芯片中形成的四核处理单元。
在各种实施例中，处理单元3204可以响应于程序代码执行各种程序并且可以维护多个并发执行的程序或进程。在任何给定的时间，要被执行的程序代码中的一些或全部代码可以驻留在(一个或多个)处理器3204中和/或存储子系统3218中。通过适当的编程，(一个或多个)处理器3204可以提供上述各种功能。计算机系统3200可以附加地包括处理加速单元3206，其可以包括数字信号处理器(dsp)、专用处理器，等等。
i/o子系统3208可以包括用户接口输入设备和用户接口输出设备。用户接口输入设备可以包括键盘、诸如鼠标或轨迹球之类的定点设备、结合到显示器中的触摸板或触摸屏、滚动轮、点击轮、拨盘、按钮、开关、键盘、具有语音命令识别系统的音频输入设备、麦克风以及其它类型的输入设备。用户接口输入设备可以包括，例如，运动感测和/或姿势识别设备，诸如的microsoft
用户接口输入设备也可以包括但不限于三维(3d)鼠标、操纵杆或指向棒、游戏板和绘图板以及音频/视频设备，诸如扬声器、数码相机、数码摄像机、便携式媒体播放器、网络摄像头、图像扫描仪、指纹扫描仪、条形码阅读器3d扫描仪、3d打印机、激光测距仪和视线跟踪设备。此外，用户接口输入设备可以包括，例如，医学成像输入设备，诸如计算机断层扫描、磁共振成像、正电子发射断层摄影术、医疗超声设备。用户接口输入设备还可以包括，例如，诸如midi键盘、数字乐器等之类的音频输入设备。
用户接口输出设备可以包括显示子系统、指示灯，或者诸如音频输出设备之类的非可视显示器，等等。显示子系统可以是阴极射线管(crt)、诸如使用液晶显示器(lcd)或等离子显示器的平板设备、投影设备、触摸屏，等等。一般而言，术语“输出设备”的使用意在包括用于从计算机系统3200向用户或其它计算机输出信息的所有可能类型的设备和机制。例如，用户接口输出设备可以包括，但不限于，可视地传达文本、图形和音频/视频信息的各种显示设备，诸如监视器、打印机、扬声器、耳机、汽车导航系统、绘图仪、语音输出设备以及调制解调器。
计算机系统3200可以包括包含软件元件、被示为当前位于系统存储器3210中的存储子系统3218。系统存储器3210可以存储可加载并且可在处理单元3204上执行的程序指令，以及在这些程序的执行期间所产生的数据。
取决于计算机系统3200的配置和类型，系统存储器3210可以是易失性的(诸如随机存取存储器(ram))和/或非易失性的(诸如只读存储器(rom)、闪存存储器，等等)。ram通常包含可被处理单元3204立即访问和/或目前正被处理单元3204操作和执行的数据和/或程序模块。在一些实现中，系统存储器3210可以包括多种不同类型的存储器，例如静态随机存取存储器(sram)或动态随机存取存储器(dram)。在一些实现中，包含有助于诸如在启动期间在计算机系统3200的元件之间传送信息的基本例程的基本输入/输出系统(bios)通常可以被存储在rom中。作为示例，但不是限制，系统存储器3210也示出了可以包括客户端应用、web浏览器、中间层应用、关系数据库管理系统(rdbms)等的应用程序3212、程序数据3214以及操作系统3216。作为示例，操作系统3216可以包括各种版本的microsoft
存储子系统3218还可以提供用于存储提供一些实施例的功能的基本编程和数据结构的有形计算机可读存储介质。当被处理器执行时提供上述功能的软件(程序、代码模块、指令)可以被存储在存储子系统3218中。这些软件模块或指令可以被处理单元3204执行。存储子系统3218还可以提供用于存储根据本发明被使用的数据的储存库。
存储子系统3200还可以包括可以被进一步连接到计算机可读存储介质3222的计算机可读存储介质读取器3220。通过与系统存储器3210一起并且，可选地与系统存储器3210相结合，计算机可读存储介质3222可以全面地表示用于临时和/或更持久地包含、存储、发送和检索计算机可读信息的远程、本地、固定和/或可移除存储设备加存储介质。
包含代码或代码的部分的计算机可读存储介质3222还可以包括本领域已知或使用的任何适当的介质，包括存储介质和通信介质，诸如但不限于，以用于信息的存储和/或传输的任何方法或技术实现的易失性和非易失性、可移除和不可移除介质。这可以包括有形的计算机可读存储介质，诸如ram、rom、电可擦除可编程rom(eeprom)、闪存存储器或其它存储器技术、cd-rom、数字多功能盘(dvd)或其它光学存储装置、磁带盒、磁带、磁盘存储装置或其它磁存储设备、或者其它有形的计算机可读介质。这还可以包括非有形的计算机可读介质，诸如数据信号、数据传输，或者可以被用来发送期望信息并且可以被计算系统3200访问的任何其它介质。
作为示例，计算机可读存储介质3222可以包括从不可移除的非易失性磁介质读取或对不可移除的非易失性磁介质写入的硬盘驱动器、从可移除的非易失性磁盘读取或对可移除的非易失性磁盘写入的磁盘驱动器、以及从可移除的非易失性光盘(诸如cdrom、dvd和blu-
通信子系统3224提供到其它计算机系统和网络的接口。通信子系统3224用作用于从其它系统接收数据和从计算机系统3200向其它系统发送数据的接口。例如，通信子系统3224可以使计算机系统3200能够经由互联网连接到一个或多个设备。在一些实施例中，通信子系统3224可以包括用于(例如，使用蜂窝电话技术、诸如3g、4g或edge(用于全球演进的增强型数据速率)之类的先进数据网络技术、wifi(ieee802.11系列标准)、或其它移动通信技术、或其任意组合))访问无线语音和/或数据网络的射频(rf)收发器部件、全球定位系统(gps)接收器部件和/或其它部件。在一些实施例中，作为无线接口的附加或者替代，通信子系统3224可以提供有线网络连接(例如，以太网)。
在一些实施例中，通信子系统3224还可以代表可以使用计算机系统3200的一个或多个用户接收结构化和/或非结构化数据馈送3226、事件流3228、事件更新3230等形式的输入通信。
作为示例，通信子系统3224可被配置为实时地从社交网络的用户和/或其它通信服务接收数据馈送3226，诸如
此外，通信子系统3224还可被配置为接收连续数据流形式的数据，这可以包括本质上可以是连续的或无界的没有明确终止的实时事件的事件流3228和/或事件更新3230。产生连续数据的应用的示例可以包括，例如，传感器数据应用、金融报价机、网络性能测量工具(例如，网络监视和业务管理应用)、点击流分析工具、汽车交通监视，等等。
通信子系统3224还可被配置为向一个或多个数据库输出结构化和/或非结构化的数据馈送3226、事件流3228、事件更新3230，等等，这一个或多个数据库可以与耦合到计算机系统3200的一个或多个流式数据源计算机通信。
计算机系统3200可以是各种类型之一，包括手持便携式设备(例如，
由于计算机和网络的不断变化的本质，在图中绘出的计算机系统3200的描述仅仅作为具体的示例。具有比图中绘出的系统更多或更少部件的许多其它配置是可能的。例如，定制的硬件也可以被使用和/或特定的元素可以用硬件、固件、软件(包括小程序)或其组合来实现。另外，也可以采用到诸如网络输入/输出设备之类的其它计算设备的连接。基于本文提供的公开内容和教导，本领域普通技术人员将认识到实现各种实施例的其它方式和/或方法。
在前面的描述中，出于解释的目的，阐述了许多具体细节以便提供对本发明的各种实施例的透彻理解。然而，对于本领域技术人员清楚的是，可以在没有这些具体细节中的一些的情况下实践本发明的实施例。在其它情况下，以框图形式示出了众所周知的结构和设备。
以上描述仅提供示例性实施例，并且不旨在限制本公开的范围、适用性或配置。更确切地说，示例性实施例的前述描述将为本领域技术人员提供用于实现示例性实施例的使能描述。应当理解的是，在不脱离所附权利要求中阐述的本发明的精神和范围的情况下，可以对元件的功能和布置进行各种改变。
在前面的描述中给出了具体细节以提供对实施例的透彻理解。然而，本领域普通技术人员将理解的是，可以在没有这些具体细节的情况下实践这些实施例。例如，电路、系统、网络、过程和其它部件可能已经以框图形式示出为部件，以免用不必要的细节模糊实施例。在其它情况下，可能已经示出了众所周知的电路、过程、算法、结构和技术而没有不必要的细节，以避免模糊实施例。
而且，要注意的是，各个实施例可能已被描述为过程，该过程被描绘为流程图、流程示意图、结构图或框图。虽然流程图可能已将操作描述为顺序过程，但许多操作可以并行或同时执行。此外，可以重新布置操作的次序。过程在其操作完成时终止，但可以有未包含在图中的附加步骤。过程可以与方法、函数、程序、子例程、子程序等对应。当过程与函数对应时，其终止可以与函数返回到调用函数或主函数对应。
术语“计算机可读介质”包括但不限于便携式或固定存储设备、光学存储设备、无线信道以及能够存储、包含或携带(一个或多个)指令和/或数据的各种其它介质。代码段或机器可执行指令可以表示过程、函数、子程序、程序、例程、子例程、模块、软件包、类或指令、数据结构或程序语句的任何组合。代码段可以通过传递和/或接收信息、数据、自变量、参数或存储器内容而耦合到另一个代码段或硬件电路。信息、自变量、参数、数据等可以经由任何合适的手段传递、转发或发送，这些手段包括存储器共享、消息传递、令牌传递、网络传输等。
此外，实施例可以通过硬件、软件、固件、中间件、微代码、硬件描述语言或其任何组合来实现。当在软件、固件、中间件或微代码中实现时，用于执行必要任务的程序代码或代码段可以存储在机器可读介质中。(一个或多个)处理器可以执行必要的任务。
在前述说明书中，参考其具体实施例对本发明的各方面进行了描述，但是本领域技术人员将认识到的是，本发明不限于此。上述公开的各个特征和方面可以被单独使用或联合使用。另外，在不脱离本说明书的更广泛精神和范围的情况下，实施例可以在除本文所述的环境和应用之外的任何数目的环境和应用中被使用。相应地，本说明书和附图应当被认为是说明性的而不是限制性的。
此外，出于说明的目的，以特定顺序描述了方法。应该认识到的是，在替代实施例中，可以以与所描述的顺序不同的顺序执行方法。还应该认识到的是，上述方法可以由硬件部件执行，或者可以以机器可执行指令的序列被实施，机器可执行指令可以用于使机器(诸如编程有指令的通用或专用处理器或逻辑电路)执行方法。这些机器可执行指令可以被存储在一个或多个机器可读介质上，诸如cd-rom或其它类型的光盘、软盘、rom、ram、eprom、eeprom、磁卡或光卡、闪存、或适合于存储电子指令的其它类型的机器可读介质。替代地，可以通过硬件和软件的组合来执行方法。
1.一种为容器环境中的容器化的服务提供运行时调试的方法，所述方法包括：
接收对在容器环境处的服务的请求，其中：
所述容器环境包括服务网格和封装在多个容器中的多个服务；以及
所述服务被封装在第一一个或多个容器中；
确定所述请求应当被路由到所述服务的调试实例；
实例化所述服务的所述调试实例，其中所述调试实例被封装在第二一个或多个容器中并且包括：
实现所述服务的代码；以及
一个或多个调试实用程序；
通过所述服务网格将所述请求路由到所述调试实例。
2.如权利要求1所述的方法，其中所述第一一个或多个容器被组织成容器舱。
3.如权利要求1所述的方法，其中所述容器环境包括编排的容器平台，所述编排的容器平台包括容器调度器。
4.如权利要求3所述的方法，其中所述容器调度器使所述服务的所述调试实例被实例化。
5.如权利要求1所述的方法，其中所述容器环境包括使得所述服务的所述调试实例被实例化的应用编程接口api注册器。
6.如权利要求5所述的方法，其中所述api注册器接收针对所述服务的所述调试实例的注册，并通过api函数调用使所述服务的所述调试实例的http端点可用。
7.如权利要求5所述的方法，其中所述api注册器接收针对所述服务的注册，所述注册包括指示应当实例化所述服务的调试实例的特性。
8.一种包括指令的非暂态计算机可读介质，所述指令在由一个或多个处理器执行时使所述一个或多个处理器执行操作，所述操作包括：
接收对在容器环境处的服务的请求，其中：
所述容器环境包括服务网格和封装在多个容器中的多个服务；以及
所述服务被封装在第一一个或多个容器中；
确定所述请求应当被路由到所述服务的调试实例；
实例化所述服务的所述调试实例，其中所述调试实例被封装在第二一个或多个容器中并且包括：
实现所述服务的代码；以及
一个或多个调试实用程序；
通过所述服务网格将所述请求路由到所述调试实例。
9.如权利要求8所述的非暂态计算机可读介质，其中所述服务被封装在单个容器中。
10.如权利要求9所述的非暂态计算机可读介质，其中所述单个容器还包括所述一个或多个调试实用程序。
11.如权利要求9所述的非暂态计算机可读介质，其中所述一个或多个调试实用程序被封装在除了所述单个容器之外的至少一个容器中。
12.如权利要求9所述的非暂态计算机可读介质，其中所述一个或多个调试实用程序包括用于监视存储器使用情况或处理器使用情况的进程。
13.如权利要求9所述的非暂态计算机可读介质，其中所述一个或多个调试实用程序包括调试守护进程。
14.如权利要求9所述的非暂态计算机可读介质，其中实现所述服务的代码包括所述服务的所述调试版本。
15.一种系统，包括：
一个或多个处理器；以及
包括指令的一个或多个存储器设备，所述指令在由所述一个或多个处理器执行时使所述一个或多个处理器执行操作，所述操作包括：
接收对在容器环境处的服务的请求，其中：
所述容器环境包括服务网格和封装在多个容器中的多个服务；以及
所述服务被封装在第一一个或多个容器中；
确定所述请求应当被路由到所述服务的调试实例；
实例化所述服务的所述调试实例，其中所述调试实例被封装在第二一个或多个容器中并且包括：
实现所述服务的代码；以及
一个或多个调试实用程序；
通过所述服务网格将所述请求路由到所述调试实例。
16.如权利要求15所述的系统，其中所述服务的所述调试实例在接收所述请求之前被实例化。
17.如权利要求15所述的系统，其中所述服务的所述调试实例响应于接收到所述请求而被实例化。
18.如权利要求15所述的系统，其中确定所述请求应当被路由到所述服务的所述调试实例包括识别所述请求的源。
19.如权利要求15所述的系统，其中确定所述请求应当被路由到所述服务的所述调试实例包括识别所述请求中将所述请求指定为调试请求的报头。
20.如权利要求15所述的系统，其中，所述请求被转发到所述服务的所述调试实例，而不中断其它请求到所述服务的路由。
技术总结