CN106817411A - 业务访问请求的处理方法和相关设备 - Google Patents

Abstract

本发明实施例提供一种业务访问请求的处理方法和相关设备。该方法包括：请求处理装置接收客户端的业务访问请求；请求处理装置根据目的应用服务的主机端口，查询应用状态库，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器；目的容器监控目的容器上的目的应用服务的状态，当目的应用服务启动完成时，在应用状态库中记录应用服务的状态为已启动；请求处理装置在监控到应用状态库中记录的目的应用服务的状态为已启动时，将存储的业务访问请求转发给目的容器，以使得目的应用服务处理业务访问请求。通过以上方式可避免容器在应用服务启动完成前接收到业务访问请求带来的访问失败的问题。

Description

业务访问请求的处理方法和相关设备

技术领域

本发明涉及信息技术领域，特别涉及一种业务访问请求的处理方法和相关设备。

背景技术

容器作为一种新兴的虚拟化方式，跟传统的虚拟化方式相比具有众多的优势，其中一个特性是轻量级，可以实现更快速的交付和部署。容器的启动时间通常是秒级的，从而可大量地节约业务上线的时间。

容器运行在主机的容器引擎上，对外提供访问端口，主机在接收到客户端发送给容器的业务访问请求时，将业务访问请求转发到容器上，由容器中的应用服务处理业务访问请求。

虽然容器可以做到秒级启动，但容器中的应用服务却无法做到秒级启动。具体的，应用服务在启动过程中需要读取相关的配置文件，加载依赖文件，以及连接数据库，因此应用服务的启动时间相对于容器而言需时较长。

在现有技术中，当容器未启动，而主机接收到针对容器内的应用服务的业务访问请求时，会启动容器，并直接转发该业务访问请求至容器，由于容器的启动速度很快，因此当业务访问请求发送至容器中时，容器已经启动，但是由于容器中的应用服务的启动时间较长，因此，当容器接收到业务访问请求时，处理该业务访问请求的应用服务可能仍然处在加载过程中，并未完成启动，从而导致业务访问请求无法得到处理，客户端对该应用服务的访问失败。

发明内容

本发明实施例提供一种业务访问请求的处理方法和相关设备，使得容器只有在应用服务启动完成后才会接收到业务访问请求，避免容器在应用服务启动完成前接收到业务访问请求带来的访问失败的问题。

第一方面，本申请提供一种主机，包括主机操作系统、请求处理装置、应用状态库以及容器，主机操作系统包括容器引擎，容器运行在容器引擎之上，容器包括应用服务和应用服务监控模块，应用状态库可记录容器中运行的应用服务的状态，请求处理装置接收客户端的业务访问请求，且业务访问请求的目的端口为待访问的目的应用服务的主机端口，请求处理装置可根据目的应用服务的主机端口来查询应用状态库，当在应用状态库中查询到目的应用服务的状态为未启动时，请求处理装置会存储业务访问请求而暂时不进行转发，此时通过容器引擎启动目的应用服务所在的目的容器，并监控应用状态库。在容器启动后，容器中的应用服务监控模块则监控目的容器上的目的应用服务的状态，当目的应用服务启动完成时，容器中的应用服务监控模块可修改应用状态库以记录目的应用服务的状态为已启动，此时，请求处理装置可监控到应用状态库中记录的目的应用服务的状态为已启动，将原先存储的业务访问请求转发给目的容器。由于应用服务已启动完成，因此，当容器接收到业务访问请求时，容器中的目的应用服务即可处理该业务访问请求。

通过实施上述实施例，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。

在第一方面的一种可能的实现方式中，主机还包括路由表，路由表记录有应用服务的主机端口与应用服务的容器端口以及应用服务所在的容器的IP地址之间的对应关系。

通过实施上述实施例，利用路由表建立主机与容器之间的内部网络连接，可将容器从公网隔离。

在第一方面的一种可能的实现方式中，请求处理装置可通过以下方式来启动目的容器：根据应用访问请求的目的端口来查询路由表，确定目的应用服务所在的目的容器的IP地址，根据目的容器的IP地址通过容器引擎启动目的容器。

在第一方面的一种可能的实现方式中，请求处理装置可通过以下方式转发业务访问请求：根据应用访问请求的目的端口，查询路由表，将业务访问请求的目的IP地址修改为容器的IP地址，将业务访问请求的目的端口修改为应用服务的容器端口，将修改后的业务访问请求发送给目的容器。

在第一方面的一种可能的实现方式中，请求处理装置在判断到目的应用服务的状态为已启动时，可不存储业务访问请求，而直接将业务访问请求发送给目的容器。

通过实施本实施例，由于应用服务已经启动，因此在接收到针对应用服务的业务访问请求后，无需再次启动容器，故不再重复执行容器启动之动作，而是将该业务请求直接转发至容器进行处理，可确保请求处理的速度。

第二方面，本申请提供一种请求处理装置，该请求处理装置设置于主机，其包括以下功能模块：

接收模块，用于接收客户端的业务访问请求，业务访问请求的目的端口为待访问的目的应用服务的主机端口；

容器启动模块，用于根据目的应用服务的主机端口，查询应用状态库，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器，其中，应用状态库用于记录主机上的容器中运行的应用服务的状态；

应用状态库监控模块，用于监控应用状态库中记录的目的应用服务的状态；

发送模块，用于在应用状态库监控模块监控到应用状态库中记录的目的应用服务的状态为已启动时，将容器启动模块存储的业务访问请求转发给目的容器，以使得目的应用服务处理业务访问请求，其中，应用状态库中记录的目的应用服务的状态为目的容器的应用服务监控模块在目的应用服务启动完成后更新的。

通过实施上述实施例，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。

在第二方面的一种可能的实现方式中，主机还包括路由表，路由表记录有应用服务的主机端口与应用服务的容器端口以及应用服务所在的容器的IP地址之间的对应关系。

通过实施上述实施例，利用路由表建立主机与容器之间的内部网络连接，可将容器从公网隔离。

在第二方面的一种可能的实现方式中，容器启动模块具体用于：根据应用访问请求的目的端口，查询路由表，确定目的应用服务所在的目的容器的IP地址，根据目的容器的IP地址通过容器引擎启动目的容器。

在第二方面的一种可能的实现方式中，发送模块具体用于：根据应用访问请求的目的端口，查询路由表，将业务访问请求的目的IP地址修改为容器的IP地址，将业务访问请求的目的端口修改为应用服务的容器端口，将修改后的业务访问请求发送给目的容器。

在第二方面的一种可能的实现方式中，容器启动模块，还用于在查询到目的应用服务的状态为已启动时，不存储业务访问请求；发送模块，还用于直接将业务访问请求发送给目的容器。

第三方面，本申请提供一种请求处理方法，该方法应用于主机，主机包括主机操作系统、请求处理装置、应用状态库以及目的容器，主机操作系统包括容器引擎，目的容器运行在容器引擎之上，目的容器包括目的应用服务，该方法包括：

请求处理装置接收客户端的业务访问请求，业务访问请求的目的端口为待访问的目的应用服务的主机端口；

请求处理装置根据目的应用服务的主机端口，查询应用状态库，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器；

目的容器监控目的容器上的目的应用服务的状态，当目的应用服务启动完成时，在应用状态库中记录应用服务的状态为已启动；

请求处理装置在监控到应用状态库中记录的目的应用服务的状态为已启动时，将存储的业务访问请求转发给目的容器，以使得目的应用服务处理业务访问请求。

其中，主机还可以包括其他容器，其他容器也运行于容器引擎之上，本发明实施例通过业务访问请求的目的端口来选择目的容器，在业务访问请求的目的端口为待访问的目的应用服务的主机端口时，选择目的应用服务所在容器为目的容器。

通过实施上述实施例，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。

在第三方面的一种可能的实现方式中，主机还包括路由表，路由表记录有应用服务的主机端口与应用服务的容器端口以及应用服务所在的容器的IP地址之间的对应关系。

通过实施上述实施例，利用路由表建立主机与容器之间的内部网络连接，可将容器从公网隔离。

在第三方面的一种可能的实现方式中，请求处理装置通过容器引擎启动目的应用服务所在的目的容器具体包括：

请求处理装置根据应用访问请求的目的端口，查询路由表，确定目的应用服务所在的目的容器的IP地址，根据目的容器的IP地址通过容器引擎启动目的容器。

在第三方面的一种可能的实现方式中，请求处理装置将存储的业务访问请求转发给目的容器具体包括：

请求处理装置根据应用访问请求的目的端口，查询路由表，将业务访问请求的目的IP地址修改为容器的IP地址，将业务访问请求的目的端口修改为应用服务的容器端口，将修改后的业务访问请求发送给目的容器。

在第三方面的一种可能的实现方式中，该方法还包括：

当请求处理装置查询到目的应用服务的状态为已启动时，不存储业务访问请求，直接将业务访问请求发送给目的容器。

通过实施本实施例，由于应用服务已经启动，因此在接收到针对应用服务的业务访问请求后，无需再次启动容器，故不再重复执行容器启动之动作，而是将该业务请求直接转发至容器进行处理，可确保请求处理的速度。

第四方面，本申请提供一种业务访问请求的处理方法，该处理方法由主机上的请求处理装置执行，包括如下步骤：步骤一、接收客户端的业务访问请求，业务访问请求的目的端口为待访问的目的应用服务的主机端口；步骤二：根据目的应用服务的主机端口，查询应用状态库，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器，其中应用状态库用于记录主机上的容器中运行的应用服务的状态；步骤三、监控应用状态库，当应用状态库中记录的目的应用服务的状态为已启动时，将存储的业务访问请求转发给目的容器，以使得目的应用服务在完成启动后处理业务访问请求，其中，应用状态库中记录的目的应用服务的状态为目的容器的应用服务监控模块在目的应用服务启动完成后更新的。

通过实施上述实施例，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。

第五方面，本申请提供一种主机，包括存储器、处理器和总线，存储器和处理器分别与总线连接，存储器存储有程序指令以及应用状态库，处理器执行存储器中的第一程序指令以实现请求处理装置的功能，处理器执行存储器中的第二程序指令以实现应用服务监控模块的功能，处理器执行存储器中的第一程序指令以执行步骤：接收客户端的业务访问请求，业务访问请求的目的端口为待访问的目的应用服务的主机端口；根据目的应用服务的主机端口，查询应用状态库，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器；处理器执行存储器中的第二程序指令以执行步骤：监控目的容器上的目的应用服务的状态，当目的应用服务启动完成时，在应用状态库中记录应用服务的状态为已启动；处理器执行存储器中的第一程序指令以执行步骤：在监控到应用状态库中记录的目的应用服务的状态为已启动时，将存储的业务访问请求转发给目的容器，以使得目的应用服务处理业务访问请求。

通过实施上述实施例，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，显而易见地，下面所描述的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是根据本发明实施例的主机的装置结构示意图；

图2是根据本发明实施例的业务访问请求的处理方法的数据交互流程图；

图3根据本发明实施例的主机的又一装置结构示意图；

图4是根据本发明实施例的主机的另一装置结构示意图。

具体实施方式

图1为根据本发明实施例的主机的装置结构示意图，如图1所示，主机100包括硬件10、主机操作系统20、请求处理装置203、应用状态库202、路由表201、容器30以及容器40。

值得说明的是，本实施例以2个容器进行说明，而在一些实施例中，容器的数量可以是1个或大于2个。

主机操作系统20包括容器引擎204以及物理网卡驱动205。请求处理装置203可访问路由表201和应用状态库202。

在一些示例中，请求处理装置203可设置在主机操作系统20的内核，通过内核运行，在另外一些示例中，请求处理装置203可作为应用软件安装到主机操作系统20，在主机操作系统20中运行。应用状态库202和路由表201可存储于主机100的磁盘中，并可加载到主机100的内存上。

硬件10包括物理网卡101，硬件10还包括处理器、存储器(图未示出)等，硬件10承载主机操作系统的运行。

而主机操作系统20中的物理网卡驱动205用于驱动物理网卡101，物理网卡驱动205相当于物理网卡101的硬件接口，主机操作系统20通过该硬件接口控制物理网卡101的工作，如发送、接收数据，可通过物理网卡101为主机100设置IP地址，该IP地址为主机100的公网地址(在一些实施例中，物理网卡101可设置多个公网地址，在本发明实施例中，只需使用其中一个公网地址即可)，在本实施例中可例如为123.456.78.101。外部设备若要访问容器30或40，需将访问请求的目的地址设定为主机100的公网地址，请求处理装置203根据路由表201记录的转发规则将访问请求转发至对应容器。通过设置路由表201，可将容器从公网隔离，来自公网的业务访问请求若要访问容器，只能先到达主机100，经主机100转发才能到达容器。

容器30包括虚拟网卡301、运行环境302、应用服务监控模块303、应用服务304以及应用服务305，容器40包括虚拟网卡401、运行环境402、应用服务监控模块403以及应用服务404。运行环境具体为包括Bins/Libs(二进制或库)文件的依赖包，不同的容器30和40具有不同的依赖包，从而令不同的应用服务通过对应依赖包可正常运行在对应的容器中。

容器30在运行环境302下运行应用服务监控模块303、应用服务304和应用服务304，容器40在运行环境402下运行应用服务监控模块403和应用服务404。容器30可以为应用服务305、304运行提供一切要素(容器40相对于应用服务404亦然)，容器30和容器40可以在容器引擎204的控制下可以运行、启动、停止(即未启动)或者被删除，容器30与容器40之间是隔离的安全应用平台。

请求处理装置203用于对客户端发送的针对特定容器内的应用服务的业务访问请求进行处理。容器引擎204通过安装而嵌入于主机操作系统20的内核，可让开发者将应用服务404以及运行环境403打包到可移植的容器40中，和/或将运行环境302、应用服务304和应用服务305打包到可移植的容器40中，然后将容器30和/或容器40发布到任何流行的Linux机器上，从而实现虚拟化。

在安装容器引擎204之后，容器引擎204可于shell接口中为主机操作系统20提供控制容器的bash指令集，其中Shell接口是主机操作系统20的用户界面，是提供了用户与主机操作系统20的内核进行交互操作的一种接口。Shell接口接收用户输入的bash指令并将其送入内核去执行，从而控制容器。并且，用户输入的bash指令也可以写入到脚本中，在Shell接口指定脚本的运行时间(或指定主机操作系统20启动后自动执行)，可令主机操作系统20自动执行bash指令。

容器引擎204还可以为容器30分配虚拟网卡301，为容器40分配虚拟网卡401，举例而言，可通过虚拟网卡301将容器30的IP地址设置为192.168.1.3，通过虚拟网卡401将容器40的IP地址设置为192.168.1.4，容器引擎204内设置了网桥2041，虚拟网卡301、虚拟网卡401分别与网桥2041连接，网桥2041通过容器的IP地址识别容器。

示例性地，虚拟网卡301为应用服务305分配端口21，为应用服务304分配端口80，应用服务304举例而言可为Web服务，应用服务305举例而言可为Ftp服务。

网桥2041可将虚拟网卡301或虚拟网卡401发出的数据转发至物理网卡驱动205，物理网卡驱动205对该数据进行封装后通过物理网卡101发送至外部设备。进一步，物理网卡101从外部设备接收的数据经物理网卡驱动205拆包之后，在经由请求处理装置203的处理(下文将会详细描述)后发送至网桥2041，并由网桥2041发送至容器30或容器40。

示例性地，主机100可在主机操作系统20中为应用服务404分配端口12404，为应用服务305分配端口12305，为应用服务304分配端口12304。

在本发明实施例中，路由表201预先记录了：

容器30的IP地址192.168.1.3、应用服务304的容器端口80二者与主机应用服务304的主机端口12304之间的对应关系；

容器30的IP地址192.168.1.3、应用服务305的容器端口21二者与主机应用服务305的主机端口12305之间的对应关系；

容器40的IP地址192.168.1.4、应用服务404的容器端口80二者与主机应用服务404的主机端口12404之间的对应关系。

路由表201如表1所示：

192.168.1.3：80	12304
		192.168.1.3：21	12305
192.168.1.4：80	12404

表1

应用服务的容器端口可以由所在容器直接分配，应用服务的主机端口可以由运行应用服务所在容器的主机分配，在可选实施例中，应用服务的容器端口和主机端口可由运行应用服务的容器所在主机统一分配，或由第三方平台分配，本发明实施例对此不作限定。

应用状态库202的作用是记录本主机上的各容器上运行的应用服务的状态，其可以由请求处理装置203及各容器中的应用服务监控模块303、403写入，并由请求处理装置203读取。值得注意的是，容器30在初始状态下处于”未启动”状态，因此容器30中的应用服务304和应用服务305也未启动，请求处理装置203通过容器引擎204检测到应用服务304和应用服务305未启动，会对独立于容器30之外的应用状态库202进行修改，修改应用状态库202使其记录应用服务304的状态为未启动。

假设应用服务304和应用服务404为Web服务，其名称为apache，应用服务305为Ftp服务，其名称为ftp，在初始状态下，应用状态库202中的部分内容至少应如表2所示：

表2

容器标识举例而言可通过容器名称或容器网络地址来实现，应用服务标识举例而言可通过应用服务名称或容器端口来实现。

示例地，在表2中，利用容器名称(container name)来实现容器标识，利用应用服务名称(app name)来实现应用服务标识。在表2的第一行，containername为容器名称，appname为应用服务名称，status为应用服务状态；在表2的第二行，container1为容器30的名称，apache为容器30的应用服务304的名称，stop表示应用服务304未启动；在表2的第三行，container1为容器30的名称，ftp为容器30的应用服务305的名称，stop表示应用服务305未启动；在表2的第四行，container2为容器40的名称，apache为容器40的应用服务404的名称，run表示应用服务305已启动。在一示例中，应用状态库202的存储路径为“/myapp”，即应用状态库202存储在主机操作系统20的目录myapp中。值得注意的是，该目录名称可根据需要设置，且在myapp目录下，仅存在应用状态库202一个文件。

图2是根据本发明实施例的业务访问请求的处理方法的数据交互流程图，以下将结合图2对实施例提供的方案进行说明。

在500部分，容器40处于“已启动”状态。

在501部分，容器30处于“未启动”状态。

请求处理装置203可向容器引擎204输入容器停止命令，从而使得容器30处于”未启动”状态，具体地，请求处理装置203可通过主机操作系统20的shell接口向容器引擎204输入容器停止命令“docker stop container1”，container1为容器30的名称。

在502部分，请求处理装置203发送容器状态检测命令至容器引擎204。

容器状态检测命令例如为“docker ps-a”和“docker ps”，命令“docker ps-a”可列出处于“未启动”状态的容器，命令“docker ps”可列出处于“已启动”状态的容器。请求处理装置203可通过主机操作系统20的shell接口向容器引擎204输入容器停止命令“dockerstop container1”。在503部分，容器引擎204运行容器状态检测命令以检测容器状态，并检测到容器30处于“未启动”状态，且容器40处于“已启动”状态。

在504部分，容器引擎204将容器30处于”未启动”状态的信息通知请求处理装置203，并且，容器引擎204可将容器40处于“已启动”状态的信息通知请求处理装置203。

在505部分，请求处理装置203在获知容器30处于”未启动”状态之后，修改应用状态库202以记录应用服务304和305的状态为“未启动”。进一步地，请求处理装置203在获知容器40处于“已启动”状态之后，请求处理装置203通过容器引擎204检测到应用服务404已启动，对应用状态库202进行修改，修改应用状态库202以记录应用服务404的状态为“已启动”。

具体地，请求处理装置203通过容器引擎204发送应用服务状态查询指令至容器40，容器40在自身shell接口中输入“ps”命令以查询应用服务404的状态，并获知其为已启动，请求处理装置203通过容器引擎204获取应用服务404的状态为“已启动”。

修改后的应用状态库202如表3所示：

表3

通过以上步骤，可使得应用状态库202所记录的应用服务状态更新为与当前应用服务的状态一致，经更新的应用状态库202可用于以下步骤506-514。

在一种具体的场景中，请求处理装置203通过主机操作系统20的shell接口来执行“etcdctl set/myapp/container1/apache/status"stop"”命令，来修改位于“/myapp”存储路径中的应用状态库202，并将应用状态库202中在名为“container1”的容器30的，且名为“apache”的应用服务的状态记录为“stop”(即如表2第二行所示)。

并且，请求处理装置203通过主机操作系统20的shell接口来执行“etcdctl set/myapp/container1/ftp/status"stop"”命令，来修改位于“/myapp”存储路径中的应用状态库202，并将应用状态库202中在名为“container1”的容器30上的、名为“ftp”的应用服务的状态记录为“stop”(即如表2第二行所示)。

进一步，请求处理装置203通过主机操作系统20的shell接口来执行“etcdctlset/myapp/container2/apache/status"start"”命令，将应用状态库202中在名为“container2”的容器40上的、名为“apache”的应用服务的状态记录为“start”(即如表2第三行所示)。

其中，请求处理装置203在503部分获知容器30(container1)处于“未启动”状态，且容器40(container2)处于“已启动”状态时，通过查询应用状态库202即可获知container1中的所有应用服务的名称：apache和ftp，且container2中的所有应用服务的名称：apache。

在506部分，请求处理装置203接收到业务访问请求。该业务访问请求是由外部设备(如客户端)针对容器30中的应用服务304而发送的。

在主机100中，首先由图1中的物理网卡101接收业务访问请求，并经物理网卡驱动205解析发送至请求处理装置203。经解析后的业务访问请求可包括目的IP地址、目的端口、源IP地址、源端口以及请求类型，请求类型包括但不限于读请求、写请求、连接请求、下载请求、测试请求等。其中，目的IP地址为主机100的外网IP地址，目的端口为应用服务304的主机端口，源IP地址和源端口为发出业务访问请求至主机100的终端的IP地址和端口。

在一个示例中，业务访问请求可为网页访问请求(http请求)，请求类型为读请求，目的IP地址为123.456.78.101(主机100的外网IP地址)，目的端口是12304(应用服务304的主机端口)，源IP地址为123.456.98.102(外部设备的IP地址)，源端口为8012。应用服务304可为Web服务器软件，如apache软件。

在另一个示例中，业务访问请求为下载请求(ftp请求)或其他常见的网络请求。

为了便于理解，在本实施例中，请求处理装置203的业务访问请求为网页访问请求。

在507和509部分，请求处理装置203在接收到业务访问请求后，解析到业务访问请求的目的端口为应用服务404的主机端口12304，查询路由表201中端口12304对应的容器地址192.168.1.3，根据容器地址192.168.1.3获知获知容器30的名称(如container1)，在应用状态表202中查询容器container1的应用服务的状态，由于container1中的应用服务apache和ftp的状态均为“未启动”，因此可以确定容器30处于“未启动”状态(参见505部分)，此时需要启动容器30，因此请求处理装置203存储业务访问请求，等待应用服务404启动后再转发业务访问请求。具体地，在507部分，请求处理装置203发送容器启动命令至容器引擎204。该容器启动命令为“docker start container1”，请求处理装置203通过主机操作系统20的shell接口来执行“docker start container1”命令。

值得注意的是，请求处理装置203会预先记录容器30的IP地址192.168.1.3与容器30的名称(如container1)之间的对应关系，由容器30的IP地址192.168.1.3获得容器30的名称container1。并且，请求处理装置203发送容器启动命令之后，可于508部分监控应用状态库202。该508部分可在发送容器启动命令之后或与发送容器启动命令同步执行。请求处理装置203可通过主机操作系统20的shell接口执行“confd/myapp”命令，来实现对应用状态库202的监控，“/myapp”为应用状态库202所在路径，应用状态库202存储在路径目录“/myapp”中。在一些实施例中，应用状态库的路径目录也可以是其他路径，本发明实施例对此不作限定。

在执行上述命令后，请求处理装置203可检测到应用状态库202的状态status变化。

在509部分，容器引擎204根据容器启动命令启动容器30。

值得注意的是，在本部分中，基于容器本身的轻量特性，容器30的启动速度为秒级。

在510部分，容器30启动应用服务304和305，并监控应用服务304和305是否完成启动。

其中，应用服务304和305可通过脚本设置为在容器30启动之后实现自动启动，图1中所示的应用服务监控模块303可用于监控应用服务304和305是否完成启动，应用服务监控模块303通过容器30的shell接口执行应用服务启动命令，应用服务启动命令例如可为“start”命令，其用法为“应用服务所在路径/bin/应用服务名称start”。

且应用服务监控模块303可进一步通过容器30的shell接口执行“curllocalhost:port/appname/index.html”命令，以监控应用服务304或305是否启动完成。其中localhost是指容器30本身，port为容器30为应用服务分配的端口(针对应用服务304是端口80，针对应用服务305是端口21)，appname为应用服务名称(针对应用服务304是apache，针对应用服务305是ftp)，该命令可用于监控容器30上的应用服务304或305是否启动完成。

由于应用服务304为网页服务软件，需要进行连接数据库、读取配置文件等动作，因此其启动所需时间比容器30启动所需时间长。

在511部分，在容器30确认应用服务304和305启动完成后，将应用状态库202记录的应用服务304和305的状态更新为已启动。

具体地，容器30中的应用服务监控模块303通过向容器30的shell接口执行“etcdctl set/myapp/container1/apache/status"run"”命令，来修改位于“/myapp”目录中的应用状态库202，并将应用状态库202中“container1”对应的名为“apache”的应用服务304的状态修改为“run”(已启动)。

并且，应用服务监控模块303还通过向容器30的shell接口执行“etcdctl set/myapp/container1/ftp/status"run"”命令，将应用状态库202中“container1”对应的名为“ftp”的应用服务305的状态修改为“run”(已启动)。

在512部分，由于应用状态库202中应用服务304的状态被修改为已启动，该状态的改变会被请求处理装置203所检测到(参见步骤508)，此时，请求处理装置203将业务访问请求转发至容器30。

值得注意的是，于此所述的“转发”是指：请求处理装置203根据业务访问请求所携带的目的端口12304，在路由表201中查找与该目的端口12304对应的容器30的IP地址和应用服务304的容器端口(192.168.1.3:80)，将业务访问请求的目的IP地址123.456.78.101修改为容器30的IP地址192.168.1.3，将目的端口12304修改为应用服务304的容器端口80，并将更新后的业务访问请求发送至图1所示的网桥2041，网桥2041根据该业务访问请求所携带的容器30的IP地址192.168.1.3和应用服务304的容器端口80将该业务访问请求发送至容器30的虚拟网卡301的端口80，从而令应用服务304在该端口80接收到应用服务请求，进而对应用服务请求进行处理。

在513部分，请求处理装置203接收到针对设置在容器30内的应用服务304的另一业务访问请求，该另一业务访问请求可例如为另一Web网页访问请求。

在514部分，请求处理装置203在判断到另一业务访问请求的目的端口为应用服务404的主机端口12304，查询路由表201中端口12304对应的容器地址192.168.1.3，根据容器地址192.168.1.3获知获知容器30的名称(如container1)，在应用状态表202中查询容器container1的应用服务的状态，由于container1中的应用服务apache和ftp的状态均为“已启动”(参见511部分)，因此可以确定容器30处于“已启动”状态(参见505部分)，此时不需要启动容器30，因此请求处理装置203不存储业务访问请求，直接将该另一业务访问请求转发至容器30，其中，转发规则可参考512部分所述，因此可使得应用服务304可对该另一业务访问请求进行处理。

可选地，请求处理装置203在转发另一业务访问请求之前，可查询应用状态库202中应用服务304的状态，具体地，在表2中container1的apache的status(状态)为“run(已启动)”时，可直接转发另一业务访问请求转发至容器30，若为“stop”则需要执行如507至511部分以启动容器30。

在本部分中，由于应用服务304已经启动，因此在接收到针对应用服务304的另一业务访问请求后，无需再次启动容器30，故不再重复执行507至511部分，而是将另一业务请求直接转发，可确保后续请求处理的速度。

在本实施例中，当请求处理装置接收到客户端的业务访问请求时，会判断处理该业务访问请求的应用服务是否已启动，只有在确定应用服务的状态为已启动时，才将业务访问请求转发至容器，避免容器在应用服务启动完成前接收到业务访问请求，无法对业务访问请求进行处理带来的访问失败的问题。

并且，在本实施例中，在初始状态下，当请求处理装置203接收到针对应用服务305的业务访问请求时，也会做出类似507至514部分的动作，从而保证业务访问请求不会因为容器40的启动速度过快而丢失。

进一步，当请求处理装置203接收到针对应用服务404的业务访问请求时，可根据应用状态库202中应用服务404的状态来转发应用服务304的业务访问请求。具体地，在查询到在表2中container2的apache的status(状态)为“run(已启动)”时，直接转发针对应用服务304的业务访问请求至容器40，由于跳过请求处理装置203的处理，因此可以保证请求处理速度。

以下请参见图3，图3示出请求处理装置203的内部结构。如图3所示，处理装置203包括接收模块101、容器启动模块102、应用状态库监控模块103以及发送模块104。

其中，接收模块101可执行上述部分506和513所述的功能，容器启动模块102可执行上述部分502和507所述的功能，应用状态库监控模块103可执行上述508部分所述的功能，发送模块104可执行上述512和514部分所述的功能。

上述的功能模块可通过脚本实现，脚本可在主机操作系统20的shell接口上运行，从而实现对应功能。

本发明实施例进一步提供一种主机，请参见图4，图4是根据本发明实施例的主机100的装置结构示意图，如图4所示，主主机100包括存储器602、处理器601和总线603，存储器602和处理器601分别与总线603连接，存储器602存储有程序指令以及应用状态库202，处理器601执行存储器602中的第一程序指令以实现请求处理装置203的功能，处理器601执行存储器602中的第二程序指令以实现应用服务监控模块303、403的功能，处理器601执行存储器602中的第一程序指令以执行步骤：接收客户端的业务访问请求，业务访问请求的目的端口为待访问的目的应用服务的主机端口；根据目的应用服务的主机端口，查询应用状态库202，当目的应用服务的状态为未启动时，存储业务访问请求，通过容器引擎启动目的应用服务所在的目的容器；处理器601执行存储器602中的第二程序指令以执行步骤：监控目的容器上的目的应用服务的状态，当目的应用服务启动完成时，在应用状态库202中记录应用服务的状态为已启动；处理器601执行存储器602中的第一程序指令以执行步骤：在监控到应用状态库202中记录的目的应用服务的状态为已启动时，将存储的业务访问请求转发给目的容器，以使得目的应用服务处理业务访问请求。

通过在确定应用服务的状态为已启动时，先存储业务访问请求，才将业务访问请求转发至容器，容器在于其中的应用服务在启动完毕之后才会接收到业务访问请求，使得应用服务可对业务访问请求进行处理，可保证业务访问请求不会因为容器的启动速度过快而丢失。

可选地，主机还包括路由表201，路由表201记录有应用服务的主机端口与应用服务的容器端口以及应用服务所在的容器的IP地址之间的对应关系。

可选地，处理器601执行存储器602中的第一程序指令以执行具体步骤来启动目的容器：根据应用访问请求的目的端口，查询路由表201，确定目的应用服务所在的目的容器的IP地址，根据目的容器的IP地址通过容器引擎启动目的容器。

可选地，处理器601执行存储器602中的第一程序指令以执行具体步骤来转发业务访问请求：根据应用访问请求的目的端口，查询路由表201，将业务访问请求的目的IP地址修改为容器的IP地址，将业务访问请求的目的端口修改为应用服务的容器端口，将修改后的业务访问请求发送给目的容器。

可选地，处理器601执行存储器602中的第一程序指令以执行步骤：当目的应用服务的状态为已启动时，不存储业务访问请求，直接将业务访问请求发送给目的容器。

综上，图4所示的实施例详细介绍了主机的硬件架构，图4所示主机的功能和效果和图1及其对应内容完全一致，于此不作赘述。需说明的是，以上描述的任意装置实施例都仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

所属领域的技术人员可以清楚地了解到，上述描述的系统、装置或单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (21)

1.一种主机，其特征在于，包括主机操作系统、请求处理装置、应用状态库以及容器，所述主机操作系统包括容器引擎，所述容器运行在所述容器引擎之上，所述容器包括应用服务和应用服务监控模块，所述应用状态库用于记录所述容器中运行的所述应用服务的状态，

所述请求处理装置，用于接收客户端的业务访问请求，所述业务访问请求的目的端口为待访问的目的应用服务的主机端口；

所述请求处理装置，还用于根据所述目的应用服务的主机端口，查询所述应用状态库，当所述目的应用服务的状态为未启动时，存储所述业务访问请求，通过所述容器引擎启动所述目的应用服务所在的目的容器；

所述应用服务监控模块，用于监控所述目的容器上的所述目的应用服务的状态，当所述目的应用服务启动完成时，在所述应用状态库中记录所述应用服务的状态为已启动；

所述请求处理装置，还用于在监控到所述应用状态库中记录的所述目的应用服务的状态为已启动时，将存储的所述业务访问请求转发给所述目的容器，以使得所述目的应用服务处理所述业务访问请求。

2.如权利要求1所述的主机，其特征在于，所述主机还包括路由表，所述路由表记录有所述应用服务的主机端口与所述应用服务的容器端口以及所述应用服务所在的容器的IP地址之间的对应关系。

3.如权利要求2所述的主机，其特征在于，

所述请求处理装置，具体用于根据所述应用访问请求的目的端口，查询所述路由表，确定所述目的应用服务所在的目的容器的IP地址，根据所述目的容器的IP地址通过所述容器引擎启动所述目的容器。

4.如权利要求2-3任一所述的主机，其特征在于，

所述请求处理装置，具体用于根据所述应用访问请求的目的端口，查询所述路由表，将所述业务访问请求的目的IP地址修改为所述容器的IP地址，将所述业务访问请求的目的端口修改为所述应用服务的容器端口，将修改后的业务访问请求发送给所述目的容器。

5.如权利要求1-4任一所述的主机，其特征在于，

所述请求处理装置，还用于当所述目的应用服务的状态为已启动时，不存储所述业务访问请求，直接将所述业务访问请求发送给所述目的容器。

6.一种请求处理装置，其特征在于，设置于主机，包括：

接收模块，用于接收客户端的业务访问请求，所述业务访问请求的目的端口为待访问的目的应用服务的主机端口；

容器启动模块，用于根据所述目的应用服务的主机端口，查询所述应用状态库，当所述目的应用服务的状态为未启动时，存储所述业务访问请求，通过容器引擎启动所述目的应用服务所在的目的容器，其中，所述应用状态库用于记录所述主机上的容器中运行的应用服务的状态；

应用状态库监控模块，用于监控所述应用状态库中记录的所述目的应用服务的状态；

发送模块，用于在所述应用状态库监控模块监控到所述应用状态库中记录的所述目的应用服务的状态为已启动时，将所述容器启动模块存储的所述业务访问请求转发给所述目的容器，以使得所述目的应用服务处理所述业务访问请求，其中，所述应用状态库中记录的所述目的应用服务的状态为所述目的容器的应用服务监控模块在所述目的应用服务启动完成后更新的。

7.如权利要求6所述的请求处理装置，其特征在于，所述主机还包括路由表，所述路由表记录有所述应用服务的主机端口与所述应用服务的容器端口以及所述应用服务所在的容器的IP地址之间的对应关系。

8.如权利要求7所述的请求处理装置，其特征在于，所述容器启动模块具体用于：

根据所述应用访问请求的目的端口，查询所述路由表，确定所述目的应用服务所在的目的容器的IP地址，根据所述目的容器的IP地址通过所述容器引擎启动所述目的容器。

9.如权利要求7-8任一所述的请求处理装置，其特征在于，所述发送模块具体用于：

根据所述应用访问请求的目的端口，查询所述路由表，将所述业务访问请求的目的IP地址修改为所述容器的IP地址，将所述业务访问请求的目的端口修改为所述应用服务的容器端口，将修改后的业务访问请求发送给所述目的容器。

10.如权利要求6-9任一所述的请求处理装置，其特征在于，

所述容器启动模块，还用于在查询到所述目的应用服务的状态为已启动时，不存储所述业务访问请求；

所述发送模块，还用于直接将所述业务访问请求发送给所述目的容器。

11.一种请求处理方法，其特征在于，所述方法应用于主机，所述主机包括主机操作系统、请求处理装置、应用状态库以及目的容器，所述主机操作系统包括容器引擎，所述目的容器运行在所述容器引擎之上，所述目的容器包括目的应用服务，所述方法包括：

所述请求处理装置接收客户端的业务访问请求，所述业务访问请求的目的端口为待访问的目的应用服务的主机端口；

所述请求处理装置根据所述目的应用服务的主机端口，查询所述应用状态库，当所述目的应用服务的状态为未启动时，存储所述业务访问请求，通过所述容器引擎启动所述目的应用服务所在的目的容器；

所述目的容器监控所述目的容器上的所述目的应用服务的状态，当所述目的应用服务启动完成时，在所述应用状态库中记录所述应用服务的状态为已启动；

所述请求处理装置在监控到所述应用状态库中记录的所述目的应用服务的状态为已启动时，将存储的所述业务访问请求转发给所述目的容器，以使得所述目的应用服务处理所述业务访问请求。

12.如权利要求11所述的方法，其特征在于，所述主机还包括路由表，所述路由表记录有所述应用服务的主机端口与所述应用服务的容器端口以及所述应用服务所在的容器的IP地址之间的对应关系。

13.如权利要求12所述的方法，其特征在于，所述请求处理装置通过所述容器引擎启动所述目的应用服务所在的目的容器具体包括：

所述请求处理装置根据所述应用访问请求的目的端口，查询所述路由表，确定所述目的应用服务所在的目的容器的IP地址，根据所述目的容器的IP地址通过所述容器引擎启动所述目的容器。

14.如权利要求12-13任一所述的方法，其特征在于，所述请求处理装置将存储的所述业务访问请求转发给所述目的容器具体包括：

所述请求处理装置根据所述应用访问请求的目的端口，查询所述路由表，将所述业务访问请求的目的IP地址修改为所述容器的IP地址，将所述业务访问请求的目的端口修改为所述应用服务的容器端口，将修改后的业务访问请求发送给所述目的容器。

15.如权利要求11-14任一所述的方法，其特征在于，还包括：

当所述请求处理装置查询到所述目的应用服务的状态为已启动时，不存储所述业务访问请求，直接将所述业务访问请求发送给所述目的容器。

16.一种业务访问请求的处理方法，其特征在于，包括：

接收客户端的业务访问请求，所述业务访问请求的目的端口为待访问的目的应用服务的主机端口；

根据所述目的应用服务的主机端口，查询应用状态库，当所述目的应用服务的状态为未启动时，存储所述业务访问请求，通过容器引擎启动所述目的应用服务所在的目的容器，其中，所述应用状态库用于记录主机上的容器中运行的应用服务的状态；

监控所述应用状态库，当所述应用状态库中记录的所述目的应用服务的状态为已启动时，将存储的所述业务访问请求转发给所述目的容器，以使得所述目的应用服务处理所述业务访问请求，其中，所述应用状态库中记录的所述目的应用服务的状态为所述目的容器的应用服务监控模块在所述目的应用服务启动完成后更新的。

17.如权利要求16所述的方法，其特征在于，所述主机还包括路由表，所述路由表记录有所述应用服务的主机端口与所述应用服务的容器端口以及所述应用服务所在的容器的IP地址之间的对应关系。

18.如权利要求17所述的方法，其特征在于，所述通过容器引擎启动所述目的应用服务所在的目的容器具体包括：

根据所述应用访问请求的目的端口，查询所述路由表，确定所述目的应用服务所在的目的容器的IP地址，根据所述目的容器的IP地址通过所述容器引擎启动所述目的容器。

19.如权利要求17-18任一所述的方法，其特征在于，所述将存储的所述业务访问请求转发给所述目的容器具体包括：

根据所述应用访问请求的目的端口，查询所述路由表，将所述业务访问请求的目的IP地址修改为所述容器的IP地址，将所述业务访问请求的目的端口修改为所述应用服务的容器端口，将修改后的业务访问请求发送给所述目的容器。

20.如权利要求16-19任一所述的方法，其特征在于，所述方法还包括：

当所述目的应用服务的状态为已启动时，不存储所述业务访问请求，直接将所述业务访问请求发送给所述目的容器。

21.一种主机，其特征在于，包括存储器、处理器和总线，所述存储器和所述处理器分别与所述总线连接，所述存储器存储有程序指令以及应用状态库，所述处理器执行所述存储器中的第一程序指令以实现请求处理装置的功能，所述处理器执行所述存储器中的第二程序指令以实现应用服务监控模块的功能，

所述处理器执行所述存储器中的第一程序指令以执行步骤：接收客户端的业务访问请求，所述业务访问请求的目的端口为待访问的目的应用服务的主机端口；根据所述目的应用服务的主机端口，查询所述应用状态库，当所述目的应用服务的状态为未启动时，存储所述业务访问请求，通过所述容器引擎启动所述目的应用服务所在的目的容器；

所述处理器执行所述存储器中的第二程序指令以执行步骤：监控所述目的容器上的所述目的应用服务的状态，当所述目的应用服务启动完成时，在所述应用状态库中记录所述应用服务的状态为已启动；

所述处理器执行所述存储器中的第一程序指令以执行步骤：在监控到所述应用状态库中记录的所述目的应用服务的状态为已启动时，将存储的所述业务访问请求转发给所述目的容器，以使得所述目的应用服务处理所述业务访问请求。