CN109788068B - 心跳状态信息上报方法、装置和设备及计算机存储介质 - Google Patents

Abstract

本发明公开了一种心跳状态信息上报方法、装置和设备及计算机存储介质，属于计算机技术领域，用于准确的向调度平台上报自身的心跳状态信息。该方法包括：在心跳状态信息上报时刻到达时，服务提供设备调用监测进程遍历所述服务提供设备中各模块所包括的被监测进程的运行状态信息；在所述监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，所述服务提供设备调用监测进程将指示自身正常运行的心跳状态信息上报给调度平台，以使得在所述服务调用设备向所述调度平台请求可提供服务列表时，所述调度平台将包括所述服务提供设备的所述可提供服务列表发送给所述服务调用设备。

Description

心跳状态信息上报方法、装置和设备及计算机存储介质

技术领域

本发明涉及计算机技术领域，特别涉及一种心跳状态信息上报方法、装置和设备及计算机存储介质。

背景技术

海量服务场景是指存在大量用户请求的服务场景，例如抖音短视频、微信或者QQ等均拥有着大量用户群体，从而这些用户群体产生的请求量十分巨大，在这些场景中，负载的均衡调度是十分重要的。针对于海量服务场景，通常可以采用服务器集群为用户提供服务，服务器集群中每一台服务器均可作为服务提供设备，在调度平台登记各自的网络协议(Internet Protocol，IP)地址以及端口(Port)号等信息，从而为服务调用设备提供服务。其中，一般而言调度平台负责向服务调用设备提供可提供服务设备列表查询，服务调用设备可从获取的可提供服务设备列表中选择其中一个服务提供设备，并向其发起服务调用。

由此可见，服务提供设备需要准确的向调度平台上报自身的可用状态，才能使得调度平台正确知晓哪些服务提供设备可用，进而才能正确的为服务调用设备提供可提供服务设备列表，因此，服务提供设备如何准确的向调度平台上报自身的可用状态是目前亟待解决的问题。

发明内容

本发明实施例提供一种心跳状态信息上报方法、装置和设备及计算机存储介质，用于准确的向调度平台上报自身的心跳状态信息。

一方面，提供一种心跳状态信息上报方法，应用于服务提供设备中，所述服务提供设备用于为服务调用设备提供服务，所述方法包括：

在心跳状态信息上报时刻到达时，服务提供设备调用监测进程遍历所述服务提供设备中各模块所包括的被监测进程的运行状态信息；

在所述监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，所述服务提供设备调用监测进程将指示自身正常运行的心跳状态信息上报给调度平台，以使得在所述服务调用设备向所述调度平台请求可提供服务设备列表时，所述调度平台将包括所述服务提供设备的所述可提供服务设备列表发送给所述服务调用设备。

一方面，提供一种心跳状态信息上报装置，应用于服务提供设备中，所述服务提供设备用于为服务调用设备提供服务，所述装置包括：

监测单元，用于在心跳状态信息上报时刻到达时，调用监测进程遍历所述服务提供设备中各模块所包括的被监测进程的运行状态信息；

心跳上报单元，用于在所述监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，所述服务提供设备将指示所述自身正常运行的心跳状态信息上报给调度平台，以使得在所述服务调用设备向所述调度平台请求可提供服务设备列表时，所述调度平台将包括所述服务提供设备的所述可提供服务设备列表发送给所述服务调用设备。

一方面，提供一种计算机设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上述方面所述的方法。

一方面，提供一种计算机可读存储介质，

所述计算机可读存储介质中存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如上述方面所述的方法。

本发明实施例中，服务提供设备可以调用监测进程遍历该设备中各模块所包括的被监测进程的运行状态信息，进而只有在确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，服务提供设备才会将指示自身正常运行的心跳状态信息上报给调度平台，这样，服务提供设备上报给调度平台的心跳状态信息是基于所有被监测进程正常运行的基础上的，因而避免出现某些进程故障却正常上报心跳状态信息的情况，并且，这样调度平台提供给服务调用设备的可提供服务设备列表中的所有设备均是可用的，从而降低服务调用设备服务调用不成功的可能性，进而提升用户使用体验。

附图说明

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

图1为现有技术中的服务提供设备的架构示意图；

图2为本发明实施例提供的应用场景示意图；

图3为本发明实施例提供的初始化过程的流程示意图；

图4为本发明实施例提供的被监测进程上报自身的运行状态信息的流程示意图；

图5为本发明实施例提供的共享内存的结构示意图；

图6为本发明实施例提供的监测进程上报心跳状态信息的流程示意图；

图7为本发明实施例提供的服务调用的流程示意图；

图8为本发明实施例提供的可提供服务设备列表的显示示意图；

图9为本发明实施例提供的心跳状态信息上报装置的一种结构示意图；

图10为本发明实施例提供的计算机设备的一种结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

为便于理解本发明实施例提供的技术方案，这里先对本发明实施例使用的一些关键名词进行解释：

心跳状态信息：或称心跳包等，用于一设备通知其他设备自身的运行状态，一般而言，成功上报心跳状态信息，则表明设备正常运行，而未能成功上报心跳状态信息，表明设备可能出现故障。心跳状态信息中可以携带flag标签，例如心跳状态信息的格式可以为IP地址+flag标签，flag标签即用于指示设备的健康与否，例如flag标签取值为1时，可以指示设备健康，也就是设备正常运行，以及flag标签取值为0时，可以指示设备不健康，也就是设备存在异常，或者，flag标签取值为1时指示设备不健康，flag标签取值为0时指示设备健康，本发明实施例对此不做限制。

模块：一般而言，对于一台服务提供设备，可以在该设备上部署一个主模块和多个从模块，主模块和从模块依赖运行，每个模块均可以包括多个进程，每个进程例如可以用于负责固定号段的用户请求，多个模块配合提供服务，如果其中一个进程挂了，虽然别的进程还能正确服务，但是路由到挂掉的进程的请求会全部失败，因此只有所有模块的所有进程都正常运行的情况下，服务提供设备才可以被认为是可用状态，即正常运行。例如一台设备上部署了模块1，模块2和模块3，只有三个模块同时正常时，才能对外提供正常的服务。

正常运行：本发明实施例中，对于设备而言，设备的正常运行是指该设备处于可用状态，也就是该设备中所有模块的所有进程的均正常运行。对于进程而言，进程的正常运行或称存活，也是指该进程处于可用状态，也就是该进程未发生故障，例如挂死、僵死以及死循环等问题。

共享内存：是指用于存储服务提供设备中所有模块的待监测进程的运行状态信息的存储空间，对于各个进程而言，均可以访问共享内存，并可以通过一定的规则找到自身所在模块的内存区域。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。

目前，调度平台一般可以通过服务提供设备上报的心跳包判断服务提供设备是否能够正常服务。在服务提供设备是单独的设备部署，即同一个ip只部署一个服务时，这种场景中简单的心跳上报就能满足要求。而对于服务提供设备由多个模块组成，多个模块部署在同一个IP地址上，且每个模块运行多个进程的场景，目前的心跳包上报方式通常是从其中一个模块中选择一个进程固定上报该设备的心跳包，调度平台如果间隔预设时长没有接收到服务提供设备上报的心跳包，则认为该设备不可用。但是，目前的心跳包上报方式依然存在上报了心跳包，但是实际上服务提供设备存在故障的情况。

请参见图1所示，为服务提供设备的架构示意图，该服务提供设备的IP地址为10.60.100.99，包括模块A和模块B，模块A包括N个进程，即图1中所示的模块A中的进程1～进程N，模块B包括M个进程，即图1中所示的模块A中的进程1～进程M，其中，通过模块A中的进程1上报该设备的心跳包。在实际应用中，可能会出现模块A中的进程1上报了心跳包，但是实际上模块A的进程2和模块B中其中一个进程未能正常运行，这种情况时，这台设备实际上不应该继续提供服务，但是由于模块A中的进程1上报了心跳包，调度平台依旧会认为该设备是可用的，那么这台设备就可能会被调度到，从而产生调度不成功的情况，从而使得用户的使用体验不佳。

本发明人对现有技术进行分析后发现，现有的方法中选择的上报进程上报的心跳包仅能表示该进程是可用的，而无法表示所有模块的所有进程是可用的，从而产生了上述调度平台获取的设备情况与设备的实际情况不一致的问题。鉴于此，要想使得调度平台获取的设备情况与设备的实际情况一致，那么服务提供设备上报的心跳包的准确性则极为重要。

鉴于上述的分析和考虑，本发明实施例提供一种心跳状态信息上报方法，在该方法中，服务提供设备可以调用监测进程遍历该设备中各模块所包括的被监测进程的运行状态信息，进而只有在确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，服务提供设备才会将指示自身正常运行的心跳状态信息上报给调度平台，这样，服务提供设备上报给调度平台的心跳状态信息是基于所有被监测进程正常运行的基础上的，因而避免出现某些进程故障却正常上报心跳状态信息的情况，并且，这样调度平台提供给服务调用设备的可提供服务设备列表中的所有设备均是可用的，从而降低服务调用设备服务调用不成功的可能性，进而提升用户使用体验。

此外，在该方法中，被监测进程还可以自动上报自身的运行状态信息到指定的内存区域中，这样，监测进程则可以定时到指定内存区域中查询各个进程的运行状态，从而确定是否需要上报心跳状态信息，从而保证监测进程上报的心跳状态信息的准确性。

本发明实施例中，在有进程重启或者配置文件变更等情况发生时，都会清空存储运行状态信息的内存，从而避免存储各个被监测进程的运行状态信息的存储空间之间发生冲突，导致数据出错的问题。

在介绍完本发明实施例的设计思想之后，下面对本发明实施例的技术方案能够适用的应用场景做一些简单介绍，需要说明的是，以下介绍的应用场景仅用于说明本发明实施例而非限定。在具体实施过程中，可以根据实际需要灵活地应用本发明实施例提供的技术方案。

请参见图2所示，为发明实施例中的技术方案能够适用的一种应用场景，在该场景中，可以包括服务提供设备10、调度平台20以及服务调用设备30。

服务提供设备10例如可以为服务器集群中的其中一台服务器。服务提供设备10投入使用时，可以在调度平台20进行登记，登记的信息例如可以包括服务提供设备10的IP地址以及端口号等信息。

调度平台20可以接收各服务提供设备10的心跳状态信息，以判断各服务提供设备10是否可用，并向服务调用设备30提供可提供服务设备列表，进而服务调用设备30可以选择可用的服务提供设备10，并发起远程服务调用。

服务调用设备30可以为用户终端，也可以是其他的服务器，用户终端例如可以为手机、笔记本电脑、平板电脑(PAD)或者个人计算机(Personal Computer)等设备，服务器例如可以是其他的服务提供设备10。

当然，本发明实施例提供的方法并不限用于图2所示的应用场景中，还可以用于其他可能的应用场景，本发明实施例并不进行限制。对于图2所示的应用场景的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。

本发明实施例中，为使得实现一套通用的解决方案，任何模块或者任何业务，只要按照要求并根据预先配置好的需要监控的模块ID以及进程数，就能实现对依赖的所有模块和进程的统一检测。

具体的，在每个进程进行初始化时，都需要加载配置文件，配置文件用于指示各模块的配置信息以及需要监测运行状态信息的进程，其中，各个模块的配置信息例如模块ID以及各模块之间的依赖关系。配置文件的格式可以如下：

本发明实施例中，每个模块均需要配置至少两个信息，即至少配置模块索引，即上述配置文件中字段“mod_index”对应的信息，模块索引例如可以为1～1024之间的整数，在设备投入使用之前，其中各个模块的索引均是预先分配好的，以避免模块索引发生冲突；以及，各模块需要监测的进程数，即上述配置文件中字段“proc_count”对应的信息。

在配置文件中，字段“master_moditem”表明该字段之后的模块为主(master)模块，例如，上述配置文件中"master_moditem":{"mod_index":1,"proc_count":7}即表示主模块为索引为1的模块，该模块需要监测的进程数为7个。

在实际应用中，监测进程可以选择从主模块中进行选择，由于在一个模块中，其他进程一般是由主进程通过fork函数创建得到的，因此可以选择主模块的主进程作为监测进程，监测进程除了需要监测自身所在模块包括的进程的运行状态信息，还需要监测其他从模块所包括的进程的运行状态信息。

在配置文件中，在一些情况下，可能某些模块甚至进程的运行状态无需监测，为便于监测功能的开启和关闭，本发明实施例设置了相应的功能开关。例如在上述配置文件中，字段“enable_slaver_mod_check”即用于控制监测功能的开启，例如当字段“enable_slaver_mod_check”的值为“1”时，则开启监测功能，即之后的模块的进程均需要监测运行状态，当字段“enable_slaver_mod_check”的值为“0”时，则禁用监测功能，即之后的模块的进程均无需监测运行状态，同理也可以设置进程的监测功能的开启和关闭。当然，也可以设置当字段“enable_slaver_mod_check”的值为“0”时开启监测功能，以及当字段“enable_slaver_mod_check”的值为“1”时禁用监测功能，本发明实施例对此不做限制。

对于被关闭运行状态信息监测功能的模块，则应将模块的所有进程从被监测进程列表中删除，以及，对于被关闭运行状态信息监测功能的进程，则应将该进程从被监测进程列表中删除。

在配置文件中，除了主模块的相关信息之外，还需配置该主模块依赖的从(slaver)模块的信息。例如，在上述配置文件中，字段“rpt_slaver_moditem”用于指示从模块列表，即字段“rpt_slaver_moditem”之后的内容为从模块列表。对于每个从模块，同样也需要配置字段“mod_index”和需要监测的进程数“proc_count”，对于此可参考主模块对应部分的内容，在此不再赘述。

在上述配置文件中，字段“rpt_modulecfg_list”用于表示配置文件为一个更大访问的配置，换句话说，一个配置文件可以包含多组主从模块的配置信息，这样，通过一个配置文件，既可以掌控所有主从模块的依赖关系。例如，上述配置文件中，包括了两组主从模块的配置信息，第一组主从模块的主模块索引为1，主模块需要监测的进程数为7个，主模块依赖的从模块的索引为2和3，模块2和模块3需要监测的进程数分别为5个和2个，第一组主从模块的主模块索引为4，主模块需要监测的进程数为4个，主模块依赖的从模块的索引为5和6，模块5和模块6需要监测的进程数分别为6个和8个。

当然，在配置文件中，还可以包括其他可能的配置信息，本发明实施例对此不做限制。

在服务提供设备初次使用时，服务提供设备需要进行初始化，由于对于每个模块或者进程而言，初始化的过程均是相同的，因此下面以主模块的进程1为例，对初始化的过程进行介绍，其他的进程可参考下述描述，不再进行赘述。请参见图3，为初始化过程的流程示意图。

步骤301：主模块进程1从配置中心获取配置文件。

本发明实施例中，配置中心用于存放配置文件并提供配置文件读取服务。在具体应用中，配置中心可以统一设置于单独的一个存储设备中，当有服务提供设备需要进行初始化时，服务提供设备则可以调用相应进程从存储设备中读取配置文件，该存储设备例如可以是固定设置的设备，还可以是可移动携带的存储介质，例如U盘或者移动硬盘等；或者，配置中心还可以是设置于各个服务提供设备中，在服务提供设备需要进行初始化时，服务提供设备则可以调用相应进程从自身的指定存储路径读取配置文件。

具体的，以主模块进程1为例，在获取配置文件时，主模块进程1可以调用用于获取配置文件的应用程序编程接口(Application Programming Interface，API)，以从指定存储路径中获取配置文件。例如，用于获取配置文件的API可以如下：

int init_module(const std::string&config_path)

上述API的参数为配置文件的存储路径，从而调用上述API后，则可以从存储路径中获取配置文件。

步骤302：主模块进程1解析配置文件，以获取主从模块配置信息。

本发明实施例中，主模块进程1获取配置文件之后，则可以对配置文件进行解析，从而获取主从模块配置信息。

具体的，由于配置文件中可能包括多个主从模块的配置信息，主模块进程1可以仅获取自身所在设备的主从模块的配置信息。

步骤303：主模块进程1加载共享内存。

本发明实施例中，在进行初始化时，对于监测进程而言，需要知晓去哪里检查各个被监测进程的运行状态信息，对于被监测进程而言，需要知晓需要将自身的运行状态信息上报至何处，因此，每个进程都需要加载共享内存，共享内存即用于存储运行状态信息的存储空间。

步骤303：主模块进程1清空共享内存。

本发明实施例中，在初次使用时，共享内存中还存在其他的数据，为避免其他数据的干扰，在加载共享内存后，可以将共享内存清空。当然，在实际应用中，可以选择其中一个或者多个进程进行共享内存的清空，例如可以选择主模块进程1清空共享内存，而其他的进程则不进行共享内存的清空，或者每个模块选择一个进程来清空自身所在模块对应的内存区域。

本发明实施例中，在服务提供设备的具体使用过程中，可能会对服务提供设备的模块和进程进行调整，进而配置文件会被更新，例如可以将某个模块的进程数从3个调整到5个。因此，服务提供设备中的各个进程需要定时检测配置文件是否更新，例如可以每间隔2分钟(min)检查一次，当配置文件发生更新时，则所有进程需要重新加载更新后的配置文件。具体的，可以调用如下API对配置文件进行更新：

int update_cfg(const std::string&config_path)

由于配置文件更新，模块索引以及需要监测的进程数都有可能会发生变化，因此为了避免共享内存中以往存储的数据的干扰，在加载更新后的配置文件之后，还可以将共享内存清空。同样的，可以选择其中一个或者多个进程进行共享内存的清空，例如可以选择主模块进程1清空共享内存，而其他的进程则不进行共享内存的清空，或者每个模块选择一个进程来清空自身所在模块对应的内存区域。

同样的，在有进程发生重启时，该进程可能会将不正常的数据填入共享内存中，为了避免脏数据对后续流程的干扰，可以在进程重启时，将共享内存清空。

本发明实施例中，在服务提供设备的具体使用过程中，被监测进程可以主动将自身的运行状态信息上报至共享内存中，以便监测进程基于共享内存的存储内存确定是否上报心跳状态信息。由于每个被监测进程上报过程类似，因此下面以其中一个被监测进程为例对该过程进行描述。请参见图4，为被监测进程上报自身的运行状态信息的流程示意图。

步骤401：服务提供设备调用被监测进程确定运行状态信息的上报时刻是否到达。

本发明实施例中，运行状态信息用于指示被监测进程的运行状态。其中，运行状态信息的格式例如可以为进程ID+flag标签，flag标签即用于指示被监测进程的运行状态，例如flag标签取值为1时，可以指示被监测进程的运行正常，flag标签取值为0时，可以指示被监测进程的运行异常或者被监测进程未上报运行状态信息；或者，可以在flag标签取值为0时，指示被监测进程的运行正常，flag标签取值为1时，可以指示被监测进程的运行异常或者被监测进程未上报运行状态信息，本发明实施例中对此不做限制。

一般而言，被监测进程能够上报运行状态信息，则表明被监测进程是存活的，即正常运行的，而若是被监测进程未能及时上报运行状态信息，则表明被监测进程未能正常运行，可能出现挂死或者僵死等异常情况。但是也可能存在一些情况下，被监测进程可能部分出现异常情况，但仍能够上报运行状态信息，那么此时上报的运行状态信息则是指示该进程未能正常运行的，例如在flag标签取值为0表示被监测进程的运行异常时，则该进程上报的flag标签取值为0。

本发明实施例中，被监测进程上报运行状态信息可以是周期性进行的，例如可以每间隔1秒(s)执行一次，当然，间隔时长可以根据实际情况具体进行设定，本发明实施例对此不做限制。在实际应用时，被监测进程在上一次上报运行状态信息完成后，则可以开始计时，当计时时长大于或者等于间隔时长时，则确定已到达上报时刻。

当步骤401的确定结果为否，则继续返回步骤401，直至到达上报时刻。

步骤402：在步骤401的确定结果为是时，服务提供设备调用被监测进程定位自身所在模块对应的内存区域。

本发明实施例中，为便于监测进程获取被监测进程的运行状态，预留了共享内存，用于存储被监测进程的运行状态信息，为便于各个模块的管理，可以将为每个模块分配对应的内存区域。

如图5所示，为共享内存的结构示意图。其中，服务提供设备包括N个模块，每个模块对应着一个内存区域，每个内存区域包括多个格子，每个格子的字节长度相同，用于存储一个进程的运行状态信息。例如，可以为每个模块分配1024个字节长度，那么每个模块对应的内存区域则为每个模块的起始位置与(起始位置+模块索引*1024)之间的存储位置，每个格子字节长度为5个字节，前4个字节存放进程ID，最后1个字节用于存放flag标签。

在实际应用中，一般而言，为每个模块分配的内存区域的存储空间长度是固定的，因此被监测进程仅需要知道自身所在的起始位置偏移即可。其中，被监测进程可以根据自身所在模块的索引调用起始位置获取接口，以获取被监测进程自身所在模块在内存中的起始位置。

具体的，被监测进程在上报自身的运行状态信息时，可以调用如下API：

bool report_current_load(uint32_t mod_index)

在调用上述API时，将该被监测进程所在模块的索引作为参数传入，则可以计算出该模块在共享内存中的起始位置偏移，进而根据起始位置和为各模块设定的存储空间长度，定位到被监测进程所在模块对应的内存区域。

步骤403：服务提供设备调用被监测进程遍历自身所在模块对应的内存区域，以确定内存区域中是否已存储自身的进程标识ID。

本发明实施例中，被监测进程定位到自身所在模块对应的内存区域之后，则可以对该内存区域中的每一个格子进行遍历，以确定内存区域中是否已存储自身的进程标识ID。

例如，一个模块包括N个进程，则在所有进程均正常上报运行状态信息的情况下，应该有N个格子存储有运行状态信息，那么被监测进程遍历时，则可以从这N个格子中找到存有自身进程ID的格子。但在实际运行中，可能并不是所有的进程都会正常上报，因此被监测进程可以按照从1到N的顺序依次遍历内存区域，以确定内存区域中是否已存储自身的进程标识ID。

具体的，当被监测进程在进行遍历时，当遍历到的格子里已经存储有运行状态信息，则可以比较其中包括的进程ID是否与本进程的ID相同，若是相同，则确定内存区域中已存储自身的进程标识ID，否则继续查看下一个格子，直至最终遍历至存储内容为空的格子。

步骤404：若步骤403的确定结果为是，则服务提供设备调用被监测进程，更新被监测进程的进程ID所在的存储位置存储的运行状态信息。

本发明实施例中，如果已有格子里已经存在自身的进程ID了，则说明之前被监测进程已成功上报过运行状态信息，那么只需要更新该格子中存储的运行状态信息，也就是更新flag标签。

具体的，对于一个进程而言，在遍历时，如果已有格子里进程ID已经有了，就可以直接更新flag，而不会占用空白的存储位置，从而避免了同一个进程占用多个格子的情况。

步骤405：若步骤403的确定结果为否，则服务提供设备调用被监测进程，将被监测进程的运行状态信息，写入内存区域中存储内容为空的存储位置。

本发明实施例中，如果未有格子里存储有自身的进程ID，则说明之前被监测进程未成功上报过运行状态信息，那么可以将运行状态信息写入内存区域中存储内容为空的存储位置。

具体的，对于不同的进程而言，由于多个进程可能同时运行，并且同时发现内存区域中未存储自身进程ID，那么则可能出现多个进程将自己的运行状态信息写入相同空白格子的情况，先写的会被后写的覆盖，从而在监测进程在遍历时，则不会获取到先写入的进程的运行状态信息，从无判定当前设备不可用。但是，这种误判仅仅是短暂的，因为写入被覆盖的进程在下一次遍历时，则无法找到存储有自身进程ID的格子，则会将自身的运行状态信息存储至空白格子中，因此短暂的误判之后，每个进程都会找到自己的格子，此时监测进程在遍历时则会检查到所有进程的运行状态信息，从而判定服务提供设备可用。

上述误判的情况通常发生在共享内存被清空时，多个进程都会去抢占格子，从而出现格子冲突的情况，但是出现上述情况时，服务提供设备仅会短暂的被调度平台判为不可用，短时间内不调度到，在各个进程均对应着自身的格子时，这种误判则相应的会被恢复，调度平台可以重新将该设备判定为可用设备。

本发明实施例中，当步骤404和步骤405完成后，本次运行状态信息的上报就已完成，则可以重新开始计时，等待下一次运行状态信息的上报时刻，也就再次返回值步骤401进行执行。

本发明实施例中，在服务提供设备的具体使用过程中，监测进程可以基于共享内存的存储内存确定是否上报心跳状态信息。请参见图6，为监测进程上报心跳状态信息的流程示意图。

步骤601：服务提供设备调用监测进程确定心跳状态信息的上报时刻是否到达。

本发明实施例中，心跳状态信息用于指示服务提供设备是否可用。其中，运行状态信息的格式例如可以为IP地址+flag标签，flag标签即用于指示服务提供设备的健康与否，例如flag标签取值为1时，可以指示设备健康，也就是设备可用，以及flag标签取值为0时，可以指示设备不健康，也就是设备不可用，或者，flag标签取值为1时指示设备不健康，flag标签取值为0时指示设备健康，本发明实施例对此不做限制。

本发明实施例中，监测进程上报心跳状态信息也可以是周期性进行的，例如可以每间隔3s执行一次，当然，间隔时长可以根据实际情况具体进行设定，本发明实施例对此不做限制。在实际应用时，被监测进程在上一次上报运行状态信息完成后，则可以开始计时，当计时时长大于或者等于间隔时长时，则确定已到达上报时刻。

为保证被监测进程能够有足够的时长将自身的运行状态信息写入共享内存中，可以设置监测进程上报心跳状态信息的间隔时长大于被监测进程上报运行状态信息的间隔时长。

当步骤601的确定结果为否，则继续返回步骤601，直至到达上报时刻。

步骤602：在步骤601的确定结果为是时，服务提供设备调用监测进程遍历各模块所包括的被监测进程的运行状态信息。

本发明实施例中，监测进程可以从配置文件中获取到需要监测的模块以及各模块需要监测的进程数列表。对于每个模块，监测进程同样可以找到该模块对应的内存区域，进而对该内存区域中的每个格子进行遍历，检查每个格子中是否存储有运行状态信息。由于，监测进程获取各个模块对应内存区域的方式和被监测进程可以相同，因此对于监测进程获取各个模块对应内存区域可以参考被监测进程部分的描述，在此不再过多赘述。

监测进程在心跳状态信息的上报时刻到达时，可以调用如下API，从而实现遍历以及心跳状态信息是否上报的确认：

bool check_and_resert()

具体的，监测进程在遍历共享内存时，可能出现以下三种情况，下面以flag标签取值为1时指示进程运行正常为例：

(1)如果格子中存储内容为空，则表明可能有进程未上报，继续检查下一个格子，直至遍历完毕；

(2)若是格子中存储内容不为空，但是flag标签为0，则表明可能进程未上报，或者进程已上报，但是该进程存在异常，记录该进程ID对应的运行状态并继续检查下一个格子，直至遍历完毕；

(3)若是格子中存储内容不为空，且flag标签为1，则表明进程已上报，且指示该进程运行正常，监测进程记录该进程的运行状态，并将flag标签重置为未上报状态，即将flag标签重置为0或者清空flag标签，完成后继续检查下一个格子，直至遍历完毕。

步骤603：服务提供设备调用监测进程确定是否上报心跳状态信息。

本发明实施例中，监测进程遍历完成后，则可以根据遍历结果知晓当前各个模块的进程的死活情况，进而根据死活情况，确定是否上报心跳状态信息。具体而言，在所有被监测进程正常运行，即均已上报运行状态信息且指示进程正常运行时，上报心跳状态信息，而有被监测进程异常运行，即有被监测进程未上报或者上报的运行状态信息指示进程存在异常时，不上报心跳状态信息。

当然，在实际应用中，监测进程也可以无需确定是否上报，而是根据死活情况生成对应的心跳状态信息，例如在所有被监测进程正常运行时，上报指示服务提供设备可用的心跳状态信息，而有被监测进程异常运行时，上报指示服务提供设备不可用的心跳状态信息。其中，本发明实施例中后续主要以上述的第一种上报方式，即根据死活情况，确定是否上报心跳状态信息为例。

步骤604：在步骤603的确认结果为是时，服务提供设备调用监测进程将心跳状态信息上报给调度平台。

本发明实施例中，监测进程成功上报心跳状态信息给调度平台则表明服务提供设备正常运行，即可用的，否则表明服务提供设备不可用。

在步骤603的确认结果为否时，则监测进程不上报心跳状态信息，并继续等待下一次监测过程。在服务提供设备存在异常时，一般维护人员会对各个模块或者进程进行修复，以保证服务的正常提供，在经过修复后，则服务提供设备则可以重新成为可用设备，监测进程则会重新上报该设备的心跳状态信息。

本发明实施例中，当步骤604完成后，本次心跳状态信息的上报就已完成，或者确定不上报心跳状态信息时，则可以重新开始计时，等待下一次心跳状态信息的上报时刻到达，也就再次返回至步骤601执行。

本发明实施例中，请参见图7，为服务调用的流程示意图。

步骤701：服务提供设备上报心跳状态信息给调度平台。

步骤702：调度平台将成功上报心跳状态信息的服务提供设备加入至可提供服务设备列表中，并将超时未上报的服务提供设备从可提供服务设备列表中删除。

具体的，对于成功上报心跳状态信息的服务提供设备，且可提供服务设备列表中未存在的服务提供设备，调度平台可以将其新增至可提供服务设备列表中，而对于可提供服务设备列表中已存在的服务提供设备，由于超时未上报心跳状态信息，则其不可用，应将其从可提供服务设备列表中删除。

步骤703：服务调用设备向调度平台发送可提供服务设备列表获取请求。

可提供服务设备列表获取请求用于请求从调度平台获取可提供服务设备列表。

步骤704：调度平台向服务调用设备发送可提供服务设备列表。

请参见图8，为可提供服务设备列表的显示示意图，其中，可提供服务设备列表可包括提供设备的IP地址和端口号等信息。

步骤705：服务调用设备从可提供服务设备列表中选择其中一个服务提供设备。

步骤706：服务调用设备向选择的服务提供设备发起服务调用请求。

步骤707：服务提供设备向服务调用设备返回服务应答。

综上所述，本发明实施例中，服务提供设备可以调用监测进程遍历该设备中各模块所包括的被监测进程的运行状态信息，进而只有在确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，服务提供设备才会将指示自身正常运行的心跳状态信息上报给调度平台，这样，服务提供设备上报给调度平台的心跳状态信息是基于所有被监测进程正常运行的基础上的，因而避免出现某些进程故障却正常上报心跳状态信息的情况，并且，这样调度平台提供给服务调用设备的可提供服务设备列表中的所有设备均是可用的，从而降低服务调用设备调用服务不成功的可能性，进而提升用户使用体验。

请参见图9，基于同一发明构思，本发明实施例还提供了一种心跳状态信息上报装置90，应用于服务提供设备中，服务提供设备用于为服务调用设备提供服务，装置包括：

监测单元901，用于在心跳状态信息上报时刻到达时，调用监测进程遍历服务提供设备中各模块所包括的被监测进程的运行状态信息；

心跳上报单元902，用于在监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，服务提供设备将指示自身正常运行的心跳状态信息上报给调度平台，以使得在服务调用设备向调度平台请求可提供服务列表时，调度平台将包括服务提供设备的可提供服务列表发送给服务调用设备。

可选的，该装置还包括运行状态上报单元903，用于：

在运行状态信息上报时刻到达时，调用被监测进程遍历被监测进程所在模块对应的内存区域；

若被监测进程确认内存区域中已存储了自身的进程标识ID，则调用被监测进程更新被监测进程的进程ID所在的存储位置中的运行状态信息；或者，

若被监测进程确认内存区域中未存储自身的进程标识ID，则调用被监测进程将被监测进程的运行状态信息，写入内存区域中存储内容为空的存储位置。

可选的，运行状态上报单元903，还用于：

被监测进程根据自身所在模块的索引调用起始位置获取接口，获取被监测进程根据自身所在模块在内存中的起始位置；

根据起始位置，以及为各模块设定的存储空间长度，获取被监测进程所在模块对应的内存区域。

可选的，监测单元901具体用于：

监测进程遍历至存储内容不为空的存储位置，且确认该存储位置上存储的运行状态信息指示进程运行状态为正常时，确认该存储位置上存储的进程ID对应的进程运行状态为正常；并，

监测进程将该存储位置上存储的运行状态信息重置为未上报状态。

可选的，该装置还包括配置更新单元904和内存清理单元905；

更新单元904，用于调用所有进程确认配置文件是否更新，配置文件中用于指示各模块的配置信息，以及需要监测运行状态信息的进程；以及在确认配置文件更新时，服务提供设备调用所有进程加载更新后的配置文件；

内存清理单元905，用于调用部分或者全部进程清空存储运行状态信息的内存区域。

可选的，内存清理单元905还用于：

确认有至少一个进程重启时，调用部分或者全部进程清空存储运行状态信息的内存区域。

可选的，监测单元901还用于：

在确认有模块关闭监测运行状态功能时，将该模块包括的所有被监测进程从被监测进程列表中删除；或者，

在确认有被监测进程关闭监测运行状态功能时，将被监测进程从被监测进程列表中删除。

该装置可以用于执行图3～图8所示的实施例中所示的方法，因此，对于该装置的各功能模块所能够实现的功能等可参考图3～图8所示的实施例的描述，不多赘述。其中，运行状态上报单元903、配置更新单元904和内存清理单元905虽然在图9中一并示出，但需要知道的是，运行状态上报单元903、配置更新单元904和内存清理单元905并不是必选的功能单元，因此在图9中以虚线示出。

请参见图10，基于同一技术构思，本发明实施例还提供了一种计算机设备100，可以包括存储器1001和处理器1002。

所述存储器1001，用于存储处理器1002执行的计算机程序。存储器1001可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作***、至少一个功能所需的应用程序等；存储数据区可存储根据计算机设备的使用所创建的数据等。处理器1002，可以是一个中央处理单元(central processing unit，CPU)，或者为数字处理单元等等。本发明实施例中不限定上述存储器1001和处理器1002之间的具体连接介质。本发明实施例在图10中以存储器1001和处理器1002之间通过总线1003连接，总线1003在图10中以粗线表示，其它部件之间的连接方式，仅是进行示意性说明，并不引以为限。所述总线1003可以分为地址总线、数据总线、控制总线等。为便于表示，图10中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器1001可以是易失性存储器(volatile memory)，例如随机存取存储器(random-access memory，RAM)；存储器1001也可以是非易失性存储器(non-volatilememory)，例如只读存储器，快闪存储器(flash memory)，硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)、或者存储器1001是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器1001可以是上述存储器的组合。

处理器1002，用于调用所述存储器1001中存储的计算机程序时执行如图3～图8中所示的实施例中设备所执行的方法。

在一些可能的实施方式中，本发明提供的方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本发明各种示例性实施方式的方法中的步骤，例如，所述计算机设备可以执行如图3～图8中所示的实施例中设备所执行的方法。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本发明的实施方式的方法的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

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

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种心跳状态信息上报方法，其特征在于，应用于服务提供设备中，所述服务提供设备用于为服务调用设备提供服务，所述方法包括：

在心跳状态信息上报时刻到达时，服务提供设备调用监测进程遍历所述服务提供设备中所有模块所包括的被监测进程的运行状态信息，所述服务提供设备调用被监测进程遍历所述被监测进程所在模块对应的内存区域，若所述被监测进程确认所述内存区域中已存储了自身的进程标识ID，则所述服务提供设备调用所述被监测进程，更新所述被监测进程的进程ID所在的存储位置中的运行状态信息；其中，所述所有模块包括主模块和多个从模块，所述主模块和所述多个从模块依赖运行；

在所述监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，所述服务提供设备调用监测进程将指示自身正常运行的心跳状态信息上报给调度平台，以使得在所述服务调用设备向所述调度平台请求可提供服务设备列表时，所述调度平台将包括所述服务提供设备的所述可提供服务设备列表发送给所述服务调用设备。

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

若所述被监测进程确认所述内存区域中未存储自身的进程标识ID，则所述服务提供设备调用所述被监测进程，将所述被监测进程的运行状态信息，写入所述内存区域中存储内容为空的存储位置。

3.如权利要求1所述的方法，其特征在于，在所述服务提供设备调用被监测进程遍历所述被监测进程所在模块对应的内存区域之前，所述方法还包括：

所述被监测进程根据自身所在模块的索引调用起始位置获取接口，获取所述被监测进程根据自身所在模块在内存中的起始位置；

根据所述起始位置，以及为各模块设定的存储空间长度，获取所述被监测进程所在模块对应的内存区域。

4.如权利要求1所述的方法，其特征在于，所述服务提供设备调用监测进程遍历所述服务提供设备中所有模块所包括的被监测进程的运行状态信息，包括：

所述监测进程遍历至存储内容不为空的存储位置，且确认该存储位置上存储的运行状态信息指示进程运行状态为正常时，确认该存储位置上存储的进程ID对应的进程运行正常；并，

所述监测进程将该存储位置上存储的运行状态信息重置为未上报状态。

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

所述服务提供设备调用所有进程确认配置文件是否更新，所述配置文件用于指示各模块的配置信息，以及需监测运行状态信息的进程；

在确认配置文件更新时，所述服务提供设备调用所有进程加载更新后的配置文件；并，

所述服务提供设备调用部分或者全部进程清空存储运行状态信息的内存区域。

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

所述服务提供设备确认有至少一个进程重启时，调用部分或者全部进程清空存储运行状态信息的内存区域。

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

所述服务提供设备在确认有模块关闭监测运行状态功能时，将该模块包括的所有被监测进程从被监测进程列表中删除；或者，

所述服务提供设备在确认有被监测进程关闭监测运行状态功能时，将所述被监测进程从被监测进程列表中删除。

8.一种心跳状态信息上报装置，其特征在于，应用于服务提供设备中，所述服务提供设备用于为服务调用设备提供服务，所述装置包括：

监测单元，用于在心跳状态信息上报时刻到达时，调用监测进程遍历所述服务提供设备中所有模块所包括的被监测进程的运行状态信息，调用被监测进程遍历所述被监测进程所在模块对应的内存区域，若所述被监测进程确认所述内存区域中已存储了自身的进程标识ID，则调用所述被监测进程，更新所述被监测进程的进程ID所在的存储位置中的运行状态信息；其中，所述所有模块包括主模块和多个从模块，主模块和多个从模块依赖运行；

心跳上报单元，用于在所述监测进程根据遍历结果确定所有被监测进程均成功上报运行状态信息时，且运行状态信息均指示进程运行状态为正常时，所述服务提供设备将指示所述自身正常运行的心跳状态信息上报给调度平台，以使得在所述服务调用设备向所述调度平台请求可提供服务设备列表时，所述调度平台将包括所述服务提供设备的所述可提供服务设备列表发送给所述服务调用设备。

9.一种计算机设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1-7中任一权利要求所述的方法。

10.一种计算机可读存储介质，其特征在于，

所述计算机可读存储介质中存储有计算机指令，当所述计算机指令在计算机上运行时，使得计算机执行如权利要求1-7中任一权利要求所述的方法。

Images