一种服务探活方法及装置与流程

本申请涉及计算机网络技术领域，特别是涉及一种服务探活方法及装置。

背景技术：

在云计算领域内，一台云物理服务器可以创建有多台以虚拟机方式运行的云服务器(elasticcomputeservice，ecs)。云服务器是一种简单高效、安全可靠、处理能力可弹性伸缩的计算服务。云服务器可以为用户提供多种线上服务，比如，云磁盘服务、简单缓存服务、负载均衡服务、对象存储服务、内容分发网络服务等。

现有技术中采用以下方法查看云服务器上的线上服务的运行状态(包括存活状态和非存活状态)，以对线上服务进行管理：管理员需要手工连接线上服务所在的云服务器，并且查看线上运行服务的日志文件，从而根据日志文件人工判断线上服务的运行状态。若虚拟机上运行有几十甚至上百个线上服务时，则管理员需要逐个去查询日志文件，耗费大量的人力物力，对线上服务进行管理十分困难。

技术实现要素：

本申请实施例的目的在于提供一种服务探活方法及装置，以解决对服务的探活操作依赖用户，浪费人力资源的问题。具体技术方案如下：

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

获取针对所述待探活服务的探活请求；

确定所述待探活服务的依赖组件，所述依赖组件为所述待探活服务运行过程中所需的组件；

向所述依赖组件发送访问请求，若访问成功，则确定针对所述待探活服务的探活结果为存活状态。

可选地，确定所述待探活服务的依赖组件，包括：

利用actuator模块，获取所述待探活服务的依赖组件标识，其中，所述actuator模块用于记录所述待探活服务的依赖组件标识；

确定所述依赖组件标识对应的依赖组件。

可选地，向所述依赖组件发送访问请求，包括：

从预设的配置文件中，获取所确定的依赖组件标识对应的访问地址，其中，所述配置文件中记录组件的标识与访问地址的对应关系；

依据所获取的访问地址，向所述依赖组件发送访问请求。

可选地，若访问成功，则确定针对所述待探活服务的探活结果为存活状态的步骤之前，还包括：

判断是否接收到所述依赖组件反馈的访问成功信息；

若接收到，则确定访问成功；

若未接收到，则确定访问失败，并确定针对所述待探活服务的探活结果为非存活状态。

可选地，所述方法还包括：

从预设的探活结果与键值的对应关系中，获取所确定出的探活结果的键值；

按照预先定义的类，将所获取的键值封装成为数据包；

将所述数据包反馈至发送所述探活请求的请求端。

可选地，所述电子设备上运行有至少一个虚拟机，每一个虚拟机上运行有至少一个服务；

获取针对所述待探活服务的探活请求的步骤之后，还包括：

基于所述探活请求携带的目的ip地址和端口号，确定运行所述待探活服务的虚拟机，作为目标虚拟机；

从所述目标虚拟机运行的服务中，确定所述待探活服务。

可选地，获取针对所述待探活服务的探活请求，包括：

接收代理服务器发送的针对所述待探活服务的探活请求，其中，所述代理服务器与每一虚拟机通信连接，所述代理服务器从负载均衡服务器接收所述探活请求，并从所述探活请求中获取所述目标虚拟机的ip地址和端口号，基于所述ip地址和所述端口号发送所述探活请求至所述目标虚拟机。

可选地，所述方法还包括：

将所述待探活服务的探活结果存储于预设数据库中，其中，所述预设数据库用于存储服务的探活结果。

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

第一获取模块，用于获取针对待探活服务的探活请求；

第一确定模块，用于确定所述待探活服务的依赖组件，所述依赖组件为所述待探活服务运行过程中所需的组件；

发送模块，用于向所述依赖组件发送访问请求，若访问成功，则确定针对所述待探活服务的探活结果为存活状态。

可选地，所述第一确定模块具体用于：

利用actuator模块，获取所述待探活服务的依赖组件标识，其中，所述actuator模块用于记录所述待探活服务的依赖组件标识；

确定所述依赖组件标识对应的依赖组件。

可选地，所述发送模块具体用于：

从预设的配置文件中，获取所确定的依赖组件标识对应的访问地址，其中，所述配置文件中记录组件的标识与访问地址的对应关系；

依据所获取的访问地址，向所述依赖组件发送访问请求。

可选地，所述装置还包括：

判断模块，用于判断是否接收到所述依赖组件反馈的访问成功信息；

第二确定模块，用于当所述判断模块的判断结果为是时，则确定访问成功；

第三确定模块，用于当所述判断模块的判断结果为否时，则确定访问失败，并确定针对所述待探活服务的探活结果为非存活状态。

可选地，所述装置还包括：

第二获取模块，用于从预设的探活结果与键值的对应关系中，获取所确定出的探活结果的键值；

封装模块，用于按照预先定义的类，将所获取的键值封装成为数据包；

反馈模块，用于将所述数据包反馈至发送所述探活请求的请求端。

可选地，所述电子设备上运行有至少一个虚拟机，每一个虚拟机上运行有至少一个服务；所述装置还包括：

第四确定模块，用于基于所述探活请求携带的目的ip地址和端口号，确定运行所述待探活服务的虚拟机，作为目标虚拟机；

第五确定模块，用于从所述目标虚拟机运行的服务中，确定所述待探活服务。

可选地，所述第一获取模块具体用于：

接收代理服务器发送的针对所述待探活服务的探活请求，其中，所述代理服务器与每一虚拟机通信连接，所述代理服务器从负载均衡服务器接收所述探活请求，并从所述探活请求中获取所述目标虚拟机的ip地址和端口号，基于所述ip地址和所述端口号发送所述探活请求至所述目标虚拟机。

可选地，所述装置还包括：

存储模块，用于将所述待探活服务的探活结果存储于预设数据库中，其中，所述预设数据库用于存储服务的探活结果。

第三方面，本申请实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现上述任一所述的服务探活方法步骤。

第四方面，本申请实施例提供了一种机器可读存储介质，所述机器可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一所述的服务探活方法步骤。

本申请实施例提供的技术方案中，获取针对待探活服务的探活请求，确定待探活服务的依赖组件，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。通过本申请实施例提供的技术方案，服务的依赖组件可以反映该服务的运行状态。基于此，当对待探活服务进行探活时，可以通过访问待探活服务的依赖组件，若对依赖组件访问成功则可以确定依赖组件是存活状态，进而确定待探活服务存活。这样，每次进行探活操作时可直接根据探活请求对依赖组件进行访问，并反馈探活结果，避免了管理员手动进行查找，节省了人力资源。

附图说明

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

图1为本申请实施例提供的服务探活方法的一种流程图；

图2为本申请实施例提供的网络结构拓扑图；

图3为本申请实施例提供的服务探活装置的一种结构示意图；

图4为本申请实施例提供的电子设备的一种结构示意图。

具体实施方式

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

为了解决对服务的探活操作依赖用户，浪费人力资源的问题，本申请实施例提供了一种服务探活方法及装置，其中，该服务探活方法包括：

获取针对待探活服务的探活请求；

根据探活请求，确定待探活服务的依赖组件，依赖组件为待探活服务运行过程中所需的组件；

向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。

本申请实施例提供的技术方案中，获取针对待探活服务的探活请求，确定待探活服务的依赖组件，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。通过本申请实施例提供的技术方案，服务的依赖组件可以反映该服务的运行状态。基于此，当对待探活服务进行探活时，可以通过访问待探活服务的依赖组件，若对依赖组件访问成功则可以确定依赖组件是存活状态，进而确定待探活服务存活。这样，每次进行探活操作时可直接根据探活请求对依赖组件进行访问，并反馈探活结果，避免了管理员手动进行查找，节省了人力资源。

下面首先对本申请实施例提供的服务探活方法进行介绍。本申请实施例提供了一种服务探活方法，可以应用于运行待探活服务的电子设备，其中，待探活服务可以是自定义设定的，待探活服务可以是电子设备所提供的服务中的一种服务。

对服务的探活操作是指检测该服务是否存活，服务处于存活状态时该服务可用，而若服务处于非存活状态则该服务是不可用的。

如图1所示，本申请实施例提供的一种服务探活方法包括如下步骤。

s101，获取针对待探活服务的探活请求。

其中，待探活服务可以是运行的程序，该程序可以是应用程序，还可以为应用程序的运行提供环境支持的程序，该程序可以为用户提供其需要的服务，比如，计算服务，存储服务等。

其中，探活请求用于请求对待探活服务进行探活操作，以查看该待探活服务是否为存活状态。探活请求中可以包括待探活服务的相关信息，例如，当该待探活服务运行在虚拟机上时，探活请求中包括该虚拟机的ip地址和端口号。

探活请求可以是请求端发送的，请求端可以是电脑、手持设备等用户终端。本申请实施例中以请求端为用户终端为例进行说明。一种实现方式中，网络结构中包括用户终端和运行待探活服务的电子设备，用户终端与运行待探活服务的电子设备直接通信连接，此时用户终端生成探活请求后将探活请求发送至电子设备，电子设备直接接收用户终端发送的探活请求。

另一种实现方式中，网络结构中可以包括用户终端、服务器和运行待探活服务的电子设备，用户终端与服务器连接，服务器与运行待探活服务的电子设备连接，用户终端将探活请求发送给服务器，服务器再将探活请求发送至运行待探活服务的电子设备。

其中，根据应用需求，服务器可以分为负载均衡服务器和代理服务器，代理服务器的数量可以有多个。此时的网络结构中，用户终端与负载均衡服务器连接，负载均衡服务器与每一代理服务器均连接，每一代理服务器均与运行待探活服务的电子设备连接。

在该网络结构中，用户终端将探活请求发送至负载均衡服务器，负载均衡服务器根据各代理服务器的负载将探活请求发送至其中一个代理服务器，接收到探活请求的代理服务器将探活请求转发至运行待探活服务的电子设备。

一种实施方式中，待探活服务的电子设备上可以运行虚拟机，待探活服务器运行在虚拟机上。具体地，电子设备上可以运行有至少一个虚拟机，每一个虚拟机上运行有至少一个服务。

待探活服务的探活请求中携带的目的ip地址和端口号，为运行该待探活服务的虚拟机的ip地址和端口号。电子设备在获取到探活请求后，可以基于探活请求携带的目的ip地址和端口号，从电子设备上运行的多个虚拟机上确定出运行该待探活服务的虚拟机，并将确定出的虚拟机作为目标虚拟机，再从该目标虚拟机运行的服务中，确定出待探活服务，针对该待探活服务进行探活操作，以检测该待探活服务是否存活。

例如，电子设备上运行有虚拟机1、虚拟机2和虚拟机3，其中，虚拟机1的ip地址为118.186.8.254，端口号为68，当获取到的探活请求的目的ip地址为118.186.8.254，端口号为68时，可以确定目标虚拟机为虚拟机1，再从虚拟机1上所运行的服务中确定待探活服务。

在上述实施方式的基础上，一种实施方式中，网络结构包括用户终端、负载均衡服务器、代理服务器和运行待探活服务的电子设备，代理服务器和电子设备上运行的每一虚拟机均通信连接。探活请求中携带的目的ip地址和端口号，为运行该待探活服务的虚拟机的ip地址和端口号。

代理服务器从负载均衡服务器接收到探活请求后，可以从探活请求中获取目的ip地址和端口号。一种实现方式中，代理服务器从探活请求中获取upstream的配置信息，该配置信息以字符串的形式显示，代理服务器以字符串解析的方式对配置信息进行解析，可以得到目的ip地址和端口号。在获得目的ip地址和端口号之后，可以向目的ip地址和端口号对应的虚拟机发送curl指令，以判断该虚拟机是否正常，若接收到虚拟机反馈的响应，则可以确定虚拟机运行正常，若未接收到虚拟机的响应，则可以认为该虚拟机运行异常。

根据该目的ip地址和端口号可以确定出运行待探活服务的目标虚拟机，将探活请求发送至运行目标虚拟机的电子设备。运行目标虚拟机的电子设备接收代理服务器发送的探活请求，并根据目的ip地址和端口号将探活请求转发至目标虚拟机进行处理。

s102，确定待探活服务的依赖组件。

其中，依赖组件为待探活服务运行过程中所需的组件。不同的服务的依赖组件可以是不相同的，也可以存在相同的依赖组件。例如，服务1的依赖组件包括db组件和redis组件，服务2的依赖组件包括db组件和mysql组件。

其中，对于每一服务，均预先记录该服务的依赖组件。当需要对待探活服务进行探活操作时，可以从待探活服务的预先记录中确定出该待探活服务的依赖组件。这样，对待探活服务的探活可以认为是对依赖组件的探活。

一种实施方式中，每一服务均设置一个api(applicationprogramminginterface，应用程序编程接口)，服务的api用于提供该服务的内部组件、内部模块、实例等信息。可以认为，每一服务的api是对外显示的接口，当需要访问服务时，需通过该服务的api。

另外，对于每一服务还可以设置有控制层，控制层可以对服务进行相应的控制，一种实现方式中，控制层可以接收发送至服务的信息，对于服务发出的信息，也通过该服务的控制层发出。

对于探活请求，电子设备接收到探活请求后，将探活请求转发至待探活服务的控制层，控制层将所接收到的探活请求转发给api，api再将探活请求发送给服务。

一种实施方式中，每一服务均设置有一个actuator模块，actuator模块用于记录服务的依赖组件标识。其中，依赖组件标识可以是依赖组件的名称、编号等。

例如，服务1设置有actuator模块1，服务2设置有actuator模块2，则actuator模块1记录服务1的依赖组件：db组件和redis组件，actuator模块2记录服务2的依赖组件：db组件和mysql组件。

当获取到针对待探活服务之后，触发该待探活服务的actuator模块，actuator模块即可以从预先记录中获取该待探活服务的依赖组件标识，并反馈所获取的依赖组件标识。获取到依赖组件标识，即可以认为确定出依赖组件标识对应的依赖组件，所确定出的依赖组件即为待探活服务的依赖组件。

一种实现方式中，待探活服务的api与actuator模块连接，api接收到探活请求后，触发actuator模块获取待探活服务的依赖组件标识。actuator模块获取到待探活服务的依赖组件标识后，将所获取的依赖组件标识发送至api。

s103，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。

若依赖组件包括多个，则向每一个依赖组件均发送访问请求。只有对每一个依赖组件均访问成功，则才能确定针对待探活服务的探活结果为存活状态；只要存在至少一个依赖组件访问失败，则可以认为针对该待探活服务的探活结果为非存活状态。

例如，待探活服务的依赖组件包括db组件、redis组件和mysql组件，则分别向db组件、redis组件和mysql组件发送访问请求，若对db组件和redis组件的访问均成功，而对mysql组件的访问失败，则可以确认针对该待探活服务的探活结果为非存活状态。若对db组件、redis组件和mysql组件的访问均成功，则可以确定针对待探活服务的探活结果为存活状态。

一种实施方式中，从预设的配置文件中，获取所确定的依赖组件标识对应的访问地址。

其中，配置文件可以是自定义设定的，配置文件中记录组件的标识与访问地址的对应关系。配置文件中所记录的组件可以是待探活服务的所有组件，还可以是待探活服务的部分组件，比如，配置文件中可以仅记录依赖组件，即可以记录待探活服务的依赖组件的标识与访问地址的对应关系。

每一服务可以对应有一个配置文件，各服务的配置文件中所记录的对应关系可以不相同。

其中，访问地址可以是域名和实例，也就是说，域名和实例可以得到一个组件的地址。一个组件可以包括多个实例，而对于服务来说，运行所需的仅是其中的一个或者部分实例，这种情况下，仅需对该一个或者部分实例进行访问即可。例如，配置文件中记录db组件标识对应的访问地址为：www.db.com/health，其中，www.db.com为域名，health为db组件的一个实例。

在获取到依赖组件的访问地址之后，依据所获取的访问地址，向依赖组件发送访问请求。

其中，若对依赖组件访问成功，依赖组件会反馈访问成功信息，而若对依赖组件访问失败，则依赖组件不会反馈。基于此，判断对依赖组件的访问是否成功的一种实施方式中，若访问成功，则确定针对待探活服务的探活结果为存活状态的步骤之前，还可以包括如下步骤。

判断是否接收到依赖组件反馈的访问成功信息，若接收到，则确定对该依赖组件访问成功；若未接收到，则确定对该依赖组件访问失败，并确定针对待探活服务的探活结果为非存活状态。

一种实现方式中，判断在预设时间段内是否接收到依赖组件反馈的访问成功信息，其中，预设时间段是以发送访问请求为时间起点的一段时长，该时长可以是自定义设定的。若在该预设时间段内接收到访问成功信息，则可以确定对依赖组件访问成功；若在该预设时间段内未接收到访问成功信息，则可以确定对该依赖组件访问失败，即使在预设时间段之后再接收到依赖组件反馈的访问成功信息，则也认为对该依赖组件访问失败。

根据是否接收到依赖组件反馈的访问成功信息，探活结果包括存活状态和非存活状态。一种实施方式中，在得到探活结果之后，可以从预设的探活结果与键值的对应关系中获取所确定出的探活结果的键值。

其中，探活结果与键值的对应关系可以是自定义设定的，每一个键值也可以是自定义设定的。例如，探活结果为存活状态对应的键值为up，探活结果为非存活状态对应的键值为down。

在获取到探活结果对应的键值之后，按照预先定义的类，将所获取的键值封装成为数据包。其中，类可以包括多个字段，每个字段包含有一个键值对<key,vlue>，这样，每一个字段存储一个探活结果对应的键值。其中，key为探活结果对应键值，vlue可以为空，还可以根据key的赋值将vlue赋值为true。

例如，探活结果为存活状态，根据上述对应关系所获取的键值为up，并将key对应的vlue赋值为true，则所得到的键值对为<up,true>，并将该键值对<up,true>封装成为数据包。

又例如，依赖组件有3个，则所获取到的探活结果有3个：探活结果1、探活结果2和探活结果3，从探活结果与键值的对应关系中可以获取探活结果1的键值1，探活结果2的键值2，以及探活结果3的键值3。其中，键值1对应的键值对为<key1,vlue1>，键值2对应的键值对为<key2,vlue2>，键值3对应的键值对为<key3,vlue3>。按照预先定义的类进行封装时，将键值对<key1,vlue1>存储于字段1中，将键值对<key2,vlue2>存储于字段2中，将键值对<key3,vlue3>存储于字段3中，封装完成后得到携带有<key1,vlue1>、<key2,vlue2>和<key3,vlue3>的数据包。

其中，按照预先定义的类进行封装时，可以封装成为restful风格的数据包，当然，还可以封装成为其他架构风格的数据包，在此不作限定。

一种实现方式中，依赖组件可以将访问成功信息反馈至api，api接收到访问成功信息之后，将该访问成功信息转发至控制层，控制层使用预先定义的类对访问成功信息进行封装，并得到restful风格的数据包。

在封装得到数据包之后，可以将该数据包反馈至发送探活请求的请求端。

根据网络结构的不同，数据包反馈的方式会不相同。一种反馈方式中，用户终端与运行待探活服务的电子设备直接连接，这种情况下，电子设备直接将数据包发送给用户终端。另一种反馈方式中，网络结构中包括用户终端、负载均衡服务器、代理服务器和运行待探活服务的电子设备，则电子设备将数据包发送给代理服务器，代理服务器再将数据包转发给负载均衡服务器，负载均衡服务器再将数据包转发给请求端，当发送探活请求的请求端为用户终端时，则将数据包转发给该用户终端。

一种实施方式中，在得到针对待探活服务的探活结果之后，可以将该探活结果存储于预设数据库中。其中，该预设数据库用于存储针对各服务的每一次探活的探活结果。

在该预设数据库中，可以按照服务对探活结果进行分类存储。对于属于同一服务的探活结果，可以按照时间先后顺序进行存储。以便于用户查看，以及数据统计和展示。

本申请实施例提供的技术方案中，获取针对待探活服务的探活请求，确定待探活服务的依赖组件，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。通过本申请实施例提供的技术方案，服务的依赖组件可以反映该服务的运行状态。基于此，当对待探活服务进行探活时，可以通过访问待探活服务的依赖组件，若对依赖组件访问成功则可以确定依赖组件是存活状态，进而确定待探活服务存活。这样，每次进行探活操作时可直接根据探活请求对依赖组件进行访问，并反馈探活结果，避免了管理员手动进行查找，节省了人力资源。

本申请实施例提供了一种网络结构拓扑图，如图2所示，用户终端与负载均衡服务器连接，负载均衡服务器还分别与代理服务器1、代理服务器2连接，代理服务器1和代理服务器2均与电子设备连接，电子设备上运行有虚拟机1和虚拟机2。以虚拟机1为例进行介绍，虚拟机1上运行有服务1、服务2和服务3，其中，对于服务1来说，依赖组件包括db组件、redis组件和mysql组件，服务1的控制层与api连接，api与actuator模块连接，且分别与db组件、redis组件、mysql组件连接。

基于上述网络结构，本申请实施例提供了一种服务探活方法，用户终端基于用户指令生成针对服务1的探活请求，并将探活请求发送至负载均衡服务器。其中，探活请求携带有运行有服务1的虚拟机1的ip地址和端口号。

负载均衡服务器接收到探活请求之后，根据代理服务器的负载情况，将探活请求发送至代理服务器1，代理服务器1将探活请求发送至运行有虚拟机1的电子设备。电子设备接收到探活请求之后，基于探活请求携带的虚拟机1的ip地址和端口号，电子设备可以确定虚拟机1，并从虚拟机1所运行的服务1、服务2和服务3中确定服务1为待探活服务。

电子设备将探活请求转发至服务1的控制层，控制层接收到探活请求后，将探活请求发送至api，api接收到探活请求后，触发actuator模块获取服务1的依赖组件名称，即db组件、redis组件和mysql组件，api获取到依赖组件名称后，从配置文件中获取各依赖组件名称对应的域名和实例，即db组件对应域名1和实例1，redis组件对应域名2和实例2，mysql组件对应域名3和实例3。依据域名1和实例1，向db组件发送访问请求；依据域名2和实例2，向redis组件发送访问请求；依据域名3和实例3，向mysql组件发送访问请求。当db组件、redis组件和mysql组件均反馈访问成功信息时，则可以确定访问成功，进而可以确定针对服务1的探活结果为存活状态。db组件、redis组件和mysql组件分别将访问成功信息反馈给api，api将所得到的访问成功信息发送至控制层，控制层使用预先定义的类对访问成功信息进行封装，得到restful风格的数据包，并将所得到的数据包发送至代理服务器1，代理服务器1再将数据包转发至负载均衡服务器，负载均衡服务器再将数据包转发给用户终端。

相应于上述服务探活方法实施例，本申请实施例还提供一种服务探活装置，如图3所示，该服务探活装置包括：

第一获取模块310，用于获取针对待探活服务的探活请求；

第一确定模块320，用于确定待探活服务的依赖组件，依赖组件为待探活服务运行过程中所需的组件；

发送模块330，用于向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。

一种实施方式中，第一确定模块320具体用于：

利用actuator模块，获取待探活服务的依赖组件标识，其中，actuator模块用于记录待探活服务的依赖组件标识；

确定依赖组件标识对应的依赖组件。

一种实施方式中，发送模块330具体用于：

从预设的配置文件中，获取所确定的依赖组件标识对应的访问地址，其中，配置文件中记录组件的标识与访问地址的对应关系；

依据所获取的访问地址，向依赖组件发送访问请求。

一种实施方式中，该服务探活装置还可以包括：

判断模块，用于判断是否接收到依赖组件反馈的访问成功信息；

第二确定模块，用于当判断模块的判断结果为是时，则确定访问成功；

第三确定模块，用于当判断模块的判断结果为否时，则确定访问失败，并确定针对待探活服务的探活结果为非存活状态。

一种实施方式中，该服务探活装置还可以包括：

第二获取模块，用于从预设的探活结果与键值的对应关系中，获取所确定出的探活结果的键值；

封装模块，用于按照预先定义的类，将所获取的键值封装成为数据包；

反馈模块，用于将数据包反馈至发送探活请求的用户终端。

一种实施方式中，电子设备上运行有至少一个虚拟机，每一个虚拟机上运行有至少一个服务；该服务探活装置还可以包括：

第四确定模块，用于基于探活请求携带的目的ip地址和端口号，确定运行待探活服务的虚拟机，作为目标虚拟机；

第五确定模块，用于从目标虚拟机运行的服务中，确定待探活服务。

一种实施方式中，所述第一获取模块310具体用于：

接收代理服务器发送的针对待探活服务的探活请求，其中，代理服务器与每一虚拟机通信连接，代理服务器从负载均衡服务器接收探活请求，并从探活请求中获取目标虚拟机的ip地址和端口号，基于ip地址和端口号发送探活请求至目标虚拟机。

一种实施方式中，该服务探活装置还可以包括：

存储模块，用于将待探活服务的探活结果存储于预设数据库中，其中，预设数据库用于存储服务的探活结果。

本申请实施例提供的技术方案中，获取针对待探活服务的探活请求，确定待探活服务的依赖组件，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。通过本申请实施例提供的技术方案，服务的依赖组件可以反映该服务的运行状态。基于此，当对待探活服务进行探活时，可以通过访问待探活服务的依赖组件，若对依赖组件访问成功则可以确定依赖组件是存活状态，进而确定待探活服务存活。这样，每次进行探活操作时可直接根据探活请求对依赖组件进行访问，并反馈探活结果，避免了管理员手动进行查找，节省了人力资源。

相应于上述服务探活方法实施例，本申请实施例还提供了一种电子设备，如图4所示，包括处理器410、通信接口420、存储器430和通信总线440，其中，处理器410，通信接口420，存储器430通过通信总线440完成相互间的通信；

存储器430，用于存放计算机程序；

处理器410，用于执行存储器430上所存放的程序时，实现如下步骤：

获取针对待探活服务的探活请求；

确定待探活服务的依赖组件，依赖组件为待探活服务运行过程中所需的组件；

向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。

本申请实施例提供的技术方案中，获取针对待探活服务的探活请求，确定待探活服务的依赖组件，向依赖组件发送访问请求，若访问成功，则确定针对待探活服务的探活结果为存活状态。通过本申请实施例提供的技术方案，服务的依赖组件可以反映该服务的运行状态。基于此，当对待探活服务进行探活时，可以通过访问待探活服务的依赖组件，若对依赖组件访问成功则可以确定依赖组件是存活状态，进而确定待探活服务存活。这样，每次进行探活操作时可直接根据探活请求对依赖组件进行访问，并反馈探活结果，避免了管理员手动进行查找，节省了人力资源。

上述电子设备提到的通信总线可以是外设部件互连标准(peripheralcomponentinterconnect，pci)总线或扩展工业标准结构(extendedindustrystandardarchitecture，eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(randomaccessmemory，ram)，也可以包括非易失性存储器(non-volatilememory，nvm)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessing，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

相应于上述服务探活方法实施例，本申请实施例还提供一种机器可读存储介质，该机器可读存储介质内存储有计算机程序，该计算机程序被处理器执行时实现上述任一所述的服务探活方法步骤。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于服务探活装置实施例而言，由于其基本相似于服务探活方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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