CN105991305B - 一种识别链路异常的方法及装置 - Google Patents

Abstract

本发明公开了一种识别链路异常的方法，所述方法包括：中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；中间件的连接状态为正常时，在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错率大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；将所述异常的中间件实例链路中的中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。本发明还同时公开了另一种识别链路异常的方法及两种识别链路异常的装置。

Description

一种识别链路异常的方法及装置

技术领域

本发明涉及数据传输技术，尤其涉及一种识别链路异常的方法及装置。

背景技术

在互联网时代，各种互联网信息呈几何级的增长，为了准确、稳定的保存及获取需要的信息，衍生了各种大型的信息技术(Information Technology，IT)系统；IT系统包括多个中间件实例，每个中间件实例包含多个应用服务；各应用服务之间相互调用使得数据传输的多个环节使用多点对多点的业务分发架构。

多点对多点的业务分发架构可采用长连接链路模式或短连接链路模式；长连接链路模式是指连接一旦建立，链路不再断开；短连接链路模式是指连接需要时才申请建立连接链路。在使用短连接链路时，由于连接的频繁申请和建立，使得业务的处理效率降低，服务器资源消耗过大；在使用长连接链路时，若出现单链路偶发性异常，则长连接链路难以恢复，导致集群停服。系统的宕机或服务不可用直接影响企业的形象、营业额以及用户的用户体验。

客户关系管理(Customer Relationship Management，CRM)系统为提高处理效率使用长连接链路模式，CRM系统中每台中间件实例由负载均衡器进行业务分发，工作模式如图1所示，客户请求的业务被负载均衡器随机分发至一台中间件上，中间件集群几十条链路相互独立，每个链路都可能接收到客户端发起的请求，并与后端数据库进行交互办理业务；因此，在出现中间件长连接链路偶发性异常时，由于负载均衡器不能及时判断中间件和服务的状态是否正常，仍会将新的业务请求分配至发生故障的中间件和服务链路上，导致部分用户办理业务失败。

多点对多点的业务分发架构的下层部署监控程序在查证到某条链路异常时，便立即向上层发送停止请求；但是，由于上层有多点，反应速度快慢不一，反应速度慢的节点仍会因为时间差而发送多笔业务请求至下层的异常节点，导致多笔业务失败；并且，在下层某个节点出现死机等极端异常情况时，无法向上层传递断开请求，导致大量业务失败。多点对多点的业务分发架构的上层部署监控程序查证到某条链路异常时，即自动断开链路，停止发送请求；但是，遇到下层各节点的对外接口均出现统一的抖动等偶发性的异常时、或上层节点与下层节点之间的网络出现短时间异常时由于上层多节点之间彼此平等、互不统属导致下层多个节点被上层节点直接屏蔽，上层节点也无法获知下层各节点是否恢复正常工作，何时恢复正常工作，最终可能引起大规模的错误判断，影响业务办理。

具体地，在CRM系统可能会出现如下局面：1、由于负载均衡器只能判断中间件实例是否正常，当中间件链路处于“假死”状态，而前端负载均衡器认为该中间件处于“在服状态”，仍会将客户端业务请求发送至该链路处理，不能及时的让客户端感知故障；2、当某一中间件办理业务效率总体下降时，负载均衡器只能判断中间件实例是否正常，不能统计一段时间内中间件业务办理的失败率；3、当中间件的某一服务发生异常时，不能根据单个中间件服务办理业务的失败率对异常中间件和服务链路进行隔离、恢复；4、当由于主机性能降低导致业务办理失败时，不能通过重启主机等主机层面的方法进行异常中间件和服务链路自动恢复；5、单一中间件实例和服务性能降低时，需要大量人力和时间分析、排除和回复异常中间件和服务链路。

发明内容

有鉴于此，本发明实施例期望提供一种识别链路异常的方法及装置，能够统计一段时间内中间件业务办理的失败率，根据单个中间件服务办理业务的失败率对异常中间件和服务链路进行隔离和恢复，及时的智能的让客户端感知中间件实例故障。

本发明实施例的技术方案是这样实现的：

本发明实施例提供一种识别链路异常的方法，所述方法包括：中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；中间件的连接状态为正常时，在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错率大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；将所述异常的中间件实例链路中的中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。

上述实现方案中，所述隔离的中间件信息在各中间件之间共享。

上述实现方案中，所述方法还包括：中间件管理器监测、记录中间件实例链路的业务量和业务处理效率。

本发明实施例还提供另一种识别链路异常的方法，所述方法包括：中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，中间件管理器确认中间件服务异常；或，接收到第三方应用推送的异常服务信息时，中间件管理器确认中间件服务异常；隔离异常的中间件服务。

上述实现方案中，所述隔离的中间件服务信息在各中间件之间共享，所述确认中间件服务异常后，所述方法还包括：中间件管理器将接收的服务请求路由至正常的中间件服务。

上述实现方案中，异常的中间件服务在时间一个切片内反馈的中间件实例链路报错次数小于第四阈值时，中间件管理器恢复所述异常中间件服务的链路路由。

本发明实施例还提供一种识别链路异常的装置，所述装置应用于中间件管理器，所述装置包括：探测模块、第一确认模块、第一判断模块和第一处理模块；其中，

所述探测模块，用于探测中间件的连接状态；

所述第一确认模块，用于在探测模块探测中间件的连接状态为异常时，确认中间件实例链路异常；

所述第一判断模块，用于在探测模块探测中间件的连接状态为正常时，判断在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数是否大于第一阈值，链路的报错率是否大于第二阈值，且链路的报错次数是否大于第三阈值；

所述第一确认模块，还用于在所述第一判断模块判断在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错次数大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

所述第一处理模块，用于在第一确认模块确认中间件实例链路异常后，将所述中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。

上述实现方案中，所述隔离的中间件信息在各中间件之间共享。

上述实现方案中，所述装置还包括：记录模块，用于监测、记录中间件实例链路的业务量和业务处理效率。

本发明实施例还提供另一种识别链路异常的装置，所述装置应用于中间件管理器，所述装置包括：第二判断模块、第二确认模块、接收模块和第二处理模块；其中，

所述第二判断模块，用于判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数是否大于第四阈值；

所述第二确认模块，用于在所述第二判断模块判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，确认中间件服务异常；

所述接收模块，用于接收第三方应用推送的异常服务信息；

所述第二确认模块，还用于在所述接收模块接收到第三方应用推送的异常服务信息时，确认中间件服务异常；

所述第二处理模块，用于隔离异常的中间件服务。

上述实现方案中，所述隔离的中间件服务信息在各中间件之间共享，所述第二处理模块，还用于将接收的服务请求路由至正常的中间件服务。

上述实现方案中，所述第二处理模块，还用于异常的中间件服务在一个时间切片内反馈的中间件实例链路报错次数小于第四阈值时，恢复所述异常中间件服务的链路路由。

本发明实施例所提供的识别链路异常的方法及装置，中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；中间件的连接状态为正常时，在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错次数大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；将所述异常的中间件实例链路中的中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件；中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，中间件管理器确认中间件服务异常；或，接收到第三方应用推送的异常服务信息时，中间件管理器确认中间件服务异常；隔离异常的中间件服务。如此，通过监测、记录中间件实例链路的业务量和业务处理效率能够智能的判断在一个时间片内中间件实例链路的异常情况，及时的让客户端感知故障，并对异常的中间件和服务链路进行隔离和恢复。

附图说明

图1为本发明CRM系统的工作模式示意图；

图2为本发明业务处理流程示意图；

图3为本发明实施例一种识别链路异常的方法的基本处理流程示意图；

图4为本发明实施例另一种识别链路异常的方法的基本处理流程示意图；

图5为本发明实施例识别链路异常的方法的详细处理流程；

图6为本发明实施例时间切片内服务异常示意图；

图7为本发明实施例一种业务请求分发至中间件服务器的示意图；

图8为本发明实施例另一种业务请求分发至中间件服务器的示意图；

图9为本发明实施例一种识别链路异常的装置的组成结构示意图；

图10为本发明实施例另一种识别链路异常的装置的组成结构示意图。

具体实施方式

现有技术中的业务处理流程，如图2所示，通过负载均衡器按照区域、号段和轮循等规则将用户的业务请求均衡地连接到各个前端Web服务器，Web服务器再将所述用户业务请求分发到中间件管理器，由中间件管理器进行综合判断，调用具体中间件实例及相关服务进行业务逻辑处理，最终转换为具体的结构化查询语言(Structured Query Language，SQL)语句到数据库执行，并将执行结果反馈给用户。

本发明实施例中，中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；中间件的连接状态为正常时，在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错次数大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；将所述异常的中间件实例链路中的中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，中间件管理器确认中间件服务异常；或，接收到第三方应用推送的异常服务信息时，中间件管理器确认中间件服务异常；隔离异常的中间件服务。

本发明实施例一种识别链路异常的方法的基本处理流程，如图3所示，包括以下步骤：

步骤101，中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；

具体地，中间件管理器通过使用weblogic应用服务和应用程序编程接口(Application Programming Interface，API)定时探测中间件的连接状态，连接状态为非true时，表明中间件的连接状态异常，则中间件管理器确认中间件实例链路异常。

步骤102，中间件的连接状态为正常时，在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错率大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

具体地，中间件管理器探测中间件的连接状态，连接状态为true时，表明中间件的连接状态正常；中间件管理器监测、记录中间件实例链路的业务量和业务处理效率，在发起服务请求前的一个时间片内，中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错率大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

其中，所述报错率是指中间件实例链路的报错次数占同等地位的中间件实例链路的比率；所述一个时间片、第一阈值、第二阈值和第三阈值均可以根据实际的系统负载进行设定；所述一个时间片可以为60s，90s等，所述第一阈值可以为90次、100次等，所述报错率可以为80％、85％等。

在确认中间件实例链路异常后，所述方法还包括：

步骤103，中间件管理器将所述中间件从自身的中间件实例集合中剔除，或隔离该中间件；

这里，中间件管理器再接收到服务请求时，将所述服务请求分发至正常的中间件实例，并自动重置异常中间件实例链路的各环节资源，在重置3次仍未恢复为正常中间件实例链路时，自动停止该异常链路，并告警；当然，重置次数也可以根据实际需要设置为2次、4次等；由于下层出现多数节点同时异常的概率极小，即使出现，通过隔离中间件也无法解决该问题，因此，在隔离的中间件超过总中间件的一定比例，如40％时，不再隔离新的中间件；在中间件的连接状态由非true变为true时，中间件管理器将自动恢复该中间件的连接，新的业务请求也将分发至恢复的中间件。

本发明实施例另一种识别链路异常的方法的基本处理流程，如图4所示，包括以下步骤：

步骤201，确认中间件服务在一个时间切片内反馈的中间件实例链路报错次数是否大于第四阈值，或是否接收到第三方应用推送的异常服务信息；

这里，所述一个时间片和所述第四阈值根据实际的系统负载进行设定，可以为60s，90s等，所述第四阈值可以是5次，6次等。

步骤202，中间件管理器确认中间件服务异常；

具体地，当中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值，或中间件管理器接收到第三方应用推送的异常服务信息时，中间件管理器确认中间件服务异常。

在确认中间件服务异常之后，本发明实施例所述方法还包括：

步骤203，中间件管理器隔离异常的中间件服务，将接收的服务请求路由至正常的中间件服务。

步骤204，异常的中间件服务在时间一个切片内反馈的中间件实例链路报错次数小于第四阈值时，中间件管理器恢复所述异常中间件服务的链路路由。

以TDOM1、TDOM2、TDOM3三台具有相同处理能力的tuxedo中间件为例，业务调用的服务为sGetUserMsg，时间片为60S，在一个中间件链路上中间件服务异常的次数超过5次，则隔离该中间件；本发明实施例识别链路异常的方法的详细处理流程，如图5所示，包括以下步骤：

步骤301，检查中间件TDOM1在60S内发生了6次服务异常，隔离中间件TDOM1；

具体地，本发明实施例时间切片内服务异常示意图，如图6所示，圆点表示发生服务异常，即：在60S内，发生了6次服务异常。

步骤302，检查TDOM2和TDOM3在60S内均发生了2次服务异常，新的业务请求被路由至TDOM2和TDOM3；

这里，若TDOM2和TDOM3在60S内均发生了5次以上的服务异常，则隔离TDOM2和TDOM3，即全部中间件均被隔离；此时，若接收到新的业务请求，中间件管理器向用户反馈没有可用的中间件处理该业务。

步骤303，在第61S时刻重新检查中间件TDOM1发生的服务异常次数；

具体地，如图6所示，在61S时刻，检查中间件TDOM1在1S至61S内发生3次服务异常，则恢复中间件TDOM1处理sGetUserMsg服务。

步骤304，在第62S时刻重新检查中间件TDOM1发生的服务异常次数；

具体地，如图6所示，在第62S时刻，检查中间件TDOM1在2S至62S内发生8次服务异常，隔离中间件TDOM1；此时，中间件管理器不会将sGetUserMsg服务请求分发至中间件TDOM1。

以一台中间件管理器管理四台中间件服务器为例，如图7所示，当中间件的连接状态均为true时，业务请求随机分发至四台中间件服务器上；当第三个中间件的连接状态为非true时，如图8所示，业务请求分发至第一台、第二台和第四台中间件服务器。

本发明上述实施例中，中间件管理器通过时间切片的方式记录中间件的上层和中间件的下层的运行信息，并对记录的信息进行统筹管理，实现了上层中间件对多个下层中间件之间链路异常的自动判定，解决了下层中间件报错、隔离不及时，隔离的故障上层中间件难以自动恢复等问题；使得上层隔离的中间件链路的信息会在各个中间件之间共享；当隔离的中间件数量超过预设的值，即不在隔离新的中间件，以此来规避上层中间件对下次中间件异常的错误判定，解决了单纯靠中间件上层判定或中间件下层通知等传统的方式出现的误判、故障中间件恢复时差等问题。

下面详细说明与现有技术相比，利用时间切片的方式识别链路异常可有效提高中间件系统服务的可用性。

现有技术中，一个中间件资源包括一个中间件实例资源和多个中间件服务资源，不考虑其他主机资源和存储资源的可用性，只对中间件实例和中间件服务的可用性进行评估；现有技术中，用户的业务请求随机的分配到每一台中间件，所有中间件资源的可用性均值即为整个系统的可用性；假设有n台中间件资源，每台中间件实例资源的可用性均为Ai，每台中间件服务的可用性为Asn，针对其中的某一服务，如sGetUserMsg服务的可用性进行计，则在未使用时间切片方法情况下，每台中间件资源sGetUserMsg服务的可用性为：

Aan＝Ai*Asn (1)；

由于在正常模式下，请求随机的分配到一台中间件资源，每台中间件实例的可用 性亦相同，所以整个中间件资源的可用性可计算为每台中间件资源的可用性求和的均值， 所以，

即：

其中，为系统总体的可用性，Aan：每台中间件资源的可用性，Ai为单个中间件实例的可用性，Asn为单个服务可用性。

利用时间切片的方式，由于使用了中间件管理器对中间件实例的可用性和中间件服务的可用性进行时间切片挂历，中间件实例的可用性和中间件服务的可用性都由中间件管理器自主判断，并自动分发至可用的中间件实例和中间件服务上；因此，只要有一台中间件的sGetUserMsg服务可用，则整个中间件系统的sGetUserMsg服务可用，sGetUserMsg服务的可用性为：

其中，1-Asn为单个sGetUserMsg服务非可用性值，Π为连乘计算，n为正整数；

在时间切片模式下，只有当所有中间件实例的sGetUserMsg服务不可用时，该服务才变为不可用；因此，整个中间件实例sGetUserMsg服务不可用值为：

由于中间件服务可用性的前提为中间件实例可用，所以，关联上述中间件实例可用性值，则整个中间件资源sGetUserMsg服务可用性计算为：

其中，Aa为中间件系统的可用性，Ai为单个中间件实例的可用性，n为中间件的数量，Asn为单个服务的可用性。

根据正常模式和时间切片模式下整个系统某一服务可用性公式进行计算，为更加明显对比出两者的差异和计算方便，假设：单个中间件实例可用性值Ai为0.955，每个服务可用性值Asn均为0.905，共有10台中间件，即n＝10，则正常模式下，中间件系统的可用性为：

时间切片模式下，中间件系统的可用性为：

可以看出，利用时间切片的方式识别链路异常可有效提高中间件系统服务的可用性。

为实现上述识别链路异常的方法，本发明实施例还提供一种识别链路异常的方法的装置，所述装置应用于中间件管理器，所述装置的组成结构，如图9所示，包括：探测模块11、第一确认模块12、第一判断模块13和第一处理模块14；其中，

所述探测模块11，用于探测中间件的连接状态；

所述第一确认模块12，用于在探测模块11探测中间件的连接状态为异常时，确认中间件实例链路异常；

所述第一判断模块13，用于在探测模块11探测中间件的连接状态为正常时，判断在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数是否大于第一阈值，链路的报错率是否大于第二阈值，且链路的报错次数是否大于第三阈值；

所述第一确认模块12，还用于在所述第一判断模块13判断在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错次数大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

所述第一处理模块14，用于在第一确认模块12确认中间件实例链路异常后，将所述中间件从中间件管理器的中间件集合中剔除，或隔离该中间件。。

上述实现方案中，所述装置还包括：记录模块15，用于监测、记录中间件实例链路的业务量和业务处理效率。

上述实现方案中，所述探测模块11通过使用weblogic应用服务和API定时探测中间件的连接状态，连接状态为非true时，表明中间件的连接状态异常，则中间件管理器确认中间件实例链路异常。

上述实现方案中，所述报错率是指中间件实例链路的报错次数占同等地位的中间件实例链路的比率；所述一个时间片、第一阈值、第二阈值和第三阈值均可以根据实际的系统负载进行设定；所述一个时间片可以为60s，90s等，所述第一阈值可以为90次、100次等，所述报错率可以为80％、85％等。

本发明实施例还提供另一种识别链路异常的装置，所述装置应用于中间件管理器，所述装置的组成结构，如图10所示，包括：第二判断模块21、第二确认模块22、接收模块23和第二处理模块24；其中，

所述第二判断模块21，用于判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数是否大于第四阈值；

所述第二确认模块22，用于在所述第二判断模块判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，确认中间件服务异常；

所述接收模块23，用于接收第三方应用推送的异常服务信息；

所述第二确认模块22，还用于在所述接收模块接收到第三方应用推送的异常服务信息时，确认中间件服务异常。

所述第二处理模块24，用于隔离异常的中间件服务；

上述实现方案中，所述第二处理模块24，还用于将接收的服务请求路由至正常的中间件服务。

上述实现方案中，所述第二处理模块24，还用于异常的中间件服务在一个时间切片内反馈的中间件实例链路报错次数小于第四阈值时，恢复所述异常中间件服务的链路路由。

上述实现方案中，所述一个时间片和所述第四阈值根据实际的系统负载进行设定，可以为60s，90s等，所述第四阈值可以是5次，6次等。

需要说明的是，在实际应用中，所述探测模块11、第一确认模块12、第一判断模块13、第一处理模块14、记录模块15、第二判断模块21、第二确认模块22、接收模块23和第二处理模块24的功能可由位于中间件管理器上的中央处理器(CPU)、或微处理器(MPU)、或数字信号处理器(DSP)、或可编程门阵列(FPGA)实现。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1.一种识别链路异常的方法，其特征在于，所述方法包括：

中间件管理器探测中间件的连接状态，中间件的连接状态为异常时，确认中间件实例链路异常；

中间件的连接状态为正常时，在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错率大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

将所述异常的中间件实例链路中的中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。

2.根据权利要求1所述识别链路异常的方法，其特征在于，所述隔离的中间件信息在各中间件之间共享。

3.根据权利要求1或2所述识别链路异常的方法，其特征在于，所述方法还包括：

中间件管理器监测、记录中间件实例链路的业务量和业务处理效率。

4.一种识别链路异常的方法，其特征在于，所述方法包括：

中间件管理器通过时间切片的方式记录中间件的上层和中间件的下层的运行信息，当中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，中间件管理器确认中间件服务异常；或，中间件管理器接收到第三方应用推送的异常服务信息时，中间件管理器确认中间件服务异常；

隔离异常的中间件服务。

5.根据权利要求4所述识别链路异常的方法，其特征在于，所述隔离的中间件服务信息在各中间件之间共享，所述确认中间件服务异常后，所述方法还包括：中间件管理器将接收的服务请求路由至正常的中间件服务。

6.根据权利要求4或5所述识别链路异常的方法，其特征在于，异常的中间件服务在时间一个切片内反馈的中间件实例链路报错次数小于第四阈值时，中间件管理器恢复所述异常中间件服务的链路路由。

7.一种识别链路异常的装置，所述装置应用于中间件管理器，其特征在于，所述装置包括：探测模块、第一确认模块、第一判断模块和第一处理模块；其中，

所述探测模块，用于探测中间件的连接状态；

所述第一确认模块，用于在探测模块探测中间件的连接状态为异常时，确认中间件实例链路异常；

所述第一判断模块，用于在探测模块探测中间件的连接状态为正常时，判断在发起服务请求前的一个时间片内中间件管理器记录的链路入服和退服次数是否大于第一阈值，链路的报错率是否大于第二阈值，且链路的报错次数是否大于第三阈值；

所述第一确认模块，还用于在所述第一判断模块判断在发起服务请求的一个时间片内中间件管理器记录的链路入服和退服次数大于第一阈值，链路的报错次数大于第二阈值，且链路的报错次数大于第三阈值时，确认中间件实例链路异常；

所述第一处理模块，用于在第一确认模块确认中间件实例链路异常后，将所述中间件从中间件管理器的中间件集合中剔除，或隔离所述中间件。

8.根据权利要求7所述识别链路异常的装置，其特征在于，所述隔离的中间件信息在各中间件之间共享。

9.根据权利要求7或8所述识别链路异常的装置，其特征在于，所述装置还包括：记录模块，用于监测、记录中间件实例链路的业务量和业务处理效率。

10.一种识别链路异常的装置，所述装置应用于中间件管理器，其特征在于，所述装置包括：第二判断模块、第二确认模块、接收模块和第二处理模块；其中，

所述第二判断模块，用于通过时间切片的方式记录中间件的上层和中间件的下层的运行信息，判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数是否大于第四阈值；

所述第二确认模块，用于在所述第二判断模块判断中间件服务在一个时间切片内反馈的中间件实例链路报错次数大于第四阈值时，确认中间件服务异常；

所述接收模块，用于接收第三方应用推送的异常服务信息；

所述第二确认模块，还用于在所述接收模块接收到第三方应用推送的异常服务信息时，确认中间件服务异常；

所述第二处理模块，用于隔离异常的中间件服务。

11.根据权利要求10所述识别链路异常的装置，其特征在于，所述隔离的中间件服务信息在各中间件之间共享，所述第二处理模块，还用于将接收的服务请求路由至正常的中间件服务。

12.根据权利要求10或11所述识别链路异常的装置，其特征在于，所述第二处理模块，还用于异常的中间件服务在一个时间切片内反馈的中间件实例链路报错次数小于第四阈值时，恢复所述异常中间件服务的链路路由。