CN115396290B - 一种故障自动恢复方法、装置及服务系统 - Google Patents

Abstract

本申请公开了一种故障自动恢复方法、装置及服务系统，包括：获取目标服务模块的配置信息集合，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将其生成为工作实例，当检测到所述工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，解决了在传统的运维管理技术中，运维管理人员处置服务系统的难度大和实效长问题，保证了服务系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

Description

一种故障自动恢复方法、装置及服务系统

技术领域

本申请涉及网络安全技术领域，尤其涉及一种故障自动恢复方法、装置及服务系统。

背景技术

服务系统是对特定的技术或组织的一种网络化配置，用来提供服务以满足顾客的需求和期望。对于需要7x24小时无间歇运行的服务系统来说，其故障监测与恢复需要专业的运维管理人员配合运维管理系统实现7x24小时无间歇的应急故障恢复能力，用以保证服务系统的稳定运行。

在实际应用中，运维管理系统负责对服务系统的硬件状态、不同服务模块的软件状态等进行实时监测，并在发现故障后发出告警信息。而运维管理人员负责监测运维管理系统的告警信息，及时处理故障，例如重启服务器，重启软件模块，对系统运行配置进行修正等。而随着分布式及时、云技术、大数据技术等的飞速发展，各种服务系统逐步大型化、复杂化，例如，在车联网入侵检测的服务系统中，服务模块众多，且每个模块会运行多个实例用于处理不同类型的数据，这对运维管理人员提出了很高的技术要求。

因此，上述传统的运维管理技术将面临很大的挑战，亟需一种自动化的故障恢复技术来降低运维管理人员处置的难度和实效问题，提高服务系统的高可用性。

发明内容

本申请提供了一种故障自动恢复方法、装置及服务系统，以解决在传统的运维管理技术中，运维管理人员处置服务系统的难度大和实效长问题。

一方面，提供了一种故障自动恢复方法，所述方法应用于服务系统，所述方法包括：

获取目标服务模块的配置信息集合；

基于所述配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，所述第二数量大于第一数量；

基于第一数量的配置信息，在所述第二数量的待启动实例中选取第一数量的第一待启动实例，并将所述第一数量的第一待启动实例生成为处于工作状态的工作实例；

当检测到所述工作实例中存在异常实例时，基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换所述异常实例；

所述第二待启动实例为除所述第一待启动实例之外的待启动实例。

又一方面，提供了一种故障自动恢复装置，包括：

配置信息集合获取模块，用于获取目标服务模块的配置信息集合；

待启动实例获取模块，用于基于所述配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，所述第二数量大于第一数量；

工作实例生成模块，用于基于第一数量的配置信息，在所述第二数量的待启动实例中选取第一数量的第一待启动实例，并将所述第一数量的第一待启动实例生成为处于工作状态的工作实例；

故障恢复实例生成模块，用于当检测到所述工作实例中存在异常实例时，基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换所述异常实例；所述第二待启动实例为除所述第一待启动实例之外的待启动实例。

在一种可能的实现方式中，所述故障自动恢复装置还包括：

等待状态确定模块，用于将所述第二待启动实例中的至少一个待启动实例确定为等待状态。

所述故障恢复实例生成模块，还用于：

在等待状态的待启动实例中选取目标待启动实例；

对所述异常实例的配置信息进行解析，获得目标解析结果；

根据所述目标解析结果，对所述目标待启动实例进行配置，生成所述故障恢复实例。

在一种可能的实现方式中，所述等待状态确定模块还用于：

将所述第二待启动实例中的至少一个待启动实例对应的实例标识，放置于状态节点的等待子节点中，以将所述至少一个待启动实例确定为等待状态。

在一种可能的实现方式中，所述工作实例生成模块还用于：

将所述第一数量的第一待启动实例对应的实例标识，放置于状态节点的工作子节点中，以将第一待启动实例将确定为工作状态，并生成为工作实例。

在一种可能的实现方式中，所述故障自动恢复装置还包括：

工作实例退出模块，用于当检测到所述目标服务模块中的配置信息集合发生变更时，将所述服务模块中对应的工作实例退出工作状态；

变更解析结果获取模块，用于获取所述目标服务模块中变更后的配置信息集合，并对所述变更后的配置信息集合进行解析，获得变更解析结果；

变更工作实例生成模块，用于根据所述变更解析结果，对所述目标服务模块对应的所有实例进行配置，生成变更工作实例。

在一种可能的实现方式中，所述故障自动恢复装置还包括：

实例启动信息获取模块，用于从信息节点中提取实例启动信息，所述实例启动信息包括已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息；

实例启动信息表构建模块，用于基于所述实例启动信息，构建实例启动信息表；

目标实例获取模块，用于当所述状态节点发生改变时，遍历所述状态节点中的实例，获取所述实例启动信息表中记录而所述状态节点中并不存在的目标实例；

重新生成模块，用于从所述实例启动信息表中，获取所述目标实例的位置信息，并基于所述位置信息重新生成所述目标实例。

在一种可能的实现方式中，所述实时状态信息包括所述第一待启动实例与所述第二待启动实例的位置及标识。

再一方面，提供了一种服务系统，包括：信息节点、配置节点、状态节点及监控节点；

所述信息节点，用于存储所述服务系统的通用配置信息及各个服务模块在不同配置下的实时状态信息；

所述配置节点，用于存储各个服务模块的配置信息集合；

所述状态节点，用于存储各个服务模块下每个实例的工作状态及等待状态；

所述监控节点，用于存储第一监控模块及第二监控模块的工作状态。

在一种可能的实施方式中，所述第一监控模块，用于监测所述工作实例中存在的异常实例及所述配置信息集合发生改变的服务模块；

所述第二监控模块，用于监测所述第一监控模块的工作状态，当所述第一监控模块出现故障时，所述第二监控模块替代所述第一监控模块监测所述工作实例中存在的异常实例及所述配置信息集合发生改变的服务模块。

又一方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如本申请所述的一种故障自动恢复方法。

再一方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述至少一条指令由处理器加载并执行以实现如本申请所述的一种故障自动恢复方法。

本申请提供的技术方案可以包括以下有益效果：

本申请实施例提供了一种故障自动恢复方法，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将第一待启动实例生成为工作实例，当检测到工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，保证了系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

附图说明

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

图1是根据一示例性实施例示出的一种服务系统的结构示意图。

图2是根据一示例性实施例示出的一种故障自动恢复方法的方法流程图。

图3是根据一示例性实施例示出的一种故障自动恢复方法的方法流程图。

图4示出了本申请实施例涉及的一种故障自动恢复逻辑示意图。

图5示出了本申请实施例涉及的一种模块异常监听和恢复流程示意图。

图6是根据一示例性实施例示出的一种故障自动恢复装置的结构方框图。

图7是根据一示例性实施例示出的一种基于zookeeper创建的服务系统管理节点结构示意图。

图8根据本申请一示例性实施例提供的一种计算机设备示意图。

具体实施方式

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

应理解，在本申请的实施例中提到的“指示”可以是直接指示，也可以是间接指示，还可以是表示具有关联关系。举例说明，A指示B，可以表示A直接指示B，例如B可以通过A获取；也可以表示A间接指示B，例如A指示C，B可以通过C获取；还可以表示A和B之间具有关联关系。

在本申请实施例的描述中，术语“对应”可表示两者之间具有直接对应或间接对应的关系，也可以表示两者之间具有关联关系，也可以是指示与被指示、配置与被配置等关系。

图1是根据一示例性实施例示出的一种服务系统的结构示意图。该服务系统中包括各个服务模块。

可选的，该服务模块中均加载有多个配置信息，每个服务模块用于运行不同的实例，每个实例对应不同的配置信息。例如，该服务系统由N个服务模块构成，每个服务模块又会根据实际情况而运行1到n个实例(对应不同的配置信息)，这些实例运行于不同的物理服务器上，每个服务器上都安装一个分布式应用程序协调服务软件(zookeeper)。

可选的，上述服务模块可以是终端或者服务器中的任意一者。

可选的，上述服务器可以是独立的物理服务器，也可以是由多个物理服务器构成的服务器集群或者是分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等技术运计算服务的云服务器。

可选的，该计算机集群系统还可以包括管理设备，该管理设备用于对该系统进行管理(如管理各个模块与服务器之间的连接状态等)，该管理设备与服务器之间通过通信网络相连。可选的，该通信网络是有线网络或无线网络。

可选的，上述的无线网络或有线网络使用标准通信技术和/或协议。网络通常为因特网，但也可以是其他任何网络，包括但不限于局域网、城域网、广域网、移动、有限或无线网络、专用网络或者虚拟专用网络的任何组合。在一些实施例中，使用包括超文本标记语言、可扩展标记语言等的技术和/或格式来代表通过网络交换的数据。此外还可以使用诸如安全套接字层、传输层安全、虚拟专用网络、网际协议安全等常规加密技术来加密所有或者一些链路。在另一些实施例中，还可以使用定制和/或专用数据通信技术取代或者补充上述数据通信技术。

图2是根据一示例性实施例示出的一种故障自动恢复方法的流程图。该方法由如图1所示的服务系统执行。如图2所示，该方法可以包括如下步骤：

步骤S201、获取目标服务模块的配置信息集合。

在一种可能的实施方式中，所执行的服务系统可以基于分布式应用程序协调服务软件(zookeeper)进行设计，该服务系统由多个服务模块构成，每个服务模块又会根据实际情况配置有不同的配置信息，这些服务模块运行于不同的物理服务器上，每个物理服务器上安装一个分布式应用程序协调服务软件(zookeeper)服务。获取服务系统中各个服务模块的配置信息，以目标服务模块为例，该目标服务模块为该服务系统中任一个服务模块，该目标服务模块的所有配置信息构成一个集合，对该集合进行获取。

其中，分布式应用程序协调服务软件(zookeeper)是一个分布式的，开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。在分布式应用程序协调服务软件(zookeeper)中，节点(znode)是一个跟Unix文件系统路径相似的节点，可以往这个节点存储或获取数据。如果在创建节点(znode)时标签(Flag)设置为非持久化(EPHEMERAL)，那么当创建这个节点(znode)的节点和分布式应用程序协调服务软件(zookeeper)失去连接后，这个节点(znode)将不再存在分布式应用程序协调服务软件(zookeeper)里，分布式应用程序协调服务软件(zookeeper)使用监听机制(Watcher)察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。本申请仅以分布式应用程序协调服务软件(zookeeper)为例，在实际应用中并不做限定，可将该分布式应用程序协调服务软件(zookeeper)替换为其他的分布式应用程序协调服务软件。

步骤S202、基于该配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，该第二数量大于第一数量。

在一种可能的实施方式中，在获取配置信息集合后，对该配置信息集合进行解析，获取解析结果，并基于该解析结果获取该目标服务模块所对应的进入竞争模式下的待启动实例，将该配置信息集合中配置信息的数量确定为第一数量，再选取第二数量的该待启动实例，该第二数量大于该第一数量，保证待启动实例的个数大于配置信息的个数。

其中，待启动实例进入竞争模式可以为：第二数量的待启动实例全部进入竞争，按照随机或时间先后顺序的原则从第二数量的待启动实例中选取实例，被选取的实例意味着该实例竞争成功。所述解析结果指示该配置信息集合中配置信息的数量以及每个配置信息中具体的配置内容、执行内容。

步骤S203、基于第一数量的配置信息，在该第二数量的待启动实例中选取第一数量的第一待启动实例，并将该第一数量的第一待启动实例生成为处于工作状态的工作实例。

在一种可能的实施方式中，在获取配置信息的第一数量及待启动实例的第二数量后，从该第二数量的待启动实例中选取与配置信息的第一数量相同数量的待启动实例，将选取的待启动实例生成为处于工作状态的工作实例，该工作实例与该配置信息一一对应。其中，选取出来的相同数量的待启动实例可以随机选取，也可以按照先后顺序选取。

步骤S204、当检测到该工作实例中存在异常实例时，基于该异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换该异常实例，该第二待启动实例为除该第一待启动实例之外的待启动实例。

在一种可能的实施方式中，在生成处于工作状态的工作实例后，基于系统的监听机制，对处于工作状态的工作实例进行实时监控，当检测到该工作实例存在异常时(如异常退出、死机情况等)，则除该第一待启动实例之外的待启动实例(即第二待启动实例)及该异常实例重新进入竞争，进行再次解析配置信息集合，确认具体的配置内容，将竞争成功的实例生成为故障恢复实例，以替换该异常实例。

综上所述，本申请实施例提供了一种故障自动恢复方法，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将第一待启动实例生成为工作实例，当检测到工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，保证了系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

图3是根据一示例性实施例示出的一种故障自动恢复方法的方法流程图。该方法由如图1所示的服务系统执行。如图3所示，该方法可以包括如下步骤：

步骤S301、获取目标服务模块的配置信息集合。

在一种可能的实施方式中，获取目标服务模块的配置信息集合，并对该配置信息集合进行解析，获取解析结果，该解析结果包括该配置信息集合中具有的配置信息的数量，以及各个配置信息的具体配置内容。

例如：服务模块N的作用是送数据，服务模块N的配置信息集合中有3个配置信息：配置信息1是要求把数据送给甲，配置信息2是要求把数据送给乙，配置信息3是要求把数据送给丙。也就是说，服务模块N的每个配置信息的实际作用不同，都要实际进行解析。

步骤S302、基于该配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，该第二数量大于第一数量。

在一种可能的实施方式中，在获取解析结果后，基于该解析结果选取该配置信息集合中配置信息的第一数量，选取大于该第一数量的待启动实例，为了方便表述，将选取的待启动实例的数量确定为第二数量，以确保始终至少有一个待启动实例处于等待模式。

例如：服务模块N有3个配置信息，实际需要启动3个实例，但为保证系统的自动恢复效果，可选取3+3个待启动实例(最少不能低于3+1个)，确保始终至少有一个待启动实例处于等待模式。

步骤S303、基于第一数量的配置信息，在该第二数量的待启动实例中选取第一数量的第一待启动实例，并将该第一数量的第一待启动实例生成为处于工作状态的工作实例。

在一种可能的实施方式下，该将该第一数量的第一待启动实例生成为处于工作状态的工作实例，包括：

将该第一数量的第一待启动实例对应的实例标识，放置于状态节点的工作子节点中，以将第一待启动实例将确定为工作状态，并生成为工作实例。

可选的，在一种可能的实施方式下，在获取配置信息的第一数量及待启动实例的第二数量后，尝试在状态节点的工作子节点下依次创建该第二数量的待启动实例的标识，假设该目标服务模块为模块N，(可以以如下形式创建：“状态节点/服务模块N/working/N配置i/i的标识”)，所创建的标识为非持久化节点，以便该待启动实例出现异常时，删除该待启动实例所对应的标识。将第二数量中创建成功的待启动实例确定为工作状态，并生成为工作实例。将该工作实例的实时状态信息记录到信息节点中，(可以以如下形式记录：“信息节点/服务模块N/N配置i/i的实时状态信息”)，该实时状态信息包括该工作实例的位置及标识。

步骤S304、将第二待启动实例中的至少一个待启动实例确定为等待状态，该第二待启动实例为除该第一待启动实例之外的待启动实例。

在一种可能的实施方式下，该将该第二待启动实例中的至少一个(或全部)待启动实例确定为等待状态，包括：

将该第二待启动实例中的至少一个(或全部)待启动实例对应的实例标识，放置于状态节点的等待子节点中，以将该至少一个(或全部)待启动实例确定为等待状态。

可选的，在一种可能的实施方式下，在状态节点的工作子节点下依次创建该第二数量的待启动实例的标识时，将该第二数量的待启动实例中创建未成功的待启动实例(即第二待启动实例)确定为等待状态，并在状态节点的等待子节点下依次创建标识(可以以如下形式创建：“状态节点/服务模块N/waiting/N配置i/i的标识”)，所创建的标识为非持久化节点，创建完成以后，将处于等待状态下的实例的实时状态信息记录到信息节点中，(可以以如下形式记录：“信息节点/服务模块N/N配置i/i的实时状态信息”)，该实时状态信息包括该实例的位置及标识。

步骤S305、当检测到该工作实例中存在异常实例时，基于该异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换该异常实例。

在一种可能的实施方式下，基于该异常实例的配置信息，以及第二待启动实例，生成故障恢复实例，包括：

在等待状态的待启动实例中选取目标待启动实例；

对该异常实例的配置信息进行解析，获得目标解析结果；

根据该目标解析结果，对该目标待启动实例进行配置，生成该故障恢复实例。

在一种可能的实施方式下，在生成处于工作状态的工作实例以及处于等待状态的等待实例后，基于系统的监听机制，对处于工作状态的工作实例进行实时监控，当检测到该工作实例存在异常时(如异常退出、死机情况等)，则删除该异常实例在工作子节点下的标识，处于等待状态的等待实例及该异常实例重新进入竞争，进行再次解析配置信息集合，确认具体的配置内容，将竞争成功的实例生成为故障恢复实例，以替换该异常实例，从而实现工作实例存在异常时，系统故障的自动恢复，进一步降低运维管理人员处置的难度和实效。

在一种可能的实施方式下，当检测到该目标服务模块中的配置信息集合发生变更时，将该服务模块中对应的工作实例退出工作状态；

获取该目标服务模块中变更后的配置信息集合，并对该变更后的配置信息集合进行解析，获得变更解析结果；

根据该变更解析结果，对该目标服务模块对应的所有实例进行配置，生成变更工作实例。

在一种可能的实施方式下，基于系统的监听机制，实时监控系统的配置节点下各服务模块的配置信息集合是否发生变更，若发生变化表示该服务模块的项目需要更改配置，则该服务模块的所有实例均停止运行，并删除所有实例在状态节点下所对应的标识，之后，获取配置信息集合发生变更的服务模块，并对该变更后的配置信息集合进行解析，获得变更解析结果，根据该变更解析结果，对该服务模块对应的所有实例进行重新配置(即所有实例重新进入竞争)，生成新的工作实例及新的等待实例，以实现配置信息集合发生变更时，故障的自动恢复，降低运维管理人员处置的难度和实效。

在一种可能的实施方式下，从信息节点中提取实例启动信息，该实例启动信息包括已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息；

基于该实例启动信息，构建实例启动信息表；

当该状态节点发生改变时，遍历该状态节点中的实例，获取该实例启动信息表中记录而该状态节点中并不存在的目标实例；

从该实例启动信息表中，获取该目标实例的位置信息，并基于该位置信息重新生成该目标实例。

在一种可能的实施方式下，基于系统的监听机制，获取该实例启动信息表中记录而该状态节点中并不存在的目标实例M，使该目标实例M重新进入竞争模式，与图2及图3中的步骤进行结合，保证了系统中每个服务模块的实例出现故障后始终有备用实例即时接替工作，且出故障的实例可被重新启动后进入工作模式或等待模式，确保了系统的高可用性。

在一种可能的实施方式下，该实时状态信息至少包括该第一待启动实例与该第二待启动实例的位置及标识。

请参考图4，其示出了本申请实施例涉及的一种故障自动恢复逻辑示意图。

其具体步骤如下：获取服务模块N(即上述目标服务模块)，从创建的服务系统的配置节点下获取服务模块N的n个配置信息，并解析该配置信息，获取解析结果，即解析个数为i(即待启动实例的个数，待启动实例的个数一定要大于配置信息的个数n)。

再依据i＝0；i++；i<n的条件尝试在该服务系统的状态节点下的working子节点下创建非持久化节点，该非持久化节点为N配置i/i的标识。

若该实例i创建成功，则根据N配置i的规则，该创建成功的实例i进入工作模式，并将该实例i的实时状态信息记录到信息节点下，该实时状态信息记录至少包括位置及标识。

若该实例i创建未成功且i>n时，在该服务系统的状态节点下的waiting子节点下创建非持久化节点，该非持久化节点为N配置i/i的标识，该实例i进入等待模式，成为等待实例。同时，将该实例i的实时状态信息记录到信息节点下。

此后，为了保证系统的故障自动修复，服务系统再基于监听机制，不仅实时监控服务模块N中处于working子节点下的实例是否变化，还要实时监控配置节点下服务模块N的配置信息是否改变。

当处于working子节点下的实例发生变化时则表示该变化的实例异常，该异常实例以及处于waiting子节点下的实例重新开始竞争工作，同时删除处于waiting子节点下的实例标识。当配置节点下服务模块N的配置信息发生改变时，处于状态节点下的所有实例全部重新进入竞争模式。

其中，该服务系统下的所有模块的所有实例都按上述流程启动。

每个模块具体启动的实例个数(即上述第二数量的待启动实例或工作实例与等待实例相加的个数)需保证大于实际配置的个数(即配置信息的个数或工作实例的个数)，例如配置了n个实例，为保证故障自动恢复效果，可启动n+n个实例(最少不能低于n+1个)，确保始终至少有一个实例处于等待模式。

因为“/状态节点/服务模块N/working/N配置i/i的标识”是基于分布式应用程序协调服务软件(zookeeper)创建的非持久化节点，基于分布式应用程序协调服务软件(zookeeper)的特性，当此节点的创建者(实例i)出现异常(进程异常退出、死机情况等)时此节点由于失去了和创建者的联系，分布式应用程序协调服务软件(zookeeper)会将此非持久化节点清除。

当发生上述变化时，处于等待模式的服务模块N的实例基于分布式应用程序协调服务软件(zookeeper)提供的监听机制监听到“/状态节点/服务模块N/working”发生了变化，表示服务模块N的某个实例进程退出工作了，则此处于等待启动模式的实例重新进入竞争工作流程，尝试进入工作模式。

工作模式下的服务模块N的实例也同时基于分布式应用程序协调服务软件(zookeeper)提供的监听机制监听“/配置节点/服务模块N”是否发生变化，若发生变化表示项目需要改变配置，则此服务模块N的实例也停止工作，删除自己对应的非持久化节点，重新进入竞争工作流程，保证系统的所有模块都自动按项目的最新配置进行运行。

请参考图5，其示出了本申请实施例涉及的一种模块异常监听和恢复流程示意图。

其具体步骤如下：从创建的服务系统的信息节点下读取所有服务模块的实例启动信息，解析出已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息，并构建实例启动信息表。

服务系统再基于监听机制，实时监控状态节点的实例是否发生改变，当监测到状态节点的实例发生改变时，遍历working子节点和waiting子节点，确认是否有实例启动信息表中记录而状态节点中并不存在的实例M。

当确定有实例启动信息表中记录而状态节点中并不存在的实例M，则根据实例启动信息表中该实例M的位置信息，重新启动实例M(重新进入竞争工作)。

其中，图5由监控模块实现，通过图5与图4的流程结合，保证了服务系统中每个服务模块及实例出现故障后始终有备用实例即时接替工作，且出故障的实例可被重新启动后进入等待模式或工作模式，确保了该服务系统的高可用性。

综上所述，本申请实施例提供了一种故障自动恢复方法，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将第一待启动实例生成为工作实例，当检测到工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，保证了系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

图6是根据一示例性实施例示出的一种故障自动恢复装置的结构方框图。该一种故障自动恢复装置包括：

配置信息集合获取模块601，用于获取目标服务模块的配置信息集合；

待启动实例获取模块602，用于基于该配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，该第二数量大于第一数量；

工作实例生成模块603，用于基于第一数量的配置信息，在该第二数量的待启动实例中选取第一数量的第一待启动实例，并将该第一数量的第一待启动实例生成为处于工作状态的工作实例；

故障恢复实例生成模块604，用于当检测到该工作实例中存在异常实例时，基于该异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换该异常实例；该第二待启动实例为除该第一待启动实例之外的待启动实例。

在一种可能的实现方式中，该故障自动恢复装置还包括：

等待状态确定模块，用于将该第二待启动实例中的至少一个待启动实例确定为等待状态。

该故障恢复实例生成模块604，还用于：

在等待状态的待启动实例中选取目标待启动实例；

对该异常实例的配置信息进行解析，获得目标解析结果；

根据该目标解析结果，对该目标待启动实例进行配置，生成该故障恢复实例。

在一种可能的实现方式中，该等待状态确定模块还用于：

将该第二待启动实例中的至少一个待启动实例对应的实例标识，放置于状态节点的等待子节点中，以将该至少一个待启动实例确定为等待状态。

在一种可能的实现方式中，该工作实例生成模块603还用于：

将该第一数量的第一待启动实例对应的实例标识，放置于状态节点的工作子节点中，以将第一待启动实例将确定为工作状态，并生成为工作实例。

在一种可能的实现方式中，该故障自动恢复装置还包括：

工作实例退出模块，用于当检测到该目标服务模块中的配置信息集合发生变更时，将该服务模块中对应的工作实例退出工作状态；

变更解析结果获取模块，用于获取该目标服务模块中变更后的配置信息集合，并对该变更后的配置信息集合进行解析，获得变更解析结果；

变更工作实例生成模块，用于根据该变更解析结果，对该目标服务模块对应的所有实例进行配置，生成变更工作实例。

在一种可能的实现方式中，该故障自动恢复装置还包括：

实例启动信息获取模块，用于从信息节点中提取实例启动信息，该实例启动信息包括已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息；

实例启动信息表构建模块，用于基于该实例启动信息，构建实例启动信息表；

目标实例获取模块，用于当该状态节点发生改变时，遍历该状态节点中的实例，获取该实例启动信息表中记录而该状态节点中并不存在的目标实例；

重新生成模块，用于从该实例启动信息表中，获取该目标实例的位置信息，并基于该位置信息重新生成该目标实例。

在一种可能的实现方式中，该实时状态信息包括该第一待启动实例与该第二待启动实例的位置及标识。

综上所述，本申请实施例提供了一种故障自动恢复装置，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将第一待启动实例生成为工作实例，当检测到工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，保证了系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

图7是根据一示例性实施例示出的一种基于zookeeper创建的服务系统管理节点结构示意图，该服务系统包括：

信息节点、配置节点、状态节点及监控节点；

该信息节点，用于存储该服务系统的通用配置信息及各个服务模块在不同配置下的实时状态信息；

该配置节点，用于存储各个服务模块的配置信息集合；

该状态节点，用于存储各个服务模块下每个实例的工作状态及等待状态；

该监控节点，用于存储第一监控模块及第二监控模块的工作状态。

在一种可能的实现方式中，该第一监控模块，为主监控模块，用于监测该工作实例中存在的异常实例及该配置信息集合发生改变的服务模块；

该第二监控模块，为备用监控模块，用于监测该第一监控模块的工作状态，当该第一监控模块出现故障时，该第二监控模块替代该第一监控模块监测该工作实例中存在的异常实例及该配置信息集合发生改变的服务模块。

进一步的，设某服务系统由N个服务模块构成，每个服务模块又会根据实际情况而运行1到n个实例(对应不同的配置信息)，这些实例运行于不同的物理服务器上，每个服务器上都安装一个分布式应用程序协调服务软件(zookeeper)。图7的具体说明如下：

XX服务系统节点(即任一服务系统，该节点为根节点)：持久化节点，是服务系统管理的根节点。

信息节点(该节点为一级子节点)：持久化节点，用于存储本系统(项目相关)的通用配置信息、各个服务模块的不同配置(即不同实例)下的实时状态信息。

信息节点下的通用节点(该节点为二级节点)：持久化节点，用于存储本服务系统的项目信息描述，至少包括：项目名称及本服务系统类型。

信息节点下的服务模块N节点(该节点为二级节点)：持久化节点，用于存储服务模块实际启动的多个实例(即第二数量的待启动实例，或工作实例及等待实例相加)的实时状态信息。

配置节点(该节点为一级子节点)：持久化节点，用于存储本系统中N个服务模块的配置信息，且每个服务模块根据需要可以有多个配置信息。

配置节点下的服务模块N节点(该节点为二级节点)：持久化节点，每个节点下根据本服务系统项目需要存储该服务模块需要启动的n个实例的配置信息。

状态节点(该节点为一级子节点)：持久化节点，用于存储本服务系统中N个服务模块下每个实例的工作状态。

状态节点下的服务模块N节点(该节点为二级节点)：持久化节点，用于记录该服务模块的工作状态，包括2个三级子节点：持久化节点working(工作中)和持久化节点waiting(等待中)。

其中，working节点下的/N配置n节点(四级节点)：非持久化节点，用于记录不同服务模块下的工作实例的标识，每创建一个代表此服务模块的对应配置信息的实例正在运行，当某节点消失则表示该服务模块中该实例出现故障；

waiting节点下的/N配置n节点(四级节点)：非持久化节点，用于记录不同服务模块下的的等待实例的标识，每创建一个代表此服务模块的备用实例等待运行。

监控节点(一级子节点)：持久化节点，用于存储独立的监控服务模块(该监控服务模块2个，一主一备)的工作状态。

监控节点下的working(二级节点)和waiting(二级节点)为持久化节点；

其中，working节点下的三级节点为临时节点，用于记录本服务系统主监控模块(即第一监控模块)下的实例标识；

waiting节点下的三级节点为临时节点，用于记录本服务系统备用监控模块(即第二监控模块)下的实例标识。

综上所述，本申请实施例提供了一种服务系统，基于配置信息的第一数量，生成大于第一数量的第二数量的待启动实例，在第二数量的待启动实例中选取第一数量的第一待启动实例，并将第一待启动实例生成为工作实例，当检测到工作实例中存在异常实例时，基于异常实例的配置信息以及除第一待启动实例之外的待启动实例，生成故障恢复实例以替换异常实例，保证了系统中实例出现故障后始终有备用实例即时接替工作，增强了分布式服务系统故障全自动化恢复的能力，极大减轻了运维人员的负担。

图8是根据本申请一示例性实施例提供的一种计算机设备示意图，所述计算机设备包括存储器和处理器，所述存储器用于存储计算机程序，所述计算机程序被所述处理器执行时，实现上述的故障自动恢复方法。

其中，处理器可以为中央处理器(Central Processing Unit，CPU)。处理器还可以为其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等芯片，或者上述各类芯片的组合。

存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序、非暂态计算机可执行程序以及模块，如本发明实施方式中的方法对应的程序指令/模块。处理器通过运行存储在存储器中的非暂态软件程序、指令以及模块，从而执行处理器的各种功能应用以及数据处理，即实现上述方法实施方式中的方法。

存储器可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储处理器所创建的数据等。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

在一示例性实施例中，还提供了一种计算机可读存储介质，用于存储有至少一条计算机程序，所述至少一条计算机程序由处理器加载并执行以实现上述方法中的全部或部分步骤。例如，该计算机可读存储介质可以是只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、只读光盘(Compact Disc Read-Only Memory，CD-ROM)、磁带、软盘和光数据存储设备等。

在一示例性实施例中，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述图2或图3任一实施例所示方法的全部或部分步骤。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (8)

1.一种故障自动恢复方法，其特征在于，所述方法应用于服务系统，所述方法包括：

获取目标服务模块的配置信息集合；

基于所述配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，所述第二数量大于第一数量；

基于第一数量的配置信息，在所述第二数量的待启动实例中选取第一数量的第一待启动实例，并将所述第一数量的第一待启动实例生成为处于工作状态的工作实例；

当检测到所述工作实例中存在异常实例时，基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换所述异常实例；

所述第二待启动实例为除所述第一待启动实例之外的待启动实例；

当检测到所述目标服务模块中的配置信息集合发生变更时，将所述服务模块中对应的工作实例退出工作状态；

获取所述目标服务模块中变更后的配置信息集合，并对所述变更后的配置信息集合进行解析，获得变更解析结果；

根据所述变更解析结果，对所述目标服务模块对应的所有实例进行配置，生成变更工作实例；

从信息节点中提取实例启动信息，所述实例启动信息包括已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息；

基于所述实例启动信息，构建实例启动信息表；

当状态节点发生改变时，遍历所述状态节点中的实例，获取所述实例启动信息表中记录而所述状态节点中并不存在的目标实例；

从所述实例启动信息表中，获取所述目标实例的位置信息，并基于所述位置信息重新生成所述目标实例。

2.根据权利要求1所述的方法，其特征在于，在所述当检测到所述工作实例中存在异常实例时，基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换所述异常实例之前，所述方法还包括：

将所述第二待启动实例中的至少一个待启动实例确定为等待状态；

所述基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例，包括：

在等待状态的待启动实例中选取目标待启动实例；

对所述异常实例的配置信息进行解析，获得目标解析结果；

根据所述目标解析结果，对所述目标待启动实例进行配置，生成所述故障恢复实例。

3.根据权利要求2所述的方法，其特征在于，所述将所述第二待启动实例中的至少一个待启动实例确定为等待状态，包括：

将所述第二待启动实例中的至少一个待启动实例对应的实例标识，放置于状态节点的等待子节点中，以将所述至少一个待启动实例确定为等待状态。

4.根据权利要求3所述的方法，其特征在于，所述将所述第一数量的第一待启动实例生成为处于工作状态的工作实例，包括：

将所述第一数量的第一待启动实例对应的实例标识，放置于状态节点的工作子节点中，以将第一待启动实例将确定为工作状态，并生成为工作实例。

5.根据权利要求1所述的方法，其特征在于，所述实时状态信息包括所述第一待启动实例与所述第二待启动实例的位置及标识。

6.一种故障自动恢复装置，其特征在于，包括：

配置信息集合获取模块，用于获取目标服务模块的配置信息集合；

待启动实例获取模块，用于基于所述配置信息集合中配置信息的第一数量，生成第二数量的待启动实例，所述第二数量大于第一数量；

工作实例生成模块，用于基于第一数量的配置信息，在所述第二数量的待启动实例中选取第一数量的第一待启动实例，并将所述第一数量的第一待启动实例生成为处于工作状态的工作实例；

故障恢复实例生成模块，用于当检测到所述工作实例中存在异常实例时，基于所述异常实例的配置信息，以及第二待启动实例，生成故障恢复实例以替换所述异常实例；所述第二待启动实例为除所述第一待启动实例之外的待启动实例；

工作实例退出模块，用于当检测到所述目标服务模块中的配置信息集合发生变更时，将所述服务模块中对应的工作实例退出工作状态；

变更解析结果获取模块，用于获取所述目标服务模块中变更后的配置信息集合，并对所述变更后的配置信息集合进行解析，获得变更解析结果；

变更工作实例生成模块，用于根据所述变更解析结果，对所述目标服务模块对应的所有实例进行配置，生成变更工作实例；

实例启动信息获取模块，用于从信息节点中提取实例启动信息，所述实例启动信息包括已启动的服务模块个数、各个已启动的服务模块中的实例个数及各个实例的实时状态信息；

实例启动信息表构建模块，用于基于所述实例启动信息，构建实例启动信息表；

目标实例获取模块，用于当状态节点发生改变时，遍历所述状态节点中的实例，获取所述实例启动信息表中记录而所述状态节点中并不存在的目标实例；

重新生成模块，用于从所述实例启动信息表中，获取所述目标实例的位置信息，并基于所述位置信息重新生成所述目标实例。

7.一种服务系统，其特征在于，所述服务系统用于执行如权利要求1至5任一所述的一种故障自动恢复方法，所述服务系统包括：信息节点、配置节点、状态节点及监控节点；

所述信息节点，用于存储所述服务系统的通用配置信息及各个服务模块在不同配置下的实时状态信息；

所述配置节点，用于存储各个服务模块的配置信息集合；

所述状态节点，用于存储各个服务模块下每个实例的工作状态及等待状态；

所述监控节点，用于存储第一监控模块及第二监控模块的工作状态。

8.根据权利要求7所述的系统，其特征在于，所述第一监控模块，用于监测所述工作实例中存在的异常实例及所述配置信息集合发生改变的服务模块；

所述第二监控模块，用于监测所述第一监控模块的工作状态，当所述第一监控模块出现故障时，所述第二监控模块替代所述第一监控模块监测所述工作实例中存在的异常实例及所述配置信息集合发生改变的服务模块。