一种服务器集群及其后端管理方法与流程

本发明涉及集群管理技术领域，特别是涉及一种服务器集群及其后端管理方法。

背景技术：

随着互联网行业的发展，对互联网行业基础设施提出了更高的要求。全球服务器出货量不断攀升，并且在行业巨头中服务于不同业务的服务器数以万计。这样大量的服务器就导致需要对服务器集群进行管理。

而目前的服务器集群在进行管理时，人工干预操作较多，例如集群进行扩展或收缩(即服务器增加或减少)后，均需要工作人员人为重新进行进程配置等操作，管理效率低；且由于集群管理过程中，人工干预较多，使得集群的整体管理较为分散，集群的管理操作分别分散在服务器自身、集群主节点以及工作人员身上，不利于集群整体的集中管理。

因此，如何提供一种管理效率高的服务器集群及其后端管理方法是本领域技术人员目前需要解决的问题。

技术实现要素：

本发明的目的是提供一种服务器集群及其后端管理方法，集群的管理操作基本集中于主服务器上，而几乎不需要人为进行干预，管理效率高，集群的管理集中性更强。

为解决上述技术问题，本发明提供了一种服务器集群后端管理方法，包括：

集群服务启动时，各个子服务器分别从指定路径下获取相应的配置文件，来启动自身的工作进程以及调度进程，主服务器从所述指定路径下获取相应的配置文件来启动管理进程；

每个所述子服务器通过运行所述调度进程及所述工作进程，周期性地发送进程运行状态至所述主服务器；

所述主服务器通过运行管理进程，来接收各个所述子服务器发送的进程运行状态并据此对各个所述子服务器进行业务管理。

优选地，所述所述子服务器周期性地发送进程运行状态至所述主服务器的过程具体为：

各个所述子服务器通过运行所述调度进程及所述工作进程，周期性地发送各项进程对应的心跳信号至所述主服务器；

此时，所述业务管理具体包括：

所述主服务器通过所述管理进程，检测是否在预设时间段内接收到所述心跳信号，若是，则所述心跳信号对应的所述调度进程或所述工作进程工作状态正常，若否，则所述心跳信号对应的所述调度进程或所述工作进程工作状态不正常。

优选地，还包括：

所述子服务器通过运行所述调度进程或所述工作进程，周期性地发送自身负载压力至所述主服务器；

所述主服务器通过运行所述管理进程，来接收各个所述子服务器发送的负载压力，，并依据所述负载压力以及各个工作进程的工作状态对各个所述子服务器进行业务均衡调度处理。

优选地，所述业务均衡调度处理具体包括：

判断所述负载压力是否超出预设负载压力范围，若是，依据预设均衡规则，将所述负载压力对应的服务器内相应比例的业务，迁移至其他负载压力未超出所述预设负载压力范围的服务器内运行。

优选地，所述主服务器对各个所述子服务器进行业务管理的过程还包括：

所述主服务器通过运行管理进程，向每个所述子服务器同步该服务器自身包含的全部工作进程的工作状态；供该服务器运行所述调度进程时，停止分配业务至工作状态不正常的工作进程内。

优选地，所述子服务器接收所述主服务器发送的工作状态后，还包括：

所述子服务器通过运行调度进程，将工作状态不正常的工作进程的业务迁移至所述集群内设置的备份服务器内，供所述备份服务器内相应的工作进程对该业务进行处理。

优选地，所述配置文件保存于所述集群内的指定服务器中的指定路径下；

所述配置文件发生更新后，所述指定服务器内保存所述配置文件的更新记录以及更新前的配置文件。

优选地，所述子服务器通过远程过程调用协议rpc与所述主服务器通信。

优选地，所述配置文件为json文件。

为解决上述技术问题，本发明还提供了一种服务器集群，包括若干个子服务器以及一个主服务器；

所述子服务器，用于在集群服务启动时，从指定路径下获取相应的配置文件，来启动自身的工作进程以及调度进程；通过运行所述调度进程及所述工作进程，周期性地发送进程运行状态至所述主服务器；

所述主服务器，用于从所述指定路径下获取相应的配置文件来启动管理进程；通过运行管理进程，来接收各个所述子服务器发送的进程运行状态并据此对各个所述子服务器进行业务管理。

本发明提供了一种服务器集群及其后端管理方法，在指定路径下保存集群内各个服务器启动进程时所需的各类配置文件，在集群服务启动时，各个服务器即可根据自身需求从指定路径下去获取相应的配置文件，从而启动自身对应的进程。其中，管理进程仅在主服务器内启动。各个子服务器启动调度进程和工作进程后，会周期性地发送各个进程的运行状态至主服务器，主服务器的管理进程即能够根据这些子服务器的进程运行状态来对各个子服务器进行业务管理。由此可见，本发明中在集群架构扩展时，新增的服务器可自行从指定路径下获取配置文件来启动进程，主服务器也能够直接依据其他服务器发送的进程运行状态进行相应的业务管理，即集群的管理操作基本集中于主服务器上，而几乎不需要人为进行干预，管理效率高，集群的管理集中性更强。

附图说明

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

图1为本发明提供的一种服务器集群后端管理方法的过程的流程图；

图2为本发明提供的另一种服务器集群后端管理方法的过程的流程图；

图3为本发明提供的一种服务器集群的结构示意图。

具体实施方式

本发明的核心是提供一种服务器集群及其后端管理方法，集群的管理操作基本集中于主服务器上，而几乎不需要人为进行干预，管理效率高，集群的管理集中性更强。

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

本发明提供了一种服务器集群后端管理方法，参见图1所示，图1为本发明提供的一种服务器集群后端管理方法的过程的流程图；包括：

步骤s1：集群服务启动时，各个子服务器分别从指定路径下获取相应的配置文件，来启动自身的工作进程以及调度进程，主服务器从指定路径下获取相应的配置文件来启动管理进程；

这里的指定路径指的是集群内指定服务器下的特定路径，通过将配置文件放置于指定路径下，方便进行统一管理，以及增加、删除或修改配置文件来实现集群的分布式调整。这里的指定服务器可由工作人员任意选择，本发明对此不作限定。

配置文件内包含有启动进程所需的参数，服务器获取配置文件后，从配置文件内解析相应的参数，来启动对应的进程。

另外，由于服务器在正常工作过程中，即需要有调度进程、工作进程和管理进程，管理进程一般仅有一个，本发明将包含有管理进程的服务器作为主服务器，用于对整个集群进行管理。除管理进程之外，每个子服务器一般包含一个调度进程以及若干个工作进程，为了避免出现业务冲突，同一个子服务器内包含的每个工作进程分别用于执行不同的业务。调度进程用于获取前端业务，并依据预设调度规则选择相应的业务分配至自身所处服务器内的各个工作进程，由工作进程进行业务处理，从而实现集群的对外服务。并且，虽然每个子服务器均包含若干个工作进程，但是各个子服务器内包含的工作进程的个数可能相同也可能不同；即使两个子服务器内包含的工作进程的个数相同，其中一个子服务器包含的一套工作进程的功能也可能与另一个子服务器包含的一套工作进程的功能相同或不同。即每个子服务器内设置的工作进程的个数和每个工作进程的功能本发明不作限定，只需要保证同一子服务器内不包含功能相同的工作进程即可。需要注意的是，一个集群内，主服务器内也可以包含调度进程和工作进程。

可以理解的是，通过将进程对应的配置文件保存至指定路径，并由服务器自行下载对应的配置文件来启动进程，能够使得当集群架构扩大，即新增服务器时，不需要人工配置新增的服务器的内容，而是由这些服务器自行配置自身进程即可，能够更加方便灵活的进行集群的扩容，减少了人工干预。

步骤s2：每个子服务器通过运行调度进程及工作进程，周期性地发送进程运行状态至主服务器；

可以理解的是，主服务器想要对集群内进行业务管理，首先需要知道用于进行业务执行的调度进程和工作进程是否正常运行，因此，每个调度进程和工作进程在运行过程中，需要周期性地将自身的运行状态告知主服务器，方便主服务器了解这些进程是否正常工作，进而进行业务的整体管理。

步骤s3：主服务器通过运行管理进程，来接收各个子服务器发送的进程运行状态并据此对各个子服务器进行业务管理。

由此可见，本发明中在集群架构扩展时，新增的服务器可自行从指定路径下获取配置文件来启动进程，主服务器也能够直接依据其他服务器发送的进程运行状态进行相应的业务管理，即集群的管理操作基本集中于主服务器上，而几乎不需要人为进行干预，管理效率高，集群的管理集中性更强。

在一种具体实施例中，步骤s2的过程具体为：

步骤s21：各个子服务器通过运行调度进程及工作进程，周期性地发送各项进程对应的心跳信号至主服务器；

步骤s22：主服务器通过管理进程，检测是否在预设时间段内接收到心跳信号，若是，则心跳信号对应的调度进程或工作进程工作状态正常，若否，则心跳信号对应的调度进程或工作进程工作状态不正常。

可以理解的是，心跳检测的实现方式是主服务器内保存下来所有进程的状态信息，然后等待子服务器定时发送自身各个进程的工作状态，从而使主服务器更新自己的保存的当前各个进程的状态信息，如果子服务器内相应的进程超过指定的时间没有发送自身的状态信息至主服务器，主服务器则认为该进程已经停止工作或者其状态异常。即这里的心跳信号内携带的是对应进程的工作状态信息。当然，心跳信号也可携带其他的信息内容，本发明对此不作限定。心跳检测能够使主服务器始终能够监测各个进程的工作状态，一旦有进程出现故障时，能够及时发现，从而方便主服务器后续及时进行补救措施，例如停止分配故障进程所承担的业务至故障进程所在的子服务器等，从而提高集群的可靠性。

具体的，在每个工作进程初始启动后，子服务器需要向主服务器注册服务，即子服务器会发送注册请求至主服务器，注册请求内携带有当前注册的工作进程对应的标识，主服务器会将该标识添加至注册列表内，从而得知当前哪些工作进程投入工作。之后主服务器会实时将注册列表发送至已经注册过的工作进程内，方便其得知当前正在工作的工作进程有哪些。并且，主服务器通过前述的心跳检测，能够得知这些工作进程是否正常工作，当有工作进程状态不正常时，主服务器会将注册列表内的不正常的工作进程的标识删除。

作为优选地，该方法还包括：

步骤s23：子服务器通过运行调度进程或工作进程，周期性地发送自身负载压力至主服务器；

可以理解的是，由于集群内包含多个服务器，不同子服务器内可以包含相同功能的工作进程，则这些工作进程会承担相同类型的业务请求，从而实现业务分担的目的。但是，主服务器若想要设定业务均衡策略来进行业务分配，并实时依据策略对各个子服务器的业务进行调度，则需要及时得知各个子服务器的负载压力。其中，这里的负载压力由子服务器自身内部程序获得，之后可以在子服务器运行调度进程或任一工作进程时发送至主服务器；不同的子服务器可以选择在运行不同的进程时发送负载压力至主服务器，例如，子服务器a在运行调度进程时发送负载压力，子服务器b在运行某一工作进程时发送负载压力。子服务器具体在运行哪个进程时发送负载压力至主服务器，本发明不作限定。

此时，步骤s3中的业务管理具体包括：

步骤s31：主服务器通过运行管理进程，来接收各个子服务器发送的负载压力，并依据负载压力以及各个工作进程的工作状态对各个子服务器进行业务均衡调度处理。

可以理解的是，在各个子服务器进行业务处理过程中，难免会出现有些子服务器负载过重，而有些子服务器负载较轻的情况，此时为了提高各个子服务器的工作效率，以及减小负载过重为子服务器带来的负面影响，主服务器需要调整业务分配，尽量使各个子服务器上的负载较为均衡。故主服务器周期性接收到各个子服务器的负载压力后，即能够及时了解到是否存在负载过重的情况或其他需要进行业务调度的情况，若存在，则主服务器举要根据预设的调度策略来重新进行业务分配，从而平衡各个子服务器上的负载压力，提高各个各个子服务器的工作效率。

其中，上述负载压力可以跟随心跳信号一起发送至主服务器，此时步骤s21与s23同时进行；负载压力也可以单独发送，此时步骤s21与s23之间并无先后顺序关联。本发明对此不作限定。

另外，本实施例中，由于主服务器在进行业务均衡时，除负载压力外，还需要综合心跳检测结果，因此主服务器的业务均衡操作需要在步骤s23和步骤s22之后进行。但在其他实施例中，若仅考虑负载压力的话，则步骤s22与s31中业务均衡操作之间无先后顺序之分，两者并列进行。具体采用以上哪种实现方式，本发明不作具体限定。参见图2所示，图2为本发明提供的另一种服务器集群后端管理方法的过程的流程图。

进一步可知，上述业务均衡调度处理具体包括：

判断负载压力是否超出预设负载压力范围，若是，依据预设均衡规则，将负载压力对应的服务器内相应比例的业务，迁移至其他负载压力未超出预设负载压力范围的服务器内运行。

可以理解的是，通常每个服务器存在一个最合适的负载压力范围，一旦服务器承担的负载压力范围超出最合适的范围后，即会对服务器造成损害，例如服务器的硬件磨损率增大以及进程容易出现故障等，因此此时需要将这些负载压力过大的服务器上的部分业务，转移至其他负载压力较小的服务器内运行。其中，这里的预设负载压力范围可根据经验设定。上述相应比例的值可设定为定值，或者也可根据负载压力超出预设负载压力范围的程度进行动态调整。选择承担迁移业务的服务器时，所选择的服务器负载压力越小越好，当然，还需要综合考虑这些服务器是否包含有能够承担迁移业务的工作进程。本发明不限定预设均衡规则的具体内容。

在一种优选实施例中，步骤s3中，主服务器对各个子服务器进行业务管理的过程还包括：

主服务器通过运行管理进程，向每个子服务器同步该服务器自身包含的全部工作进程的工作状态；供该服务器运行调度进程时，停止分配业务至工作状态不正常的工作进程内。

可以理解的是，主服务器在得知各个子服务器内各个进程的工作状态后，可以依据这些工作状态信息进行整体的业务调度。或者也可以如上述实施例，告知每个子服务器其自身包含的各个进程的工作状态。这是因为，虽然子服务器运行调度进程以及工作进程时，会发送各个进程的工作状态至主服务器，但是调度进程本身并不知道同一服务器内工作进程的工作状态，由于调用进程是用于为工作进程分配业务的，因此，为了避免调用进程分配业务至故障的工作进程，主服务器需要及时向各个子服务器同步该子服务器自身的工作进程的工作状态，从而使调度进程及时得知自身所处的子服务器内有哪些工作进程可用、哪些不可用，进而停止分配业务至这些不可用的工作进程。并且，由于每个子服务器内不包含具有相同功能的工作进程，因此，一旦停止分配业务至不可用的工作进程的话，这些不可用的工作进程所对应的业务即无法在该子服务器上进行处理，因此集群自然会将这些业务分发至其他可以处理这部分业务的子服务器内处理，从而尽可能避免这些不可用的工作进程白白占用业务，却无法正常处理而导致的业务处理失败的情况出现，提高集群业务处理的可靠性。

进一步可知，子服务器接收主服务器发送的工作状态后，还包括：

子服务器通过运行调度进程，将工作状态不正常的工作进程的业务迁移至集群内设置的备份服务器内，供备份服务器内相应的工作进程对该业务进行处理。

可以理解的是，为了提高集群的高可用性，优选在集群内设置若干个备份服务器，这些备份服务器和子服务器一样包含调度进程和若干个工作进程，只是这些备份服务器在正常情况下是不工作的，只有当子服务器中有工作进程发生故障时，才会把故障的工作进程中正在处理的任务，迁移至备份服务器内相应的工作进程内继续进行处理，并且由于子服务器已经得知自身存在故障的工作进程，故子服务器的调度进程不会再发送业务至故障的工作进程内，后续该故障的工作进程所对应的一类业务，会由其他子服务器或迁移至的备份服务器内对应的工作进程进行处理。这种业务迁移方式，能够尽可能避免正在运行的业务由于工作进程突然故障导致的处理失败的情况发生，提高业务处理的可靠性。

在一种具体的实施例中，配置文件保存于集群内的指定服务器中的指定路径下；配置文件发生更新后，指定服务器内保存配置文件的更新记录以及更新前的配置文件。

可以理解的是，配置文件进行更新后，新的配置文件有时可能存在问题，因此需要恢复至原本的配置文件，即回滚至上一版本的配置文件，为了实现该目的，需要对每个版本的配置文件均进行记录保存，即每次更新后，也会保留之前的配置文件的历史记录，从而方便进行配置文件的版本回滚以及工作人员的查询。当然，当配置文件发生更新后，各个服务器在下载配置文件时，会自动下载最新版本的配置文件。

另外，由于配置文件有多种，因此，这些对应不同进程的配置文件可以统一放置于同一目录下，也可以分别将对应不同进程的配置文件放置于不同的目录下，具体采用哪种方式，本发明不作限定。

另外，这里的指定路径可以为zk(zookeeper)指定的路径，zk是一种分布式应用程序协调服务。当然，本发明对此不作限定。

其中，子服务器通过rpc(remoteprocedurecallprotocol,远程过程调用协议)与主服务器通信。当然，子服务器与主服务器之间如何进行通信，本发明不作具体限定。

在一种优选实施例中，配置文件为json文件。json(jsonjavascriptobjectnotation)是一种轻量级的数据交换格式。通过json文件描述集群配置参数，配置文件便于解析。当然，配置文件也可以为其他格式的文件，本发明不限定配置文件的具体格式。

本发明还提供了一种服务器集群，包括若干个子服务器2以及一个主服务器1；参见图3所示，图3为本发明提供的一种服务器集群的结构示意图。

子服务器2，用于在集群服务启动时，从指定路径下获取相应的配置文件，来启动自身的工作进程以及调度进程；通过运行调度进程及工作进程，周期性地发送进程运行状态至主服务器1；

主服务器1，用于从指定路径下获取相应的配置文件来启动管理进程；通过运行管理进程，来接收各个子服务器2发送的进程运行状态并据此对各个子服务器2进行业务管理。

以上的几种具体实施方式仅是本发明的优选实施方式，以上几种具体实施例可以任意组合，组合后得到的实施例也在本发明的保护范围之内。应当指出，对于本技术领域的普通技术人员来说，相关专业技术人员在不脱离本发明精神和构思前提下推演出的其他改进和变化，均应包含在本发明的保护范围之内。

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