CN110109649B - 针对Web服务的容器控制方法、装置和容器系统 - Google Patents

针对Web服务的容器控制方法、装置和容器系统 Download PDF

Info

Publication number
CN110109649B
CN110109649B CN201810099857.1A CN201810099857A CN110109649B CN 110109649 B CN110109649 B CN 110109649B CN 201810099857 A CN201810099857 A CN 201810099857A CN 110109649 B CN110109649 B CN 110109649B
Authority
CN
China
Prior art keywords
container
service
class library
candidate
base
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810099857.1A
Other languages
English (en)
Other versions
CN110109649A (zh
Inventor
何震苇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Telecom Corp Ltd
Original Assignee
China Telecom Corp Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Telecom Corp Ltd filed Critical China Telecom Corp Ltd
Priority to CN201810099857.1A priority Critical patent/CN110109649B/zh
Publication of CN110109649A publication Critical patent/CN110109649A/zh
Application granted granted Critical
Publication of CN110109649B publication Critical patent/CN110109649B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design
    • G06F8/24—Object-oriented
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5048—Automatic or semi-automatic definitions, e.g. definition templates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Abstract

本公开提出一种针对Web服务的容器控制方法、装置和容器系统，涉及云计算技术领域。本公开的一种容器控制方法包括：接收容器申请请求；根据与容器申请请求的匹配度从容器池中选择候选容器，在候选容器的基础上构建服务容器，其中，容器池中包括类库容器、基础容器、休眠容器和基础容器镜像缓存。通过这样的方法，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的Web服务器的启动效率。

Description

针对Web服务的容器控制方法、装置和容器系统
技术领域
本公开涉及云计算技术领域，特别是一种针对Web服务的容器控制方法、装置和容器系统。
背景技术
Web(World Wide Web，全球广域网)通常运行在Web服务器上，对外提供基于HTTP的远程服务接口，接收和处理客户端发来的HTTP请求，向客户端返回HTTP应答，Web服务的HTTP请求通常是状态无关的，即不同的HTTP请求相互独立，互不影响。Web服务通常由Web服务组件、Web服务类库和运行Web服务的Web服务器构成，Web服务组件提供Web服务的核心业务处理逻辑，每个Web服务都拥有独立的Web服务组件，同时每个Web服务往往会依赖若干服务类库，这些类库封装了一些的共性服务功能单元或业务逻辑，如服务日志、服务监控、数据访问等，服务类库通常可供多个Web服务复用，Web服务器提供了Web服务的基础运行环境，并加载Web服务组件及其所依赖的类库，绑定Web服务端口和URL，将HTTP请求转发给Web服务组件处理。
在大型的Web应用或微服务(Micro Services)系统中，不同的Web服务可以由不同的开发团队使用不同的技术栈实现，这些技术栈往往是实现某种Web服务的最佳选择，常见的Web服务技术栈至少包括Java、NodeJS、PHP、Go，每种技术栈都有独立的打包格式、部署方式和运行机制，例如基于Java的Web服务通常打包成JAR或WAR，通过Tomcat、WebLogic等Web服务器部署运行，基于NodeJS的Web服务通常打包成NPM包，通过NPM(Node PackageManager)部署到NodeJS上运行，由于不同技术栈的打包部署方式不统一，给大型Web服务应用的部署和管理带来和很大挑战。
以Docker为代表的容器技术出现为Web服务提供了统一的服务打包、部署和运行机制，基于容器的部署运行Web服务已成为当前互联网业界的主流选择。以Docker为例，通过容器部署运行Web服务的过程通常是这样的：将Web服务组件、Web服务所依赖的类库和Web服务器打包成Docker镜像，将Docker镜像上传Docker镜像仓库，通过某种容器集群装置(如Swarm、Kubernetes)调度预装在主机上的Docker容器引擎从镜像仓库中将镜像下载到本地，基于本地的镜像文件运行Docker容器，通过容器镜像定义的命令启动Web服务器，通过Web服务器加载服务类库和服务组件，最后绑定容器内部的Web服务端口和对外的Web服务端口，从而完成整个Web服务的部署和启动。由于Docker镜像支持分层机制，上层镜像可以共享下层镜像的内容，每个镜像层只需在主机上下载一次，为了减少底层镜像的部署次数，业界通常将Web服务器和服务组件+服务类库作为不同的镜像层打包，从而达到多个Web服务镜像层共享相同的Web服务器镜像层，减少Web服务器镜像下载次数的目的。然而由于在Docker容器中，Web服务的Web服务器、服务类库、服务组件仍然是作为一个整体启动运行，每个Web服务容器的启动时间较长，大型的互联网应用往往需要快速加载数以万计的Web服务容器实例，现有技术批量加载大量Web服务容器实例的CPU资源开销很大，加载速度很慢，同时Web服务容器实例一旦启动之后往往驻留内存长期运行，大量运行的Web服务容器实例也占用了有限的内存资源。
发明内容
本公开的一个目的在于通过提高容器的构建速度来提高Web服务器的启动效率。
根据本公开的一个方面，提出一种针对Web服务的容器控制方法，包括：接收容器申请请求；根据与容器申请请求的匹配度从容器池中选择候选容器，在候选容器的基础上构建服务容器，其中，容器池中包括类库容器、基础容器、休眠容器和基础容器镜像缓存。
可选地，基础容器为加载了基础容器镜像的容器；类库容器为加载了基础容器镜像和公共类库的容器；服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；休眠容器为保存了基础容器的运行状态的基础容器快照；基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
可选地，根据与容器申请请求的匹配度从容器池中选择候选容器包括：确定基于容器池中的各个容器构建容器申请请求所需的服务容器的开销；选择加载开销最小的容器作为候选容器。
可选地，在候选容器的基础上构建服务容器包括：若候选容器为容器镜像缓存，则基于容器镜像缓存创建基础容器，并加载类库和服务组件；若候选容器为休眠容器，则通过基础容器快照恢复基础容器运行，并通过加载类库和服务组件；若候选容器为基础容器，则在基础容器的基础上根据容器申请请求加载类库和服务组件；若候选容器为类库容器，则在类库容器的基础上，根据容器申请请求执行：卸载容器申请请求不需要的类库、加载容器申请请求需要但候选容器中未加载的类库，和加载服务组件。
可选地，根据与容器申请请求的匹配度从容器池中选择候选容器包括：根据与容器申请请求的匹配度从类库容器中选择候选容器；若存在与容器申请请求的匹配度大于预定匹配度下限的类库容器，则选择匹配度最高的类库容器作为候选容器；若不存在与容器申请请求的匹配度大于预定匹配度下限的类库容器，则根据与容器申请请求的匹配度从基础容器、休眠容器或基础容器镜像缓存中选择候选容器。
可选地，根据与容器申请请求的匹配度从基础容器或休眠容器中选择候选容器包括：若存在与容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高和/或空闲时间最长的基础容器作为候选容器；若不存在与容器申请请求的匹配度大于预定匹配度下限的基础容器，则根据与容器申请请求的匹配度从基础容器、休眠容器或基础容器镜像缓存中选择候选容器。
可选地，还包括：记录服务容器、类库容器和基础容器上加载的内容和/或资源占用信息。
可选地，还包括：监控服务容器的访问频率；若服务容器的访问频率低于预定频率下限，则卸载服务容器的私有类库和服务组件，成为类库容器。
可选地，还包括：监控类库容器持续未被访问时长；若类库容器的持续未被访问时长高于第一预定时长上限，则卸载类库容器的公共类库，成为基础容器。
可选地，还包括：监控基础容器的未被访问时长；若基础容器的持续未被访问时长高于第二预定时长上限，则卸载基础容器上的基础容器镜像。
可选地，还包括：监控服务容器的资源占用率；若资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长，则减少为服务容器分配的资源；若资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长，则增加为服务容器分配的资源。
通过这样的方法，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的Web服务器的启动效率。
根据本公开的另一个方面，提出一种针对Web服务的容器控制装置，包括：请求接收模块，用于接收容器申请请求；服务容器构建模块，用于根据与容器申请请求的匹配度从容器池中选择候选容器，在候选容器的基础上构建服务容器，其中，容器池中包括类库容器、基础容器、休眠容器和基础容器镜像缓存。
可选地，基础容器为加载了基础容器镜像的容器；类库容器为加载了基础容器镜像和公共类库的容器；服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；休眠容器为持久化保存了基础容器的运行状态的基础容器快照；基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
可选地，服务容器构建模块包括候选容器确定单元，被配置为确定基于容器池中的各个容器构建容器申请请求所需的服务容器的开销；选择加载开销最小的容器作为候选容器。
可选地，服务容器构建模块包括加载单元，被配置为：若候选容器为容器镜像缓存，则基于容器镜像缓存创建基础容器，并加载类库和服务组件；若候选容器为休眠容器，则通过基础容器快照恢复基础容器运行，并通过加载类库和服务组件；若候选容器为基础容器，则在基础容器的基础上根据容器申请请求加载类库和服务组件；若候选容器为类库容器，则在类库容器的基础上，根据容器申请请求执行：卸载容器申请请求不需要的类库、加载容器申请请求需要但候选容器中未加载的类库，和加载服务组件。
可选地，服务容器构建模块包括候选容器确定单元，被配置为：根据与容器申请请求的匹配度从类库容器中选择候选容器；若存在与容器申请请求的匹配度大于预定匹配度下限的类库容器，则选择匹配度最高的类库容器作为候选容器；若不存在与容器申请请求的匹配度大于预定匹配度下限的类库容器，则根据与容器申请请求的匹配度从基础容器、休眠容器或基础容器镜像缓存中选择候选容器。
可选地，候选容器确定单元，还被配置为：若存在与容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高和/或空闲时间最长的基础容器作为候选容器；若不存在与容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高的休眠容器作为候选容器，或选择匹配的寄出容器镜像构建基础容器作为候选容器。
可选地，还包括：记录模块，被配置为记录服务容器、类库容器和基础容器上加载的内容和/或资源占用信息。
可选地，还包括卸载模块，被配置为：监控服务容器的访问频率；若服务容器的访问频率低于预定频率下限，则卸载服务容器的私有类库和服务组件，成为类库容器；监控类库容器持续未被访问时长；若类库容器的持续未被访问时长高于第一预定时长上限，则卸载类库容器的公共类库，成为基础容器；和/或，监控基础容器的未被访问时长；若基础容器的持续未被访问时长高于第二预定时长上限，则卸载基础容器上的基础容器镜像。
可选地，还包括：监控模块，被配置为监控服务容器的资源占用率；资源调度模块，被配置为若资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长，则减少为服务容器分配的资源；若资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长，则增加为服务容器分配的资源。
根据本公开的又一个方面，提出一种针对Web服务的容器控制装置，包括：存储器；以及耦接至存储器的处理器，处理器被配置为基于存储在存储器的指令执行上文中任意一种针对Web服务的容器控制方法。
这样的装置能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
根据本公开的再一个方面，提出一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现上文中任意一种方法的步骤。
通过执行这样的计算机可读存储介质上的指令，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
另外，根据本公开的一个方面，提出一种针对Web服务的容器系统，包括：上文中任意一种针对web服务的容器控制装置；和，容器池，被配置为管理容器和容器资源；数据仓库，被配置为存放基础容器镜像数据、类库数据和服务组件数据；容器引擎，被配置为根据容器控制装置的调度信息为容器配置基础容器镜像；组件代理模块，被配置为根据容器控制装置的调度信息为容器配置类库和服务组件。
可选地，还包括：服务路由，被配置为通过Web服务的前端服务端口与后端容器端口的映射关系将Web服务请求转发给对应的服务容器处理，当Web请求的应用前后端映射关系不存在时，通知针对Web服务的容器控制装置构建服务容器。
这样的系统在为Web服务提供支持的过程中，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
附图说明
此处所说明的附图用来提供对本公开的进一步理解，构成本公开的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：
图1为本公开的针对Web服务的容器控制方法的一个实施例的流程图。
图2为本公开的针对Web服务的容器控制方法的另一个实施例的流程图。
图3为本公开的针对Web服务的容器控制方法的又一个实施例的流程图。
图4为本公开的针对Web服务的容器控制装置的一个实施例的示意图。
图5为本公开的针对Web服务的容器控制装置的另一个实施例的示意图。
图6为本公开的针对Web服务的容器控制装置的又一个实施例的示意图。
图7为本公开的针对Web服务的容器系统的一个实施例的示意图。
图8为本公开的针对Web服务的容器系统的另一个实施例的示意图。
具体实施方式
下面通过附图和实施例，对本公开的技术方案做进一步的详细描述。
本公开的针对Web服务的容器控制方法的一个实施例的流程图如图1所示。
在步骤101中，接收容器申请请求。在一个实施例中，当收到Web服务请求后，可以先查找可用的服务容器。当现有的服务容器已无法承载新的Web服务请求后，发起容器申请请求。在一个实施例中，容器申请请求由服务路由生成并发送，容器申请请求可以包括Web服务标识和Web服务容器数，前者唯一确定一个Web服务，后者描述需要加载的Web服务容器数目。
在步骤102中，根据与容器申请请求的匹配度从容器池中选择候选容器，在候选容器的基础上构建服务容器。容器池中可以包括类库容器、基础容器、休眠容器和基础容器镜像缓存。在一个实施例中，基础容器为加载了基础容器镜像的容器；类库容器为加载了基础容器镜像和公共类库的容器；服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；休眠容器为保存了基础容器的运行状态的基础容器快照；基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
通过这样的方法，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
在一个实施例中，在基于类库容器构建服务容器时，可以先卸载类库容器中已下载但当前容器申请请求不需要的类库、加载类库容器中未下载但当前容器申请请求需要的类库，进而加载当前容器申请请求需要的服务组件，从而得到满足容器申请请求的容器。由于对于小型Web应用，其基础软件和公共类库的大小往往占了整个Web应用的80％以上，整个应用的启动时间大部分都花在基础软件启动和类库加载上，基础软件和公共类库对小型Web应用的镜像构建、镜像传输和应用启动过程带来了很多额外的开销。上述实施例中的方法无需进行镜像的加载，且能够减少部分类库的加载过程，特备是当匹配度比较高的情况下，能够大大提高服务容器的构建效率。
在一个实施例中，在基于基础容器构建服务容器时，首先应该保证基础容器中加载的基础容器镜像与容器申请请求相同，进而加载所需的私有类库、公共类库和服务组件。这一过程无需进行基础容器镜像的加载，从而提高了服务容器的构建效率。
在一个实施例中，在基于休眠容器构建服务容器时，首先通过基础容器快照恢复基础容器运行，进而在基础容器基础上加载类库和服务组件。通过这样的方法，能够将一部分容器已休眠状态存在，一方面减少了对设备运行资源，如内存和CPU的使用，另一方面基于快照回复基础容器的过程费时较小，能够起到一定的提高服务容器的构建效率的作用。
在一个实施例中，在基于基础容器镜像缓存构建服务容器时，基于容器镜像缓存创建基础容器，并加载类库和服务组件。基于已缓存的基础容器镜像构建服务容器的方法无需进行镜像的下载、解压，能够起到一定的提高服务容器的构建效率的作用；另外，保证了在其他容器与需求匹配度交底的情况下服务容器能够成功建立，提高了系统的可靠性。
在一个实施例中，从容器池中选择容器首要标准为基础容器镜像匹配，即包括种类和版本完全一致，在基础容器镜像相同的情况下，选择类库加载和卸载开销最小的容器作为候选容器。
把一个池化容器(类库容器或基础容器)变成一个服务容器包含以下步骤：
1、(如果有的话)卸载应用不需要的类库；
2、加载应用需要且该容器尚未加载的类库；
3、加载服务组件包及其私有类库；
4、更新容器状态和服务路由规则。
对于所有的池化容器而言，步骤3和步骤4的开销是固定的，而步骤1、2的开销是非固定的，因此选择容器的标准是选择卸载旧类库和加载新类库的开销最小的容器。类库加载和卸载的开销可以用CPU时间周期数来衡量，由于不同的类库的大小、类数目不同，不同Web服务器的类库加载和卸载机制也不同，所以不同类库的加载和卸载开销是不同的。类库的加载负载和卸载负载可以在该类库首次上传到类库仓库时测量，测量方法可以为通过一个使用单个CPU核的没有加载任何其他类库的基础软件容器中进行指定类库的加载、卸载开销测量。
假设单核基础软件容器的单位时间背景开销为CB，指定类库加载前的时刻为T0，容器CPU周期计数为C0，指定类库加载后的时刻为T1，容器CPU周期计数为C1，指定类库卸载后的时刻为T2，容器CPU周期计数为C2，那么该类库的加载开销LC为(C1-C0)-CB*(T1-T0),该类库的卸载开销UC为(C2-C1)-CB*(T2-T1)。
通常每个类库只能运行在一种基础软件上，例如JAR(Java Archive，Java归档文件)只能运行在基于JAVA的Web服务器上，NPM只能运行在NodeJS服务器上，一般情况下，同类基础软件使用相同的机制加载和卸载类库，因此同类基础软件加载和卸载同一个类库的开销是相同的，例如Tomcat、JBoss、Weblogic等JavaWeb服务器加载和卸载同一个JAR类库的开销可以认为是相同的，同时一个JAR类库在同一个基础软件的不同版本，如Tomcat6、Tomcat7和Tomcat8上的加载和卸载开销也可以认为是相同的。
从容器池中选择合适容器的原则是选择加载新类库开销与卸载旧类库开销之和最小的容器，举例如下：
假设有4个类库CL1、CL2、CL3、CL4，加载和卸载开销如下表所示：
表1类库加载开销示例
假设目标服务容器所需的类库为CL3、CL4，服务组件为SL1，通过容器池加载目标服务容器的开销如下表所示：
表2开销计算
其中C0为主机未下载的基础容器镜像，通过C0加载目标容器的开销包括基础镜像下载、基础容器初始化、Web服务器启动、服务类库加载、服务组件加载，其总开销为2900；C1为主机的基础容器镜像缓存，通过C1加载目标容器的开销包括基础容器初始化、Web服务器启动、服务类库加载、服务组件加载，其总开销为1900；C2为休眠容器，通过C2加载目标容器的开销包括Web服务器启动、服务类库加载、服务组件加载，其总开销为1700；C3为基础容器，通过C3加载目标容器的开销包括服务类库加载、服务组件加载，其总开销为700；C4为类库容器，通过C4加载目标容器的开销包括服务类库卸载、服务类库加载、服务组件加载，其总开销为1300；依次类推,类库容器C5、C6、C7的总开销分别为800、1000、600；服务容器C8由于不需要额外的加载和卸载，其开销为0。从上表可以看出，除了服务容器之外，开销最小的容器既有可能是类库容器，也有可能是基础容器，在极端情况下甚至还有可能是休眠容器。因此，在一个实施例中，可以不考虑候选容器的类型，采用开销最小的方式构建服务容器。
类库容器和基础容器都是容器池中已经加载到内存中运行的容器，选择容器的依据是类库加载和卸载的总开销最小的容器，类库容器、基础容器甚至休眠容器(未加载基础容器镜像)都可能成为开销最小的候选容器。
当主机首次部署某个基础软件时，需要通过主机上的容器引擎从镜像仓库下载基础软件镜像，以后每次通过基础软件镜像启动只需要从读取本地缓存的基础软件镜像文件启动。
在一个实施例中，可以如图2所示：
在步骤201中，接收容器申请请求。
在步骤202中，确定基于容器池中的各个容器构建容器申请请求所需的服务容器的开销。在一个实施例中，可以通过上文中所述的开销计算过程计算加载、卸载的开销。在一个实施例中，不同类库、镜像加载、卸载的开销不同，可以在系统中预存对应的开销以便计算。
在步骤203中，选择加载开销最小的容器作为候选容器。在一个实施例中，当从容器池中筛选处了多个匹配度相同的容器时，若这些容器位于相同主机，则可以随机选择候选容器，若这些容器位于不同主机，则优先选择负载最低的主机上的容器作为候选容器。
在步骤204中，在候选容器的基础上构建服务容器。在一个实施例中，可以根据候选容器种类、情况的不同采用上文中所述的方法完成服务容器的构建。
通过这样的方法，能够灵活的计算构建容器的开销，从而选择最适合的类库容器、基础容器或资源进行服务容器的构建，进一步提高了服务容器构建的效率。
本公开的针对Web服务的容器控制方法的又一个实施例的流程图如图3所示。
在步骤301中，接收容器申请请求。
在步骤302中，根据与容器申请请求的匹配度从类库容器中选择候选容器。在一个实施例中，可以选择类库、基础容器镜像与容器申请请求相似度高的容器，或者还可以考虑到容器的资源占用量与目标容器的相似程度。在一个实施例中，考虑到在不同容器的基础上构建完全符合容器申请请求的容器的开销不同，可以选择开销最小的容器或资源作为候选容器以提高容器创建效率。
在步骤303中，判断是否存在与容器申请请求的匹配度大于预定匹配度下限的类库容器。在一个实施例中，匹配度可以用类库相同比例来表示，或者可以用在当前容器基础上构建目标服务容器的开销大小来表示。若存在与容器申请请求的匹配度大于预定匹配度下限的类库容器，则执行步骤304；否则执行步骤305。
在步骤304中，选择匹配度最高的类库容器作为候选容器。
在步骤305中，判断是否存在与容器申请请求的匹配度大于预定匹配度下限的基础容器。基础容器与容器申请请求的匹配度除了考虑基础容器镜像是否相同，还可以考虑容器的资源占用量与目标容器的相似程度。若存在与容器申请请求的匹配度大于预定匹配度下限的基础容器，则执行步骤306；否则执行步骤307。
在步骤306中，选择匹配度最高和/或空闲时间最长的基础容器作为候选容器。由于空闲时长最长的基础容器距离被卸载基础容器镜像的时间最短，因此选择空闲时间最长的容器作为候选容器能够避免基础容器镜像的加载和卸载，减少系统的运算操作。
在步骤307中，判断是否存在与容器申请请求的匹配度大于预定匹配度下限的休眠容器。若存在，则执行步骤308；若不存在，则执行步骤309。
在步骤308中，将休眠容器作为候选容器。
在步骤309中，将容器镜像缓存作为候选容器。
在步骤310中，根据候选容器的具体情况，在候选容器的基础上构建服务容器。具体构建方式可以如上文实施例中所示。
通过这样的方法，能够以匹配度作为考虑因素进行服务容器的构建。由于基础容器镜像和公共类库的加载耗时较长、开销较大，优先选择已加载了部分公共类库的类库容器的方法能够降低服务容器构建的开销，提高容器构建效率。
在一个实施例中，如图3所示本公开的容器控制方法还可以包括：
在步骤311中，记录服务容器、类库容器、基础容器和休眠容器上加载的信息和/或资源占用信息。
通过这样的方法，能够实现对每个容器的监控，方便对容器的使用状况做出及时反应，提高系统的自适应能力。
在一个实施例中，还可以监控服务容器的访问频率、持续未被访问时长，判断服务容器的访问频率是否低于预定频率下限，或持续未被访问时长是否高于预定服务容器的预定时长上线。若访问频率低于预定频率下限或长时间未被访问，则卸载服务容器的私有类库和应用，成为类库容器。
在一个实施例中，还可以监控对类库容器的访问调用，判断类库容器的持续未被访问时长是否高于第一预定时长上限。若高于第一预定时长上限，则卸载类库容器的公共类库，成为基础容器。
在一个实施例中，可以监控对基础容器的访问调用，判断基础容器的持续未被访问时长是否高于第二预定时长上限。若高于第二预定时长上限，则卸载基础容器上加载的基础容器镜像，存储基础容器快照，以休眠容器状态存储，不占用内存、CPU等运行资源。
在一个实施例中，当休眠容器长时间未被调用，可删除该快照，以释放部分存储资源。
在一个实施例中，当镜像缓存的缓存时间超过预定时长时，还可以删除该镜像缓存以释放部分存储空间。
通过这样的方法，能够使经常使用的服务容器保持其服务容器的状态，降低Web服务等待时间；保证一定的基础容器、类库容器的运行量，降低容器配置加载和Web服务的等待时间；释放资源以减少对CPU和内存等运行资源的占用量，提高运行资源的利用率；释放部分存储资源以维护系统环境的稳定。
在一个实施例中，服务容器可以报告自身的负载变化情况，报告的方式可以是单条报告(每处理1条报告1次)、周期性报告(每隔n秒报告1次)或批量性(每处理n条请求报告1次)，当服务容器处理完最后一条请求后，如果服务容器在m秒内没有接收到新的请求(m为正数)，则通知本地的容器资源管理器卸载容器中的应用软件包，并向服务路由(或元数据库)报告服务容器卸载事件，卸载的应用软件的容器作为类库容器放到类库容器资源池中。其中m至少要大于完整服务容器的平均加载时间。
在一个实施例中，还可以实时监控服务容器的资源占用率；若资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长，则说明该服务容器对资源的占用需求较小，可以减少为服务容器分配的资源；若资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长，则说明当前服务容器的资源紧缺，可以增加为服务容器分配的资源。
通过这样的方法，能够根据需要动态为服务容器配置资源，从而实现服务容器占用资源的弹性化配置，提高服务容器运行的效率和可靠性，也能够提高系统资源的利用率。
本公开的容器控制装置的一个实施例的示意图如图4所示。请求接收模块401能够接收容器申请请求。服务容器构建模块402能够根据与容器申请请求的匹配度从容器池中选择候选容器，在候选容器的基础上构建服务容器。容器池中可以包括类库容器、基础容器、休眠容器和基础容器镜像缓存。在一个实施例中，基础容器为加载了基础容器镜像的容器；类库容器为加载了基础容器镜像和公共类库的容器；服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；休眠容器为保存了基础容器的运行状态的基础容器快照；基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
这样的装置能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
在一个实施例中，在基于类库容器构建服务容器时，服务容器构建模块402可以先卸载类库容器中已下载但当前容器申请请求不需要的类库、加载类库容器中未下载但当前容器申请请求需要的类库，进而加载当前容器申请请求需要的服务组件，从而得到满足容器申请请求的容器。
在一个实施例中，在基于基础容器构建服务容器时，服务容器构建模块402在保证基础容器中加载的基础容器镜像与容器申请请求相同的基础上，加载所需的私有类库、公共类库和服务组件。这一过程无需进行基础容器镜像的加载，从而提高了服务容器的构建效率。
在一个实施例中，在基于休眠容器构建服务容器时，服务容器构建模块402首先通过基础容器快照恢复基础容器运行，进而在基础容器基础上加载类库和服务组件。
在一个实施例中，在基于基础容器镜像缓存构建服务容器时，服务容器构建模块402基于容器镜像缓存创建基础容器，并加载类库和服务组件。
在一个实施例中，服务容器构建模块402从容器池中选择容器首要标准为基础容器镜像匹配，即包括种类和版本完全一致，在基础容器镜像相同的情况下，选择类库加载和卸载开销最小的容器作为候选容器。
通过这样的方法，能够根据选择的容器不同实现服务容器的构建，提高系统的可用性。
在一个实施例中，服务容器构建模块402可以先计算服务容器构建开销，从容器池中选择开销最小的作为候选容器，或者采用上文中如图3所述的实施例执行候选容器的选择和构建，从而进一步提高Web服务效率。
在一个实施例中，针对Web的容器控制装置还可以包括记录模块403，能够记录服务容器、类库容器、基础容器和休眠容器上加载的信息和/或资源占用信息，从而方便实现对每个容器的监控，方便对容器的使用状况做出及时反应，提高系统的自适应能力
在一个实施例中，针对Web的容器控制装置还可以包括卸载模块404，包括监控服务容器的访问频率，当访问频率低于预定频率下限时卸载服务容器的私有类库和应用，成为类库容器；监控对类库容器的访问调用，当类库容器的持续未被访问时长高于第一预定时长上限时，卸载类库容器的公共类库，成为基础容器；监控对基础容器的访问调用，当基础容器的持续未被访问时长高于第二预定时长上限时，卸载基础容器上加载的基础容器镜像，存储基础容器快照，以休眠容器状态存储，不占用内存、CPU等运行资源；当休眠容器长时间未被调用，删除该快照，以释放部分存储资源。
这样的装置能够使经常使用的服务容器保持其服务容器的状态，降低Web服务等待时间；保证一定的基础容器、类库容器的运行量，降低容器配置加载和Web服务的等待时间；释放资源以减少对CPU和内存等运行资源的占用量，提高运行资源的利用率；释放部分存储资源以维护系统环境的稳定。
在一个实施例中，针对Web的容器控制装置还可以包括监控模块和资源调度模块。监控模块能够监控服务容器的资源占用率；资源调度模块能够在资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长的情况下，减少为服务容器分配的资源；在资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长的情况下，增加为服务容器分配的资源。
这样的装置能够根据需要动态为服务容器配置资源，从而实现服务容器占用资源的弹性化配置，提高服务容器运行的效率和可靠性，也能够提高系统资源的利用率。
本公开容器控制装置的一个实施例的结构示意图如图5所示。容器控制装置包括存储器501和处理器502。其中：存储器501可以是磁盘、闪存或其它任何非易失性存储介质。存储器用于存储上文中容器控制方法的对应实施例中的指令。处理器502耦接至存储器501，可以作为一个或多个集成电路来实施，例如微处理器或微控制器。该处理器502用于执行存储器中存储的指令，能够提高运行在服务容器上的web服务器的启动效率。
在一个实施例中，还可以如图6所示，容器控制装置600包括存储器601和处理器602。处理器602通过BUS总线603耦合至存储器601。该容器控制装置600还可以通过存储接口604连接至外部存储装置605以便调用外部数据，还可以通过网络接口606连接至网络或者另外一台计算机系统(未标出)。此处不再进行详细介绍。
在该实施例中，通过存储器存储数据指令，再通过处理器处理上述指令，能够提高运行在服务容器上的web服务器的启动效率。
在另一个实施例中，一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现针对Web服务的容器控制方法对应实施例中的方法的步骤。本领域内的技术人员应明白，本公开的实施例可提供为方法、装置、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用非瞬时性存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本公开的容器系统70的一个实施例的示意图如图7所示。容器控制装置71可以为上文中任意一种容器控制装置。容器池72包括公共容器池和服务容器池。服务容器池中包括已完成创建的各个服务容器，加载了完整的Web服务器，可对外提供服务；公共容器池由若干空闲的基础容器、类库容器、休眠容器和基础容器镜像缓存构成，这些容器预先完成了部分服务容器构建的步骤，当需要创建新的服务容器时可从容器池中挑选匹配的空闲容器快速加载运行服务容器，当服务容器的服务组件被卸载时，作为空闲的类库容器放回容器池，当类库容器的类库被卸载，作为空闲的基础容器待命。
数据仓库73包括镜像仓库、服务类库仓库和服务组件仓库。镜像仓库负责基础容器镜像存储和管理，提供镜像下载和上传服务接口。基础容器镜像采用某种主流容器镜像格式(如Docker、AppC或OCI等)，打包支撑应用运行的基础软件，这些基础软件与业务无关，通常可作为独立进程运行，如Tomcat、Apache等，基础软件所依赖的底层系统库(如Glibc、JVM、Alpine等)也属于基础软件层面。此外还打包了用于加载/卸载类库的类库管理单元，以及加载/卸载服务组件的程序管理单元。类库仓库负载类库包的管理和存储，提供类库包的上传和下载服务接口。程序仓库负载服务组件包的管理和存储，提供服务组件包的上传和下载服务接口。
容器引擎74能够从镜像仓库中下载基础容器镜像，负责基础容器镜像的加载和运行。容器引擎74能够在接收到来自容器控制装置71的指令后进行基础容器镜像的下载和加载至容器。容器引擎74还可以执行基础容器镜像的卸载。
组件代理模块75能够响应容器控制装置71的类库加载指令，从本地或远程类库仓库中将指定的类库包加载到容器中，或者响应类库卸载事件，将容器中指定的类库或全部类库从内存中卸载。此外，还能够响应容器控制装置71的服务组件加载指令，从本地或远程程序仓库中将指定的服务组件加载到容器中，或者响应服务组件卸载指令，将容器中指定的服务组件从内存中卸载。在一个实施例中，组件代理模块可以内置于各个容器中，由组件代理模块对接Web服务器，对外提供统一的组件加载和卸载接口，这种方式可以通过定制Web服务器镜像实现。在另一个实施例中，可以借鉴Kubernetes的Pod概念，将组件代理做成容器，用Pod包装组件代理容器和Web服务容器，同一个Pod的不同容器之间共享网络栈和IPC资源，而且不需要现有的容器镜像，不改变现有服务镜像的部署方式。
这样的系统在为Web服务提供支持的过程中，能够从容器池中选择类库容器、基础容器、休眠容器或基础容器镜像缓存进行服务容器的构建，从而减少了在构建容器过程中对基础容器镜像、部分公共类库的加载过程，减少了服务容器构建的开销，从而提高了运行在服务容器上的web服务器的启动效率。
本公开的容器管理系统的另一个实施例的示意图如图8所示。容器控制装置81、容器引擎82、公共容器池83、服务容器池84、程序仓库86、类库仓库87、镜像仓库88与图7所示实施例中相似。从图8中可以看出，公共容器池83中的容器加载了相同或不同的基础容器镜像和公共类库，如图8所示，服务容器池84中的容器加载了相同或不同的基础容器镜像、类库和服务组件。
容器管理系统还可以包括元数据库85，能够存储各个容器加载的各种内容的信息(包括服务组件名称、应用版本、应用包名和版本、类库包(类库包名和版本)列表、基础容器镜像的名称和版本)、容器基本信息(比如容器所占用的)以及各种内容与容器的绑定关系，容器控制装置81可以根据元数据库85中存储的内容选择合适的容器。服务路由89能够通过Web应用的前端服务端口与后端容器端口的映射关系将Web应用请求转发给相应的服务容器处理，当Web请求的应用前后端映射关系不存在时，通知针对Web的容器控制装置81加载相应的服务容器。在一个实施例中，服务路由89还可以根据应用请求的应用ID、请求时间和响应时长更新应用性能计量器(包括应用平均访问频率值和应用平均响应时间)。
这样的容器系统能够服务容器部署和启动速度，只需基于容器池的已有容器加载服务组件和少量私有类库，避免耗时的基础软件运行和公共类库加载过程；具备快速扩容能力，可以从容器池中快速批量加载容器；能够降低运行的资源开销，自动从内存卸载访问频率过低的服务组件和类库包，自动关闭没有业务量的容器。
在一个实施例中，当用户首次部署服务时，除了提交服务容器镜像之外，还需要提交一个服务部署依赖文件，该文件定义了某个Web服务所依赖的服务组件信息、服务类库信息和Web服务器信息，其中服务组件信息包括服务组件标识(可采用名称+版本形式)、服务组件版本和服务组件文件名，服务类库信息包括零个或多个服务类库的类库标识(可采用名称+版本形式)、类库名称和类库文件名，Web服务器信息包括Web服务器标识、Web服务器名称、Web服务器版本号、Web服务端口号、Web服务器容器镜像标识(该信息也可以从服务容器镜像信息中提取)等，其中，服务组件文件名和服务类库文件名与服务容器镜像中所封装的服务组件文件名和服务类库文件名一致。
服务容器镜像可以采用两层方式(即Web服务器镜像+服务容器镜像)或三层方式(即Web服务器镜像+服务类库镜像+服务容器镜像)，其中两层方式的服务容器镜像中同时打包了服务组件文件和服务类库文件。
用户通过DockerRegistryAPI或CLI工具将服务容器镜像上传到容器镜像仓库。用户首次在部署Web服务容器时，根据用户提交的服务部署依赖文件，组件/类库提取模块90从已上传到镜像仓库88的服务容器镜像中提取服务组件文件和类库文件，将提取的服务组件保存在服务组件仓库中，将提取的类库文件保存在服务类库仓库中。
这样的系统能够使用户无需改变初始部署的习惯，由系统根据用户提供的服务容器镜像提取服务组件文件和类库文件并分别存储，以保证在各类容器构建过程中能够调用，提高了用户体验。
在一个实施例中，容器的规格包括五个基本指标：CPU核数CC、内存大小MC、最大并发量MV、最佳并发量BV、平均处理速度U，其中最大并发量是指容器在满负载情况下能同时处理的请求数，最佳并发量是指容器在最佳负载情况下能够并发处理的请求数，通常是满负载的70％-80％。假设服务器i的CPU核数为CSi，内存大小为MSi，服务器i能够运行的容器数为min([CSi/CC,MSi/MC])，整个集群有n台服务器，那么集群能运行的容器数MAXCN为
当服务路由接收到某个应用请求时，可以优先将应用请求转发给负载较高但尚未超过BV的服务容器处理，如果该应用的所有容器实例的正在处理的请求数都达到或超过了BV，则需要先将应用请求排队，然后通知容器控制装置加载新的服务容器实例，当服务容器实例可用后再将排队的请求转发到该容器处理。如果已加载运行的服务容器数已达到集群的上限无法增加新的容器实例时，则将请求依次转发给未达到MV的服务容器处理，如果该应用的所有容器均达到容量上限，且无法增加新的容器实例，则将该应用的请求排队。
例如，某个应用已有三个服务容器实例C1、C2、C3，当前并发分别为5、6、7，它们的最大并发均为10，最佳并发均为7。如果当前有100个请求到达，那么尝试加载先将其中的3个请求分配给C1、C2，为剩下的97个请求加载个服务容器；如果100个请求到达时集群资源不足，比如最多只能为该应用加载5个容器，那么将剩下的97个请求的50个平均分配给5个新加载的容器(每个容器10个请求)，已有的容器各分配3个请求，剩下的38个请求排队。
这样的系统能够设置任务分配逻辑，以及系统容器上限、服务容器资源上限，有助于防止逻辑错误，且从系统承载力出发并行执行任务，在提高执行效率的前提下保证系统的稳定运行。
本公开是参照根据本公开实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
至此，已经详细描述了本公开。为了避免遮蔽本公开的构思，没有描述本领域所公知的一些细节。本领域技术人员根据上面的描述，完全可以明白如何实施这里公开的技术方案。
可能以许多方式来实现本公开的方法以及装置。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本公开的方法以及装置。用于所述方法的步骤的上述顺序仅是为了进行说明，本公开的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本公开实施为记录在记录介质中的程序，这些程序包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于执行根据本公开的方法的程序的记录介质。
最后应当说明的是：以上实施例仅用以说明本公开的技术方案而非对其限制；尽管参照较佳实施例对本公开进行了详细的说明，所属领域的普通技术人员应当理解：依然可以对本公开的具体实施方式进行修改或者对部分技术特征进行等同替换；而不脱离本公开技术方案的精神，其均应涵盖在本公开请求保护的技术方案范围当中。

Claims (20)

1.一种针对Web服务的容器控制方法，包括：
接收容器申请请求；
根据与所述容器申请请求的匹配度从容器池中选择候选容器，在所述候选容器的基础上构建服务容器，其中，所述容器池中包括类库容器、基础容器、休眠容器和基础容器镜像缓存；
还包括：
监控服务容器的访问频率；若所述服务容器的访问频率低于预定频率下限，则卸载所述服务容器的私有类库和服务组件，成为类库容器；
监控类库容器持续未被访问时长；若所述类库容器的持续未被访问时长高于第一预定时长上限，则卸载所述类库容器的公共类库，成为基础容器；和/或，
监控基础容器的未被访问时长；若所述基础容器的持续未被访问时长高于第二预定时长上限，则卸载所述基础容器上的基础容器镜像。
2.根据权利要求1所述的方法，其中，
所述基础容器为加载了基础容器镜像的容器；
所述类库容器为加载了基础容器镜像和公共类库的容器；
所述服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；
所述休眠容器为保存了基础容器的运行状态的基础容器快照；
所述基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
3.根据权利要求1所述的方法，其中，所述根据与所述容器申请请求的匹配度从容器池中选择候选容器包括：
确定基于容器池中的各个容器构建所述容器申请请求所需的服务容器的开销；
选择加载开销最小的容器作为候选容器。
4.根据权利要求1～3任意一项所述的方法，其中，所述在所述候选容器的基础上构建服务容器包括：
若所述候选容器为容器镜像缓存，则基于容器镜像缓存创建基础容器，并加载类库和服务组件；
若所述候选容器为休眠容器，则通过基础容器快照恢复基础容器运行，并通过加载类库和服务组件；
若所述候选容器为基础容器，则在所述基础容器的基础上根据所述容器申请请求加载类库和服务组件；
若所述候选容器为类库容器，则在所述类库容器的基础上，根据所述容器申请请求执行：卸载所述容器申请请求不需要的类库、加载所述容器申请请求需要但所述候选容器中未加载的类库，和加载服务组件。
5.根据权利要求1或2所述的方法，其中，
所述根据与所述容器申请请求的匹配度从容器池中选择候选容器包括：
根据与所述容器申请请求的匹配度从所述类库容器中选择候选容器；
若存在与所述容器申请请求的匹配度大于预定匹配度下限的类库容器，则选择匹配度最高的类库容器作为候选容器；
若不存在与所述容器申请请求的匹配度大于预定匹配度下限的类库容器，则根据与所述容器申请请求的匹配度从所述基础容器、休眠容器或所述基础容器镜像缓存中选择候选容器。
6.根据权利要求5所述的方法，其中，所述根据与所述容器申请请求的匹配度从所述基础容器或休眠容器中选择候选容器包括：
若存在与所述容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高和/或空闲时间最长的基础容器作为候选容器；
若不存在与所述容器申请请求的匹配度大于预定匹配度下限的基础容器，则根据与所述容器申请请求的匹配度从所述基础容器、休眠容器或所述基础容器镜像缓存中选择候选容器。
7.根据权利要求1所述的方法，还包括：
记录所述服务容器、所述类库容器和所述基础容器上加载的内容和/或资源占用信息。
8.根据权利要求1所述的方法，还包括：
监控所述服务容器的资源占用率；
若所述资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长，则减少为所述服务容器分配的资源；
若所述资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长，则增加为所述服务容器分配的资源。
9.一种针对Web服务的容器控制装置，包括：
请求接收模块，用于接收容器申请请求；
服务容器构建模块，用于根据与所述容器申请请求的匹配度从容器池中选择候选容器，在所述候选容器的基础上构建服务容器，其中，所述容器池中包括类库容器、基础容器、休眠容器和基础容器镜像缓存；
还包括卸载模块，被配置为：
监控服务容器的访问频率；若所述服务容器的访问频率低于预定频率下限，则卸载所述服务容器的私有类库和服务组件，成为类库容器；
监控类库容器持续未被访问时长；若所述类库容器的持续未被访问时长高于第一预定时长上限，则卸载所述类库容器的公共类库，成为基础容器；和/或，
监控基础容器的未被访问时长；若所述基础容器的持续未被访问时长高于第二预定时长上限，则卸载所述基础容器上的基础容器镜像。
10.根据权利要求9所述的装置，其中，
所述基础容器为加载了基础容器镜像的容器；
所述类库容器为加载了基础容器镜像和公共类库的容器；
所述服务容器为加载了基础容器镜像、公共类库、私有类库和服务组件的容器中选择候选容器；
所述休眠容器为持久化保存了基础容器的运行状态的基础容器快照；
所述基础容器镜像缓存为已下载到本地并解压的基础容器镜像。
11.根据权利要求9所述的装置，其中，所述服务容器构建模块包括候选容器确定单元，被配置为确定基于容器池中的各个容器构建所述容器申请请求所需的服务容器的开销；选择加载开销最小的容器作为候选容器。
12.根据权利要求9～11任意一项所述的装置，其中，所述服务容器构建模块包括加载单元，被配置为：
若所述候选容器为容器镜像缓存，则基于容器镜像缓存创建基础容器，并加载类库和服务组件；
若所述候选容器为休眠容器，则通过基础容器快照恢复基础容器运行，并通过加载类库和服务组件；
若所述候选容器为基础容器，则在所述基础容器的基础上根据所述容器申请请求加载类库和服务组件；
若所述候选容器为类库容器，则在所述类库容器的基础上，根据所述容器申请请求执行：卸载所述容器申请请求不需要的类库、加载所述容器申请请求需要但所述候选容器中未加载的类库，和加载服务组件。
13.根据权利要求9或10所述的装置，其中，
所述服务容器构建模块包括候选容器确定单元，被配置为：
根据与所述容器申请请求的匹配度从所述类库容器中选择候选容器；
若存在与所述容器申请请求的匹配度大于预定匹配度下限的类库容器，则选择匹配度最高的类库容器作为候选容器；
若不存在与所述容器申请请求的匹配度大于预定匹配度下限的类库容器，则根据与所述容器申请请求的匹配度从所述基础容器、休眠容器或所述基础容器镜像缓存中选择候选容器。
14.根据权利要求13所述的装置，其中，所述候选容器确定单元，还被配置为：
若存在与所述容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高和/或空闲时间最长的基础容器作为候选容器；
若不存在与所述容器申请请求的匹配度大于预定匹配度下限的基础容器，则选择匹配度最高的休眠容器作为候选容器，或选择匹配的所述寄出容器镜像构建基础容器作为所述候选容器。
15.根据权利要求9所述的装置，还包括：
记录模块，被配置为记录所述服务容器、所述类库容器和所述基础容器上加载的内容和/或资源占用信息。
16.根据权利要求9所述的装置，还包括：
监控模块，被配置为监控所述服务容器的资源占用率；
资源调度模块，被配置为若所述资源占用率低于预定资源占用下限的时间达到第一预定资源占用时长，则减少为所述服务容器分配的资源；若所述资源占用率高于预定资源占用下限的时间达到第二预定资源占用时长，则增加为所述服务容器分配的资源。
17.一种针对Web服务的容器控制装置，包括：
存储器；以及
耦接至所述存储器的处理器，所述处理器被配置为基于存储在所述存储器的指令执行如权利要求1至8任一项所述的方法。
18.一种计算机可读存储介质，其上存储有计算机程序指令，该指令被处理器执行时实现权利要求1至8任意一项所述的方法的步骤。
19.一种针对Web服务的容器系统，包括：
权利要求9～16任意一项所述的针对web服务的容器控制装置；和，
容器池，被配置为管理容器和容器资源；
数据仓库，被配置为存放基础容器镜像数据、类库数据和服务组件数据；
容器引擎，被配置为根据所述容器控制装置的调度信息为容器配置基础容器镜像；
组件代理模块，被配置为根据所述容器控制装置的调度信息为容器配置类库和服务组件。
20.根据权利要求19所述的系统，还包括：
服务路由，被配置为通过Web服务的前端服务端口与后端容器端口的映射关系将Web服务请求转发给对应的服务容器处理，当所述Web请求的应用前后端映射关系不存在时，通知所述针对Web服务的容器控制装置构建服务容器。
CN201810099857.1A 2018-02-01 2018-02-01 针对Web服务的容器控制方法、装置和容器系统 Active CN110109649B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810099857.1A CN110109649B (zh) 2018-02-01 2018-02-01 针对Web服务的容器控制方法、装置和容器系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810099857.1A CN110109649B (zh) 2018-02-01 2018-02-01 针对Web服务的容器控制方法、装置和容器系统

Publications (2)

Publication Number Publication Date
CN110109649A CN110109649A (zh) 2019-08-09
CN110109649B true CN110109649B (zh) 2023-08-08

Family

ID=67483197

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810099857.1A Active CN110109649B (zh) 2018-02-01 2018-02-01 针对Web服务的容器控制方法、装置和容器系统

Country Status (1)

Country Link
CN (1) CN110109649B (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111177160B (zh) * 2019-11-06 2023-08-04 腾讯云计算（北京）有限责任公司 服务更新方法、装置、服务器及介质
CN111786904B (zh) * 2020-07-07 2021-07-06 上海道客网络科技有限公司 一种实现容器休眠与唤醒的系统及休眠与唤醒方法
CN112052068A (zh) * 2020-08-17 2020-12-08 烽火通信科技股份有限公司 一种Kubernetes容器平台CPU绑核的方法与装置
CN112506615B (zh) * 2020-12-11 2023-11-03 浪潮电子信息产业股份有限公司 JavaWeb应用部署方法、装置、设备及存储介质
CN112631797A (zh) * 2020-12-18 2021-04-09 京东数字科技控股股份有限公司 配置业务系统的方法和装置
CN113010224B (zh) * 2021-03-03 2024-01-30 南方电网数字平台科技(广东)有限公司 前端微服务化方法、装置、计算机设备和存储介质
CN113791864B (zh) * 2021-09-08 2024-03-26 国电南瑞科技股份有限公司 一种基于容器和微服务化功能的监控系统及其构建方法
CN114610573A (zh) * 2022-03-11 2022-06-10 航天科工智慧产业发展有限公司 基于容器编排的微服务监控方法、装置、设备及存储介质
CN115809120A (zh) * 2023-02-22 2023-03-17 北京知其安科技有限公司 Docker容器的攻击模拟检测方法、系统、介质及电子设备
CN116166473A (zh) * 2023-02-27 2023-05-26 北京远舢智能科技有限公司 一种数据处理方法、装置、电子设备及存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104714812A (zh) * 2013-12-13 2015-06-17 中国电信股份有限公司 在云环境中快速部署和加载Java应用的方法和系统
CN105718479A (zh) * 2014-12-04 2016-06-29 中国电信股份有限公司 跨idc大数处理架构下执行策略生成方法、装置
US9426030B1 (en) * 2015-12-11 2016-08-23 International Business Machines Coporation Automatically generating configuration images and deploying computer components in a computing environment that comprises a shared pool of configurable computing resources
CN106790483A (zh) * 2016-12-13 2017-05-31 武汉邮电科学研究院 基于容器技术的Hadoop集群系统及快速构建方法
WO2017113074A1 (zh) * 2015-12-28 2017-07-06 华为技术有限公司 一种资源的分配方法、装置和系统
WO2018001004A1 (zh) * 2016-06-27 2018-01-04 中兴通讯股份有限公司 一种基于Docker的云平台控制方法及装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040068553A1 (en) * 2002-10-07 2004-04-08 International Business Machines Corporation Dynamically selecting a Web service container for hosting remotely instantiated Web services
GB0427670D0 (en) * 2004-12-16 2005-01-19 Ibm Methods, systems and computer program products for loading a resource

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104714812A (zh) * 2013-12-13 2015-06-17 中国电信股份有限公司 在云环境中快速部署和加载Java应用的方法和系统
CN105718479A (zh) * 2014-12-04 2016-06-29 中国电信股份有限公司 跨idc大数处理架构下执行策略生成方法、装置
US9426030B1 (en) * 2015-12-11 2016-08-23 International Business Machines Coporation Automatically generating configuration images and deploying computer components in a computing environment that comprises a shared pool of configurable computing resources
WO2017113074A1 (zh) * 2015-12-28 2017-07-06 华为技术有限公司 一种资源的分配方法、装置和系统
WO2018001004A1 (zh) * 2016-06-27 2018-01-04 中兴通讯股份有限公司 一种基于Docker的云平台控制方法及装置
CN106790483A (zh) * 2016-12-13 2017-05-31 武汉邮电科学研究院 基于容器技术的Hadoop集群系统及快速构建方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ContainerCloudSim: An environment for modeling and simulation of containers in cloud data centers;Sareh Fotuhi Piraghaj等;《https://doi.org/10.1002/spe.2422》;20160627;全文 *

Also Published As

Publication number Publication date
CN110109649A (zh) 2019-08-09

Similar Documents

Publication Publication Date Title
CN110109649B (zh) 针对Web服务的容器控制方法、装置和容器系统
CN109729143B (zh) 在终端设备上部署基于网络的云平台
US11099870B1 (en) Reducing execution times in an on-demand network code execution system using saved machine states
US11573816B1 (en) Prefetching and managing container images using cluster manifest
US11231955B1 (en) Dynamically reallocating memory in an on-demand code execution system
CN115328663B (zh) 基于PaaS平台进行资源调度的方法、装置、设备和存储介质
WO2020123439A1 (en) Performance-based hardware emulation in an on-demand network code execution system
CN107590033B (zh) 一种创建docker容器的方法、装置和系统
US11650837B2 (en) Location-based virtualization workload placement
CN111930473B (zh) 在容器云上部署图像识别服务的方法与设备
US10193973B2 (en) Optimal allocation of dynamically instantiated services among computation resources
US11740921B2 (en) Coordinated container scheduling for improved resource allocation in virtual computing environment
WO2018196462A1 (zh) 资源调度装置、资源调度系统和资源调度方法
US11403150B1 (en) Replenishment-aware resource usage management
US20160299783A1 (en) Network service infrastructure management system and method of operation
US20100122256A1 (en) Scheduling Work in a Multi-Node Computer System Based on Checkpoint Characteristics
WO2017107483A1 (zh) 一种虚拟化网管文件下载负载均衡的方法及网管服务器
CN109951551A (zh) 一种容器镜像管理系统及方法
CN107045452B (zh) 虚拟机调度方法和装置
US11916998B2 (en) Multi-cloud edge system
US20230118994A1 (en) Serverless function instance placement among storage tiers
KR102413924B1 (ko) 복수의 컴퓨팅 노드를 이용한 고성능 클라우드 서비스 시스템에서의 프로세스 그룹 관리 방법 및 그 시스템
US11625358B1 (en) Automatic object archiving based on user selections
US20210067599A1 (en) Cloud resource marketplace
JP4887223B2 (ja) 情報処理システム、情報処理方法、およびプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant