CN109688011A - 一种基于OpenStack的agent选择方法及装置 - Google Patents

Abstract

本申请提供一种基于OpenStack的服务代理进程agent选择方法及装置，涉及网络通信技术领域，能够解决因控制节点中部署的agent服务失效所导致的数据配置失败的技术问题。该方法包括：云服务器接收用于实现数据配置的消息；根据消息中携带的用户标识，确定部署在各节点上的与用户标识对应的agent；在用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent；将消息通过RPC服务器向目标agent发送，以使目标agent处理消息。本申请适用于云服务器的agent选择过程。

Description

一种基于OpenStack的agent选择方法及装置

技术领域

本申请涉及网络通信技术领域，尤其涉及一种基于OpenStack的服务代理进程(agent)选择方法及装置。

背景技术

OpenStack是一个开源的云计算管理平台项目，可以通过部署在OpenStack中的多个组件的组合来实现相应功能。其中，Neutron作为OpenStack提供的一项服务，可以为OpenStack中的其他服务提供网络连接。在应用过程中，Neutron可以为租户提供核心服务，比如，Neutron可以通过提供虚拟的网络(network)、子网(subnet)及路由器(router)等组件来为租户提供核心服务。在一种实现方式中，Neutron还可以为租户提供扩展网络服务。其中，扩展网络服务可以为防火墙即服务(Fire Wall as a Service，FWaaS)等。

以FWaaS为例，租户/工作人员可以在显示屏展示的界面上，对防火墙进行数据配置。在用于实现数据配置的消息传送到相应的控制节点(controller)后，控制节点可以将消息传送给部署在控制节点上的agent对消息进行处理，以完成防火墙的数据配置。

在上述实现过程中，一旦agent因故障等原因造成死机，使agent服务失效，那么租户/工作人员就无法成功完成防火墙的数据配置，从而导致数据配置失败。

发明内容

有鉴于此，本申请提供一种基于OpenStack的agent选择方法及装置，能够解决因控制节点中部署的agent服务失效所导致的数据配置失败的技术问题。

具体地，本申请是通过如下技术方案实现的：

一种基于OpenStack的agent选择方法。该方法应用于一种网络系统，网络系统至少包括至少一个云服务器和远程过程调用RPC服务器；其中，每个云服务器上部署至少一个控制节点。

该方法包括：

云服务器接收用于实现数据配置的消息；根据消息中携带的用户标识，确定部署在各节点上的与用户标识对应的agent；在用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent；将消息通过RPC服务器向目标agent发送，以使目标agent处理消息。

一种基于OpenStack的agent选择装置。该装置应用于一种网络系统，网络系统至少包括至少一个云服务器和远程过程调用RPC服务器；其中，每个云服务器上部署至少一个控制节点。

该装置包括：

通信单元，用于接收用于实现数据配置的消息。

处理单元，用于根据通信单元接收的消息中携带的用户标识，确定部署在各节点上的与用户标识对应的agent。

处理单元，还用于在用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent。

通信单元，还用于将消息通过RPC服务器向处理单元确定的目标agent发送，以使目标agent处理消息。

由以上本申请提供的技术方案可见，相比较于现有技术，本申请提供的技术方案，能够使云服务器从诸多agent中选择目标agent处理云服务器接收到的消息。即从部署在不同节点(即多个控制节点，或是单个控制节点及至少一个除控制节点以外的节点)上的多个agent中，选择活跃agent提供服务。这样能够避免因消息传送给死机的agent，而导致的接收消息的agent无法为租户/工作人员提供相应服务的问题。并且，采用本申请实施例提供的高可用性(High Availability，HA)的agent选择方案，能够充分利用部署在各节点上的agent，达到agent的高可用。

附图说明

图1为本申请实施例提供的网络系统结构示意图一；

图2为本申请实施例提供的网络系统结构示意图二；

图3为本申请实施例提供的方法流程图一；

图4为本申请实施例提供的方法流程图二；

图5为本申请实施例提供的agent列表、第一列表及第二列表的生成关系示意图；

图6为本申请实施例提供的一种装置结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例提供一种网络系统，该网络系统至少包括至少一个云服务器和远程过程调用(Remote Procedure Call，RPC)服务器。其中，每个云服务器上部署至少一个控制节点。在本申请实施例中，通过多节点(即多个控制节点，或是单个控制节点及至少一个除控制节点以外的节点)的HA来解决现有技术中因控制节点中部署的agent服务失效所导致的数据配置失败的技术问题。

如图1所示，为本申请实施例适用的一种网络系统的结构示意图，其中，在该网络系统中部署了多个控制节点。HAProxy作为一个用于实现负载均衡的软件，可以运行在大部分的Linux操作系统上。在云服务器调用HAProxy实现负载均衡后，可以将租户/工作人员输入的用于实现诸如数据配置的消息，传送给部署在相应控制节点的neutron-server进行处理。比如，在云服务器调用HAProxy后，将接收到的消息传送给部署在控制节点B上的neutron-server进行处理。

需要说明的是，调用HAProxy后进行负载均衡的具体实现方式，可以参考现有技术中与负载均衡相关的内容，在此不予赘述。并且，在本申请实施例中，对于确定将接收到的消息发送给哪一个或是多个控制节点上的neutron-server的实现方式不予限定。

其中，neutron-server作为Neutron的核心组件之一，可以负责接收外部发送的请求，并基于请求调度后端相应的插件(plugin)进行处理。在图1所示的场景中，以租户/工作人员输入的消息为用于实现防火墙数据配置的消息为例，在部署在控制节点B上的neutron-server接收到该消息后，可以调度部署在节点B上的防火墙插件(即图1中节点B中的plugin)进行相应处理。

参考图1，控制节点B中的neutron-server可以采用本申请实施例下文提供的选择agent的实现方式，来选择合适的agent对控制节点B接收到的消息进行处理，比如，图1中示出的部署在控制节点A上的agent_A。例如，agent_A将租户/工作人员输入的数据存储到数据库中，以完成基于防火墙的数据配置过程。需要说明的是，在实现过程中，neutron-server需要通过RPC服务器(图1中未示出)将消息发送给相应的agent。

相比较与现有技术，对于控制节点而言，在控制节点上部署的neutron-server接收到消息后，可以基于各控制节点上已部署的agent的状态，选择合适的agent来完成基于消息的处理过程。其中，具体实现过程可以参考下文。

如图2所示，为本申请实施例适用的另一种网络系统的结构示意图，其中，在该网络系统中部署了单个控制节点。对于单控制节点的情况，为了使neutron-server能够有选择性的调用agent，在本申请实施例的实现过程中，在原有网络系统架构的部署基础上，在除控制节点以外的至少一个节点上部署agent。比如，在图2所示的场景中，需要在节点D和节点F上分别部署agent，即在节点D上部署agent_D，且在节点F上部署agent_F。这样对于部署在控制节点E上的neutron-server而言，可以有选择性的将消息发送给合适的agent，比如，图2所示的neutron-server将消息传送给agent_D处理。

需要说明的是，对于单个控制节点的场景，除了agent的部署方式有所不同外，关于agent选择及后续将消息传送给相应agent进行处理的过程均类似，在此不予赘述。

下面结合本申请实施例提供的基于OpenStack的agent选择方法，对本申请实施例提供的技术方案进行进一步阐述。

如图3所示，该方法可以包括S101至S104。

S101、云服务器接收用于实现数据配置的消息。

S102、根据消息中携带的用户标识，确定部署在各节点上的与用户标识对应的agent。

响应于云服务器接收到的消息，云服务器可以从消息中获取用户标识，以根据用户标识从网络系统中已部署的多个agent中，确定与该用户标识对应的agent。其中，用户标识可以用于区分为租户提供服务的服务方，比如，用于表示某一家为租户提供服务的企业的名称等。在一种实现方式中，用户标识可以为字符或字符串等，在本申请实施例中，对于用户标识的设置方式、表现形式等不予限定。

在本申请实施例中，云服务器中可以预先存储agent列表。其中，agent列表中包括网络系统中部署的所有agent的相关信息，该相关信息具体可以包括但不限于agent对应的用户标识、agent的代理标识(比如，agent对应的标题(topic))，以及agent所在节点的互联网协议地址(Internet Protocol Address，IP地址)。

S103、在用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent。

用于确定活跃agent的方式多种多样。比如，在agent列表中还可以记载agent是否活跃的状态信息，这样云服务器就可以根据agent列表中记载的内容来确定各agent是否活跃。再比如，可以预先规定各agent周期性向云服务上报各agent的状态信息，那么可以根据各agent是否周期性上报状态消息，来确定周期性上报状态消息的agent为活跃agent，而未按照周期上报状态消息的agent，即达到周期所规定的时间仍未上报状态消息的agent为非活跃agent。

上述例举了两种用于确定活跃agent的实现方式，但在实现过程中，还可以采用其他实现手段来进行agent是否活跃的判断，在此不一一例举。

S104、将消息通过RPC服务器向目标agent发送，以使目标agent处理消息。

在确定目标agent之后，neutron-server可以使用目标agent对应的topic及目标agent所在节点的IP地址，对消息进行处理，并将处理后的消息通过RPC服务器发送给目标agent。

其中，topic的内容可以包括agent对应的用户标识及agent所在节点的IP地址。在本申请实施例中，从多个agent中选择的与用户标识对应的agent的用户标识可以为agent的关键字，比如，该关键字可以表示为dp。

需要说明的是，agent处理消息的过程可以参考现有技术中agent基于消息实现相应处理的具体过程，在此不予赘述。

相比较于现有技术，本申请实施例提供的技术方案，能够使云服务器从诸多agent中选择目标agent处理云服务器接收到的消息。即从部署在不同节点(即多个控制节点，或是单个控制节点及至少一个除控制节点以外的节点)的多个agent中，选择活跃agent提供服务。这样能够避免因消息传送给死机的agent，而导致的接收消息的agent无法为租户/工作人员提供相应服务的问题。并且，采用本申请实施例提供的HA的agent选择方案，能够充分利用部署在各节点上的agent，达到agent的高可用。

考虑到活跃agent可能存在多个，那么为了进一步提升消息处理效率，在本申请实施例的一种实现方式中，可以结合各活跃agent的负载情况选定相应的目标agent。即S103可以具体实现为S1031。

S1031、在用户标识对应的agent中，若确定出多个活跃agent时，根据各活跃agent的负载情况，选择作为目标agent的活跃agent。

具体实现过程如下：

若各活跃的agent中存在满足预设条件的agent，则在负载情况满足预设条件的活跃agent中，选择作为目标agent的活跃agent；否则，将各活跃agent中负载最小的agent，作为目标agent。

其中，负载情况满足预设条件的活跃agent包括中央处理器(Central ProcessingUnit，CPU)利用率小于第一阈值的活跃agent，和/或，内存使用率小于第二阈值的活跃agent。

上述第一阈值和第二阈值可以预先设定，对于第一阈值与第二阈值的取值，可以根据具体的应用场景，或是待处理的消息所需要占用资源的情况等进行调整。需要说明的是，第一阈值与第二阈值的取值可以相同或不同。比如，在一种实现方式中，第一阈值与第二阈值的取值相同，可以设置为80％。

在本申请实施例中，在负载情况满足预设条件的活跃agent中，选择作为目标agent的活跃agent，可以有多种实现方式。

比如，在满足预设条件的agent中，选择资源占用最小的agent作为目标agent。

再比如，在满足预设条件的agent中，随机选择活跃的agent作为目标agent。

又比如，在满足预设条件的agent中，依次对agent进行判断，在确定出可以作为目标agent的活跃agent之后停止判断操作，即不在对未进行判断的agent进行额外的判断操作。也就是，按照agent的相关信息在agent列表中的排列顺序，逐个或是逐批(每批包括多个agent的相关信息)对agent进行筛选，在找到可以作为目标agent的活跃agent之后，可以停止本次遍历操作，将已找到的可以作为目标agent的活跃agent，作为目标agent。

若各活跃的agent中不存在满足预设条件的agent，则将各活跃agent中负载最小的agent，作为目标agent。

也就意味着，各活跃的agent均处于繁忙状态(处于繁忙状态的agent的负载较高)，那么可以将各活跃agent中CPU利用率最小或是内存使用率最小的agent，作为目标agent。

考虑到在内存不足的情况下，即便agent的CPU利用率较低，也会导致agent无法处理消息的情况，因此，在一种实现方式中，可以优选将各活跃agent中CPU利用率最小的agent，作为目标agent。

考虑到CPU利用率及内存使用率会对agent处理消息的过程带来不同程度的影响，因此，在另一种实现方式中，可以权衡CPU利用率及内存使用率对本次消息处理过程可能带来的影响，之后从多个活跃agent中选择适用于本次处理过程的agent。此时，作为目标agent的活跃agent的CPU利用率或内存使用率往往不是多个活跃agent中最小的。比如，预先对CPU利用率及内存使用率分别设置权重，之后计算用于表示agent的负载情况的参数，以将得到的参数中最小参数对应的agent确定为目标agent。其中，针对每个agent对应参数的计算方式可以为：CPU利用率*CPU利用率对应的权重+内存使用率*内存使用率对应的权重。其中，CPU利用率对应的权重与内存使用率对应的权重相加为1。需要说明的是，在本申请实施例中，对于CPU利用率对应的权重与内存使用率对应的权重的取值不予限定。

由此可见，在结合agent的负载情况从多个活跃agent中筛选目标agent的方式多种多样，具体筛选过程包括但不限于上述例举的情况。并且，考虑到反映agent负载情况的参数包括但不限于CPU利用率及内存使用率，因此，在实现过程中，还可以参考其他能够获取到的用于反应agent负载情况的参数。

考虑到相比较于使用非本端云服务器上部署的agent，使用本端云服务器上部署的agent能够有效节省消息传输过程所耗费的资源，因此，在本申请实施例的一种实现方式中，可以由云服务器预先建立用于记载各agent的相关信息的第一列表，并按照agent所在云服务器是否为本端为基准，在各agent的相关信息写入第一列表的过程中，调整第一列表中产生写入操作的位置，从而使选择目标agent时，优先从本端云服务器上部署的agent中选择。

在本申请实施例提供的方法流程中，如图4所示，还可以包括S201至S205，或是S201至S204及S206。

S201、云服务器预先建立第一列表。

需要说明的是，云服务器预先建立的第一列表可以为空的列表。

S202、针对用户标识，确定部署在各节点上的与用户标识对应的agent。

S203、确定与用户标识对应的agent的代理标识和IP地址。

云服务器可以从agent列表中获取部署在各节点上的与用户标识对应的agent，以及该agent的相关信息。在S203中，以相关信息为agent的代理标识和IP地址为例进行描述，需要了解的是，相关信息可以包括但不限于agent的代理标识和IP地址。

S204、针对确定出的与用户标识对应的每个agent，判断该agent所在节点是否为云服务器上部署的节点。若是，则执行S205；否则，执行S206。

对于确定出的与用户标识对应的每个agent，均可以执行上述判断操作，即判断当前这个agent所在的节点是否部署在该云服务器上。也就意味着，确定该agent是否为本端云服务器上部署的agent。

S205、将该agent的代理标识和IP地址插入到第一列表中的首位。

S206、将该agent的代理标识和IP地址插入到第一列表中的末位。

对于agent为本端云服务器上部署的agent的情况，则在将该agent的相关信息存储到第一列表时，将该agent的相关信息插入到第一列表中的首位。并且，对于agent为非本端云服务器上部署的agent的情况，则在将该agent的相关信息存储到第一列表时，将该agent的相关信息插入到第一列表中的末位。

这样在后续挑选agent的过程中，若是根据第一列表中agent的相关信息的排列顺序，依次确定agent是否为目标agent，即按照第一列表的顺序逐个或是逐批进行筛选，就可以优先考虑本端云服务器上部署的agent，以在条件允许的情况下，尽可能减少传输资源。

为了方便后续筛选，在生成第一列表之后，可以将第一列表中状态信息为活跃状态的agent的相关信息进行整理，以得到第二列表。也就意味着，第一列表所记载相关信息对应的agent的数量，大于或是等于第二列表所记载相关信息对应的agent的数量。并且，对于同一agent而言，第一列表和第二列表中所记载的该agent的相关信息可以相同或是部分相同。

在一种实现方式中，生成第二列表的过程可以实现为S301。

S301、按照第一列表中各agent的代理标识的排列顺序，依次将第一列表中状态信息为活跃状态的agent的代理标识，写入第二列表。

这样，S103就可以实现为S1032。

S1032、在用户标识对应的agent中，按照预设规则，根据第二列表，确定活跃agent为目标agent。

其中，根据第二列表，确定活跃agent为目标agent，可以指的是按照第二列表中记载的各活跃agent的排列顺序，逐个或是逐批确定出作为目标agent的活跃agent。

需要说明的是，按照预设规则，确定活跃agent为目标agent的具体实现方式已在上文描述，将相应内容套用至以第二列表为依据的实现方案中即可，对于具体实现过程可以参考上文，在此不予赘述。

为了能够准确掌握网络系统中各agent的状态信息，在本申请实施例的一种实现方式中，可以预先规定网络系统中各agent主动或是被动上报该agent的状态信息。因此，在第二列表已形成后，该方法流程还可以包括S302和S303。

S302、通过各控制节点，接收各agent上报的状态消息。

其中，状态消息至少包括agent所在节点的IP地址、topic，以及agent的状态信息。

agent可以按照预设的上报机制，周期或是非周期性将该agent的状态消息上报给相应的控制节点。比如，在agent采用周期性上报的方式上报该agent的状态消息时，上报周期可以被设置为10秒。需要说明的是，在本申请实施例中，对于上报周期的设置方式、具体取值等不予限定，可以结合应用场景、云服务器的负载情况等诸多因素中的一项或是多项进行调整。

以图1所示的应用场景为例，针对每个agent而言，该agent可以将状态消息通过该agent所在控制节点的neutron-server传送给云服务器。比如，agent_C可以将状态消息通过控制节点C的neutron-server传送给云服务器。

S303、根据状态信息，更新第二列表。

在执行完S302之后，可以由相应的控制节点周期或是非周期性将接收到的各agent上报的状态消息更新到第二列表中。

比如，在控制节点长期未接收到agent上报的状态消息的情况下，控制节点可以确定该agent当前不是活跃agent。由于第二列表中仅记载了活跃agent的相关信息，因此，可以将第二列表中该agent的相关信息删除，或是将该agent的状态信息从活跃修改为不活跃等。

再比如，控制节点接收到未处于第二列表中的agent发送的状态消息，那么可以将该agent的相关信息写入第二列表，供后续使用。

需要说明的是，更新第二列表的方式包括但不限于上述例举的情况。在一种实现方式中，云服务器还可以根据各agent周期上报的内容逐个更新agent列表、第一列表及第二列表，或是逐个更新第一列表和第二列表。在本申请实施例中，对于云服务器是直接更新第二列表，还是通过更新其他列表，以根据其他列表进一步更新第二列表的方式，最终实现第二列表的更新，不予限定。

在本申请实施例中，第二列表是根据第一列表以及各agent上报的状态消息生成的，而各agent在上报过程中是非实时性的上报，因此，很可能在agent完成一次状态消息的上报后出现死机的情况，而此时第二列表并未被更新，从而导致死机的agent仍处于第二列表中，进而有可能导致云服务器选择的目标agent为该死机的agent，最终影响处理过程。

为了避免上述问题的发生，在本申请实施例的一个实现方式中，基于第二列表中记载的状态信息为活跃状态的agent的代理标识，可以执行S401和S402，以刷新第二列表中记载的内容，即对第二列表中记载的各状态信息对应的agent的实际状态进行判别，并将实际死机的agent的相关信息从第二列表中删除，以保证第二列表中各状态信息对应的agent为实际活跃的agent。

在S103之前，该方法还包括：

S401、针对第二列表中的每个agent，通过RPC服务器向该agent发送用于检测该agent是否死机的检测消息。

其中，检测消息用于检测agent是否死机。在本申请实施例中，检测消息可以为向agent周期性发送的调用消息，以根据agent是否应答来确定应答的agent可以被调用，而未应答的agent无法被调用。或者，检测消息可以为心跳报文，以使agent接收到心跳报文后返回响应消息，从而根据是否接收到响应消息来确定接收到响应消息则表示agent未死机，否则agent死机。

以检测消息为RPC呼叫(RPC call)消息为例，对于每个状态信息为活跃状态的agent，在本申请实施例中，可以由neutron-server通过RPC服务器向该agent发送RPC呼叫消息。

S402、在预设时间内，若接收到该agent反馈的应答消息，则确定该agent为活跃agent。

若在预设时间内，neutron-server接收到该agent基于RPC呼叫消息所发送的应答消息，则确定该agent为实际活跃的agent，即活跃agent；否则，确定该agent为非活跃agent，即agent可能死机。

考虑到响应的延时，比如，agent的负载情况等会对agent响应RPC呼叫消息的时间造成影响，因此，在本申请实施例的一个实现方式中，可以向同一agent周期性发送多条RPC呼叫消息，以减少将活跃agent确定为非活跃agent的情况。其中，向同一agent周期性发送RPC呼叫消息的数量，以及发送周期等可以预先设定，在本申请实施例中，对于设置方式、具体的取值等不予限定。比如，可以预先设定向同一agent周期性发送RPC呼叫消息的数量不超过3条，发送周期为40毫秒。需要说明的是，若向同一agent周期性发送RPC呼叫消息的数量还未达到3条，就已经接收到该agent发送的响应消息，那么可以不再向该agent继续发送RPC呼叫消息，从而节省传输资源。

下面参照图5，结合具体实例，对本申请实施例中提出的agent列表、第一列表及第二列表之间的关系进行进一步说明。

1、在网络系统存储的agent列表中，选择用户标识为用户标识1的agent的相关信息，以生成第一列表。

其中，由于本端云服务器上部署的节点的IP地址为IP2和IP4，因此，在将用户标识为用户标识1的agent的相关信息写入第一列表时，需要对该agent所在节点的IP地址进行判断。以将本端云服务器上部署的agent的相关信息插入第一列表的首位，将非本端云服务器上部署的agent的相关信息插入第一列表的末位。

2、在得到第一列表后，需要将第一列表中各agent按照该agent上报的状态信息，来确定状态信息为活跃状态的agent的相关信息写入第二列表。

3、得到第二列表之后，对第二列表中各agent的实际状态进行确定，以将实际非活跃的agent的相关信息从第二列表中删除，得到最终的第二列表，在最终的第二列表中记载这实际活跃的agent的相关信息。

需要说明的是，图5中示出了agent列表、第一列表及第二列表中记载了agent的代理标识及agent所在节点的IP地址的情况。在实际维护列表过程中，可以将诸如agent的状态信息等内容写入部分或是全部列表中，在此对于agent列表、第一列表及第二列表中记载的内容不予限定。

在本申请实施例提供的技术方案中，不考虑agent列表中不存在所需用户标识对应agent的相关信息的情况。并且，在本申请实施例提供的技术方案中，认为存在活跃agent提供消息处理过程。

需要说明的是，若根据agent的状态消息发现第一列表中不存在活跃agent，那么可以在租户/工作人员执行相应配置操作的界面上提示配置失败等内容，以使工作人员对网络系统进行维护。

本申请实施例提供一种基于OpenStack的服务代理进程agent选择装置。该装置应用于一种网络系统，网络系统至少包括至少一个云服务器和RPC服务器；其中，每个云服务器上部署至少一个控制节点。

如图6所示，装置50包括：

通信单元51，用于接收用于实现数据配置的消息。

处理单元52，用于根据通信单元51接收的消息中携带的用户标识，确定部署在各节点上的与用户标识对应的agent。

处理单元52，还用于在用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent。

通信单元51，还用于将消息通过RPC服务器向处理单元52确定的目标agent发送，以使目标agent处理消息。

在一种实现方式中，处理单元52，具体用于：

当在用户标识对应的agent中，确定出多个活跃agent时，根据各活跃agent的负载情况，选择作为目标agent的活跃agent。

在一种实现方式中，处理单元52，还用于预先建立第一列表；针对用户标识，确定部署在各节点上的与用户标识对应的agent；确定与用户标识对应的agent的代理标识和IP地址；针对确定出的与用户标识对应的每个agent，判断该agent所在节点是否为云服务器上部署的节点。

装置50还包括存储单元53：

存储单元53，用于若是，则将该agent的代理标识和IP地址插入到第一列表中的首位；否则，将该agent的代理标识和IP地址插入到第一列表中的末位。

在一种实现方式中，存储单元53，还用于按照第一列表中各agent的代理标识的排列顺序，依次将第一列表中状态信息为活跃状态的agent的代理标识，写入第二列表。

处理单元52，具体用于：

根据存储单元存储的第二列表，确定活跃agent为目标agent。

在一种实现方式中，通信单元51，还用于通过各控制节点，接收各agent上报的状态消息，状态消息至少包括agent所在节点的IP地址、标题topic，以及agent的状态信息。

存储单元53，还用于根据通信单元接收的状态信息，更新第二列表。

在一种实现方式中，第二列表用于记载状态信息为活跃状态的agent的代理标识。通信单元51，还用于针对第二列表中的每个agent，通过RPC服务器向该agent发送用于检测该agent是否死机的检测消息。

处理单元52，还用于在预设时间内，若通信单元51接收到该agent反馈的应答消息，则确定该agent为活跃agent。

在一种实现方式中，处理单元52，具体用于：

若各活跃的agent中存在满足预设条件的agent，则在负载情况满足预设条件的活跃agent中，选择作为目标agent的活跃agent；否则，将各活跃agent中负载最小的agent，作为目标agent。

其中，负载情况满足预设条件的活跃agent包括中央处理器CPU利用率小于第一阈值的活跃agent，和/或，内存使用率小于第二阈值的活跃agent。

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

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

Claims (14)

1.一种基于OpenStack的服务代理进程agent选择方法，其特征在于，所述方法应用于一种网络系统，所述网络系统至少包括至少一个云服务器和远程过程调用RPC服务器；其中，每个云服务器上部署至少一个控制节点；

所述方法包括：

云服务器接收用于实现数据配置的消息；

根据所述消息中携带的用户标识，确定部署在各节点上的与所述用户标识对应的agent；

在所述用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent；

将所述消息通过所述RPC服务器向所述目标agent发送，以使所述目标agent处理所述消息。

2.如权利要求1所述的方法，其特征在于，按照预设规则，确定活跃agent为目标agent，具体包括：

当在所述用户标识对应的agent中，确定出多个活跃agent时，根据各活跃agent的负载情况，选择作为所述目标agent的活跃agent。

3.如权利要求1所述的方法，其特征在于，所述方法还包括：

所述云服务器预先建立第一列表；

针对所述用户标识，确定部署在各节点上的与所述用户标识对应的agent；

确定与所述用户标识对应的agent的代理标识和互联网协议IP地址；

针对确定出的与所述用户标识对应的每个agent，判断该agent所在节点是否为所述云服务器上部署的节点；

若是，则将该agent的代理标识和IP地址插入到所述第一列表中的首位；

否则，将该agent的代理标识和IP地址插入到所述第一列表中的末位。

4.如权利要求3所述的方法，其特征在于，所述方法还包括：

按照所述第一列表中各agent的代理标识的排列顺序，依次将所述第一列表中状态信息为活跃状态的agent的代理标识，写入第二列表；

确定活跃agent为目标agent，具体包括：

根据所述第二列表，确定活跃agent为目标agent。

5.如权利要求4所述的方法，其特征在于，所述方法还包括：

通过各控制节点，接收各agent上报的状态消息，所述状态消息至少包括agent所在节点的IP地址、标题topic，以及agent的状态信息；

根据所述状态信息，更新所述第二列表。

6.如权利要求1至5中任意一项所述的方法，其特征在于，第二列表用于记载状态信息为活跃状态的agent的代理标识；

在按照预设规则，确定活跃agent为目标agent之前，所述方法还包括：

针对所述第二列表中的每个agent，通过所述RPC服务器向该agent发送用于检测该agent是否死机的检测消息；

在预设时间内，若接收到该agent反馈的应答消息，则确定该agent为活跃agent。

7.如权利要求2所述的方法，其特征在于，根据各活跃agent的负载情况，选择作为所述目标agent的活跃agent，具体包括：

若各活跃的agent中存在满足预设条件的agent，则在负载情况满足所述预设条件的活跃agent中，选择作为所述目标agent的活跃agent；

否则，将各活跃agent中负载最小的agent，作为所述目标agent；

其中，负载情况满足所述预设条件的活跃agent包括中央处理器CPU利用率小于第一阈值的活跃agent，和/或，内存使用率小于第二阈值的活跃agent。

8.一种基于OpenStack的服务代理进程agent选择装置，其特征在于，所述装置应用于一种网络系统，所述网络系统至少包括至少一个云服务器和远程过程调用RPC服务器；其中，每个云服务器上部署至少一个控制节点；

所述装置包括：

通信单元，用于接收用于实现数据配置的消息；

处理单元，用于根据所述通信单元接收的所述消息中携带的用户标识，确定部署在各节点上的与所述用户标识对应的agent；

所述处理单元，还用于在所述用户标识对应的agent中，按照预设规则，确定活跃agent为目标agent；

所述通信单元，还用于将所述消息通过所述RPC服务器向所述处理单元确定的所述目标agent发送，以使所述目标agent处理所述消息。

9.如权利要求8所述的装置，其特征在于，所述处理单元，具体用于：

当在所述用户标识对应的agent中，确定出多个活跃agent时，根据各活跃agent的负载情况，选择作为所述目标agent的活跃agent。

10.如权利要求8所述的装置，其特征在于，所述处理单元，还用于预先建立第一列表；

针对所述用户标识，确定部署在各节点上的与所述用户标识对应的agent；

确定与所述用户标识对应的agent的代理标识和互联网协议IP地址；

针对确定出的与所述用户标识对应的每个agent，判断该agent所在节点是否为所述云服务器上部署的节点；

所述装置还包括存储单元：

所述存储单元，用于若是，则将该agent的代理标识和IP地址插入到所述第一列表中的首位；

否则，将该agent的代理标识和IP地址插入到所述第一列表中的末位。

11.如权利要求10所述的装置，其特征在于，所述存储单元，还用于按照所述第一列表中各agent的代理标识的排列顺序，依次将所述第一列表中状态信息为活跃状态的agent的代理标识，写入第二列表；

所述处理单元，具体用于：

根据所述存储单元存储的所述第二列表，确定活跃agent为目标agent。

12.如权利要求11所述的装置，其特征在于，所述通信单元，还用于通过各控制节点，接收各agent上报的状态消息，所述状态消息至少包括agent所在节点的IP地址、标题topic，以及agent的状态信息；

所述存储单元，还用于根据所述通信单元接收的所述状态信息，更新所述第二列表。

13.如权利要求8至12中任意一项所述的装置，其特征在于，第二列表用于记载状态信息为活跃状态的agent的代理标识；

所述通信单元，还用于针对所述第二列表中的每个agent，通过所述RPC服务器向该agent发送用于检测该agent是否死机的检测消息；

所述处理单元，还用于在预设时间内，若所述通信单元接收到该agent反馈的应答消息，则确定该agent为活跃agent。

14.如权利要求9所述的装置，其特征在于，所述处理单元，具体用于：

若各活跃的agent中存在满足预设条件的agent，则在负载情况满足所述预设条件的活跃agent中，选择作为所述目标agent的活跃agent；

否则，将各活跃agent中负载最小的agent，作为所述目标agent；

其中，负载情况满足所述预设条件的活跃agent包括中央处理器CPU利用率小于第一阈值的活跃agent，和/或，内存使用率小于第二阈值的活跃agent。