CN114726821A - 容器化后的业务组件的处理方法及组件、系统 - Google Patents

Abstract

本发明公开了一种容器化后的业务组件的处理方法及组件、系统，其中，所述方法包括：服务组件配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；中心查询组件向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表；所述中心查询组件根据所述容器信息列表中的公网访问信息，从宿主机处获取各个所述业务容器的容器状态，并筛选出候选业务容器；所述任务派发组件从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。本申请提供的技术方案，能够减少公网I P地址的占用，从而提高了业务容器的可扩展性。

Description

容器化后的业务组件的处理方法及组件、系统

技术领域

本发明涉及互联网技术领域，特别涉及一种容器化后的业务组件的处理方法及组件、系统。

背景技术

随着微服务架构的提出以及Docker、Kubernetes技术不断的发展，无状态服务(Stateless Server)、有状态服务(Stateful Service)等均不断地从原有的物理机/虚机部署迁移到容器，而从物理机/虚机等迁移到容器的过程伴随着网络、存储、调度等各种方面的巨大变化，其中网络问题也是一个影响迁移的关键因素。

当前Kubernetes本身提供的外网访问能力有五种，分别是hostNetwork、hostPort、NodePort、LoadBalancer和Ingress。

现有Kubernetes网格框架中，支持的5种外网访问功能无法完全满足定向公网访问Pod、不暴露宿主机IP、尽可能减少IP消耗这三条要求，因此无法完全满足业务服务迁移的网络能力需求。

发明内容

本申请的目的在于提供一种容器化后的业务组件的处理方法及组件、系统，能够减少公网IP地址的占用，从而提高了业务容器的可扩展性。

为实现上述目的，本申请一方面提供一种容器化后的业务组件的处理方法，所述方法包括：服务组件配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；中心查询组件向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；所述中心查询组件根据所述容器信息列表中的公网访问信息，从宿主机处获取各个所述业务容器的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给所述任务派发组件；所述任务派发组件从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。

为实现上述目的，本申请另一方面还提供一种中心查询组件，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联，其中，所述业务容器具备公网访问信息，所述公网访问信息与所述业务容器的内网访问信息相互映射，并且所述公网访问信息基于所述业务容器关联的公网虚拟地址构建得到；所述中心查询组件包括：列表获取单元，用于向服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；状态查询单元，用于根据所述容器信息列表中的公网访问信息，向所述业务容器所在的宿主机发起状态查询请求；所述状态查询请求中的公网访问信息经过所述宿主机转换为相映射的内网访问信息，以基于转换得到的内网访问信息获取业务容器的状态；信息提供单元，用于接收所述业务容器反馈的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给任务派发组件。

为实现上述目的，本申请另一方面还提供一种服务组件，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联；所述服务组件包括：信息配置单元，用于识别目标业务类型下的业务容器，并配置所述业务容器的公网访问信息，所述公网访问信息中包括所述业务容器关联的公网虚拟地址和为所述业务容器分配的公网端口；关系建立单元，用于识别所述业务容器的内网访问信息，所述内网访问信息包括所述业务容器的内网地址和内网端口，并建立所述公网访问信息和所述内网访问信息之间的映射关系；关系下发单元，用于存储所述映射关系，并将所述映射关系下发至所述业务容器所在的宿主机处。

为实现上述目的，本申请另一方面还提供一种容器化后的业务组件系统，所述系统包括服务组件、中心查询组件以及任务派发组件，其中：所述服务组件，用于配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；所述中心查询组件，用于向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；根据所述容器信息列表中的公网访问信息，从宿主机处获取各个所述业务容器的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给所述任务派发组件；所述任务派发组件，用于从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。

本申请提供的技术方案，针对同一业务类型下的多个业务容器，可以关联同一个公网虚拟地址，从而减少公网IP地址的消耗。在将多个业务容器关联至同一个公网虚拟地址后，为了区分各个不同的业务容器，可以为不同的业务容器配置不同的公网访问信息，该公网访问信息可以包括公网虚拟地址和公网端口。外部设备可以针对公网访问信息，向对应的业务容器发起访问。

在业务容器所在的内网，每个业务容器可以具备自身的内网访问信息，该内网访问信息可以包括业务容器的内网地址和内网端口。通过将业务容器的内网访问信息与公网访问信息进行相互映射，在接收到携带公网访问信息的访问请求时，可以将该公网访问信息转换为对应的内网访问信息。最终，根据内网访问信息便可以实现对业务容器的访问。

可见，通过上述的方案，不仅减少了公网IP地址的消耗，同时也能保证外部设备发起的访问请求能够被业务容器正常接收，从而提高了业务容器的扩展性。

附图说明

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

图1是现有技术中的业务组件的访问系统的结构示意图；

图2是本发明实施方式中容器化后的业务组件系统的结构示意图；

图3是本发明实施方式中容器化后的业务组件的访问方法步骤图；

图4是本发明实施方式中中心查询组件的功能模块示意图；

图5是本发明实施方式中容器化后的业务组件的配置方法步骤图；

图6是本发明实施方式中服务组件的功能模块示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

请参阅图1，现有技术中基于Kubernetes技术构建的业务组件的访问系统可以包括任务派发组件、中心查询组件以及各个业务组件。其中，针对每个业务组件，都会分配对应的公网IP地址。业务组件在运行过程中，会主动向中心查询组件上报自身的运行状态。中心查询组件在接收到各个业务组件上报的运行状态后，会对运行状态进行分析，从而确定出各个业务组件当前具备的业务能力。例如，运行状态可以是业务组件的CPU利用率、内存利用率、连接数等能够表征负载状态的参数。通过对这些参数进行分析，可以确定出各个业务组件当前具备的业务能力。该业务能力可以通过量化的指标来表示。例如，该指标可以与CPU利用率、内存利用率以及连接数等成反比，从而代表空闲的资源量。空闲的资源量越多，对应的业务能力就越强。

通过对各个业务组件的业务能力进行分析，可以从众多的业务组件中筛选出业务能力较强的多个候选业务组件。然后，中心查询组件可以将候选业务组件的公网IP地址反馈给任务派发组件。任务派发组件可以根据一致性哈希算法，计算出当前待派发的任务对应的目标业务组件，并将该任务派发至目标业务组件处。

图1所示的系统中，由于每个业务组件都需要占用一个公网IP地址，因此会造成公网IP地址的大量消耗，从而影响业务组件的扩展性。

鉴于此，在本申请中，可以对图1所示的系统中的各个组件进行一定程度的改进，从而在保证任务正常派发的情况下，减少公网IP地址的消耗。

请参阅图2，本申请一个实施方式提供的容器化后的业务组件系统可以包括任务派发组件、中心查询组件、服务组件、服务控制器以及容器化后的各个业务容器。在该系统中，业务容器可以按照业务类型进行划分。对于每个业务容器而言，可以具备自身的内网IP地址以及内网端口，内网IP地址和内网端口的组合可以构成业务容器的内网访问信息。例如，业务类型A1下的一个业务容器，内网访问信息可以表示为IP1：port，其中，IP1表示内网IP地址，对于不同的业务容器，内网IP地址也可以互不相同；port表示内网端口的端口号。这样，内网IP地址与内网端口的组合，可以唯一地表征一个业务容器。

为了减少对公网IP地址的消耗，同一个业务类型下的各个业务容器，可以关联同一个公网虚拟地址，为了区分同类型业务的不同容器，可以为不同的业务容器配置不同的公网端口。这样，公网虚拟地址和公网端口的组合，就可以形成业务容器的公网访问信息。例如，同一个业务类型下的业务容器A和业务容器B，各自的公网访问信息可以表示为公网IP2：port1和公网IP2：port2，其中，公网IP2可以是该业务类型下各个业务容器关联的公网虚拟地址。

在一个实施方式中，服务组件可以通过预先设置的多个方式(例如label和headless service)自动发现挂载于后端的各个业务容器。在发现业务容器的过程中，服务组件可以获取到各个业务容器的内网访问信息。服务组件可以为发现的各个业务容器配置对应的公网访问信息，然后服务组件会为发现的各个业务容器配置对应的公网访问信息映射。具体地，服务组件可以按照业务类型，为不同的业务容器分配不同的公网端口号。需要说明的是，对于不同业务类型下的两个业务容器，可以具备相同的公网端口号，由于这两个业务容器关联的公网虚拟地址不同，因此最终生成的公网访问信息也互不相同。

在本实施方式中，服务组件在为各个业务容器配置了公网访问信息后，可以建立同一个业务容器的公网访问信息和内网访问信息之间的映射关系。这样，公网访问信息后续就可以转换为相关联的内网访问信息。

在实际应用中，服务组件在建立了公网访问信息和内网访问信息的映射关系后，可以存储该映射关系。同时，由于业务容器是部署于宿主机上的，后续宿主机在接收到外部设备发来的请求后，需要将其中的公网访问信息转换为对应的内网访问信息，才能对业务容器正常地进行访问。因此，服务组件可以将建立的映射关系下发至各个宿主机处。

需要说明的是，服务组件可以将当前存在的各个业务容器的映射关系均下发给每一个宿主机。不过在不同的宿主机上，会部署不同的业务容器，因此尽管各个宿主机全量配置了所有的映射关系，但是最终在接收到外部设备发来的请求时，也只会针对部署于本地的业务容器进行访问信息的转换。

请参阅图3，由中心查询组件执行的访问方法，可以包括以下多个步骤。

S11：向服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息。

在本实施方式中，服务组件针对不同业务类型，可以对外提供不同的管理端口。其中，管理端口可以由业务容器的公网虚拟地址和管理端口号共同决定。对于不同的业务类型而言，管理端口中的公网虚拟地址也会不同。

中心查询组件可以向服务组件提供的管理端口发送查询请求。服务组件通过管理端口接收到查询请求后，可以根据接收该查询请求的管理端口，识别出中心查询组件当前需要查询的是哪个业务类型下的业务容器的信息。具体地，服务组件可以将查询请求转发给服务控制器，服务控制器从而可以将对应的业务类型下的各个业务容器的公网访问信息填充于容器信息列表中，并将该容器信息列表反馈给中心查询组件。

S13：根据所述容器信息列表中的公网访问信息，向所述业务容器所在的宿主机发起状态查询请求；所述状态查询请求中的公网访问信息经过所述宿主机转换为相映射的内网访问信息，以基于转换得到的内网访问信息获取业务容器的状态。

具体地，根据所述容器信息列表中的公网访问信息，直接向其发起状态查询请求；所述状态查询请求最终会到达相应宿主机，并经由相应宿主机上的映射规则转换为访问业务容器的内网访问信息，从而获取业务容器的状态。

在本实施方式中，中心查询组件接收到容器信息列表后，可以向对应的业务容器发起状态查询请求，以获知各个业务容器当前的容器状态。该容器状态可以表征业务容器的业务能力。

具体地，中心查询组件可以遍历容器信息列表中的各个公网访问信息，从而向各个业务容器发起状态查询请求。中心查询组件针对公网访问信息发起的状态查询请求可以由业务容器所在的宿主机接收。宿主机接收到状态查询请求后，可以提取其中的公网访问信息。然后，宿主机可以根据服务组件下发的映射关系，查询到该公网访问信息相映射的内网访问信息。然后，宿主机可以基于内网访问信息，对业务容器发起状态查询。在获取到业务容器反馈的容器状态后，宿主机可以将该容器状态提供给中心查询组件。

S15：接收所述业务容器反馈的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给任务派发组件。

在本实施方式中。中心查询组件接收到业务容器反馈的容器状态后，可以对各个业务容器的容器状态进行分析，从而确定出各个业务容器当前的业务能力。为了提高任务的处理效率，中心查询组件可以按照业务能力，对各个业务容器进行排序，并将排名靠前的多个业务容器作为候选业务容器。中心查询组件确定出候选业务容器后，可以将候选业务容器的公网访问信息提供给任务派发组件。

任务派发组件接收到中心查询组件发来的候选业务容器的公网访问信息后，可以采用一致性哈希算法，对待派发的任务进行计算，并根据计算得到的哈希值，从候选业务容器中确定出处理任务的目标业务容器。由于同一个业务类型下的各个业务容器，在公网访问信息中会对应不同的公网端口，因此任务派发组件在进行任务派发时，也需要针对不同的端口来下发任务。而现有技术中通过一致性哈希算法来确定业务组件时，只是对业务组件的公网IP地址进行选择，下发任务的端口都是相同的。因此，与现有技术相比，任务派发组件从按照固定端口下发任务转变为了按照不同的端口下发任务。

通过上述的描述可见，现有技术中是由业务组件上报自身的运行状态，但在本申请中，是由中心查询组件去主动查询各个业务容器的容器状态。此外，在本申请中，服务组件的改动都是在TCP/IP的四层逻辑上实现的，并不涉及七层的改动。因此，服务组件的改动与实际的业务无关，可以应用于需要单独向外暴露业务容器的通用场景。上述的服务组件也可以作为新的CRD(Custom Resource Definition，用户自定义资源)，从而不会影响原先的服务组件和Kubernetes原有的功能逻辑。

请参阅图4，本申请还提供一种中心查询组件，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联，其中，所述业务容器具备公网访问信息，所述公网访问信息与所述业务容器的内网访问信息相互映射，并且所述公网访问信息基于所述业务容器关联的公网虚拟地址构建得到；所述中心查询组件包括：

列表获取单元，用于向服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；

状态查询单元，用于根据所述容器信息列表中的公网访问信息，向所述业务容器所在的宿主机发起状态查询请求；所述状态查询请求中的公网访问信息经过所述宿主机转换为相映射的内网访问信息，以基于转换得到的内网访问信息获取业务容器的状态；

具体地，状态查询单元可以用于根据所述容器信息列表中的公网访问信息，直接向其发起状态查询请求；所述状态查询请求最终会到达相应宿主机，并经由相应宿主机上的映射规则转换为访问业务容器的内网访问信息，从而获取业务容器的状态。

信息提供单元，用于接收所述业务容器反馈的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给任务派发组件。

请参阅图5，本申请还提供一种容器化后的业务组件的配置方法，该方法可以由上述的服务组件执行，所述方法包括以下多个步骤。

S21：识别目标业务类型下的业务容器，并配置所述业务容器的公网访问信息，所述公网访问信息中包括所述业务容器关联的公网虚拟地址和为所述业务容器分配的公网端口；

S23：识别所述业务容器的内网访问信息，所述内网访问信息包括所述业务容器的内网地址和内网端口，并建立所述公网访问信息和所述内网访问信息之间的映射关系；

S25:存储所述映射关系，并将所述映射关系下发至所述业务容器所在的宿主机处。

在一个实施方式中，所述方法还包括：

在接收到中心查询组件发来的查询请求后，获取各个所述业务容器的公网访问信息，并将获取的所述公网访问信息反馈给所述中心查询组件。

在一个实施方式中，服务组件提供有管理端口，所述管理端口由业务容器的公网虚拟地址和管理端口号共同决定；

所述中心查询组件发来的所述查询请求由所述管理端口接收；其中，不同业务类型可以对应不同的管理端口。

请参阅图6，本申请还提供一种服务组件，所述服务组件包括：

信息配置单元，用于识别目标业务类型下的业务容器，并配置所述业务容器的公网访问信息，所述公网访问信息中包括所述业务容器关联的公网虚拟地址和为所述业务容器分配的公网端口；

关系建立单元，用于识别所述业务容器的内网访问信息，所述内网访问信息包括所述业务容器的内网地址和内网端口，并建立所述公网访问信息和所述内网访问信息之间的映射关系；

关系下发单元，用于存储所述映射关系，并将所述映射关系下发至所述业务容器所在的宿主机处。

本申请还提供一种容器化后的业务组件系统，请参阅图2，所述系统包括服务组件、中心查询组件以及任务派发组件，其中：

所述服务组件，用于配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；

所述中心查询组件，用于向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；根据所述容器信息列表中的公网访问信息，从业务容器处获取各个所述业务容器的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给所述任务派发组件；

所述任务派发组件，用于从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。

本申请提供的技术方案，针对同一业务类型下的多个业务容器，可以关联同一个公网虚拟地址，从而减少公网IP地址的消耗。在将多个业务容器关联至同一个公网虚拟地址后，为了区分各个不同的业务容器，可以为不同的业务容器配置不同的公网访问信息，该公网访问信息可以包括公网虚拟地址和公网端口。外部设备可以针对公网访问信息，向对应的业务容器发起访问。

在业务容器所在的内网，每个业务容器可以具备自身的内网访问信息，该内网访问信息可以包括业务容器的内网地址和内网端口。通过将业务容器的内网访问信息与公网访问信息进行相互映射，在接收到携带公网访问信息的访问请求时，可以将该公网访问信息转换为对应的内网访问信息。最终，根据内网访问信息便可以实现对业务容器的访问。

可见，通过上述的方案，不仅减少了公网IP地址的消耗，同时也能保证外部设备发起的访问请求能够被指定业务容器正常接收，从而提高了业务容器的扩展性，并满足了业务容器的特定指向性。

本领域技术人员可以理解，实现上述实施方式方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施方式的流程。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(Random AccessMemory，RAM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等；所述存储介质还可以包括上述种类的存储器的组合。

本说明书中的各个实施方式均采用递进的方式描述，各个实施方式之间相同相似的部分互相参见即可，每个实施方式重点说明的都是与其他实施方式的不同之处。尤其，针对系统和工作节点的实施方式来说，均可以参照前述方法的实施方式的介绍对照解释。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种容器化后的业务组件的处理方法，其特征在于，所述方法包括：

服务组件配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；

中心查询组件向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；

所述中心查询组件根据所述容器信息列表中的公网访问信息，从宿主机处获取各个所述业务容器的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给所述任务派发组件；

所述任务派发组件从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。

2.根据权利要求1所述的方法，其特征在于，从宿主机处获取各个所述业务容器的容器状态包括：

向所述业务容器所在的宿主机发起状态查询请求，所述状态查询请求中的公网访问信息经过所述宿主机转换为相映射的内网访问信息，以基于转换得到的内网访问信息获取业务容器的状态。

3.根据权利要求1所述的方法，其特征在于，所述公网访问信息包括业务容器的公网虚拟地址和公网端口，所述内网访问信息包括业务容器的内网地址和内网端口；其中，同一业务类型下的各个业务容器具备不同的内网地址。

4.根据权利要求1或3所述的方法，其特征在于，所述服务组件提供有管理端口，所述管理端口由业务容器的公网虚拟地址和管理端口号共同决定；中心查询组件向所述服务组件发送查询请求包括：

中心查询组件向所述服务组件提供的所述管理端口发送所述查询请求；其中，不同业务类型对应不同的管理端口。

5.根据权利要求1所述的方法，其特征在于，所述业务容器的公网访问信息和内网访问信息的映射关系存储于所述服务组件和所述宿主机中；其中，所述宿主机根据存储的所述映射关系，将所述状态查询请求中的公网访问信息转换为相映射的内网访问信息。

6.根据权利要求1所述的方法，其特征在于，在建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系之后，所述方法还包括：

所述服务组件存储所述映射关系，并将所述映射关系下发至所述业务容器所在的宿主机处。

7.根据权利要求6所述的方法，其特征在于，所述方法还包括：

所述服务组件在接收到所述中心查询组件发来的查询请求后，获取各个所述业务容器的公网访问信息，并将获取的所述公网访问信息反馈给所述中心查询组件。

8.根据权利要求1所述的方法，其特征在于，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联，其中，所述业务容器具备公网访问信息，所述公网访问信息与所述业务容器的内网访问信息相互映射，并且所述公网访问信息基于所述业务容器关联的公网虚拟地址构建得到。

9.一种中心查询组件，其特征在于，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联，其中，所述业务容器具备公网访问信息，所述公网访问信息与所述业务容器的内网访问信息相互映射，并且所述公网访问信息基于所述业务容器关联的公网虚拟地址构建得到；所述中心查询组件包括：

列表获取单元，用于向服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；

状态查询单元，用于根据所述容器信息列表中的公网访问信息，向所述业务容器所在的宿主机发起状态查询请求；所述状态查询请求中的公网访问信息经过所述宿主机转换为相映射的内网访问信息，以基于转换得到的内网访问信息获取业务容器的状态；

信息提供单元，用于接收所述业务容器反馈的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给任务派发组件。

10.一种服务组件，其特征在于，同一业务类型下的各个业务容器与同一个公网虚拟地址相关联；所述服务组件包括：

信息配置单元，用于识别目标业务类型下的业务容器，并配置所述业务容器的公网访问信息，所述公网访问信息中包括所述业务容器关联的公网虚拟地址和为所述业务容器分配的公网端口；

关系建立单元，用于识别所述业务容器的内网访问信息，所述内网访问信息包括所述业务容器的内网地址和内网端口，并建立所述公网访问信息和所述内网访问信息之间的映射关系；

关系下发单元，用于存储所述映射关系，并将所述映射关系下发至所述业务容器所在的宿主机处。

11.一种容器化后的业务组件系统，其特征在于，所述系统包括服务组件、中心查询组件以及任务派发组件，其中：

所述服务组件，用于配置业务容器的公网访问信息，并建立所述公网访问信息和所述业务容器的内网访问信息之间的映射关系；

所述中心查询组件，用于向所述服务组件发送查询请求，并接收所述服务组件反馈的容器信息列表，所述容器信息列表中包括各个业务容器的公网访问信息；根据所述容器信息列表中的公网访问信息，从宿主机处获取各个所述业务容器的容器状态，并根据所述容器状态筛选出候选业务容器，并将所述候选业务容器的公网访问信息提供给所述任务派发组件；

所述任务派发组件，用于从所述候选业务容器中确定目标业务容器，并将任务下发至所述目标业务容器处进行处理。

Images