CN110417586A - 服务监控方法、服务节点、服务器及计算机可读存储介质 - Google Patents

服务监控方法、服务节点、服务器及计算机可读存储介质 Download PDF

Info

Publication number
CN110417586A
CN110417586A CN201910649658.8A CN201910649658A CN110417586A CN 110417586 A CN110417586 A CN 110417586A CN 201910649658 A CN201910649658 A CN 201910649658A CN 110417586 A CN110417586 A CN 110417586A
Authority
CN
China
Prior art keywords
service
heartbeat message
corresponding relationship
abnormal
services
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201910649658.8A
Other languages
English (en)
Other versions
CN110417586B (zh
Inventor
郝向东
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
New H3C Big Data Technologies Co Ltd
Original Assignee
New H3C Big Data Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by New H3C Big Data Technologies Co Ltd filed Critical New H3C Big Data Technologies Co Ltd
Priority to CN201910649658.8A priority Critical patent/CN110417586B/zh
Publication of CN110417586A publication Critical patent/CN110417586A/zh
Application granted granted Critical
Publication of CN110417586B publication Critical patent/CN110417586B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12Discovery or management of network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/535Tracking the activity of the user

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本申请提出一种服务监控方法、服务节点、服务器及计算机可读存储介质,涉及计算机技术领域,通过由包括第一服务在内的多个服务共同构成拓扑结构,并将拓扑结构中包含的每个服务与其他至少一个服务建立对应关系,从而使拓扑结构中的各个服务,能够通过判断心跳信息的接收情况是否异常,确定出与该对应关系中与每一服务各自对应的服务是否可能出现异常的服务,从而实现对多个服务工作状态的监测,相比于现有技术,通过由多个服务共同构成拓扑结构,并由每一服务各自对拓扑结构中与该服务对应的其他服务进行监测,从而避免了独立的监测服务出现单点故障等造成其他服务监测功能完全丢失。

Description

服务监控方法、服务节点、服务器及计算机可读存储介质
技术领域
本申请涉及计算机技术领域,具体而言,涉及一种服务监控方法、服务节点、服务器及计算机可读存储介质。
背景技术
在由多个服务构成的服务集群***为用户提供服务时,为了避免某些服务工作异常,导致数据丢失或者是***功能故障等,一般需要对服务集群***中的各个服务的工作状态进行监测,以确保服务集群***正常稳定的运行。
目前一般采用独立的监测服务,对服务集群***中的各个服务统一进行监测;但独立的监测服务会存在单点故障的问题,若监测服务本身出现异常,则可能导致整个服务集群***的监测功能丢失,无法持续对整个服务集群***进行监测。
发明内容
本申请的目的在于提供一种服务监控方法、服务节点、服务器及计算机可读存储介质,能够持续对拓扑结构提供监测服务。
为了实现上述目的,本申请实施例采用的技术方案如下:
第一方面,本申请实施例提供一种服务监控方法,应用于运行有第一服务的服务节点,所述第一服务与多个其他服务共同构成拓扑结构;所述拓扑结构包含的每个服务与其他至少一个服务建立有对应关系,且每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测;所述方法包括:
所述第一服务判断心跳信息的接收情况是否异常;
若确定心跳信息的接收情况出现异常,则所述第一服务判断所述第一服务对应的其他服务中是否出现异常的服务。
第二方面,本申请实施例提供一种服务节点,所述服务节点运行有第一服务,所述第一服务与多个其他服务共同构成拓扑结构;所述拓扑结构包含的每个服务与其他至少一个服务建立有对应关系,且每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测;所述服务节点包括:
判断模块,用于判断所述第一服务接收心跳信息的情况是否异常;
处理模块,用于若确定所述第一服务接收心跳信息的情况出现异常,则判断所述第一服务对应的其他服务中是否出现异常的服务。
第三方面,本申请实施例提供一种服务器,所述服务器包括存储器,用于存储一个或多个程序;处理器;当所述一个或多个程序被所述处理器执行时,实现上述的服务监控方法。
第四方面,本申请实施例提供一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述的服务监控方法。
本申请实施例提供的一种服务监控方法、服务节点、服务器及计算机可读存储介质,通过由包括第一服务在内的多个服务共同构成拓扑结构,并将拓扑结构中包含的每个服务与其他至少一个服务建立对应关系,从而使拓扑结构中的各个服务,能够通过判断心跳信息的接收情况是否异常,确定出与该对应关系中与每一服务各自对应的服务是否可能出现异常的服务,从而实现对多个服务工作状态的监测,相比于现有技术,使得由多个服务构成的拓扑结构的监测功能无需由独立的监测服务提供,而是由拓扑结构中的每一服务对拓扑结构中与该服务对应的其他服务进行监测,从而避免了独立的监测服务出现单点故障等造成的拓扑结构服务监测功能完全丢失,确保能够持续对拓扑结构提供监测服务。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其它相关的附图。
图1为监测服务集群***中服务状态的一种示意性应用场景图;
图2为本申请实施例提供的服务器的一种示意性结构框图;
图3为本申请实施例提供的服务监控方法的一种示意性应用场景图;
图4为本申请一实施例提供的服务监控方法的一种示意性流程图;
图5为图4中S201的子步骤的一种示意性流程图;
图6为图4中S201的子步骤的另一种示意性流程图;
图7为图4中S203的子步骤的一种示意性流程图;
图8为图7中S203-2的子步骤的一种示意性流程图;
图9为本申请实施例提供的服务监控方法的另一种示意性流程图;
图10为本申请实施例提供的服务节点的一种示意性结构图。
图中:100-服务器;101-存储器;102-处理器;103-通信接口;300-服务节点;301-判断模块;302-处理模块。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。
因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本申请的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
请参阅图1,图1为监测服务集群***中服务状态的一种示意性应用场景图,目前针对多个服务构成的服务集群***一般采用如图1所示的监测方案执行,即部署独立的用于进行服务状态监测的监测服务,统一对服务集群***中的所有服务进行监测;服务集群***中的每个服务均向监测服务上报心跳信息,若某个服务上报给监测服务的心跳信息出现异常,则监测服务确定该心跳信息异常所对应的服务出现异常,并产生告警信息,以提醒维护人员进行处理。
但对于如图1所示的监测方案,由于服务集群***中的每个服务均依靠该监测服务进行心跳监测,若该监测服务自身出现故障,则可能导致该服务集群***的监测功能丢失,对所有服务均不能再提供监测服务,即存在单点故障的缺陷。
因此,基于上述缺陷,本申请实施例提供的一种可能的实现方式为:通过预先在多个服务构成的拓扑结构所包含的所有服务中,建立每个服务与其他至少一个服务的对应关系,且每个服务接收该服务对应的其他服务发送的心跳信息,并通过判断心跳信息的接收情况是否异常,对该服务所对应的其他服务进行异常检测;即使某个服务出现异常,也仅会影响与出现异常的服务具有对应关系的服务的监测功能丢失,但不会导致整个拓扑结构的监测功能丢失,从而改善了现有技术中因中心化的监测服务出现单点故障导致无法对其他服务进行监测的问题。
下面结合附图,对本申请的一些实施方式作详细说明。在不冲突的情况下,下述的实施例及实施例中的特征可以相互组合。
请参阅图2,图2为本申请实施例提供的服务器100的一种示意性结构框图。服务器100包括存储器101、处理器102和通信接口103,该存储器101、处理器102和通信接口103相互之间直接或间接地电性连接,以实现数据的传输或交互,例如,这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。
存储器101可用于存储软件程序及模块,如本申请实施例提供的服务节点300对应的程序指令/模块,处理器102通过执行存储在存储器101内的软件程序及模块,从而执行各种功能应用以及数据处理,以实现本申请实施例提供的服务监控方法。该通信接口103可用于服务器100与其他节点设备进行信令或数据的通信。
其中,存储器101可以是但不限于,随机存取存储器(Random Access Memory,RAM),只读存储器(Read Only Memory,ROM),可编程只读存储器(Programmable Read-OnlyMemory,PROM),可擦除只读存储器(Erasable Programmable Read-Only Memory,EPROM),电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory,EEPROM)等。
处理器102可以是一种集成电路芯片,具有信号处理能力。该处理器102可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(NetworkProcessor,NP)等;还可以是数字信号处理器(Digital Signal Processing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
可以理解,图2所示的结构仅为示意,服务器100还可以包括比图2中所示更多或者更少的组件,或者具有与图2所示不同的配置。图2中所示的各组件可以采用硬件、软件或其组合实现。
请参阅图3,图3为本申请实施例提供的服务监控方法的一种示意性应用场景图,本申请实施例提供的服务监控方法应用于运行第一服务的服务节点,比如可以将图3中的服务C作为第一服务,该第一服务与多个其他服务共同构成拓扑结构,且该拓扑结构包括的每个服务与其他至少一个服务建立有对应关系,每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测。
其中,值得说明的是,图3仅为示意,将属于同一服务集群***的多个服务共同构成拓扑结构;在本申请实施例其他一些可能的实现方式中,共同构成拓扑结构的多个服务还可以不属于同一服务集群***,比如在如图3所示的应用场景中,服务A、服务B、服务C、服务D及服务E共同构成拓扑结构,服务A、服务B及服务C属于同一服务集群***,而服务D与服务E属于另一服务集群***。
并且,作为一种可能的实现方式,该拓扑结构中的每个服务与其他至少一个服务建立的对应关系可以是单向的,比如在图3所示的应用场景中,该对应关系中服务A与服务E建立有对应关系,服务B与服务A建立有对应关系,服务C与服务B建立有对应关系,服务D与服务C建立有对应关系,服务E与服务D建立有对应关系,即该对应关系中每个服务与其他至少一个服务建立的对应关系是单向的,服务A对服务E进行异常检测,服务E对服务D进行异常检测,服务D对服务C进行异常检测,服务C对服务B进行异常检测,服务B对服务A进行异常检测。
但在其他一些可能的应用场景中,每个服务与其他服务建立的对应关系还可以是双向的,比如基于如图3所示的应用场景,该对应关系中服务C与服务E建立的对应关系可以是双向的,服务C用于接收服务E发送的心跳信息,以对服务E进行异常检测;服务E也用于接收服务C发送的心跳信息,以对服务C进行异常检测。
另外,需要说明的是,如图3所示的拓扑结构包含的所有服务,可以是位于同一个服务节点中,也可以是位于不同的服务节点中;比如在如图3所示的应用场景中,以服务C作为第一服务为例,服务C可以与其他的服务(比如服务A、服务B、服务D或服务E)运行于相同的服务节点,也可以运行于不同的服务节点;比如图3中的每个服务可以各自运行在不同的服务节点中,将运行有该拓扑结构中包含的至少一个服务的所有服务节点构成服务***,为用户提供服务。
本申请实施例对拓扑结构中的各个服务是否位于同一服务节点不做任何限制,这取决于具体的应用场景而定,只要第一服务与多个其他服务能够构成拓扑结构即可。
并且,该拓扑结构包含的所有服务中每个服务与其他至少一个服务建立的对应关系,可以通过设定的***程序实现;比如图3所示的服务集群***在被搭建、该服务集群***被启动或者是该服务集群***在更新时,由该***程序将每个服务与其他至少一个服务建立对应关系,从而形成拓扑结构。
基于如图3所示的应用场景,请参阅图4,图4为本申请一实施例提供的服务监控方法的一种示意性流程图,包括以下步骤:
S201,第一服务判断心跳信息的接收情况是否异常;若正常,执行S202;若异常,执行S203;
S202,第一服务确定第一服务对应的其他服务中未出现异常的服务;
S203,第一服务判断第一服务对应的其他服务中是否出现异常的服务。
在本申请实施例中,第一服务按照对应关系,接收对应关系中与第一服务对应的其他至少一个服务发送的心跳信息,第一服务通过判断心跳信息的接收情况是否异常,从而判断与第一服务对应的其他服务是否出现服务异常。
其中,若第一服务判定心跳信息的接收情况出现异常,则第一服务需要进一步判断第一服务对应的其他服务中是否出现异常的服务;若第一服务判定心跳信息的接收情况正常,则第一服务确定第一服务对应的其他服务中未出现异常的服务,此时第一服务还可以对第一服务对应的其他服务的工作状态进行记录,以表征第一服务监测确定与第一服务对应的其他服务此刻处于正常的工作状态。
比如,以图3中服务C作为第一服务为例,假定***程序建立的对应关系中与服务C对应的服务为服务B;若服务C判定心跳信息的接收情况正常时,则表征服务B的工作状态正常;若服务C判定心跳信息的接收情况异常时,则表征服务B的工作状态可能出现异常。
值得说明的是,上述示例为便于描述,直接采用服务C与服务B两者之间建立有用于异常检测的对应关系进行举例,在本申请实施例其他一些可能的应用场景中,服务C在接收心跳信息时,还可能无需关注发送该心跳信息的具体对象,当服务C判定心跳信息的接收情况正常时,直接记录用于表征与第一服务对应的其他服务的工作状态处于正常的标识信息即可;比如上述示例中,服务C直接记录用于表征该对应关系中与服务C对应的服务的工作状态处于正常的第一指示信息即可,而无需具体记录服务B正常;在服务C判定心跳信息的接收情况异常时,同样只需要记录用于表征该对应关系中与服务C对应的服务的工作状态处于异常的第二指示信息即可。
并且,在本申请其他一些可能的应用场景中,服务C在判断心跳信息的接收情况是否异常时,也可以通过查询该对应关系的方式,确定出服务C在该对应关系中对应的是服务B,从而直接判断服务B是否异常。
可见,本申请实施例提供的上述方案,通过预先在多个服务构成的拓扑结构所包含的所有服务中,建立每个服务与其他至少一个服务的对应关系,且每个服务接收该服务对应的其他服务发送的心跳信息,并通过判断心跳信息的接收情况是否异常,对该服务所对应的其他服务进行异常检测;即使某个服务出现异常,也仅会影响与出现异常的服务具有对应关系的服务的监测功能丢失,但不会导致整个拓扑结构的监测功能丢失。
基于上述设计,本申请实施例提供的一种服务监控方法,通过由包括第一服务在内的多个服务共同构成拓扑结构,并将拓扑结构中包含的每个服务与其他至少一个服务建立对应关系,从而使拓扑结构中的各个服务,能够通过判断心跳信息的接收情况是否异常,确定出与该对应关系中与每一服务各自对应的服务是否可能出现异常的服务,从而实现对多个服务工作状态的监测,相比于现有技术,使得由多个服务构成的拓扑结构的监测功能无需由独立的监测服务提供,而是由拓扑结构中的每一服务对拓扑结构中与该服务对应的其他服务进行监测,从而避免了独立的监测服务出现单点故障等造成的拓扑结构服务监测功能完全丢失,确保能够持续对拓扑结构提供监测服务。
需要说明的是,由多个服务共同构成的该拓扑结构可以由多种形式实现。
可选地,作为一种可能的实现方式,第一服务与多个其他服务共同构成的拓扑结构可以为例如图3所示的环状拓扑结构,该环状拓扑结构中每一服务和沿环状拓扑结构中第一方向相邻的上一服务组成对应关系。比如在图3所示的应用场景中,以逆时针方向作为第一方向为例,服务A与服务E建立对应关系,服务B与服务A建立对应关系,服务C与服务B建立对应关系,服务D与服务C建立对应关系,服务E与服务D建立对应关系,从而使A、B、C、D、E依次相连形成环状的拓扑结构;在该环状拓扑结构中,以逆时针方向为正方向示例,服务A的下一服务为服务B、服务B的下一服务为服务C、服务C的下一服务为服务D、服务D的下一服务为服务E、服务E的下一服务为服务A,则按照上述对应关系的监测策略,服务B对服务A进行监测、服务C对服务B进行监测、服务D对服务C进行监测、服务E对服务D进行监测、服务A对服务E进行监测。
并且,作为一种可能的实现方式,***程序在形成该拓扑结构时,***程序可以设定心跳监测周期,即每隔设定的周期T,拓扑结构中的每一服务均向在对应关系中对应的服务发送心跳信息;同理,则每一服务同样按照该设定的周期T,在设定的心跳检测时间点接收各自在对应关系中对应的服务所发送的心跳信息;比如在如图3所示的应用场景中,服务B按照设定的周期T向服务C发送心跳信息,同理,服务C按照设定的周期T接收服务B发送的心跳信息。
其中,需要说明的是,上述设定的周期T,可以基于拓扑结构中各个服务产生业务数据的周期设置,比如在如图3所示的应用场景中,假定服务A每分钟产生一条业务数据,服务B与服务C每五分钟进行一次业务数据交互,服务A与服务D每10分钟进行一次业务数据交互,且服务E每3分钟产生一条业务数据,则该设定的周期T可以设置按照小于或等于1分钟的规则进行设置,比如该设定的周期T可以设置为30秒、或者是45秒等等,只要该设定的周期T能够小于或等于拓扑结构中任一服务产生业务数据或者是进行业务数据交互的时间间隔即可。
可选地,请参阅图5,图5为图4中S201的子步骤的一种示意性流程图,作为一种可能的实现方式,在实现S201时,可以包括以下子步骤:
S201-1,第一服务判断在设定的心跳检测时间点是否接收到沿环状拓扑结构中第一方向上与第一服务相邻的上一服务发送的心跳信息;若接收到,则执行S201-2;若未接收到,则执行S201-3;
S201-2,第一服务判定心跳信息的接收情况正常;
S201-3,第一服务判定心跳信息的接收情况出现异常。
基于图3所示的环状拓扑结构,该环状拓扑结构中的每一服务和沿环状拓扑结构中第一方向上相邻的上一服务组成该对应关系,相对地,则每一服务和沿环状拓扑结构中第一方向上相邻的下一服务发送心跳信息;因此,以第一服务为例,第一服务按照设定的周期T,在设定的心跳检测时间点判断是否接收到对应关系中第一方向上与第一服务相邻的上一服务发送的心跳信息,若接收到,则第一服务判定心跳信息的接收情况正常;若未接收到,则第一服务判定心跳信息的接收情况出现异常。
另外,若第一服务判定心跳信息的接收情况出现异常,则在执行S203时,第一服务判定沿环状拓扑结构中第一方向上与第一服务相邻的上一服务出现异常。比如在如图3所示的应用场景中,以服务C作为第一服务、逆时针方向作为第一方向为例,则在该应用场景下,该环状拓扑结构中沿逆时针方向上与服务C相邻的上一服务为服务B;若服务C按照设定的心跳检测时间点接收到服务B发送的心跳信息,则服务C判定服务B的工作状态正常;若服务C按照设定的心跳检测时间点未接收到服务B发送的心跳信息,则服务C判定服务B的工作状态出现异常。
可见,基于上述设计,本申请实施例提供的一种服务监控方法,通过将拓扑结构设置为环状,并使该环状拓扑结构中每一服务均与该环状拓扑结构中沿第一方向相邻的上一服务组成对应关系,从而使该环状拓扑结构中的每一服务均对该环状拓扑结构中沿第一方向相邻的上一服务进行监测,能够简化服务监测时的数据量,降低冗余。
值得说明的是,上述实现方式仅为示意,在本申请实施例其他一些可能的应用场景中,拓扑结构可以设置为其他形式,比如将服务A、服务B、服务C、服务D和服务E任意两两服务间均建立对应关系,从而使拓扑结构以网状的形式呈现;或者是将服务A、服务B、服务C、服务D和服务E依次建立双向的对应关系,从而使拓扑结构以链状的形式呈现;本申请实施例对拓扑结构的形式不进行限定,只要第一服务与多个其他服务共同构成拓扑结构,且该拓扑结构中的每个服务与其他至少一个服务建立有对应关系即可。
在一些可能的应用场景中,第一服务在该对应关系中可能对应有多个服务,在该应用场景下,第一服务需要接收该拓扑结构中多个服务发送的心跳信息。比如在如图3所示的应用场景中,以服务C作为第一服务进行示例性说明,假定服务C与服务B建立有对应关系,且服务C与服务E两者间存在业务数据交互;为确保服务C与服务E构成的服务单元能够稳定的为用户提供服务,可以在服务C与服务E存在业务数据交互的基础上,将服务C与服务E同样建立用于服务异常检测的对应关系;则在该应用场景下,服务C不仅需要接收服务B发送的心跳信息,服务C同样需要接收服务E发送的心跳信息。
在此基础之上,请参阅图6,图6为图4中S201的子步骤的另一种示意性流程图,基于前述应用场景,作为另一种可能的实现方式,S201还可以包括以下子步骤:
S201-5,第一服务判断在设定的心跳检测时间点接收到的心跳信息的数量与设定数值是否相同;若相同,则执行S201-6;若不相同,则执行S201-7;
S201-6,第一服务确定心跳信息的接收情况正常;
S201-7,第一服务确定心跳信息的接收情况出现异常。
作为一种可能的实现方式,***程序在建立或者是更新如图3所示的拓扑结构时,***程序可以根据建立的对应关系,为该拓扑结构中的每一服务下发一设定数值,该设定数值为每一服务在设定的心跳监测时间点需要接收到的各自对应服务发送的心跳信息的数量。比如在前述应用场景中,以服务C作为第一服务为例,***程序为服务C与服务B建立有对应关系,且为服务C与服务E建立有对应关系,示例性地,***程序为服务C下发的设定数值为2,表征服务C需要在设定的心跳监测时间点需要接收到2条心跳信息。因此,在执行S201时,第一服务可以根据在设定的心跳监测时间点所接收到的心跳信息的数量,与设定数值进行比较;若两者相同,则第一服务确定心跳信息的接收情况正常;反之,若两者不同,则第一服务确定心跳信息的接收情况出现异常。以服务C作为第一服务、且***程序为服务C下发的设定数值为2为例进行说明,若服务C在设定的心跳监测时间点接收到2条心跳信息,与下发给服务C的设定数值2相同,则服务C确定心跳信息的接收情况正常;若服务C在设定的心跳监测时间点接收到0条心跳信息(即没有接收到心跳信息)或1条心跳信息,与下发给服务C的设定数值2不相同,则服务C确定心跳信息的接收情况出现异常。
值得说明的是,上述仅为示例,可以将第一服务与存在业务数据交互的其他服务建立该对应关系,本申请实施例对建立该对应关系的条件并不进行限定,比如在如图3所示的应用场景中,假定服务C与服务A两者并不存在业务数据交互,但仍然可以建立服务C与服务A两者间建立该对应关系,这取决于具体的应用场景或者是用户的具体配置而定。
另外,在例如图3所示应用场景中,以服务C作为第一服务、且服务C与服务B和服务E均建立有对应关系为例,若服务C确定心跳信息的接收情况出现异常,则可能存在三种情况:服务B发送给服务C的心跳信息出现异常、服务E发送给服务C的心跳信息出现异常、服务B发送给服务C的心跳信息与服务E发送给服务C的心跳信息均出现异常。
但在前述示例中,服务C和服务B两者的关系与服务C和服务B两者的关系是不尽相同的,服务C与服务B建立对应关系是基于***程序在建立该拓扑结构时,在服务C与服务B之间建立该对应关系;而服务C与服务E是基于两者相互间可能存在业务数据交互,为确保服务C与服务E均能够正常工作,进而在服务C与服务E两者间建立的该对应关系,以使服务C与服务E相互间能够判断对方的工作状态是否处于正常。
因此,作为一种可能的实现方式,本申请实施例将每个服务与其对应的其他任一服务建立的对应关系分为第一类对应关系或第二类对应关系,且该拓扑结构包含的所有服务中每个服务与对应的其他服务中的一个服务建立第一类对应关系;其中,对于第一类对应关系,每一服务能够对与该服务建立第一类对应关系的服务是否异常进行直接判断;而对于第二类对应关系,每一服务则是对该与服务建立第二类对应关系的服务是否异常进行辅助判断。比如在前述示例中,服务C与服务B建立的对应关系为第一类对应关系,服务C与服务E建立的对应关系为第二类对应关系,则服务C能够对服务B的工作状态是否异常进行直接判断,但服务C对服务E的工作状态是否异常则进行辅助判断。
其中,需要说明的是,直接判断是指一个服务能够根据是否接收到该服务对应的服务发送的心跳信息,直接判断该服务对应的服务是否工作异常,而辅助判断是指一个服务根据是否接收到该服务对应的服务发送的心跳信息,只能判断对应的服务为是否疑似出现异常。
比如在上述示例中,服务C与服务B建立的对应关系为第一类对应关系,则若服务C接收到服务B发送的心跳信息,则可以直接确定服务B工作正常,若没有接收到服务B发送的心跳信息,则可以直接确定服务B工作异常;而服务C与服务E建立的对应关系为第二类对应关系,若服务C接收到服务E发送的心跳信息,则服务C确定服务E处于正常工作的状态,若服务C未接收到服务E发送的心跳信息,则服务C确定服务E疑似出现异常,需要进一步判断服务E是否工作异常。
基于上述实施例,接下来对判断第一服务对应的其他服务中是否出现异常的服务的具体过程进行说明,请参阅图7,图7为图4中S203的子步骤的一种示意性流程图,作为一种可能的实现方式,S203可以包括以下子步骤:
S203-1,第一服务确定在设定的心跳检测时间点接收到的心跳信息与设定心跳信息相比缺省的目标心跳信息;
S203-2,第一服务根据目标心跳信息,判断需要发送目标心跳信息的服务是否为与第一服务建立第一类对应关系的服务;若为是,则执行S203-3;若为否,则执行S203-4;
S203-3,第一服务确定与第一服务建立第一类对应关系的服务出现异常;
S203-4,第一服务确定与第一服务建立第一类对应关系的服务未出现异常。
在本申请实施例中,第一服务在对第一类对应关系和第二类对应关系中与第一服务对应的所有服务进行监测时,每当第一服务按照设定的周期T,判定在设定的心跳检测时间点心跳信息的接收情况正常时,第一服务可以将该时间点接收到的心跳信息进行记录,进而将该记录的心跳信息作为设定心跳信息,以用于下一次判断心跳信息的接收情况出现异常时,确定出心跳异常的服务,其中,该设定心跳信息包括第一服务在设定的心跳检测时间点需要接收的所有心跳信息。
值得说明的是,由于心跳检测的服务一般是周期性的,则每当第一服务判定心跳信息的接收情况正常时,作为一种可能的实现方式,可以采用以当前时刻接收到的心跳信息将上一次接收到的正常的心跳信息进行覆盖的方式,确保第一服务在整个心跳检测的过程中,第一服务始终记录的设定心跳信息为最新接收的正常的心跳信息。
另外,在本申请实施例其他一些可能的应用场景中,还可以不覆盖上一次接收的正常的心跳信息,而采用为每一次接收的正常的心跳信息添加时间戳或者是按照时间先后顺序添加顺序编号的方式,将每一次确定为正常的心跳信息记录为设定心跳信息;只要第一服务能够在判断心跳信息的接收情况是否异常时,能够获得设定心跳信息作为标准,以获得缺省的目标心跳信息即可;此外,在本申请其他一些可能的应用场景中,还可以通过***程序指定的方式,即***程序在初始化该拓扑结构时,直接将生成的设定心跳信息发送给第一服务,以使第一服务根据该接收的设定心跳信息,获取接收到的心跳信息与该设定心跳信息相比缺省的目标心跳信息。
由此,在执行S203时,第一服务将该设定的心跳检测时间点接收到的心跳信息与该设定心跳信息相比,获取接收到的心跳信息相比于设定心跳信息中缺省的目标心跳信息。其中,该设定心跳信息可以是上述示例中,第一服务通过不断覆盖更新的方式记录的心跳信息,也可以是根据时间戳确定的最新记录的心跳信息,或者是根据顺序编号所确定的编号最大的心跳信息;另外,第一服务获得的缺省的目标心跳信息,表征的是第一服务在该设定的心跳检测时间点接收到的心跳信息中所缺少的心跳信息。
比如,以上述服务C作为第一服务为例,若服务C记录的设定心跳信息包括{“flag”:[1,0]}和{“E”:urlA},且服务C在该设定的心跳检测时间点接收到的心跳信息为{“E”:urlA},则服务C确定出的缺省的目标心跳信息为{“flag”:[1,0]};或者,若服务C在该设定的心跳检测时间点接收到的心跳信息为{“flag”:[1,0]},则服务C确定出的缺省的目标心跳信息为{“E”:urlA}。
第一服务基于所获得的目标心跳信息,判断需要发送该目标心跳信息的服务是否为与第一服务建立第一类对应关系的服务;若为是,则第一服务确定与第一服务建立第一类对应关系的服务出现异常;若为否,则第一服务确定与第一服务建立第一类对应关系的服务未出现异常。
其中,为实现上述S203-2,可选地,请参阅图8,图8为图7中S203-2的子步骤的一种示意性流程图,作为一种可能的实现方式,S203-2可以包括以下子步骤:
S203-2a,第一服务判断目标心跳信息中是否包含用于表征第一类对应关系的第一标识信息;若包含有,则执行S203-2b;若不包含有,则执行S203-2c。
S203-2b,第一服务确定需要发送目标心跳信息的服务为与第一服务建立第一类对应关系的服务;
S203-2c,第一服务确定需要发送目标心跳信息的服务不为与第一服务建立第一类对应关系的服务。
在本申请实施例中,可以通过设置表征第一类对应关系的第一标识信息,以使该拓扑结构中的每一服务在接收到对应的其他服务发送的心跳信息时,可以利用该第一标识信息,确定发送该心跳信息的服务是否为与该服务建立第一类对应关系的服务。
因此,第一服务对于确定出的缺省的目标心跳信息,判断该目标心跳信息中是否包含有第一标识信息;若包含有,则第一服务确定需要发送目标心跳信息的服务为与第一服务建立第一类对应关系的服务,从而确定与第一服务建立第一类对应关系的服务出现异常;若不包含,则第一服务确定需要发送目标心跳信息的服务不为与第一服务建立第一类对应关系的服务,从而可以确定与第一服务建立第一类对应关系的服务未出现异常。
比如在上述示例中,结合图3所示,以服务C作为第一服务、服务B为与服务C建立第一类对应关系的服务为例,且假定第一标识信息为“flag”;若服务C确定出的目标心跳信息为{“flag”:[1,0]},包含第一标识信息“flag”,即表征需要发送该目标心跳信息的服务为与服务C建立第一类对应关系的服务出现异常,即服务B出现异常;若服务C确定出的目标心跳信息为{“E”:urlA},不包含第一标识信息“flag”,即表征需要发送目标心跳信息的服务不为与服务C建立第一类对应关系的服务,即服务B未出现异常。
另外,在例如图1所示的监测方案中,监测服务作为中心化监测机构,一般需要对多个不同的服务集群***进行监测,即对来自于多个不同服务集群***的大量服务进行心跳监测,而不同的服务本身往往具有不同的功能,导致若某个服务出现故障,监测服务只能记录并告警给维护人员,以使维护人员对出现故障的服务进行处理,比如由维护人员对出现故障的服务进行重启或者是移除服务集群***等等。
因此,为减少维护人员的操作,节约人力资源,请参阅图9,图9为本申请实施例提供的服务监控方法的另一种示意性流程图,若执行S203后第一服务确定与第一服务建立第一类对应关系的服务出现异常,比如上述示例中服务C判定服务B出现异常时,则该服务监控方法还包括以下步骤:
S204,第一服务判断与第一服务建立第一类对应关系的服务是否与拓扑结构中的其他服务建立有第二类对应关系;若建立有,则执行S205;若未建立有,则执行S206;
S205,第一服务将目标心跳信息中用于指示工作状态的标识信息更新为异常标识,以更新设定心跳信息;
S206,第一服务判断与第一服务建立第一类对应关系的服务是否被卸载;若被卸载,则执行S207;若未被卸载,则执行S209;
S207,第一服务指示在拓扑结构中移除与第一服务建立第一类对应关系的服务并基于剩余的服务重构拓扑结构;
S208,第一服务将目标心跳信息从设定心跳信息中移除;
S209,第一服务指示重启与第一服务建立第一类对应关系的服务,并将目标心跳信息中用于指示工作状态的标识信息更新为重启标识,以更新设定心跳信息。
在本申请实施例中,若第一服务判断与第一服务建立有第一类对应关系的服务与该拓扑结构中的其他服务建立有第二类对应关系,则表征第一服务仅用于对与第一服务建立第一类对应关系的服务的工作状态进行记录,则此时第一服务将目标心跳信息中用于指示工作状态的标识信息更新为异常标识,从而更新该设定心跳信息,以指示与第一服务建立有第一类对应关系的服务出现异常。
反之,若第一服务确定与第一服务建立第一类对应关系的服务未与该拓扑结构中的其他服务建立第二类对应关系,则第一服务需要对与第一服务建立第一类对应关系的服务进行维护操作,即:若第一服务确定与第一服务建立第一类对应关系的服务已经被卸载,则第一服务指示在该拓扑结构中移除与第一服务建立第一类对应关系的服务,并基于剩余的服务重构拓扑结构,且将目标心跳信息从设定心跳信息中移除;若第一服务确定与第一服务建立第一类对应关系的服务未被卸载,则第一服务指示重启与第一服务建立第一类对应关系的服务,并将目标心跳信息中用于指示工作状态的标识信息更新为重启标识,以更新该设定心跳信息,从而指示该拓扑结构中与第一服务建立第一类对应关系的服务正在重启。
值得说明的是,作为一种可能的实现方式,上述S206在实现时,第一服务可通过调用***程序实现。比如,***程序实时记录拓扑结构中每一服务的状态,比如异常、正常、被卸载等等,第一服务可直接查询该***程序以判断与第一服务建立第一类对应关系的服务是否已被卸载。
另外,可以由***程序负责维护该拓扑结构,比如初始化拓扑结构、重启服务、将服务加入该拓扑结构、以及将服务从该拓扑结构中移除等等,第一服务在指示从拓扑结构中移除与第一服务建立第一类对应关系的服务时,也可以通过调用***程序实现;当然,可以理解的是,在本申请实施例其他一些可能的实现方式中,在拓扑结构中移除与第一服务建立第一类对应关系的服务的操作,也可以通过预先在第一服务中植入设定的拓扑更新程序,以实现在拓扑结构中移除与第一服务建立第一类对应关系的服务,更新该拓扑结构,只要能够在该拓扑结构中实现移除与第一服务建立第一类对应关系的服务,并能够基于剩余的服务重构拓扑结构即可。
同样地,在实现第一服务指示重启与第一服务建立第一类对应关系的服务时,也可以由第一服务调用***程序实现;同样可以理解的是,在本申请实施例其他一些可能的实现方式中,还可以通过预先在第一服务中植入设定的重启指示程序,进而由第一服务自行重启与第一服务建立第一类对应关系的服务,本申请实施例每一服务指示其他服务重启的操作方式不做限定;比如说,还可以为:每一服务预先设置有可以用于自行重启的重启程序,第一服务在确定与第一服务建立第一类对应关系的服务未被卸载时,可以通过向与第一服务建立第一类对应关系的服务中设置的重启程序发送激活指令的方式,以使与第一服务建立第一类对应关系的服务自行重启。
示例性地,假定第一服务记录第一类对应关系中与第一服务对应的服务的正常心跳信息的格式为{“flag”:[x,y]};该格式中,“flag”为第一标识信息;x为工作状态标识,“x”的值用于指示该服务的工作状态,比如可以用0表示故障(即第一服务未接收到与第一服务建立第一类对应关系的服务发送的心跳信息)、1表示正常(即第一服务接收到与第一服务建立第一类对应关系的服务发送的心跳信息)、2表示重启(即与第一服务建立第一类对应关系的服务正在重启);y为同步状态标识,“y”的值用于指示该服务是否与拓扑结构中的其他服务建立有第二类对应关系,比如可以用0表示与其他服务未建立有第二类对应关系、1表示与其他服务建立有第二类对应关系。
则按照上述示例并结合图3所示的应用场景,假定服务C为第一服务,服务B为第一类对应关系中与服务C对应的服务。若服务C获得的目标心跳信息为{“flag”:[1,0]},则根据该目标心跳信息{“flag”:[1,0]}中包含的第一标识信息“flag”,服务C确定出现异常的服务为服务B;并根据“[1,0]”中第二位的0,确定服务B与其他服务未建立有第二类对应关系,则服务C调用***程序判断服务B是否被卸载;若服务C确定服务B已被卸载,则调用***程序将服务B从拓扑结构中移除,并基于剩余的服务A、服务C、服务D及服务E重新构建拓扑结构,且将{“flag”:[1,0]}从服务C记录的设定心跳信息移除;若服务C确定服务B未被卸载,则指示重启服务B,比如调用***程序以重启服务B,并将目标心跳信息中的“1”更新为“2”,2即为重启标识,即目标心跳信息更新为{“flag”:[2,0]},表示服务B正在重启。
值得说明的是,在上述示例中,对于服务C记录的目标心跳信息{“flag”:[1,0]},该目标心跳信息中的1可以是由服务C记录,而该目标心跳信息中的0则由服务B记录;即服务C在正常接收到服务B发送的心跳信息时,服务C接收到的心跳信息内容可以为{“flag”:[x,0]},其中,x为未知量(或者也可以为已知量,比如默认为1),当服务C判定接收服务B的心跳信息正常时,服务C将x更新为1,即服务C记录的设定心跳信息更新为{“flag”:[1,0]};若服务C判定接收服务B的心跳信息异常,则服务C未能正常接收到服务B发送的心跳信息,则服务C将目标心跳信息中的“1”更新为“0”,即记录服务B的心跳信息为{“flag”:[0,0]},表征服务B故障;若服务C判定接收服务B正在重启,则服务C将目标心跳信息中的“1”更新为“2”,即记录服务B的心跳信息为{“flag”:[2,0]},表征服务B正在重启。
另外,在前述示例中,若服务C获得的目标心跳信息为{“flag”:[1,1]},表示服务B与其他服务建立有第二类对应关系,则服务C直接记录服务B的心跳信息为{“flag”:[0,1]},表示服务B已经故障。
另一方面,请继续参阅图9,若第一服务判定需要发送目标心跳信息的服务不是与第一服务建立第一类对应关系的服务,则该服务监控方法还包括以下步骤:
S210,第一服务根据目标心跳信息中包含的第二标识信息,确定需要发送目标心跳信息的服务为疑似异常的服务,以及确定与疑似异常的服务建立有第一类对应关系的第二服务;
S211,第一服务向第二服务查询疑似异常的服务的工作状态;若第一服务查询到疑似异常的服务正常或正在重启,则执行S212;若第一服务查询到疑似异常的服务工作异常,则执行S213;
S212,第一服务等待接收疑似异常的服务在设定的心跳检测时间点的下一心跳检测时间点发送的心跳信息;
S213,第一服务判断疑似异常的服务是否被卸载;若被卸载,则执行S214;若未被卸载,则执行S215;
S214,第一服务指示将疑似异常的服务从拓扑结构中移除并基于剩余的服务重构拓扑结构;
S208,第一服务将目标心跳信息从设定心跳信息中移除;
S215,第一服务指示重启疑似异常的服务,并向第二服务发送重启记录指令,以使第二服务将疑似异常的服务正在重启的情况进行记录。
在本申请实施例中,建立第二类对应关系的两个服务间所发送的心跳信息中包含有第二标识信息,该第二标识信息用于指示与发送该心跳信息的服务建立有第一类对应关系的服务;比如,假定建立第二类对应关系的两个服务间所发送的心跳信息为{“E”:urlA},则表示发送该心跳信息的服务为服务E,第二标识信息为“urlA”,urlA(查询地址)表示与发送该心跳信息的服务E建立有第一类对应关系的服务为服务A。因此,若第一服务判定需要发送目标心跳信息的服务不为与第一服务建立第一类对应关系的服务,则第一服务根据目标心跳信息中包含的第二标识信息,确定需要发送该目标心跳信息的服务为疑似异常的服务,以及确定与该异常的服务建立有第一类对应关系的第二服务;比如在上述示例中,若以服务C作为第一服务,假定服务C确定的目标心跳信息为{“E”:urlA},则服务C确定服务E为疑似异常的服务,且与服务E建立第一类对应关系的服务A为第二服务。
在此基础之上,第一服务可以向第二服务查询该疑似异常的服务的工作状态;一方面,若第二服务查询到该疑似异常的服务正常或正在重启,则第一服务等待该疑似异常的服务在该设定的心跳检测时间点的下一心跳检测时间点发送的心跳信息发送的心跳信息。
另一方面,若第二服务查询到该疑似异常的服务的异常,则第一服务进一步判断该疑似异常的服务是否被卸载,若第一服务确定该疑似异常的服务已被卸载,则第一服务确定未接收到该疑似异常的服务发送的心跳信息是由于该疑似异常的服务已被卸载,不再属于该拓扑结构,第一服务则指示在该拓扑结构中移除该疑似异常的服务,并基于剩余的服务重构拓扑结构;反之,若第一确定该疑似异常的服务未被卸载,则第一服务确定未接收到该疑似异常的服务发送的心跳信息是由于该疑似异常的服务出现了异常,此时第一服务则指示重启该疑似异常的服务,并向第二服务发送重启记录指令,以使第二服务将该疑似异常的服务正在重启的情况进行记录。
比如在上述以服务C作为第一服务的示例中,若服务C确定出的目标心跳信息为{“E”:urlA},则表示与服务E(疑似异常的服务)组成第一类对应关系的是服务A(第二服务),服务C即向服务A查询服务E的工作状态;若服务C查询到服务E的工作状态为{“flag”:[1,1]}或{“flag”:[2,1]},则表示服务E正常或正在重启,此时服务C等待接收服务E在该设定的心跳检测时间点的下一心跳检测时间点发送的心跳信息;若服务C查询到服务E的工作状态为{“flag”:[0,1]},则表示服务E工作异常,服务C调用***程序判断服务E是否被卸载;若服务C确定服务E已被卸载,则服务C指示在拓扑结构中移除服务E,由剩余的服务A、服务B、服务C及服务D重新构建拓扑结构,比如调用***程序在拓扑结构中移除服务E;若服务C确定服务E未被卸载,则服务C指示重启服务E,以自动处理处于异常工作状态的服务E,并向服务A发送重启记录指令,以指示服务A将服务E正在重启的状态进行记录,比如服务A记录的服务E的工作状态更新为{“flag”:[2,1]}。
需要说明的是,作为一种可能的实现方式,第一服务向第二服务查询该疑似异常的服务的工作状态的方式,可以采用第一服务向第二服务发送查询指令的方式,由第二服务直接向第一服务反馈该疑似异常的服务的工作状态的方式实现,或者是,采用第一服务向第二服务获取记录的该疑似异常的服务对应的心跳信息,然后由第一服务解析第二服务反馈的心跳信息实现;本申请实施例对第一服务向第二服务查询该疑似异常的服务的工作状态的方式不进行限定,只要第一服务能够向第二服务查询到该疑似异常的服务的工作状态即可,比如说,第一服务向第二服务查询该疑似异常的服务的工作状态的方式,还可以是第一服务调用第二服务的接口,在第二服务本地解析第二服务所记录的该疑似异常的服务对应的心跳信息,从而获得该疑似异常的服务的工作状态。
基于与本申请实施例提供的上述服务监控方法相同的发明构思,请参阅图10,图10为本申请实施例提供的服务节点300的一种示意性结构图,该服务节点300运行有第一服务,第一服务与多个其他服务共同构成拓扑结构;拓扑结构包含的每个服务与其他至少一个服务建立有对应关系,且每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测;该服务节点300包括判断模块301及处理模块302;其中:
判断模块301用于判断第一服务接收心跳信息的情况是否异常;
处理模块302用于若确定第一服务接收心跳信息的情况出现异常,则判断第一服务对应的其他服务中是否出现异常的服务。
可选地,作为一种可能的实现方式,第一服务对应的其他服务存在多个时,判断模块301在判断第一服务接收心跳信息的情况是否异常时,具体用于:
判断第一服务在设定的心跳检测时间点接收到的心跳信息的数量与设定数值是否相同,其中,设定数值为第一服务在设定的心跳检测时间点需要接收到的心跳信息的数量;
若不同,则确定第一服务接收心跳信息的情况出现异常;
若相同,则确定第一服务接收心跳信息的情况正常。
可选地,作为一种可能的实现方式,每个服务与其对应的其他任一服务建立的对应关系为第一类对应关系或第二类对应关系,其中,拓扑结构包含的所有服务中每个服务与对应的其他服务中的一个服务建立第一类对应关系,每一服务对与该服务建立第一类对应关系的服务是否异常进行直接判断,每一服务对与该服务建立第二类对应关系的服务是否异常进行辅助判断;
处理模块302在判断第一服务对应的其他服务中是否出现异常的服务时,具体用于:
确定第一服务在设定的心跳检测时间点接收到的心跳信息与设定心跳信息相比缺省的目标心跳信息,其中,设定心跳信息包括第一服务在心跳检测时间点需要接收到的所有心跳信息;
根据目标心跳信息,判断需要发送目标心跳信息的服务是否为与第一服务建立第一类对应关系的服务;
若是,则确定与第一服务建立第一类对应关系的服务出现异常。
可选地,作为一种可能的实现方式,处理模块302在根据目标心跳信息,判断需要发送目标心跳信息的服务是否为与第一服务建立第一类对应关系的服务时,具体用于:
判断目标心跳信息中是否包含用于表征第一类对应关系的第一标识信息;
若包含有,则确定需要发送目标心跳信息的服务为与第一服务建立第一类对应关系的服务。
可选地,作为一种可能的实现方式,若确定与第一服务建立第一类对应关系的服务出现异常,则处理模块302还用于:
判断与第一服务建立第一类对应关系的服务是否与拓扑结构中的其他服务建立有第二类对应关系;
若建立有,则将目标心跳信息中用于指示工作状态的标识信息更新为异常标识,以更新设定心跳信息。
可选地,作为一种可能的实现方式,处理模块302还用于:
若与第一服务建立第一类对应关系的服务未与拓扑结构中的其他服务建立有第二类对应关系,则判断与第一服务建立第一类对应关系的服务是否被卸载;
若被卸载,则指示在拓扑结构中移除与第一服务建立第一类对应关系的服务并基于剩余的服务重构拓扑结构;第一服务将目标心跳信息从设定心跳信息中移除;
若未被卸载,则指示重启与第一服务建立第一类对应关系的服务,并将目标心跳信息中用于指示工作状态的标识信息更新为重启标识,以更新设定心跳信息。
可选地,作为一种可能的实现方式,处理模块302还用于:
若判定需要发送目标心跳信息的服务不是与第一服务建立第一类对应关系的服务,则根据目标心跳信息中包含的第二标识信息,确定需要发送目标心跳信息的服务为疑似异常的服务,以及确定与疑似异常的服务建立有第一类对应关系的第二服务,其中,第二标识信息用于指示与疑似异常的服务建立有第一类对应关系的服务为第二服务;
向第二服务查询疑似异常的服务的工作状态;
若查询到疑似异常的服务正常或正在重启,则等待接收疑似异常的服务在设定的心跳检测时间点的下一心跳检测时间点发送的心跳信息;
若查询到疑似异常的服务工作异常,则判断疑似异常的服务是否被卸载;
若被卸载,则指示将疑似异常的服务从拓扑结构中移除并基于剩余的服务重构拓扑结构;将目标心跳信息从设定心跳信息中移除;
若未被卸载,则指示重启疑似异常的服务,并向第二服务发送重启记录指令,以使第二服务将疑似异常的服务正在重启的情况进行记录。
可选地,作为一种可能的实现方式,拓扑结构为环状拓扑结构;在环状拓扑结构中,每一个服务和沿环状拓扑结构中第一方向相邻的上一服务组成对应关系;
判断模块301在判断第一服务接收心跳信息的情况是否异常时,具体用于:
判断在设定的心跳检测时间点是否接收到沿环状拓扑结构中第一方向上与第一服务相邻的上一服务发送的心跳信息;
若接收到,则判定第一服务接收心跳信息的情况正常;
若未接收到,则判定第一服务接收心跳信息的情况出现异常;
若判定第一服务接收心跳信息的情况出现异常,处理模块302判断第一服务对应的其他服务中是否出现异常的服务时,具体用于:
判定沿环状拓扑结构中第一方向上与第一服务相邻的上一服务出现异常。
需要说明的是,服务节点300包括的判断模块301和处理模块302,可以是所属于第一服务的功能模块,比如由服务器100中的处理器102执行第一服务包括的一段程序代码,从而实现上述的服务监控方法;在本申请实施例其他一些可能的实现方式中,服务节点300包括的判断模块301和处理模块302还可以为与第一服务不相关联的功能模块,此时第一服务可以通过调用并执行该判断模块301和处理模块302的方式,实现上述的服务监控方法。
在本申请所提供的实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。
也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。
也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
另外,在本申请实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
综上所述,本申请实施例提供的一种服务监控方法、服务节点、服务器及计算机可读存储介质,通过由包括第一服务在内的多个服务共同构成拓扑结构,并将拓扑结构中包含的每个服务与其他至少一个服务建立对应关系,从而使拓扑结构中的各个服务,能够通过判断心跳信息的接收情况是否异常,确定出与该对应关系中与每一服务各自对应的服务是否可能出现异常的服务,从而实现对多个服务工作状态的监测,相比于现有技术,使得由多个服务构成的拓扑结构的监测功能无需由独立的监测服务提供,而是由拓扑结构中的每一服务对拓扑结构中与该服务对应的其他服务进行监测,从而避免了独立的监测服务出现单点故障等造成的拓扑结构服务监测功能完全丢失,确保能够持续对拓扑结构提供监测服务。
并且,通过将拓扑结构设置为环状,并使该环状拓扑结构中每一服务均与该环状拓扑结构中沿第一方向相邻的上一服务组成对应关系,从而使该环状拓扑结构中的每一服务均对该环状拓扑结构中沿第一方向相邻的上一服务进行监测,能够简化服务监测时的数据量,降低冗余。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
对于本领域技术人员而言,显然本申请不限于上述示范性实施例的细节,而且在不背离本申请的精神或基本特征的情况下,能够以其它的具体形式实现本申请。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本申请的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims (11)

1.一种服务监控方法,其特征在于,应用于运行第一服务的服务节点,所述第一服务与多个其他服务共同构成拓扑结构;
所述拓扑结构包含的每个服务与其他至少一个服务建立有对应关系,且每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测;
所述方法包括:
所述第一服务判断心跳信息的接收情况是否异常;
若确定心跳信息的接收情况出现异常,则所述第一服务判断所述第一服务对应的其他服务中是否出现异常的服务。
2.如权利要求1所述的方法,其特征在于,所述第一服务对应的其他服务存在多个时,所述第一服务判断心跳信息的接收情况是否异常,包括:
所述第一服务判断在设定的心跳检测时间点接收到的心跳信息的数量与设定数值是否相同,其中,所述设定数值为所述第一服务在所述设定的心跳检测时间点需要接收到的心跳信息的数量;
若不同,则所述第一服务确定心跳信息的接收情况出现异常;
若相同,则所述第一服务确定心跳信息的接收情况正常。
3.如权利要求2所述的方法,其特征在于,每个服务与其对应的其他任一服务建立的对应关系为第一类对应关系或第二类对应关系,其中,所述拓扑结构包含的所有服务中每个服务与对应的其他服务中的一个服务建立所述第一类对应关系,每一服务对与该服务建立所述第一类对应关系的服务是否异常进行直接判断,每一服务对与该服务建立所述第二类对应关系的服务是否异常进行辅助判断;
所述第一服务判断所述第一服务对应的其他服务中是否出现异常的服务,包括:
所述第一服务确定在所述设定的心跳检测时间点接收到的心跳信息与设定心跳信息相比缺省的目标心跳信息,其中,所述设定心跳信息包括所述第一服务在所述心跳检测时间点需要接收到的所有心跳信息;
所述第一服务根据所述目标心跳信息,判断需要发送所述目标心跳信息的服务是否为与所述第一服务建立所述第一类对应关系的服务;
若是,则所述第一服务确定与所述第一服务建立所述第一类对应关系的服务出现异常。
4.如权利要求3所述的方法,其特征在于,所述第一服务根据所述目标心跳信息,判断需要发送所述目标心跳信息的服务是否为与所述第一服务建立所述第一类对应关系的服务,包括:
所述第一服务判断所述目标心跳信息中是否包含用于表征所述第一类对应关系的第一标识信息;
若包含有,则所述第一服务确定需要发送所述目标心跳信息的服务为与所述第一服务建立所述第一类对应关系的服务。
5.如权利要求3或4所述的方法,其特征在于,若所述第一服务确定与所述第一服务建立所述第一类对应关系的服务出现异常,则所述方法还包括:
所述第一服务判断与所述第一服务建立所述第一类对应关系的服务是否与所述拓扑结构中的其他服务建立有所述第二类对应关系;
若建立有,则所述第一服务将所述目标心跳信息中用于指示工作状态的标识信息更新为异常标识,以更新所述设定心跳信息。
6.如权利要求5所述的方法,其特征在于,所述方法还包括:
若与所述第一服务建立所述第一类对应关系的服务未与所述拓扑结构中的其他服务建立有所述第二类对应关系,则所述第一服务判断与所述第一服务建立所述第一类对应关系的服务是否被卸载;
若被卸载,则所述第一服务指示在所述拓扑结构中移除与所述第一服务建立所述第一类对应关系的服务并基于剩余的服务重构拓扑结构;所述第一服务将所述目标心跳信息从所述设定心跳信息中移除;
若未被卸载,则所述第一服务指示重启与所述第一服务建立所述第一类对应关系的服务,并将所述目标心跳信息中用于指示工作状态的标识信息更新为重启标识,以更新所述设定心跳信息。
7.如权利要求3或4所述的方法,其特征在于,所述方法还包括:
若所述第一服务判定需要发送所述目标心跳信息的服务不是与所述第一服务建立所述第一类对应关系的服务,则所述第一服务根据所述目标心跳信息中包含的第二标识信息,确定需要发送所述目标心跳信息的服务为疑似异常的服务,以及确定与所述疑似异常的服务建立有所述第一类对应关系的第二服务,其中,所述第二标识信息用于指示与所述疑似异常的服务建立有所述第一类对应关系的服务为所述第二服务;
所述第一服务向所述第二服务查询所述疑似异常的服务的工作状态;
若所述第一服务查询到所述疑似异常的服务正常或正在重启,则所述第一服务等待接收所述疑似异常的服务在所述设定的心跳检测时间点的下一心跳检测时间点发送的心跳信息;
若所述第一服务查询到所述疑似异常的服务工作异常,则所述第一服务判断所述疑似异常的服务是否被卸载;
若被卸载,则所述第一服务指示将所述疑似异常的服务从所述拓扑结构中移除并基于剩余的服务重构拓扑结构;所述第一服务将所述目标心跳信息从所述设定心跳信息中移除;
若未被卸载,则所述第一服务指示重启所述疑似异常的服务,并向所述第二服务发送重启记录指令,以使所述第二服务将所述疑似异常的服务正在重启的情况进行记录。
8.如权利要求1所述的方法,其特征在于,所述拓扑结构为环状拓扑结构;在所述环状拓扑结构中,每一服务和沿所述环状拓扑结构中第一方向相邻的上一服务组成所述对应关系;
所述第一服务判断心跳信息的接收情况是否异常,包括:
所述第一服务判断在设定的心跳检测时间点是否接收到沿所述环状拓扑结构中第一方向上与所述第一服务相邻的上一服务发送的心跳信息;
若接收到,则所述第一服务判定心跳信息的接收情况正常;
若未接收到,则所述第一服务判定心跳信息的接收情况出现异常;
若所述第一服务判定心跳信息的接收情况出现异常,所述第一服务判断所述第一服务对应的其他服务中是否出现异常的服务,包括:
所述第一服务判定沿所述环状拓扑结构中第一方向上与所述第一服务相邻的上一服务出现异常。
9.一种服务节点,其特征在于,所述服务节点运行有第一服务,所述第一服务与多个其他服务共同构成拓扑结构;
所述拓扑结构包含的每个服务与其他至少一个服务建立有对应关系,且每个服务用于接收该服务对应的其他服务发送的心跳信息,对该服务所对应的其他服务进行异常检测;
所述服务节点包括:
判断模块,用于判断所述第一服务接收心跳信息的情况是否异常;
处理模块,用于若确定所述第一服务接收心跳信息的情况出现异常,则判断所述第一服务对应的其他服务中是否出现异常的服务。
10.一种服务器,其特征在于,包括:
存储器,用于存储一个或多个程序;
处理器;
当所述一个或多个程序被所述处理器执行时,实现如权利要求1-8中任一项所述的方法。
11.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该计算机程序被处理器执行时实现如权利要求1-8中任一项所述的方法。
CN201910649658.8A 2019-07-18 2019-07-18 服务监控方法、服务节点、服务器及计算机可读存储介质 Active CN110417586B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910649658.8A CN110417586B (zh) 2019-07-18 2019-07-18 服务监控方法、服务节点、服务器及计算机可读存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910649658.8A CN110417586B (zh) 2019-07-18 2019-07-18 服务监控方法、服务节点、服务器及计算机可读存储介质

Publications (2)

Publication Number Publication Date
CN110417586A true CN110417586A (zh) 2019-11-05
CN110417586B CN110417586B (zh) 2022-04-08

Family

ID=68361945

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910649658.8A Active CN110417586B (zh) 2019-07-18 2019-07-18 服务监控方法、服务节点、服务器及计算机可读存储介质

Country Status (1)

Country Link
CN (1) CN110417586B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111651294A (zh) * 2020-05-13 2020-09-11 浙江华创视讯科技有限公司 一种节点异常检测方法及装置
CN113645102A (zh) * 2021-10-14 2021-11-12 腾讯科技(深圳)有限公司 路由收敛时间的确定方法及装置
CN114189464A (zh) * 2021-11-24 2022-03-15 国能大渡河瀑布沟发电有限公司 一种电力监控***通讯异常监测报警方法
WO2022199229A1 (zh) * 2021-03-25 2022-09-29 北京金山云网络技术有限公司 悬挂事务巡检方法和装置、电子设备和存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102215123A (zh) * 2011-06-07 2011-10-12 南京邮电大学 基于多环网络拓扑结构的大规模集群***
CN103763155A (zh) * 2014-01-24 2014-04-30 国家电网公司 分布式云存储***多服务心跳监测方法
CN104811325A (zh) * 2014-01-24 2015-07-29 华为技术有限公司 一种集群节点控制器监控方法、相关装置以及控制器
CN107733684A (zh) * 2017-08-31 2018-02-23 北京宇航***工程研究所 一种基于龙芯处理器的多控制器计算冗余集群
CN109361525A (zh) * 2018-10-25 2019-02-19 珠海派诺科技股份有限公司 重启分布式部署多服务的方法、装置、控制终端及介质
CN109714183A (zh) * 2017-10-26 2019-05-03 阿里巴巴集团控股有限公司 一种集群中的数据处理方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102215123A (zh) * 2011-06-07 2011-10-12 南京邮电大学 基于多环网络拓扑结构的大规模集群***
CN103763155A (zh) * 2014-01-24 2014-04-30 国家电网公司 分布式云存储***多服务心跳监测方法
CN104811325A (zh) * 2014-01-24 2015-07-29 华为技术有限公司 一种集群节点控制器监控方法、相关装置以及控制器
CN107733684A (zh) * 2017-08-31 2018-02-23 北京宇航***工程研究所 一种基于龙芯处理器的多控制器计算冗余集群
CN109714183A (zh) * 2017-10-26 2019-05-03 阿里巴巴集团控股有限公司 一种集群中的数据处理方法及装置
CN109361525A (zh) * 2018-10-25 2019-02-19 珠海派诺科技股份有限公司 重启分布式部署多服务的方法、装置、控制终端及介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111651294A (zh) * 2020-05-13 2020-09-11 浙江华创视讯科技有限公司 一种节点异常检测方法及装置
WO2022199229A1 (zh) * 2021-03-25 2022-09-29 北京金山云网络技术有限公司 悬挂事务巡检方法和装置、电子设备和存储介质
CN113645102A (zh) * 2021-10-14 2021-11-12 腾讯科技(深圳)有限公司 路由收敛时间的确定方法及装置
CN113645102B (zh) * 2021-10-14 2022-02-08 腾讯科技(深圳)有限公司 路由收敛时间的确定方法及装置
CN114189464A (zh) * 2021-11-24 2022-03-15 国能大渡河瀑布沟发电有限公司 一种电力监控***通讯异常监测报警方法

Also Published As

Publication number Publication date
CN110417586B (zh) 2022-04-08

Similar Documents

Publication Publication Date Title
CN110417586A (zh) 服务监控方法、服务节点、服务器及计算机可读存储介质
CN104615497B (zh) 一种线程挂起的处理方法及装置
CN110213068B (zh) 一种消息中间件的监控方法及相关设备
CN105610648B (zh) 一种运维监控数据的采集方法及服务器
CN104834582B (zh) 一种监控事件展示方法
CN106940677A (zh) 一种应用日志数据告警方法及装置
CN103117879A (zh) 一种计算机硬件运行参数网络监测***
US20130055271A1 (en) Apparatus and method for controlling polling
CN111143167B (zh) 用于多平台的告警归并方法及装置、设备、存储介质
CN108459944A (zh) ***运行监控方法、装置及服务器
CN110502326A (zh) 基于故障检测的云服务调度与恢复的方法及终端设备
CN110196780B (zh) 确定服务器状态的方法、装置、存储介质和电子装置
CN112650642A (zh) 一种告警处理方法及装置、设备、存储介质
CN114091610A (zh) 智能决策方法及装置
CN114356499A (zh) Kubernetes集群告警根因分析方法及装置
CN113364628A (zh) 服务器与交换机拓扑关系建立方法及设备
CN114070711A (zh) 告警信息的处理方法、装置、电子设备及存储介质
CN106487597A (zh) 一种基于Zookeeper的服务监控***和方法
CN112272106A (zh) 一种多站点数据同步异常告警方法、装置、设备、产品
CN112860504A (zh) 监控方法及装置、计算机存储介质、电子设备
CN110750425A (zh) 数据库监控方法、装置、***和存储介质
CN114827168A (zh) 告警聚合上报方法、装置、计算机设备及存储介质
CN105357026B (zh) 一种资源信息收集方法和计算节点
CN111209333B (zh) 数据更新方法、装置、终端及存储介质
CN112260902A (zh) 网络设备监控方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant