CN110659184B - 健康状态检查方法、装置及*** - Google Patents

Abstract

本申请公开了健康状态检查方法、装置及***，涉及计算机领域，尤其涉及网络领域。具体实现方案为：获取服务实例的异常状态的信息；根据所述异常状态的信息的来源，判断是否需要进一步确定所述异常状态；在需要进一步确认所述异常状态的情况下，拉取所述服务实例的健康状态。本申请涉及云计算领域，能够利用较小的***资源消耗，提高健康状态检查的准确率。

Description

健康状态检查方法、装置及***

技术领域

本申请涉及计算机领域，尤其涉及网络领域。

背景技术

应用程序包含的多个微服务通信需要多个服务实例来支撑。微服务通信中，服务实例的异常会导致通信状态的异常。因此需要对微服务的服务示例的健康状态进行检查。

现有技术中采用“推”或“拉”的方式对服务实例的健康状态进行检查，然而采用“推”的方式检查健康状态，可能会将服务实例与注册中心的长连接断开的情况识别为服务实例健康状态异常。采用“拉”的方式进行健康状态检查，可能会导致大部分检测操作都是在服务实例健康状态正常的状态下执行的，造成资源的浪费。

发明内容

为了解决现有技术中的至少一个问题，本申请提出一种健康状态检查方法、装置及***。

第一方面，本申请提供一种健康状态检查方法，包括：

获取服务实例的异常状态的信息；

根据异常状态的信息的来源，判断是否需要进一步确定异常状态；

在需要进一步确认异常状态的情况下，拉取服务实例的健康状态。

在本申请实施例中，获取服务实例的异常状态的信息，可以归属为通过“推”的方式检测服务实例的健康状态。在一般状态下，本申请采用推的方式进行健康检查，即不对服务实例的健康状态进行拉取式检查，在推送式的状态下收到服务实例的异常状态的信息时，进一步对异常状态的信息进行确定。从而既能够保证服务实例的健康检查结果的准确性，又能够避免过多的无用拉取检查，节省资源。

在一种实施方式中，根据异常状态的信息的来源，判断是否需要进一步确认异常状态，包括：

在异常状态的信息为根据服务实例上报的异常报告获得的情况下，判定不需要进一步确认异常状态；

在异常状态的信息为根据服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认异常状态；

在异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认异常状态。

在本申请实施例中，若异常状态的信息为根据服务实例上报的异常状态获得的，考虑到服务实例不会在正常的状态下上报自己异常状态，因此在服务实例自己上报异常时认定服务实例出现异常，在长连接出现问题或者请求转发失败的情况下，进一步确定实例的健康状态是是否异常，从而无需一直拉取健康状态，节省***资源。

在一种实施方式中，拉取服务实例的健康状态，包括：

向解耦模块发送服务实例健康状态拉取信息；

接收解耦模块获得的述服务实例的健康状态，服务实例的健康状态是解耦模块响应于服务实例健康状态拉取信息获得的。

在本申请实施例中，由于拉取健康状态的操作需要轮询进行，消耗较多资源，因此通过解耦模块对拉取信息进行解耦，利用解耦后的信息向服务实例获取其健康状态，能够合理分配资源消耗，使得消耗资源较多的任务分配到能够承受这种消耗的设备上。

第二方面，本申请实施例提供一种健康状态检查方法，包括：

接收网关发送的服务实例健康状态拉取信息；

调用服务实例的健康端点；

利用健康端点获得服务实例的健康状态。

在本申请实施例中，接收到服务实例健康状态拉取信息然后拉取服务实例的健康状态，从而在需要健康状态时，能够获取健康状态。无需一直拉取健康状态，节约***资源。

在一种实施方式中，利用健康端点获得服务实例的健康状态之后，还包括：

在健康状态为正常的情况下，发送健康状态；

在健康状态为异常的情况下，返回调用服务实例的健康端点的步骤。

在本申请实施例中，在服务实例健康状态异常的情况下，继续对服务实例的健康状态进行拉取，直到拉取的健康状态为正常为止。从而无需网关拉取服务实例的健康状态，节省网关的资源消耗，从而不影响网关执行转发请求等其它操作。

第三方面，本申请提供一种健康状态检查装置，包括：

异常状态的信息获取模块：用于获取服务实例的异常状态的信息；

判断模块：用于根据异常状态的信息的来源，判断是否需要进一步确定异常状态；

拉取模块：用于在需要进一步确认异常状态的情况下，拉取服务实例的健康状态。

在一种实施方式中，判断模块包括：

第一判定单元：用于在异常状态的信息为根据服务实例上报的异常报告获得的情况下，判定不需要进一步确认异常状态；

第二判定单元：用于在异常状态的信息为根据服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认异常状态；

第三判定单元：用于在异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认异常状态。

在一种实施方式中，拉取模块包括：

拉取信息发送单元：用于向解耦模块发送服务实例健康状态拉取信息；

健康状态接收单元：用于接收解耦模块获得的述服务实例的健康状态，服务实例的健康状态是解耦模块响应于服务实例健康状态拉取信息获得的。

第四方面，本申请提供一种健康状态检查装置，包括：

健康状态拉取信息接收模块：用于接收网关发送的服务实例健康状态拉取信息；

健康端点调用模块：用于调用服务实例的健康端点；

健康状态获得模块：用于利用健康端点获得服务实例的健康状态。

在一种实施方式中，装置还包括：

健康状态发送模块：用于在健康状态为正常的情况下，发送健康状态；

健康状态处理模块：用于在健康状态为异常的情况下，触发健康状态发送模块。

第五方面，本申请实施例提供一种健康检查***，包括本申请任意一项实施例所提供的健康检查装置。

第六方面，本申请实施例提供一种电子设备，包括：

至少一个处理器；以及

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

存储器存储有可被至少一个处理器执行的指令，指令被至少一个处理器执行，以使至少一个处理器能够执行本申请任意一项实施例所提供的方法。

第七方面，本申请实施例提供一种存储有计算机指令的非瞬时计算机可读存储介质，计算机指令用于使计算机执行本申请任意一项实施例所提供的方法。

上述申请中的一个实施例具有如下优点或有益效果：能够在提高健康状态检查的准确性的同时，降低资源消耗。因为采用推拉结合的方式进行健康状态检查的技术手段，所以克服了健康状态检查不准确或资源消耗大的技术问题，进而达到提高健康检查结果的准确性和降低资源消耗的技术效果。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请第一实施例的健康状态检查方法流程示意图；

图2是根据本申请第二实施例的健康状态检查方流程示意图；

图3是根据本申请第三实施例的健康状态检查方流程示意图；

图4是根据本申请第四实施例的健康状态检查方法实现构架示意图；

图5是根据本申请第五实施例的健康状态检查装置结构示意图；

图6是根据本申请第六实施例的健康状态检查装置结构示意图；

图7是根据本申请第七实施例的健康状态检查装置结构示意图；

图8是用来实现本申请实施例的健康状态检查方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本申请实施例首先提供一种健康状态检查方法，如图1所示，包括：

步骤S11：获取服务实例的异常状态的信息。

步骤S12：根据异常状态的信息的来源，判断是否需要进一步确定异常状态。

步骤S13；在需要进一步确认异常状态的情况下，拉取服务实例的健康状态。

在本申请实施例中，服务实例的异常状态的信息，可以根据服务实例或者其它消息发送方因为感知到服务实例的健康状态可能存在异常，而发送的报告或信息获得；也可以根据一定的事件，例如消息转发操作失败而获得。

在本申请实施例中，异常状态的信息的来源，可以包括异常状态的信息的原因。本申请实施例根据异常状态的信息产生的原因，可以将异常状态的信息划分为需要进一步确定和不需要进一步确定的情况。从而仅在需要进一步确定时对服务实例的健康状态进行拉取。

拉取获得的服务实例的健康状态，可以认定为确定前述异常状态信息的直接依据。即，拉取获得的服务实例的健康状态，包括正常和异常两种情况，如果拉取获得的服务实例的健康状态为正常，则确定在此之前获得的异常状态的信息与服务实例的实际状态不符合。如果拉取获得的服务实例的健康状态为异常，则确定在此之前获得的异常状态的信息与服务实例的实际状态符合。

在本申请实施例中，服务实例的健康状态可包括正常或异常。若服务实例的健康状态为正常，则表明服务实例能够正常接收并处理网关转发的请求。若服务实例的健康状态为异常，则表明服务实例不能够正常接收或处理网关转发的请求。

在微服务构架下，对后端的服务实例健康状态的快速、准确、高效感知很重要。如果对服务实例的健康状态的感知不够迅速，会造成服务实例的健康状态异常后没有被及时从网关摘除，造成在异常未被感知这段时间内网关转发给该实例的流量出现请求异常。如果对服务实例的健康状态的感知不够准确，会造成对后端实例正常或异常的误判，导致正常的服务实例被认为异常而不进行转发，造成资源闲置，平白增大其他服务实例的压力。如果对后端的服务实例健康检查不够高效，会在后端的服务实例横向扩容时需要显著增加进行健康检查的服务器数量，造成成本上升。在本申请实施例中，获取服务实例的异常状态的信息，可以归属为通过“推”的方式检测服务实例的健康状态。在一般状态下，本申请采用推的方式进行健康检查，即不对服务实例的健康状态进行拉取式检查，在推送式的状态下收到服务实例的异常状态的信息时，进一步对异常状态的信息进行确定。从而既能够保证服务实例的健康检查结果的准确性，又能够避免过多的无用拉取检查，节省资源。

在一种实施方式中，根据异常状态的信息的来源，判断是否需要进一步确认异常状态，包括：

在异常状态的信息为根据服务实例上报的异常报告获得的情况下，判定不需要进一步确认异常状态；

在异常状态的信息为根据服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认异常状态；

在异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认异常状态。

在本申请实施例中，在异常状态的信息为根据服务实例上报的异常报告获得的情况下，异常状态信息可以认为包括服务实例上报的异常报告，或者说可以认为异常状态的信息的来源为服务实例上报的异常报告。

在异常状态信息为根据服务实例和服务注册中心之间的长连接状态获得的情况下，异常状态信息的来源可以认为是服务实例和服务注册中心之间的长连接状态，例如，若服务实例和服务注册中心的长连接断开，则根据长连接上的租约，服务器会删除相应的IP(Internet Protocol Access，网际协议地址)。在这种情况下，可根据服务实例和服务注册中心之间的长连接状态，产生异常状态的信息。

在异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，异常状态的信息的来源可以认为是向服务实例发送请求连续失败的次数达到或超过设定阈值。

在本申请一种示例中，向服务实例发送请求连续失败的次数阈值可以为5-30次，例如，可以设定为10次、15次、20次或25次等。

在本申请实施例的中，对不同模式、不同途径上报的健康状态的信任程度是不一样的。信任程度最高的是推送模式下的不健康状态上报数据。因为不健康状态是由服务实例结合自己的业务场景给出。服务实例自己上报不健康，***会认为该实例确实处于不健康状态。

本申请实施例在服务实例和服务注册中心之间的长连接出现异常，或者向服务实例发送请求连续失败的次数超过设定阈值时，进一步通过拉取服务实例的健康状态来确定服务实例是否真的发生异常，避免因为长连接异常或者单纯的转发失败而产生的服务实例的异常状态的信息导致误判，进而避免在服务实例健康状态正常的情况下误判服务实例为异常而影响后续的请求转发。

在一种实施方式中，拉取服务实例的健康状态，包括：

向解耦模块发送服务实例健康状态拉取信息；

接收解耦模块获得的述服务实例的健康状态，服务实例的健康状态是解耦模块响应于服务实例健康状态拉取信息获得的。

在本申请实施例中，由于拉取健康状态的操作需要轮询进行，消耗较多资源，因此通过解耦模块对拉取信息进行解耦，利用解耦后的信息向服务实例获取其健康状态，能够合理分配资源消耗，使得消耗资源较多的任务分配到能够承受这种消耗的设备上。

本申请实施例还提供一种健康状态检查方法，如图2所示，包括：

步骤S21：接收服务实例健康状态拉取信息。

步骤S22：调用服务实例的健康端点(Endpoint)。

步骤S23：利用健康端点获得服务实例的健康状态。

在本申请实施例中，服务实例健康状态拉取信息，可以包括网关认为需要确定服务实例的健康状态时发送的信息，响应于服务实例健康状态拉取信息，调用服务实例的健康端点获取健康状态。

在本申请实施例中，服务实例健康状态拉取信息，还可以包括网关认为需要确定服务实例的健康状态时，向解耦模块同步的服务实例与服务注册中心的长连接状态，或者向解耦模块同步的服务实例请求失败的状态。

在本申请实施例中，服务实例健康状态拉取信息，还可以包括网关向解耦模块同步的服务实例状态信息中的异常状态的信息，或者从服务注册中心向解耦模块同步的服务实例状态信息中的异常状态的信息。

在本申请实施例中，在接收到网关发送的服务实例健康状态拉取信息后，对服务实例的健康状态进行拉取，从而在网关需要健康状态时执行拉取健康状态的操作，可以避免对健康状态进行不必要的获取，消耗过多的资源。

在本申请实施例中服务实例的健康状态可包括正常或异常。

在一种实施方式中，如图3所示，利用健康端点获得服务实例的健康状态之后，还包括：

步骤S31：在健康状态为正常的情况下，发送健康状态。

步骤S32：在健康状态为异常的情况下，返回调用服务实例的健康端点的步骤。

在本申请实施例中，若服务实例的健康状态为正常，则可通过服务注册中心将健康状态转发到网关，从而网关在后续操作中会将请求继续转发到服务实例。避免在长连接异常而服务实例健康状态正常时，因为将服务实例的健康状态误判为异常而后续不再向实例转发请求。若服务实例的健康状态为异常，则可继续拉取，直到拉取的服务实例的健康状态为正常。

在本申请实施例中，若网关感知到服务实例和服务注册中心之间的长连接断开而发送服务实例健康状态拉取信息，则需要向注册中心发送实例同步请求，同步长连接断开的服务实例。

在本申请一种示例中，健康状态检查方法的实现构架如图4所示，包括网关41、服务注册中心(Service Registry)42、健康检查模块(Health Check Module)43、服务实例(Service Instance)44。微服务架构下，网关41向服务实例44转发用户请求，服务实例44与服务注册中心42之间建立有长连接，服务实例44可设置有两个或多个。在服务实例44发生故障、无法正常提供服务时，需要及时将对应的服务实例44从网关41的记录中摘除，避免将用户请求转发到异常的服务实例上，在后端的服务实例恢复正常时，继续转发请求。从而保证用户请求转发过程的稳定性。

服务实例44通过与服务注册中心42之间的长连接来主动推送服务健康状态到服务注册中心，可以保证健康状态更新的及时性。网关41从服务注册中心42得知有哪些健康状态正常的服务实例44，然后向这些健康状态正常的服务实例44进行请求转发。在网关41感知到服务实例44可能存在异常时，将异常的服务实例信息同步给健康检查模块，由健康检查模块通过拉取模式调用待检查实例的Health Endpoint(健康端点)，来确认实例的真实健康状态，并将确认后的状态更新到服务注册中心42。其中健康检查模块43和网关41同机部署，从而，在健康检查模块43因为网络问题无法访问到实例时，可以保证同机部署的网关也无法正常访问，此时健康检查模块43获得的服务实例44的健康状态与网关41能否正常向服务实例44发送请求的情况一致。否则，会引入网关41到服务实例和健康检查模块43到实例的非对称网络异常造成健康状态误判的情况，影响准确性。在本示例中，健康检查模块43即解耦模块。

如果网关41感知到服务实例43和服务注册中心42之间的长连接断开，则认为服务实例44可能存在异常，向健康检查模块43发送信息，健康检查模块43请求服务注册中心42将异常的服务实例44同步到健康检查模块43，然后根据同步的信息，对可能存在异常的服务实例44调用健康端点进行健康检查，拉取健康状态。若网关41从服务注册中心42接收到关于某个服务实例44的健康状态为正常，而网关41向该服务实例44转发请求多次失败，则网关41发送信息给健康检查模块43，健康检查模块43调用该服务实例44的健康端点，进行健康状态拉取。如果拉取的健康状态为正常，则将健康状态同步到服务注册中心42，然后由服务注册中心42将健康状态同步到网关41。

在本申请示例中，网关信任健康检查模块通过拉取模式的检查结果。因为健康检查模块和网关同机部署，不会存在非对称网络异常场景下的健康状态误判情况。

倾向于信任推送模式下的健康状态上报数据。但是在长连接断开，服务实例通过服务注册中心上报健康状态正常，但是网关多次访问实例失败时，会认为该实例可能不健康，交由健康检查模块进行拉取模式的健康状态的进一步检查。

本申请实施例还提供一种健康状态检查装置，如图5所示，包括：

异常状态的信息获取模块51：用于获取服务实例的异常状态的信息；

判断模块52：用于根据异常状态的信息的来源，判断是否需要进一步确定异常状态；

拉取模块53：用于在需要进一步确认异常状态的情况下，拉取服务实例的健康状态。

在一种实施方式中，判断模块包括：

第一判定单元：用于在异常状态的信息为根据服务实例上报的异常报告获得的情况下，判定不需要进一步确认异常状态；

第二判定单元：用于在异常状态的信息为根据服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认异常状态；

第三判定单元：用于在异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认异常状态。

在一种实施方式中，拉取模块包括：

拉取信息发送单元：用于向解耦模块发送服务实例健康状态拉取信息；

健康状态接收单元：用于接收解耦模块获得的服务实例的健康状态，服务实例的健康状态是解耦模块响应于服务实例健康状态拉取信息获得的。

本申请实施例还提供一种健康状态检查装置，如图6所示，包括：

健康状态拉取信息接收模块61：用于接收网关发送的服务实例健康状态拉取信息；

健康端点调用模块62：用于调用服务实例的健康端点；

健康状态获得模块63：用于利用健康端点获得服务实例的健康状态。

在一种实施方式中，装置还包括：

健康状态发送模块71：用于在健康状态为正常的情况下，发送健康状态；

健康状态处理模块72：用于在健康状态为异常的情况下，触发健康状态发送模块。

本申请实施例还提供一种健康检查***，至少包括图5所示的健康检查装置和图6所示的健康检查装置。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图8所示，是根据本申请实施例的健康状态检查方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示，该电子设备包括：一个或多个处理器801、存储器802，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示图形用户界面(Graphical User Interface，GUI)的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器***)。图8中以一个处理器801为例。

存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中，存储器存储有可由至少一个处理器执行的指令，以使至少一个处理器执行本申请所提供的健康状态检查方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的健康状态检查方法。

存储器802作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的健康状态检查方法对应的程序指令/模块(例如，附图5所示的异常状态的信息获取模块51、判断模块52、拉取模块53)。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的健康状态检查方法。

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

健康状态检查方法的电子设备还可以包括：输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接，图8中以通过总线连接为例。

输入装置803可接收输入的数字或字符信息，以及产生与健康状态检查电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(Liquid Crystal Display，LCD)、发光二极管(Light EmittingDiode，LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的***和技术的各种实施方式可以在数字电子电路***、集成电路***、专用集成电路(Application Specific Integrated Circuits，ASIC)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程***上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储***、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储***、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(programmable logic device，PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的***和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(Cathode Ray Tube，阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的***和技术实施在包括后台部件的计算***(例如，作为数据服务器)、或者包括中间件部件的计算***(例如，应用服务器)、或者包括前端部件的计算***(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的***和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算***中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将***的部件相互连接。通信网络的示例包括：局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)和互联网。

计算机***可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。

根据本申请实施例的技术方案，在一般状态下，本申请采用推的方式进行健康检查，即不对服务实例的健康状态进行拉取式检查，在推送式的状态下收到服务实例的异常状态的信息时，进一步对异常状态的信息进行确定。从而既能够保证服务实例的健康检查结果的准确性，又能够避免过多的无用拉取检查，节省资源。

在推拉结合健康检查模式下，***正常运行期间，健康状态由实例主动通过长连接推送，无需定时调用健康端点进行检查，不会造成服务器资源的浪费，很好的满足了健康检查的高效性和及时性。在服务实例和注册中心长连接断开或者网关多次转发请求到同一实例异常时，解耦模块仅对这些可能存在异常的实例进行健康端点的调用并更新实例健康状态，因为检查的实例仅为可能存在异常的服务实例，不需要像传统拉取模式那样长时间定时调用全量后端实例的健康端点，保证了高效性。同时，因为对可能异常的实例进行了拉取模式的调用，克服了传统推送模式在非对称网络异常情况下对健康状态的误判，保证了健康状态检查的准确性。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。

Claims (11)

1.一种健康状态检查方法，其特征在于，包括：

获取服务实例的异常状态的信息；

根据所述异常状态的信息的来源，判断是否需要进一步确定所述异常状态；

在需要进一步确认所述异常状态的情况下，拉取所述服务实例的健康状态；

所述拉取所述服务实例的健康状态，包括：

向解耦模块发送服务实例健康状态拉取信息；

接收所述解耦模块获得的所述服务实例的健康状态，所述服务实例的健康状态是所述解耦模块响应于所述服务实例健康状态拉取信息获得的。

2.根据权利要求1所述的方法，其特征在于，根据所述异常状态的信息的来源，判断是否需要进一步确认所述异常状态，包括：

在所述异常状态的信息为根据所述服务实例上报的异常报告获得的情况下，判定不需要进一步确认所述异常状态；

在所述异常状态的信息为根据所述服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认所述异常状态；

在所述异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认所述异常状态。

3.一种健康状态检查方法，其特征在于，包括：

接收网关发送的服务实例健康状态拉取信息；

调用所述服务实例的健康端点；

利用所述健康端点获得所述服务实例的健康状态；

其中，调用所述服务实例的健康端点的解耦模块与所述网关同机部署。

4.根据权利要求3所述的方法，其特征在于，利用所述健康端点获得所述服务实例的健康状态之后，还包括：

在所述健康状态为正常的情况下，发送所述健康状态；

在所述健康状态为异常的情况下，返回调用所述服务实例的健康端点的步骤。

5.一种健康状态检查装置，其特征在于，包括：

异常状态的信息获取模块：用于获取服务实例的异常状态的信息；

判断模块：用于根据所述异常状态的信息的来源，判断是否需要进一步确定所述异常状态；

拉取模块：用于在需要进一步确认所述异常状态的情况下，拉取所述服务实例的健康状态；

所述拉取模块包括：

拉取信息发送单元：用于向解耦模块发送服务实例健康状态拉取信息；

健康状态接收单元：用于接收所述解耦模块获得的述服务实例的健康状态，所述服务实例的健康状态是所述解耦模块响应于所述服务实例健康状态拉取信息获得的。

6.根据权利要求5所述的装置，其特征在于，所述判断模块包括：

第一判定单元：用于在所述异常状态的信息为根据所述服务实例上报的异常报告获得的情况下，判定不需要进一步确认所述异常状态；

第二判定单元：用于在所述异常状态的信息为根据所述服务实例和服务注册中心之间的长连接状态获得的情况下，判定需要进一步确认所述异常状态；

第三判定单元：用于在所述异常状态的信息为根据向服务实例发送请求连续失败的次数获得的情况下，判定需要进一步确认所述异常状态。

7.一种健康状态检查装置，其特征在于，包括：

健康状态拉取信息接收模块：用于接收网关发送的服务实例健康状态拉取信息；

健康端点调用模块：用于调用所述服务实例的健康端点；

健康状态获得模块：用于利用所述健康端点获得所述服务实例的健康状态；

其中，调用所述服务实例的健康端点的解耦模块与所述网关同机部署。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

健康状态发送模块：用于在所述健康状态为正常的情况下，发送所述健康状态；

健康状态处理模块：用于在所述健康状态为异常的情况下，触发所述健康状态发送模块。

9.一种健康检查***，其特征在于，包括权利要求5-6中任意一项所述的健康状态检查装置，以及权利要求7-8中任意一项所述的健康状态检查装置。

10.一种电子设备，其特征在于，包括：

至少一个处理器；以及

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

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

11.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-4中任一项所述的方法。

Images