CN105045762A - 一种配置文件的管理方法及装置 - Google Patents

Abstract

本申请公开了一种配置文件的管理方法及装置，该方法包括：接收各负载均衡实例，确定各负载均衡实例对应的标识，将各负载均衡实例及其对应的标识写入到同一个配置文件中，通过上述方法，由于所有的负载均衡实例都在同一个配置文件中，而一个配置文件只需一个进程运行，因此，不需要分配访问请求的负载均衡实例不会占用额外的进程，处于LBaaS架构下的云服务端也就不会浪费CPU资源来运行这些额外的进程，不仅节省了云服务端的CPU资源，同时也提高了云服务端的运行效率。

Description

一种配置文件的管理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种配置文件的管理方法及装置。

背景技术

随着网络技术的不断发展，网络服务商(如：网站)为用户提供的服务种类也越来越多。

目前，由于网络服务商提供的业务类型逐渐的增加，业务量也在逐渐的增加，因此，网络服务商通常采用多个服务器为用户提供服务。而由于采用多个服务器为用户提供服务时，用户的访问请求会被随机的分配到某一个服务器上，因此，服务器会出现忙闲不均的情况，也就是说，有的服务器比较繁忙，有的服务器比较空闲，这样就会降低访问请求的处理效率。为了避免各服务器忙闲不均，网络服务商一般会使用负载均衡设备将用户的访问请求合理的分配到相应的服务器上。

在实际应用中，考虑到运行与维护负载均衡设备的成本问题，网络服务商通常会使用第三方提供的负载均衡服务，即网络服务商无需自己去建立负载均衡设备，只需要使用第三方提供的负载均衡服务即可，也即，LBaaS(LoadBalancerasaService)，因此，整个LBaaS结构框架如图1所示。

在现有技术中，当网络服务商使用第三方提供的负载均衡服务时，第三方会在云服务端上为网络服务商分配一定的空间，在该空间内，网络服务商可根据自己的需求创建至少一个负载均衡实例，负载均衡实例中包含分配访问请求的分配规则。针对任一负载均衡实例而言，云服务端可根据该负载均衡实例，生成对应的配置文件。在为该网络服务商提供负载均衡服务时，该云服务端可读取该配置文件，并通过一个进程运行该配置文件。当用户使用该网络服务商提供的服务时，则向云服务端发送访问请求，云服务端接收到该访问请求后，根据该配置文件中包含的分配规则，并通过运行该配置文件的进程，将该访问请求分配到对应的服务器上。

但是，在实际应用中，第三方往往不止为一个网络服务商提供负载均衡服务，因此，第三方的云服务端中会存在大量的负载均衡实例，由于现有技术中每个负载均衡实例对应的配置文件都需要由一个进程来运行，因此，处于LBaaS架构下的云服务端的中央处理器(CentralProcessingUnit，CPU)在运行这些进程时，会为每个进程分配一个CPU时间，并根据为这些进程分配的CPU时间，对这些进程进行逐一的运行。而由于对于一个进程来说，云服务端并不是每时每刻都会接收到该进程对应的访问请求，但该进程依然会需要被运行，也就是说，无论该进程是否需要对访问请求进行分配，云服务端都要运行该进程，因此，这不仅会浪费云服务端的CPU资源，还会降低云服务端的运行效率。

发明内容

本申请实施例提供一种配置文件的管理方法及装置，用以解决现有技术中的LBaaS架构下，浪费云服务端的CPU资源，还会降低云服务端的运行效率。

本申请实施例提供的一种配置文件的管理方法，所述管理方法用于管理云服务端中的配置文件，所述云服务端用于提供负载均衡服务，所述管理方法包括：

所述云服务端接收各负载均衡实例；

确定各负载均衡实例对应的标识；

将各负载均衡实例及其对应的标识写入到同一个配置文件中。

本申请实施例提供的一种负载均衡方法，所述负载均衡方法应用于云服务端提供的负载均衡服务中，所述方法包括：

所述云服务端接收用户的访问请求；

根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识；

根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。

本申请实施例提供的配置文件的管理装置，所述管理装置设置在云服务端，用于管理云服务端中的配置文件，所述云服务端用于提供负载均衡服务，所述管理装置包括：

接收模块，用于接收各负载均衡实例；

确定模块，用于确定各负载均衡实例对应的标识；

写入模块，用于将各负载均衡实例及其对应的标识写入到同一个配置文件中。

本申请实施例提供的负载均衡装置，所述负载均衡装置设置在云服务端，所述云服务端用于提供的负载均衡服务中，所述装置包括：

接收模块，用于接收用户的访问请求；

确定模块，用于根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识；

分配模块，根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。

本申请实施例提供一种配置文件的管理方法及装置，该方法是由云服务端接收各负载均衡实例，确定各负载均衡实例对应的标识，将各负载均衡实例及其对应的标识写入到同一个配置文件中，通过上述方法，由于所有的负载均衡实例都在同一个配置文件中，而一个配置文件只需一个进程运行，因此，不需要分配访问请求的负载均衡实例不会占用额外的进程，云服务端也就不会浪费CPU资源来运行这些额外的进程，不仅节省了云服务端的CPU资源，同时也提高了云服务端的运行效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为背景技术中提供的LBaaS结构框架示意图；

图2为本申请实施例提供的配置文件的管理过程；

图3为本申请实施例提供的LBaaS结构框架示意图；

图4为本申请实施例提供的负载均衡过程；

图5为本申请实施例提供的配置文件的管理装置结构示意图；

图6为本申请实施例提供的负载均衡装置结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，第三方对外提供的LBaaS是由云服务端实现的，该云服务端可以是实体机，也可以是由计算机程序实现的虚拟机，第三方通过互联网络将该云服务端供以服务的形式对外提给使用者，使用者无需自己去建立负载均衡设备，只需要使用第三方提供的负载均衡服务，并在云服务端中根据需求建立负载均衡实例即可，云服务端会根据使用者建立的负载均衡实例生成配置文件，图2为本申请实施例提供的配置文件的管理过程。

图2为本申请实施例提供的配置文件的管理过程，具体包括以下步骤：

S201：云服务端接收各负载均衡实例。

在本申请实施例中，LBaaS结构框架包括：用户、提供负载均衡服务的第三方以及使用该负载均衡服务的使用者，如图3所示。图3中所示的使用者可以是网络服务商，也可以是其他使用负载均衡服务的使用者，第三方则通过云服务端向使用者提供负载均衡服务，用户在访问使用者的服务器时，用户的访问请求需经过处于LBaaS架构下的云服务端的处理，才能到达使用者的服务器。

而使用者在使用第三方的负载均衡服务时，可在处于LBaaS架构下的云服务端上创建负载均衡实例，具体的，使用者在使用第三方提供负载均衡服务时，可登录第三方的负载均衡创建平台(该负载均衡创建平台是第三方对外提供给使用者的，用于建立负载均衡实例的窗口)，使用者可根据自身的实际需求在该平台上输入以下信息：

虚拟互联网协议(VirtualInternetProtocol，VIP)地址(以下简称“虚拟IP地址”)与该使用者的各服务器的真实互联网协议(InternetProtocol，IP)地址(以下简称“真实IP地址”)的映射关系，以及，对访问请求的分配规则。虚拟IP地址与真实IP地址的映射关系以及访问请求的分配规则就构成了负载均衡实例。

其中，上述虚拟IP地址与分配规则可以由使用者自行创建，也可以由该平台提供给使用者一些虚拟IP和分配规则的实例，以供使用者选择。上述的负载均衡服务创建平台和处于LBaaS架构下的云服务端可以是两个不同的硬件设备(或虚拟机)，使用者在负载均衡服务创建平台上创建负载均衡实例后，负载均衡服务创建平台即可将负载均衡实例发送给云服务端(负载均衡服务创建平台在图3中未示出)。

由于使用者会提供给用户各种不同的服务(如下载服务、搜索服务、娱乐服务等)，因此，使用者通常会针对其提供的不同服务创建不同的分配规则，也就是说，使用者提供的每个服务均对应一个分配规则，每个分配规则都包含在一个负载均衡实例中，也就相当于，使用者提供的每种服务都对应一个负载均衡实例。

而且，上述虚拟IP地址的作用就是使用户的访问请求先到达处于LBaaS架构下的云服务端，这是为了使用户的访问请求先经过云服务端的分配再到达使用者的服务器，而不是直接被发送到使用者的服务器。同一使用者在创建各负载均衡实例时，各负载均衡实例中的虚拟IP地址均是不同的，如，对于下载服务对应的负载均衡实例而言，其对应的虚拟IP地址是0.0.0.0:80，而对于搜索服务对应的负载均衡实例而言，其对应的虚拟IP地址是0.0.0.0:81。

例如，假设使用者A拥有四台服务器，分别为服务器1、服务器2、服务器3、服务器4，同时，使用者B拥有两台服务器，分别为服务器5、服务器6，A、B均使用第三方C提供的负载均衡服务。则：

A登录C的负载均衡服务创建平台，创建了负载均衡实例1和负载均衡实例2，其中，负载均衡实例1如表1所示：

表1

负载均衡实例2如表2所示：

表2

B登录C的负载均衡服务创建平台，创建了负载均衡实例3，其中，负载均衡实例3如表3所示：

表3

当A创建了负载均衡实例1和负载均衡实例2以及B创建了负载均衡实例3后，负载均衡服务创建平台将A与B创建完成的负载均衡实例1与负载均衡实例2以及负载均衡实例3发送给云服务端。

S202：确定各负载均衡实例对应的标识。

在本申请实施例中，处于LBaaS架构下的云服务端在接收各负载均衡实例后，会确定各负载均衡实例对应的标识，其中，所述标识包括：使用者的名称(如，使用者的名称为tenantA)，和/或，使用者创建的各负载均衡实例携带的虚拟IP地址(如，使用者针对下载服务，创建了一个负载均衡实例，该负载均衡实例携带的虚拟IP地址是0.0.0.0:80)，由于使用者所提供的每个服务均对应其创建的一个负载均衡实例，因此，所述标识用于区分对接收到的访问请求应该使用哪个负载均衡实例中的分配规则进行分配，也就是说，当云服务端接收到用户的访问请求后，对该用户的访问请求使用对应的分配规则。

另外，由上述表1～3可以看出，不同的使用者创建的负载均衡实例中携带的虚拟IP地址可能是相同的(A创建的负载均衡实例1和B创建的负载均衡实例3中携带的虚拟IP地址均是0.0.0.0:80)，因此，为了更加准确的区分负载均衡实例，本申请实施例中负载均衡实例的标识具体可以是：使用者的名称和负载均衡实例中携带的虚拟IP地址相结合而形成的标识。

延续上例，当处于LBaaS架构下的云服务端接收到负载均衡实例1、负载均衡实例2和负载均衡实例3后，可以确定这两个负载均衡实例中携带的虚拟IP地址和使用者的名称，作为这两个负载均衡实例的标识，确定出负载均衡实例1的标识为0.0.0.0:80+tenantA，确定出负载均衡实例2的标识为0.0.0.0:81+tenantA，确定出负载均衡实例3的标识为0.0.0.0:80+tenantB。

S203：将各负载均衡实例及其对应的标识写入到同一个配置文件中。

在本申请实施例中，处于LBaaS架构下的云服务端确定了各负载均衡实例的标识后，则可将各负载均衡实例及其对应的标识，按照一定的格式写入到同一个配置文件中。

延续上例，将上述负载均衡实例1、负载均衡实例2和负载均衡实例3及其各自对应的标识写入到同一配置文件中，如下所示：

其中，在上述配置文件中，针对使用者A的负载均衡实例1而言，“0.0.0.0:80nstenantA”是负载均衡实例1对应的标识，其中，“0.0.0.0:80”表示的是负载均衡实例1携带的虚拟IP地址，“ns”用于标识后面的“tenantA”是使用者A的名称，当然，“ns”也可以换成其他的符号代替，并不是唯一固定的，“server1192.168.1.1:80nstenantA”中“192.168.1.1:80”表示的是使用者A的服务器1对应的真实IP地址，“ns”与“tenantA”表示的和上述的含义一样，从中也可以看出虚拟IP地址和各服务器的真实IP的映射关系。

通过上述方法，负载均衡实例1、负载均衡实例2与负载均衡实例3均被写入到同一个配置文件中，而一个配置文件只需一个进程运行即可，这样，当云服务端接收到要访问服务器1的访问请求时，只需要在进程中调取访问请求对应的负载均衡实例即可(如，调取负载均衡实例1)，而负载均衡实例2和负载均衡实例3不会占用额外的进程，处在LBaaS架构下的云服务端也就不会浪费CPU资源来运行这些额外的进程，不仅节省了云服务端的CPU资源，同时也提高了云服务端的运行效率。

在上述配置文件生成之后，云服务端可先将当前的配置文件存储在指定的存储区域(如，本地或外部的数据库)中，再读取当前的配置文件，并通过进程运行当前的配置文件。

但是，在实际应用中，由于使用者可能会根据实际需求添加、修改或删除各负载均衡实例，因此，下面详细说明使用者添加、修改或删除负载均衡实例时，配置文件的管理方法。

当处在LBaaS架构下的云服务端接收到携带有各负载均衡实例的实例添加请求时，首先确定该实例添加请求中携带的各负载均衡实例对应的标识，再将该实例添加请求中携带的各负载均衡实例及其对应的标识写入到已经存在的配置文件中。

在此需要说明的是，在向已经存在的配置文件中添加负载均衡实例时，实例添加请求中携带的负载均衡实例的标识不能与该配置文件中的已经存在的负载均衡实例的标识一致，如果实例添加请求中的某个负载均衡实例的标识与该配置文件中的已经存在的某个负载均衡实例的标识一致，则处在LBaaS架构下的云服务端可通过负载均衡创建平台向使用者返回添加错误信息。

另外，在实际应用中，添加负载均衡实例时，处在LBaaS架构下的云服务端中也可能尚不存在配置文件(如，该云服务端是一台新设备)，则云服务端在接收到携带有各负载均衡实例的实例添加请求后，首先确定该实例添加请求中携带的各负载均衡实例对应的标识，再生成配置文件，并将实例添加请求中的各负载均衡实例及其对应的标识写入到生成的配置文件中。

也即，当云服务端接收到实例添加请求时，可先判断当前是否已经存在配置文件，若是，则直接将实例添加请求中的各负载均衡实例及其对应的标识写入到已经存在的配置文件中，否则，处在LBaaS架构下的云服务端可生成配置文件，并将该实例添加请求中的负载均衡实例及其对应的标识写入到生成的配置文件中。

当云服务端接收到携带有修改后的各负载均衡实例的实例修改请求后，则可先确定实例修改请求中携带的修改后的各负载均衡实例对应的标识，并获取已经存在的的配置文件，再针对该实例修改请求中任一修改后的负载均衡实例，根据确定的该修改后的负载均衡实例对应的标识，在配置文件中确定与该修改后的负载均衡实例具有相同标识的负载均衡实例，采用该修改后的负载均衡实例替换在配置文件中确定的负载均衡实例。

延续上例，假设当前时刻处在LBaaS架构下的云服务端上已经存在配置文件，使用者A根据业务需求在第三方C的负载均衡创建平台上将负载均衡实例1中的服务器1的IP地址修改为192.168.1.1:82，修改后的负载均衡实例1如表4所示：

表4

云服务端在接收到携带有修改后的负载均衡实例1的实例修改请求后，依然采用上述确定标识的方式确定出修改后的负载均衡实例1的标识为0.0.0.0:80+tenantA，并获取配置文件，在该配置文件中，查找出与修改后的负载均衡实例1具有相同标识的负载均衡实例为：

则采用修改后的负载均衡实例1(如表4所示)替换配置文件中标识为“0.0.0.0:80nstenantA”的负载均衡实例，修改后的配置文件如下所示：

当处在LBaaS架构下的云服务端接收到携带有待删除负载均衡实例的标识的实例删除请求后，则可先获取已经存在的配置文件，在配置文件中确定与该实例删除请求中携带的标识相对应的负载均衡实例，再直接将确定出的负载均衡实例从配置文件中删除即可。

需要说明的是，上述获取的已经存在的配置文件指的是当前存储在本地或外部的数据库中的配置文件，当处在LBaaS架构下的云服务端通过进程读取该配置文件后，该进程即可独立运行该配置文件，该进程的运行与存储的配置文件相互独立、互不影响，也就是说，当前的配置文件在被更改(如，对当前的配置文件进行添加、修改或删除各负载均衡实例)时，进程也不会受任何影响，仍然运行更改前的配置文件，因此，如果当前的配置文件发生变更，则云服务端需要通过进程重新运行变更后的配置文件。

具体的，当处在LBaaS架构下的云服务端对当前的配置文件进行更改(如，对当前的配置文件进行添加、修改或删除各负载均衡实例)后，可通过进程重新运行变更后的配置文件。如，云服务端的CPU可发送指令信号(如，HUP信号)给当前正在运行配置文件的进程，使该进程重新读取变更后的配置文件，并重新运行变更后的配置文件，当然也可以使用其他方式使进程重新读取并运行变更后的配置文件。

由于处在LBaaS架构下的云服务端通过发送指令信号，使得当前运行配置文件的进程重新读取并运行变更后的配置文件，无需再额外生成一个新的进程，因此，这样也可以实现对同一个进程的复用，可进一步提高运行效率。

通过上述整个过程，第三方的云服务端可更加有效的运行包含负载均衡实例的配置文件，当用户访问该使用者的各服务器时，整个负载均衡的工作过程如图4所示，其中，该负载均衡的工作过程是基于云服务端提供的负载均衡服务实现的。

图4为本申请实施例提供的负载均衡过程，具体包括以下步骤：

S401：所述云服务端接收用户的访问请求。

在本申请实施例中，由于使用者使用了第三方提供的负载均衡服务，为了使得访问该使用者的服务器的用户的访问请求，先经过处于LBaaS架构下的云服务端，再到达使用者的服务器，因此，使用者对外发布的其服务器的IP地址可以是其创建的负载均衡实例的虚拟IP地址。则，当用户访问使用者的服务器时，用户的访问请求中携带的目的IP地址就是使用者对外发布的虚拟IP地址，而通过该虚拟IP地址，该访问请求就会先到达云服务端。

延续上例，假设使用者A创建的负载均衡实例1如表1所示，其对外发布的服务器1和服务器2的IP地址为虚拟IP地址0.0.0.0:80，则当用户访问服务器1时，用户的访问请求中携带的目的地址就是该虚拟IP地址0.0.0.0:80，而并非是服务器1的真实IP地址192.168.1.1:80，通过该虚拟IP地址0.0.0.0:80，用户的访问请求就会先到达处于LBaaS架构下的云服务端，也即，处于LBaaS架构下的云服务端会接收到用户的访问请求。

S402：根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识。

在本申请实施例中，用户的访问请求中除了携带有目的IP地址(使用者对外发布的虚拟IP地址)以外，还携带有使用者的名称(即，访问目标的名称)，当处于LBaaS架构下的云服务端接收到用户的访问请求后，则可将访问请求中携带的虚拟IP地址和使用者的名称(即，访问目标的名称)提取出来，同样采用“虚拟IP地址+使用者的名称”的方式确定出该访问请求对应的标识，再根据确定出的访问请求对应的标识，在配置文件中确定该标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识。

延续上例，假设用户的问请求中携带的使用者A的名称(即，访问目标的名称)为tenantA，则当处于LBaaS架构下的云服务端将接收到的用户的访问请求后，将访问请求中携带的目的IP地址0.0.0.0:80和tenantA提取出来，确定该访问请求对应的标识为0.0.0.0:80+tenantA，根据确定出的标识0.0.0.0:80+tenantA，在配置文件中查找出与标识对应的负载均衡实例为：

S403：根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。

延续上例，假设该负载均衡实例1中的分配规则如表1所示，服务器1中当前访问人数为30个，服务器2中当前访问人数为40个，因此，处于LBaaS架构下的云服务端通过运行该配置文件的进程，采用如表1所示的分配规则将该用户的访问请求分配给服务器1。

以上为本申请实施例提供的配置文件的管理方法和负载均衡方法，基于同样的思路，本申请实施例还提供一种配置文件的管理装置和负载均衡装置，如图5、图6所示。

图5为本申请实施例提供的配置文件的管理装置结构示意图，所述管理装置设置在云服务端，用于管理云服务端中的配置文件，所述云服务端用于提供负载均衡服务，所述管理装置包括：

接收模块501，用于接收各负载均衡实例；

确定模块502，用于确定各负载均衡实例对应的标识；

写入模块503，用于将各负载均衡实例及其对应的标识写入到同一个配置文件中。

所述接收模块501，具体用于接收实例添加请求，所述实例添加请求中携带各负载均衡实例；

所述写入模块503具体用于，判断是否已经存在配置文件，若是，则将所述实例添加请求中的各负载均衡实例及其对应的标识写入到已经存在的配置文件中，否则，生成配置文件，并将所述实例添加请求中的各负载均衡实例及其对应的标识写入到生成的配置文件中。

所述接收模块501，具体用于接收实例修改请求，所述实例修改请求中携带修改后的各负载均衡实例；

所述写入模块503具体用于，获取已经存在的配置文件，针对所述实例修改请求中任一修改后的负载均衡实例，根据确定的该修改后的负载均衡实例对应的标识，在配置文件中确定与该修改后的负载均衡实例具有相同标识的负载均衡实例，采用该修改后的负载均衡实例替换在配置文件中确定的负载均衡实例。

所述接收模块501还用于，接收实例删除请求，所述实例删除请求中携带待删除负载均衡实例的标识；

所述写入模块503具体用于，获取已经存在的配置文件，在配置文件中确定与所述实例删除请求中携带的标识相对应的负载均衡实例，将确定出的负载均衡实例从配置文件中删除。

所述装置还包括：

运行模块504，用于通过进程运行当前的配置文件，当所述当前的配置文件发生变更时，通过所述进程重新运行变更后的配置文件。

具体的，如图5所示的管理装置具体可以位于云服务端中。

图6为本申请实施例提供的负载均衡装置结构示意图，所述负载均衡装置设置在云服务端，所述云服务端用于提供负载均衡服务，所述装置包括：

接收模块601，用于接收用户的访问请求；

确定模块602，用于根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识；

分配模块603，用于根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。

具体的，如图6所示的管理装置具体可以位于云服务端中。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flashRAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

1.一种配置文件的管理方法，其特征在于，所述管理方法用于管理云服务端中的配置文件，所述云服务端用于提供负载均衡服务，所述管理方法包括：

所述云服务端接收各负载均衡实例；

确定各负载均衡实例对应的标识；

将各负载均衡实例及其对应的标识写入到同一个配置文件中。

2.如权利要求1所述的方法，其特征在于，所述云服务端接收各负载均衡实例，具体包括：

所述云服务端接收实例添加请求，所述实例添加请求中携带各负载均衡实例；

将各负载均衡实例及其对应的标识写入到同一个配置文件中，具体包括：

判断是否已经存在配置文件；

若是，则将所述实例添加请求中的各负载均衡实例及其对应的标识写入到已经存在的配置文件中；

否则，生成配置文件，并将所述实例添加请求中的各负载均衡实例及其对应的标识写入到生成的配置文件中。

3.如权利要求1所述的方法，其特征在于，所述云服务端接收各负载均衡实例，具体包括：

所述云服务端接收实例修改请求，所述实例修改请求中携带修改后的各负载均衡实例；

将各负载均衡实例及其对应的标识写入到同一个配置文件中，具体包括：

获取已经存在的配置文件；

针对所述实例修改请求中任一修改后的负载均衡实例，根据确定的该修改后的负载均衡实例对应的标识，在配置文件中确定与该修改后的负载均衡实例具有相同标识的负载均衡实例，采用该修改后的负载均衡实例替换在配置文件中确定的负载均衡实例。

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

所述云服务端接收实例删除请求，所述实例删除请求中携带待删除负载均衡实例的标识；

获取已经存在的配置文件；

在配置文件中确定与所述实例删除请求中携带的标识相对应的负载均衡实例；

将确定出的负载均衡实例从配置文件中删除。

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

所述云服务端通过进程运行当前的配置文件；

当所述当前的配置文件发生变更时，通过所述进程重新运行变更后的配置文件。

6.一种负载均衡方法，其特征在于，所述负载均衡方法应用于云服务端提供的负载均衡服务中，所述方法包括：

所述云服务端接收用户的访问请求；

根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识；

根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。

7.一种配置文件的管理装置，其特征在于，所述管理装置设置在云服务端，用于管理云服务端中的配置文件，所述云服务端用于提供负载均衡服务，所述管理装置包括：

接收模块，用于接收各负载均衡实例；

确定模块，用于确定各负载均衡实例对应的标识；

写入模块，用于将各负载均衡实例及其对应的标识写入到同一个配置文件中。

8.如权利要求7所述的装置，其特征在于，所述接收模块具体用于，接收实例添加请求，所述实例添加请求中携带各负载均衡实例；

所述写入模块具体用于，判断是否已经存在配置文件，若是，则将所述实例添加请求中的各负载均衡实例及其对应的标识写入到已经存在的配置文件中，否则，生成配置文件，并将所述实例添加请求中的各负载均衡实例及其对应的标识写入到生成的配置文件中。

9.如权利要求7所述的装置，其特征在于，所述接收模块具体用于，接收实例修改请求，所述实例修改请求中携带修改后的各负载均衡实例；

所述写入模块具体用于，获取已经存在的配置文件，针对所述实例修改请求中任一修改后的负载均衡实例，根据确定的该修改后的负载均衡实例对应的标识，在配置文件中确定与该修改后的负载均衡实例具有相同标识的负载均衡实例，采用该修改后的负载均衡实例替换在配置文件中确定的负载均衡实例。

10.如权利要求7所述的装置，其特征在于，所述接收模块还用于，接收实例删除请求，所述实例删除请求中携带待删除负载均衡实例的标识；

所述写入模块具体用于，获取已经存在的配置文件，在配置文件中确定与所述实例删除请求中携带的标识相对应的负载均衡实例，将确定出的负载均衡实例从配置文件中删除。

11.如权利要求7～10任一所述的装置，其特征在于，所述装置还包括：

运行模块，用于通过进程运行当前的配置文件，当所述当前的配置文件发生变更时，通过所述进程重新运行变更后的配置文件。

12.一种负载均衡装置，其特征在于，所述负载均衡装置设置在云服务端，所述云服务端用于提供负载均衡服务，所述装置包括：

接收模块，用于接收用户的访问请求；

确定模块，用于根据所述访问请求中携带的标识，在配置文件中确定所述标识对应的负载均衡实例，其中，所述配置文件中包含至少两个负载均衡实例及其对应的标识；

分配模块，用于根据确定出的负载均衡实例中包含的分配规则，通过运行所述配置文件的进程对所述访问请求进行分配。