服务守护方法、装置及可读存储介质

摘要

本申请提供一种服务守护方法、装置及可读存储介质，涉及计算机技术领域。所述方法包括：在守护的目标服务的当前状态为停止状态时，判断该目标服务是否为共生服务；若该目标服务为共生服务，则确定该目标服务所在的共生服务组，然后向该共生服务组中的其他服务发送目标服务停止命令，以使该共生服务组中各服务的状态为停止状态；最后向该共生服务组中的各个服务发送目标服务启动命令，以启动该共生服务组，使该共生服务组中各个服务的目标状态的状态信息相同。由此，可保证共生服务之间目标状态的状态信息的一致性，避免由于共生服务的目标状态的状态信息不一致而导致软件系统异常。

说明书

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种服务守护方法、装置及可读存储介质。

背景技术

由于业务需要，系统的多个服务之间往往需要保证某个状态的状态信息的一致性，这在当前的软件系统中十分常见。对于一个完善的软件系统，如果其中的多个服务需要保证某个状态的状态信息的一致性，那么，当其中一个服务该状态的状态信息发生改变时，其他服务会主动将该状态信息进行同步改变，这部分逻辑一般会在服务代码层面实现。但是，对于一些软件系统来说，由于种种限制无法在服务代码层面实现这种状态信息的同步机制。若在这种情况下，一组共生服务中的某个服务为停止状态，即，某个服务与该组共生服务中的其他服务所要维护的状态的状态信息不同，将导致软件系统异常。

发明内容

为了克服现有技术中的上述不足，本申请的目的在于提供一种服务守护方法、装置及可读存储介质，其能够保证共生服务之间所维护的状态的时时一致性，避免由于共生服务之间所维护的状态的状态信息不一致而导致软件系统异常。

本申请的实施例可以这样实现：

第一方面，本申请实施例提供一种服务守护方法，包括：

在守护的目标服务的当前状态为停止状态时，判断所述目标服务是否为共生服务；

若所述目标服务为共生服务，确定所述目标服务所在的共生服务组；

向所述共生服务组中的其他服务发送目标服务停止命令，以使所述共生服务组中各服务的状态为停止状态；

向所述共生服务组中的各个服务发送目标服务启动命令，以启动所述共生服务组，使所述共生服务组中各个服务的目标状态的状态信息相同。

在可选的实施方式中，在所述在守护的目标服务的当前状态为停止状态时，判断所述目标服务是否为共生服务之前，所述方法还包括：

通过守护线程获取守护的目标服务的服务锁；

若获取服务锁成功，则获取所述目标服务的当前状态。

在可选的实施方式中，所述方法还包括：

若所述目标服务的当前状态不是停止状态，则释放所述目标服务对应的服务锁；

若所述目标服务不是共生服务，则通过所述目标服务启动命令启动所述目标服务，并释放所述目标服务对应的服务锁。

在可选的实施方式中，所述向所述共生服务组中的其他服务发送目标服务停止命令，包括：

通过守护线程获取该共生服务组的守护锁；

若获取守护锁成功，则向所述共生服务组中的其他服务发送所述目标服务停止命令。

在可选的实施方式中，所述方法还包括：

若获取守护锁失败，则释放所述目标服务对应的服务锁。

在可选的实施方式中，所述向所述共生服务组中的各个服务发送目标服务启动命令，包括：

通过守护线程获取该共生服务组的状态锁；

若获取成功，则向该共生服务组中各个服务发送所述目标服务启动命令；

若获取失败，则在等待一预设时间段后再次执行获取该共生服务组的状态锁的步骤。

在可选的实施方式中，在所述向所述共生服务组中的各个服务发送目标服务启动命令，以启动所述共生服务组，使所述共生服务组中各个服务的目标状态的状态信息相同之后，所述方法还包括：

释放所述共生服务组的状态锁、所述共生服务组的守护锁、及所述目标服务的服务锁。

第二方面，本申请实施例提供一种服务守护装置，包括：

判断模块，用于在守护的目标服务的当前状态为停止状态时，判断所述目标服务是否为共生服务；

确定模块，用于在所述目标服务为共生服务时，确定所述目标服务所在的共生服务组；

控制模块，用于向所述共生服务组中的其他服务发送目标服务停止命令，以使所述共生服务组中各服务的状态为停止状态；

控制模块，还用于向所述共生服务组中的各个服务发送目标服务启动命令，以启动所述共生服务组，使所述共生服务组中各个服务的目标状态的状态信息相同。

在可选的实施方式中，所述控制模块还用于：

获取守护的目标服务的服务锁，并在获取服务锁成功时，获取所述目标服务的当前状态。

第三方面，本申请实施例提供一种可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的服务守护方法。

相对于现有技术而言，本申请具有以下有益效果：

在守护的目标服务的当前状态为停止状态时，首先判断该目标服务是否为共生服务。若该目标服务为共生服务，则确定该目标服务所在的共生服务组，然后向该共生服务组中的其他服务发送目标服务停止命令，以使该共生服务组中各服务的状态为停止状态。最后向该共生服务组中的各个服务发送目标服务启动命令，以启动该共生服务组，使该共生服务组中各个服务的目标状态的状态信息相同。由此，可保证共生服务之间目标状态的一致性，避免由于共生服务的目标状态的状态信息不一致而导致软件系统异常。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本申请实施例提供的共生服务的说明示意图；

图2是本申请实施例提供的电子设备的方框示意图；

图3是本申请实施例提供的服务守护方法的流程示意图之一；

图4是本申请实施例提供的服务守护方法的流程示意图之二；

图5是本申请实施例提供的服务守护装置的方框示意图。

图标：100-电子设备；110-存储器；120-存储控制器；130-处理器；200-服务守护装置；210-判断模块；220-确定模块；230-控制模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。此外，若出现术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

需要说明的是，在不冲突的情况下，本申请的实施例中的特征可以相互结合。

请参照图1，图1是本申请实施例提供的共生服务的说明示意图。图1中方框表示服务，圆形表示状态s，有填充的圆形表示状态s的状态信息为s1，无填充的圆形表示状态s的状态信息为初始信息s0。若一组服务需要严格保证某个状态或某些状态的一致性，则该组服务中的服务之间存在共生关系，该组服务为一组共生服务，该共生服务组中的每个服务都是共生服务。比如，有服务A、B、C、D，每个服务有状态s、y、w，若需要保证服务A、B、C、D中状态s(或状态y及状态w)的状态信息完全一致，则服务A、B、C、D为一组共生服务。若共生服务要维护的某个状态的状态信息不一致，会导致软件系统异常。

举例来说，假设服务A、B、C、D是一组共生服务，每个服务都维护了状态s，即服务A、B、C、D所维护的状态s必须完全一致。在阶段一，服务A、B、C、D刚刚启动完成还未接收外部请求，此时服务A、B、C、D中的状态s的状态信息均为初始信息s0，是一致的，系统正常。在阶段二，外部请求将服务A、B、C、D中的状态s的状态信息统一改为s1，系统正常。但是，如果在阶段二后，服务B被重启，那么服务B中的状态s的状态信息就会变为初始信息s0，此时则如图1中的阶段三所示：服务A、C、D状态s的状态信息为s1，服务B状态s的状态信息为初始信息s0，服务A、B、C、D中的状态s的状态信息不再一致，由此便会导致系统异常。除此之外，还存在其他导致服务A、B、C、D中的状态s的状态信息不一致的情况，此处不再一一列举。

请参照图2，图2是本申请实施例提供的电子设备100的方框示意图，该电子设备100可以是，但不限于，智能手机、个人电脑(personal computer，PC)、平板电脑、个人数字助理(personal digital assistant，PDA)等。该电子设备100可以包括存储器110、存储控制器120、处理器130及服务守护装置200。

所述存储器110、存储控制器120及处理器130各元件之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器110中存储有服务守护装置200，所述服务守护装置200包括至少一个可以软件或固件(firmware)的形式存储于所述存储器110中的软件功能模块。所述处理器130通过运行存储在存储器110内的软件程序以及模块，如本申请实施例中的服务守护装置200，从而执行各种功能应用以及数据处理，即实现本申请实施例中的服务守护方法。

可以理解，图2所示的结构仅为示意，电子设备100还可包括比图2中所示更多或者更少的组件，或者具有与图2所示不同的配置。图2中所示的各组件可以采用硬件、软件或其组合实现。

请参照图3，图3是本申请实施例提供的服务守护方法的流程示意图之一。下面对服务守护方法的具体流程进行详细阐述。

步骤S110，在守护的目标服务的当前状态为停止状态时，判断所述目标服务是否为共生服务。

若所述目标服务为共生服务，则执行步骤S120。

步骤S120，确定所述目标服务所在的共生服务组。

步骤S130，向所述共生服务组中的其他服务发送目标服务停止命令，以使所述共生服务组中各服务的状态为停止状态。

步骤S140，向所述共生服务组中的各个服务发送目标服务启动命令，以启动所述共生服务组，使所述共生服务组中各个服务的目标状态的状态信息相同。

守护进程是始终运行在系统后台，负责监控系统的各个服务运行状况的一个进程。守护进程在守护的某个服务的当前状态为停止状态时，通过查找系统配置文件判断该服务是否为共生服务。该系统配置文件中可以包括与其他服务存在共生关系的服务的标识之间的对应关系，基于该对应关系可以获得每组共生服务中各服务的标识。由此，基于该系统配置文件可判断一服务是否为共生服务，并在该服务为共生服务时，获得与该服务存在共生关系的其他服务的标识。其中，上述标识可以是服务的名称，也可以是其他可用于唯一标识服务的参数。可选地，系统配置文件中还可以包括每组共生服务需要维护的目标状态，该目标状态表示该组共生服务要维护状态信息一致的状态是什么状态，比如，目标状态为状态s。其中，目标服务表示守护进程守护的服务。

基于该系统配置文件，守护进程可确定当前状态为停止状态的该目标服务是否是共生服务，并在该目标服务为共生服务时，得到与该目标服务存在共生关系的其他服务的标识。由此，守护进程可确定目标服务所在的共生服务组。

在确定当前状态为停止状态的目标服务所在的共生服务组后，守护进程可同时向共生服务组中的其他每个服务(即，该共生服务组中的除目标服务之外的其他每个服务)发送目标服务停止命令。其他服务在接收到该目标服务停止命令后，停止运行。若在接收到该目标服务停止命令之前，其他服务中存在已经是停止状态的服务，则该服务仍然是停止状态。可选地，守护进程也可以直接向共生服务组中的每个服务发送所述目标服务停止命令，以保证共生服务组中的各服务均停止运行。或者，守护进程在发送目标服务停止命令前，先获得共生服务组中其他每个服务的当前状态，并判断其他每个服务的当前状态是否为停止状态，然后向共生服务组中当前状态不是停止状态的各服务发送目标服务停止命令。

由此通过目标服务停止命令，使所述共生服务组中的各服务的状态均为停止状态。接着，守护进程可向该共生服务组中各个服务发送目标服务启动命令，以同步启动所述共生服务组中的各个服务。共生服务组中的各个服务在启动后，目标状态的状态信息均为初始信息，该初始信息相同。

本申请实施例针对无法在服务代码层面实现服务状态同步机制的系统，从系统运维的角度给出一种共生服务的服务守护控制方案，保证共生服务之间目标状态的一致性。在本申请实施例中，为保持共生服务目标状态的一致性，对于某一停止的共生服务，先同步停止所有与其有共生关系的服务，然后再同步启动该服务及与该服务有共生关系的其他服务。由此，在系统中的某个共生服务停止时，守护进程不仅会拉起该服务自身，还会兼顾该服务重新启动对与其存在共生关系的其他服务的影响，实现共生服务之间所维护的状态信息(即，目标状态的状态信息)的同步，保证系统的正常运行。

在本申请实施例中，针对每个服务的单次服务控制操作(启动或停止)，都启动一个独立的线程来完成。针对每一个服务的运行情况，守护进程可分别为其创建对应的守护线程来执行监控任务，即每个服务对应一个守护线程，不同服务的守护线程并发执行。当某个服务异常停止时，该服务对应的守护线程会根据特定的策略使该服务恢复正常运行。

针对每个服务，定义如下服务控制命令：

第一服务启动命令：startCmd，第一服务启动命令为不受服务锁约束的服务启动命令；

第一服务停止命令：stopCmd，第一服务停止命令为不受服务锁约束的服务停止命令；

第二服务启动命令：startSynCmd，第二服务启动命令为受服务锁约束的服务启动命令；

第二服务停止命令：stopSynCmd，第二服务停止命令为受服务锁约束的服务停止命令。

其中，第一服务启动命令startCmd及第一服务停止命令stopCmd只能由守护线程调用。服务锁用于保证同一时刻只能有一个线程可以对某个服务进行控制，该线程可以是该服务对应的守护线程，也可以是针对该服务的单次控制操作(比如，第二服务启动命令startSynCmd、或第二服务停止命令stopSynCmd)对应的线程。

请参照图4，图4是本申请实施例提供的服务守护方法的流程示意图之二。在步骤S110之前，所述方法还可以包括步骤S101及步骤S102。

步骤S101，判断是否成功通过守护线程获取守护的目标服务的服务锁。

若获取服务锁成功，则执行步骤S102。

步骤S102，获取所述目标服务的当前状态。

守护线程与服务一一对应，守护线程守护的服务即为该守护线程守护的目标服务。守护线程在守护时，首先尝试获取该服务(即，守护线程守护的目标服务)的服务锁。在本实施例中，服务锁用于保证同一时刻只能有一个线程可以对某个服务进行控制，如果守护线程成功获取了该目标服务的服务锁，那么其他针对该服务的控制操作(第二服务启动命令startSynCmd、或第二服务停止命令stopSynCmd)就不会生效。由此，可避免其他的服务控制操作影响守护线程的工作。

若守护线程没有成功获取守护的目标服务的服务锁，守护线程则结束本轮守护。

若守护线程成功获取守护的目标服务的服务锁，则获取该目标服务的当前状态，并判断该目标服务是否处于停止状态。

若守护线程成功获取守护的目标服务的服务锁，且该目标服务未处于停止状态，守护线程则释放获取到的目标服务的服务锁，并结束本轮守护。在本申请实施例中，服务未处于停止状态，可表示该服务正常运行，守护线程此时无需对该服务进行控制，因此可直接释放服务锁，并结束该轮守护。

若该目标服务处于停止状态，守护线程则执行步骤S110：判断目标服务是否为共生服务。

若该目标服务不是共生服务，可选地，守护线程可直接释放服务锁，并结束该轮守护。或者，守护线程可执行步骤S150：通过所述目标服务启动命令启动所述目标服务，并释放所述目标服务对应的服务锁。即，守护线程可通过系统配置文件确定该目标服务是否为共生服务，并在该目标服务不是共生服务时，直接调用该目标服务的目标服务启动命令，以将该目标服务启动，然后释放获取到的该目标服务的服务锁，并结束本轮守护。其中，目标服务启动命令为上文所述的第一服务启动命令startCmd。

若该目标服务是共生服务，守护线程则执行步骤S120～S140。

可选地，守护线程在确定守护的目标服务是共生服务，且确定目标服务所在的共生服务组后，尝试获取该共生服务组的守护锁。在实施例中，守护锁保证了同一时刻最多只有一个共生服务的守护线程在工作。守护线程在成功获取守护锁后，同步向共生服务组中的其他服务发送所述目标服务停止命令(即第一服务停止命令stopCmd)，以使与守护的目标服务对应的共生服务组中的其他服务停止运行。若守护线程没有成功获取该共生服务组的守护锁，表示其他的守护线程正在工作，此时守护线程可直接结束本轮守护；或者，释放获取到的目标服务的服务锁，并结束本轮守护。

由于守护线程会先停止与守护的目标服务存在共生关系的其他服务，然后再将该目标服务及与该目标服务存在共生关系的其他服务一起重新启动。如果服务A、B、C、D是一组共生服务，服务A的守护线程A'检测到A处于停止状态之后，会将服务B、C、D停止，然后再将服务A、B、C、D启动。如果没有守护锁，那么服务B的守护线程B'可能会在守护线程A'停止服务B之后，检测到服务B处于停止状态，由此守护线程B'也进入服务守护流程。同理，守护线程B'也会进行停止服务A、C、D的操作，如果此时守护线程A'已经完成守护流程将A、B、C、D启动完成了，这时便会导致守护流程的混乱，甚至会导致服务A、B、C、D处于无休止的停止、重启的循环中。而通过设置守护锁，则可以保证同一时刻最多只有一个共生服务的守护线程在工作，从而避免上述问题。

可选地，守护线程在确定守护的目标服务所在的共生服务组后，可将该共生服务组中各个服务的标识一并放到集合SET中。接着，守护线程应用所述目标服务停止命令(即stopCmd命令)停止集合SET对应的所有服务。

然后，守护线程尝试获取该共生服务组的状态锁。在本实施例中，任何针对共生服务所维护的状态(即目标状态)的修改操作都要先获取状态锁，状态锁保证了一组共生服务的目标状态修改的同步性。即，状态锁是用于保证一组共生服务的目标状态能够被同步修改的一种机制。

如果没有状态锁，那么有可能当服务A、B、C、D只启动了服务A、B时，就有外部请求来改变这四个服务的状态。服务A、B因为已经启动了可以修改成功，但是服务C、D还没有启动就无法修改。如此一来，待服务C、D启动之后其状态为初始值，与服务A、B状态不一致，导致系统异常。同理，外部请求修改共生服务的状态时也会获取状态锁。

若守护线程没有成功获取守护的目标服务所在的共生服务组的状态锁，即获取状态锁失败，则在等待一预设时间段后重新尝试获取状态锁。此时是由于外部请求获取了状态锁，外部请求想要修改这组共生服务的目标状态。但是由于这组共生服务已经因为所述目标服务停止命令而为停止状态，其目标状态无法被外部请求更改，所以外部请求会很快释放该共生服务组的状态锁。

若守护线程成功获取该共生服务组的状态锁，则向该共生服务服务组中的各个服务发送所述目标服务启动命令，以启动该共生服务组中的各个服务。共生服务组中的各个服务在启动后，目标状态的状态信息均为相同的初始值。可选地，守护线程在成功获取状态锁后，可应用所述目标服务启动命令(即startCmd命令)启动集合SET对应的所有服务，并将该组共生服务所维护的状态的状态信息置为相同的初始信息。

重新启动共生服务组中的各服务后，守护线程可释放获取到的目标服务的服务锁、共生服务组的守护锁和状态锁，以便其他线程或外部请求对目标服务或目标服务所在的共生服务组进行控制，并结束本轮守护。

在本实施例的一种实施方式中，守护线程先释放该共生服务组的状态锁，以允许外部请求对这组共生服务进行状态修改，从而使得外部请求能够及时获得状态锁，进而修改该组共生服务的状态。接着，守护线程释放该共生服务组的守护锁，以允许其他服务的守护线程进行服务守护操作。然后，守护线程释放守护的目标服务的服务锁，以允许其他线程对该目标服务进行服务控制，并结束本轮守护。由此，在使得共生服务组的目标状态的状态信息一致后，确保其他线程或外部请求在有需要的情况下，能够及时对目标服务或目标服务所在的共生服务组进行控制。

上述过程是一个服务的守护线程的一次守护流程。可选地，一个服务的守护线程可间隔一定时间(比如，10s)进行一次上述守护流程。由此，通过应用服务锁、守护锁、状态锁，可完成对共生服务的服务守护，实现共生服务之间所维护的状态信息的同步，保证系统正常运行。

请参照图5，图5是本申请实施例提供的服务守护装置200的方框示意图。所述服务守护装置200可以包括判断模块210、确定模块220及控制模块230。

判断模块210，用于在守护的目标服务的当前状态为停止状态时，判断所述目标服务是否为共生服务。

确定模块220，用于在所述目标服务为共生服务时，确定所述目标服务所在的共生服务组。

控制模块230，用于向所述共生服务组中的其他服务发送目标服务停止命令，以使所述共生服务组中各服务的状态为停止状态。

控制模块230，还用于向所述共生服务组中的各个服务发送目标服务启动命令，以启动所述共生服务组，使所述共生服务组中各个服务的目标状态的状态信息相同。

可选地，在本实施例中，所述控制模块230还用于：

获取守护的目标服务的服务锁，并在获取服务锁成功时，获取所述目标服务的当前状态。

可选地，在本申请实施例中，所述控制模块230具体用于：

获取该共生服务组的守护锁；

若获取守护锁成功，则向所述共生服务组中的其他服务发送所述目标服务停止命令。

可选地，在本申请实施例中，所述控制模块230还具体用于：

获取该共生服务组的状态锁；

若获取成功，则向该共生服务组中各个服务发送所述目标服务启动命令；

若获取失败，则在等待一预设时间段后再次执行获取该共生服务组的状态锁的步骤。

可选地，在本申请实施例中，所述控制模块230还用于在发送目标服务启动命令后，释放所述共生服务组的状态锁、所述共生服务组的守护锁、及所述目标服务的服务锁。

在本实施例中，关于所述服务守护装置200的具体描述可参见上文对服务守护方法的描述，在此不再阐述。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

综上所述，本申请实施例提供了一种服务守护方法及装置。在守护的目标服务的当前状态为停止状态时，首先判断该目标服务是否为共生服务。若该目标服务为共生服务，则确定该目标服务所在的共生服务组，然后向该共生服务组中的其他服务发送目标服务停止命令，以使该共生服务组中各服务的状态为停止状态。最后向该共生服务组中的各个服务发送目标服务启动命令，以启动该共生服务组，使该共生服务组中各个服务的目标状态的状态信息相同。由此，可保证共生服务之间目标状态的状态信息的一致性，避免由于共生服务的目标状态的状态信息不一致而导致软件系统异常。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。