微服务故障处理方法及装置

技术领域

本发明涉及大数据技术领域，尤其涉及微服务故障处理方法及装置。

背景技术

注册中心是指微服务架构下，提供服务地址的发布和订阅的中心，服务的提供方Provider可以注册到注册中心，服务的消费方Consumer去注册中心订阅，并且服务方有变动时，订阅方式可以感知到的。

对于服务提供过程中的节点故障，是在服务订阅方进行判断处理，也就是熔断处理，服务订阅方进行实际服务调用时，如果调用失败率高，则进行熔断(停止对该服务的访问)，甚至进行降级处理(服务熔断后的较友好返回处理)。

现有技术的不足在于：业务失败率高。

发明内容

本发明实施例提供一种微服务故障处理方法，用以解决业务失败率高的不足，该方法包括：

通过注册中心监控各服务提供方的各节点提供服务的情况；

在根据服务的情况确定节点有故障后，通过注册中心决策将有故障的节点隔离。

本发明实施例还提供一种微服务故障处理装置，用以解决业务失败率高的不足，该装置包括：

监控模块，用于通过注册中心监控各服务提供方的各节点提供服务的情况；

故障模块，用于在根据服务的情况确定节点有故障后，通过注册中心决策将有故障的节点隔离。

本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述微服务故障处理方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述微服务故障处理方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述微服务故障处理方法。

本发明实施例中，与现有技术中在服务订阅方判断处理故障的技术方案相比，通过服务调用监控发现故障节点，在注册中心层面对故障节点进行摘除，由于由服务监控系统通知节点隔离系统进行服务实例下线的处理，该实例下线后，服务订阅方可动态到变化，并更新自己本地的服务节点列表，后续服务调用时不会再请求到故障节点；因而故障隔离彻底效果好，对服务订阅方完全透明，也由于完全透明因而也不会出现一个服务提供方节点故障，所有的服务订阅方都要进行熔断处理，导致恢复过程中服务的调用都会受到影响，业务失败率较高的问题。

进一步的，由于通过注册中心的服务下线隔离故障节点，只是在注册中心层面打标不可用，实际的故障节点保持现状，仍可排查故障原因，传统的直接停掉故障节点服务，导致故障排查困难。

进一步的，由于故障恢复好，只需要再次注册到注册中心即可，整个隔离和恢复对订阅方无感。

附图说明

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

图1为本发明实施例中微服务故障处理方法实施流程示意图；

图2为本发明实施例中微服务故障处理架构示意图；

图3为本发明实施例中微服务故障处理流程示意图；

图4为本发明实施例中微服务故障处理装置结构示意图；

图5为本发明实施例中计算机设备示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

发明人在发明过程中注意到：

节点假活是指服务端口和连接状态正常，但是实际服务调用无响应，或是服务质量非常差。

银行现在都在进行技术转型，从传统的集中式架构转向分布式微服务架构，服务器基本采用的X86或ARM架构的机器，机器的故障率相对于传统的小型机或大型机要高一些，如何在微服务架构下有效处理故障节点的问题，尤其是对于节点假活的状态进行有效隔离处理，是需要解决的问题。

而在现有的故障处理方式下，如果一个服务提供方节点故障，所有的服务订阅方都要进行熔断处理，且再间隔一段时间就要尝试恢复，恢复过程中服务的调用都会受到影响，业务失败率较高。

发明人还注意到：

微服务体系中，Service Registration and Discovery(服务注册与发现)是最核心的模块之一。例如：ServiceA(服务A)调用ServiceB时，需要通过Service Discovery从Service Registry(注册中心)得到Service Catalog(服务目录)，继而得到ServiceB的Endpoint(端点)列表，而ServiceB的Instance(实例)在启动时需要把提供服务的Endpoint注册到Service Registry的Service Catalog中。

Service Registry(注册中心)除了需要完成Service Registration的工作之外，还需要提供以下功能：

主动与被动的健康检查：

主动健康检查：由Service Registry主动定期发送健康检查探测包，探测Producer APP是否正常提供服务。主动探测的好处在于服务提供方不用做任何改动即可快融入微服务架构。

被动健康检查：则是指由Producer APP自动通过心跳方式保持活性。

基于此，可以通过服务调用监控发现故障节点，在注册中心层面对故障节点进行摘除，故障隔离彻底效果好，对服务订阅方完全透明。故障隔离后，通过监控通知运维人员进行故障分析定位，故障恢复好，只需要再次注册到注册中心即可，整个隔离和恢复对订阅方无感。

下面结合实施例进行说明。

图1为微服务故障处理方法实施流程示意图，如图1所示，可以包括：

步骤101、通过注册中心监控各服务提供方的各节点提供服务的情况；

步骤102、在根据服务的情况确定节点有故障后，通过注册中心决策将有故障的节点隔离。

实施中，根据以下服务的情况之一或者其组合确定节点有故障：

节点技术失败率超过预设阈值，节点无响应，节点服务响应时间长度超过预设阈值。

具体的，如果判断某个服务提供方的某个节点技术失败率过高，或是无响应，或是服务响应持续缓慢，决策该服务节点可隔离。

实施中，通过注册中心监控各服务提供方的各节点提供服务的情况，是通过服务调用链的监控系统进行监控的。

具体的，可以通过服务调用监控，服务调用链路的监控，能发现调用链上的服务质量，提供故障节点判断。

实施中，将有故障的节点隔离，包括：

由监控系统通知节点隔离系统进行服务实例下线处理。

具体的，根据故障决策，调用注册中心服务节点停用API(ApplicationProgramming Interface，应用程序编程接口)，参数可以包括服务、节点IP，进行故障节点的下线处理。

由服务监控系统通知节点隔离系统进行服务实例下线的处理，该实例下线后，服务订阅方可动态到变化，并更新自己本地的服务节点列表，后续服务调用时不会再请求到故障节点。

实施中，将有故障的节点隔离后，还可以进一步包括：

在节点故障清除后，将节点注册到注册中心。

具体的，由服务监控系统通知节点隔离系统进行服务实例下线的处理，该实例下线后，服务订阅方可动态到变化，并更新自己本地的服务节点列表，后续服务调用时不会再请求到故障节点。故障隔离后，通过监控通知运维人员进行故障分析定位，故障恢复好，只需要再次注册到注册中心即可，整个隔离和恢复对订阅方无感。

实施时，只需对注册中心有理解，能使用服务节点的停用API；在服务调用层面进行服务调用链监控，能采集到服务提供方的节点IP，并能决策判断服务节点的服务质量，为节点摘除提供正确的决策即可。

下面通过实例进行说明。

图2为微服务故障处理架构示意图，如图2所示，可以包括：

注册中心：提供服务的注册和发现，并提供服务摘除的API访问。

服务提供方：发布的注册中心的服务提供方，一般都是多节点的集群。

服务订阅方：订阅注册中心的服务订阅方，一般也是多节点集群。

服务调用监控：服务调用链路的监控，能发现调用链上的服务质量，提供故障节点判断。

故障决策：根据服务监控输出的结果，分析判断故障节点，决策是否进行节点摘除。

节点摘除模块：根据故障决策，调用注册中心服务节点停用API(参数包括服务、节点IP)，进行故障节点的下线处理。

图3为微服务故障处理流程示意图，如图3所示，可以包括：

步骤301、服务提供方注册服务到注册中心。

步骤302、服务订阅方通过注册中心订阅到要调用的服务节点列表，并缓存到本地，调用时根据软负载算法，从订阅到的服务节点列表中选取一个节点进行调用。

步骤303、服务调用时，会输出日志到监控模块，监控模块对异常的数据报告给故障决策模块。

步骤304、故障决策模块分析异常数据，根据决策策略，判断故障节点，如有被判定为故障节点的，就调用故障摘除节点进行服务下线处理。

步骤305、节点摘除模块调用注册中心的服务节点停用API，对故障节点进行服务下线处理(仅是注册中心层面的停用)。

步骤306、服务订阅方感知订阅服务节点列表的变化，更新本地缓存，后续调用时不再访问故障节点。

方案通过微服务调用链的监控系统，判断某个服务提供方的某个节点技术失败率过高，或是无响应，或是服务响应持续缓慢，决策该服务节点可隔离，由服务监控系统通知节点隔离系统进行服务实例下线的处理，该实例下线后，服务订阅方可动态到变化，并更新自己本地的服务节点列表，后续服务调用时不会再请求到故障节点。

本发明实施例中还提供了一种微服务故障处理装置，如下面的实施例所述。由于该装置解决问题的原理与微服务故障处理方法相似，因此该装置的实施可以参见微服务故障处理方法的实施，重复之处不再赘述。

图4为微服务故障处理装置结构示意图，如图4所示，可以包括：

监控模块401，用于通过注册中心监控各服务提供方的各节点提供服务的情况；

故障模块402，用于在根据服务的情况确定节点有故障后，通过注册中心决策将有故障的节点隔离。

实施中，故障模块进一步用于根据以下服务的情况之一或者其组合确定节点有故障：

节点技术失败率超过预设阈值，节点无响应，节点服务响应时间长度超过预设阈值。

实施中，监控模块进一步用于通过注册中心监控各服务提供方的各节点提供服务的情况，是通过服务调用链的监控系统进行监控的。

实施中，故障模块进一步用于将有故障的节点隔离，包括：

由监控系统通知节点隔离系统进行服务实例下线处理。

实施中，进一步包括：

注册模块，用于将有故障的节点隔离后，在节点故障清除后，将节点注册到注册中心。

在实施本发明实施例提供的技术方案时，可以按如下方式实施。

图5为计算机设备示意图，如图5所示，计算机设备中包括：

处理器500，用于读取存储器520中的程序，执行下列过程：

通过注册中心监控各服务提供方的各节点提供服务的情况；

在根据服务的情况确定节点有故障后，通过注册中心决策将有故障的节点隔离；

收发机510，用于在处理器500的控制下接收和发送数据。

实施中，根据以下服务的情况之一或者其组合确定节点有故障：

节点技术失败率超过预设阈值，节点无响应，节点服务响应时间长度超过预设阈值。

实施中，通过注册中心监控各服务提供方的各节点提供服务的情况，是通过服务调用链的监控系统进行监控的。

实施中，将有故障的节点隔离，包括：

由监控系统通知节点隔离系统进行服务实例下线处理。

实施中，将有故障的节点隔离后，进一步包括：

在节点故障清除后，将节点注册到注册中心。

其中，在图5中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器500代表的一个或多个处理器和存储器520代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发机510可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器500负责管理总线架构和通常的处理，存储器520可以存储处理器500在执行操作时所使用的数据。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述微服务故障处理方法。

本发明实施例还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时实现上述微服务故障处理方法。

本发明实施例中，通过监控发现故障节点，通过注册中心去摘除故障节点，进行有效隔离。

至少有以下效果之一：

1、隔离效果好；

2、对订阅方透明；

3、一点隔离，多点(多个订阅方)受益；

4、故障恢复对订阅方也透明；

5、通过注册中心的服务下线隔离故障节点，只是在注册中心层面打标不可用。实际的故障节点保持现状，仍可排查故障原因，传统的直接停掉故障节点服务，导致故障排查困难。

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

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

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

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

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。