[发明专利]一种拨测方法、装置、存储介质及芯片

说明书

本申请提供一种拨测方法、装置、存储介质及芯片，该方法包括：调用链系统中的应用性能监测节点在接收到全链路拨测指令后，可以确定包含多个拨测子用例的全链路拨测用例，其中，每个拨测子用例用于指示该拨测子用例对应的第一服务节点对第二服务节点执行拨测处理，第一服务节点与第二服务节点通过链路连接；应用性能监测节点将全链路拨测用例中的每个拨测子用例分别发送到对应的第一服务节点后，接收每个第一服务节点发送的拨测处理结果；其中，任一个第一服务节点发送的拨测处理结果包含：第一服务节点对第二服务节点进行拨测处理的时间和拨测状态。通过该方法，能够实现对整个调用链系统进行全链路的自动拨测，节省大量的人力成本。

技术领域

本申请涉及服务可用性检测领域，特别涉及一种拨测方法、装置、存储介质及芯片。

背景技术

在给定的时间段内，服务(service)可用的时间所占百分比，即为服务的可用性。服务可用性是衡量服务质量和稳定性的关键指标之一。而拨测(dial test)是一种常用的检测服务可用性的技术手段。拨测是指定时对服务对外提供的应用程序接口(applicationprogramming interface，API)进行调用，并在调用出现问题的时候及时报警。通过执行拨测可以在服务出现问题时，系统能够及时的发现并修复，减少服务的不可用时长。

微服务架构为是一项在云中部署应用和服务的新技术，其本质是把整体的业务拆分成多个明确特定功能的服务。微服务架构目前已经成为了服务架构的主流模式。现有的拨测方式，对微服务架构下的一个API调用的背后，往往是一个涉及多个微服务的复杂调用链。因此该情况下容易出现以下几个问题：

一、现有通过手动针对各个微服务架构中的各个微服务进行拨测用例的配置十分耗时且流程繁杂，容易出现遗漏。

二、在使用微服务架构对外提供的应用程序接口API进行拨测失败时，难以给出导致拨测失败的根本原因，即，无法确定到底是微服务架构下的哪个微服务出现异常，需要根据调用关系逐个排查。

三、难以对故障进行定界，若某个微服务在一段时间内出现了问题，通过现有的拨测方式虽然监控并解决了故障问题，但在具体的故障定界时无法进行举证。

有鉴于此，急需提出一种针对微服务架构场景下的拨测方法，从而能够实现对整个调用链进行全链路的自动拨测，确保拨测的全面性，提高拨测的速度和质量。

发明内容

本申请提供一种拨测方法、装置、存储介质及芯片，用于实现对整个调用链进行全链路的自动拨测，确保拨测的全面性，提高拨测的速度和质量。

第一方面，本申请实施例提供一种拨测方法，该方法包括如下步骤：

接收全链路拨测指令，根据所述全链路拨测指令，确定全链路拨测用例；其中，所述全链路拨测用例中包含多个拨测子用例，每个拨测子用例用于指示该拨测子用例对应的第一服务节点对第二服务节点执行拨测处理；所述第一服务节点与所述第二服务节点通过链路连接；将所述全链路拨测用例中的多个拨测子用例分别发送到多个第一服务节点；所述多个拨测子用例与所述多个第一服务节点一一对应；接收所述多个第一服务节点发送的拨测处理结果；其中，任一个第一服务节点发送的拨测处理结果包含：所述第一服务节点对第二服务节点进行拨测处理的时间和拨测状态。

通过该方法，能够解决现有微服务架构场景下的拨测方法，无法自动的对整个调用链系统进行全链路拨测的问题。由多个拨测子用例构成全链路拨测用例，从而实现对整个调用链系统进行全链路的自动拨测，节省大量的人力成本。

在一些可能的实施方式中，根据所述全链路拨测指令，获取所述调用链系统的历史访问记录；所述历史访问记录包括：调用链标识、被调用服务节点的父标识符、调用服务节点的子标识符中的任一或任多种；根据所述历史访问记录，确定所述调用链系统中各个服务节点之间的链路连接关系；根据所述调用链系统中各个服务节点之间的链路连接关系，生成全链路拨测用例。